Category: Tech

One new developer at Socialtext recommended Skype, and suddenly 9 people were Skyping. At the same time, I opened the box on my cute little Plantronics headset phone for the landline.
Skype is two parts good — free, excellent voice quality when it works — and one part annoying — “are you there, are you there.” Suddenly, I can talk on the phone from the local wireless cafes (the cell was unbearable with the background noise). It’s fun being a small part of a network adoption trend — watching a technology adopted, one group at a time.
And I live in a tangle of headphone cords. I almost never have the right headphone on, or near to hand. “Wait, let me get that headphone…” (trips across home office). The headphone cords have an unnatural fondness for each other, the phone cord, and the laptop power cord. I impersonate the fates, weaving and unweaving the destiny of the world, except unravelling and untangling the headset cords. When everything is untangled, I think the world will end.
*The landline is wired — I gave up on cordless after years of phones that didn’t quite work, with battery life that didn’t support working with a distributed team.

Dan Hunter’s article arguing that open source development is a form of contemporary Marxism led me to read Coase’s Penguin, the classic paper by Yochai Benkler that provides an economic explanation of open source software and other peer production endeavors like Wikipedia.
Marxism argues in favor of collective production and against monetary rewards out of political belief that capitalism is inherently exploitative. The way to ensure a just society is collective production where production is organized and rewards are distributed fairly through central planning. But centrally planned collective production proved inefficient and corrupt.
The first puzzle about open source peer production isn’t whether or not developers have marxist political beliefs, but why it works, especially since the Marxist collective model failed miserably.
This is what Benkler explains elegantly. Coase’s Penguin builds on the theory of Ronald Coase, who explained in the 30s that firms exist when the cost of separate transactions with many independent parties is greater than the price-efficiency of a competitive market. The problem Coase was trying to solve at the time was to explain the persistance and dramatic growth of centrally managed corporations, if a market is an ideal way to allocate economic resources.
Benkler solves today’s version of the same problem. If money is the ideal way to incent and co-ordinate production, why are we seeing the persistence and dramatic growth of production methods that don’t use money?
Benkler explains that commons-based peer production is more efficient than either firms or markets for information goods, where the costs of communication and distribution are low, and the difficult problem is allocating human creativity. When there are masses of potential contributors, and it’s easy to participate in little chunks like an open source plugin or a wikipedia article, the best way match skills and work is a million little decisions by independent contributors.
Mandatory, Marxist-style collective farming doesn’t benefit from these resource allocation efficiencies. Workers on collective farms have pre-defined work and can’t leave. Collective farms don’t gain the benefit of unique, voluntary contributions by thousands of distributed workers.
Another attribute of political marxism is an belief in mandatory equality. Peer production projects often have a meritocratic culture with dramatic inequality, where founding leaders and high-value contributors have greater prestige, influence, and sometimes financial reward. It’s not considered inherently unjust that leaders of open source projects like Perl and Python have received grant, foundation, and corporate funding to do their work (although visible leaders of peer projects can also become lightning rods for criticism).
Another marxist value is opposition to a money economy. Cash is seen as a symptom of the alienation of workers from the products that result from their labors.
Clearly, the motivation of many thousands of open source, wikipedia, livejournal, and other peer content producers is non-monetary. But is it anti-monetary?
Benkler deals with the incentive question in the excellent third section of Coases Penguin. Benkler makes an astute distinction between activities where money is commonly thought to be an inverse motivation (sex), and where it is seen as complementary (sports, music). Many people who like basketball would love to be NBA stars. By contrast, most people who like sex would not like to be prostitutes.
Some Free Software activists are in fact marxists, with beliefs that money is inherently exploitative, and visions of a world that is socially and economically organized without money.
The GPL license, a strict license that forbids the redistribution of modified code with a nonfree license, doesn’t forbid selling the software in a package, or customizing software for money, or selling services based on knowledge of open source tools.
For many people, software development is pretty clearly in the complementary category, where the rewards of prestige and satisfaction coexist with monetary rewards. There are Apache developers on corporate payrolls, and companies supporting open source technologies, ranging from IBM to MySQL, Zope, and Jabber. There are developers who make a living consulting based on free software expertise.
So, while some software developers are marxists, it doesn’t follow that peer production is inherently Marxist.

Socialtext loves to hire developers with open source experience and reputation. We know people are good developers. We know they have initiative and have gotten things done. We know they have creative ideas, because thos ideas are public. People who’ve been active in open source have a public community reputation.
And I’m beginning to think that it is a great way to do the R part of R&D. One of the big problems with classic corporate R&D is that innovations don’t see the light of day. The typical corporate reaction is to put researchers on a short leash, and tell them their blue-sky research needs to turn into a commercial product in a finite amount of time.
An alternative approach is to do open source experimentation. If the experiment is interesting and valuable, it will attract other developers. So you’re building an ecosystem from the start rather than stifling it. If it works and seems valuable, you can package and develop and commercialize it — or leave it to an independent noncommercial life.
It increases one risk, because new ideas aren’t secret. It decreases the risk of developing products in the lab that don’t ever work or get done or find users.

John Koenig has a nice article in the IT Manager’s Journal listing seven open source business models: Optimization, Dual License, Consulting, Subscription, Patronage, Hosted, and Embedded.
From the perspective of software developers, however, there are only two. Patronage works for individual developers who are so brilliant, innovative and famous that a corporation or foundation will hire them to do whatever it is they do next. A few people merit this approach.
All of the other business models are based on a single principle — provide software and services that someone else wants. The stereotypical open source model is to “scratch your own itch” – build software that you want. That is a powerful motivation that gets a lot of software built.
But if you want to make money, you need to do something that somebody else wants, and that is valuable enough that they’re willing to pay you to do it. That something could be optimization, custom consulting, service and support, or a packaged product that uses your code (Koenig’s list). There’s also a patronage model that’s at the level of a project, not an individual — IBM’s sponsorship of Apache fits this model. In this case, the sponsor is paying for ongoing development and maintenance.
The solipsistic/bohemian model of open source — artists make software only for other artists, and talk only to other artists — falls short if those artists are looking to make a living. Unless you’re one of a handful of superstars, you need to provide a product or service that’s of immediate value to someone else.

I wish it was available now. I would pay.
As is, I don’t watch enough television to subscribe to cable. Just not in the habit. I watch series’ occasionally on video.
As is, Bittorrent will do. I’d rather pay for reliable, high-quality, scheduled delivery, and compensate Jon Stewart.
I hope the industry takes this opportunity instead of suing it out of existence.

.. when you hand people a complex tool like a computer, the variation in what they can do with it is enormous. That’s not a new idea. Fred Brooks wrote about it in 1974, and the study he quoted was published in 1968. But I think he underestimated the variation between programmers. He wrote about productivity in lines of code: the best programmers can solve a given problem in a tenth the time.
But what if the problem isn’t given? In programming, as in many fields, the hard part isn’t solving problems, but deciding what problems to solve. Imagination is hard to measure, but in practice it dominates the kind of productivity that’s measured in lines of code.
My favorite quote from Paul Graham‘s essay, based on his OSCON talk and book, Hackers and Painters. I need to go read the book, carrying questions about the craft vs manufacturing models of software development.
The article also repeats some unhelpful stereotypes about hacker’s lack of empathy. Graham appreciates the Mac and Google as examples of beauty. But he also describes the natural habitat of the geek as tools rather than applications.
Graham suggests optimizing a tech company’s development process by sic’ing the best developers on infrastructure, far away from customer applications. “have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications.”
Graham says that hacker’s hate having to “customize something for an individual client’s complex and ill-defined needs.” To use Martin Fowler’s image of “bad smells in code” that hint at poor design, this is a bad smell that suggests poor account management — somebody on the developer’s team hasn’t done the hard work of understanding the customer’s needs, and helping the customer prioritize. (though it is a genuine problem sometimes — customer truly is internally conflicted, hopelessly confused, and is impossible to please.)
The stereotype isn’t 100% right — there are counterexamples of software developers with empathy — but Graham echoes the cultural prestige given to hackers who stay the furthest away from the people who use their work.

Thanks to the techs at PC Guru on South Lamar, and no thanks to Fujitsu. The inside portion of the power connector was loose and needed resoldering. I needed to hold the power cord at an angle just so to keep it from depowering, and it didn’t seem that far from not working at all.
I called Fujitsu tech support. The repair would take 5-7 days. The guy on the service line wanted a deposit of $100, and said the repair would be up to $600, if they determined I did anything that broke warranty.
And the kicker — they wanted advance permission to reformat the hard drive. “Why on earth do you want to reformat the hard drive?” “We want to do the best possible job at warranty service. ” “Sure, we’ll mow the lawn. Please give us advance permission to cut down the trees if we need to.”
At PC Guru, the repair was $120 with one-day turnaround. Nobody threatened to reformat the hard drive. What a pleasure to deal with real live geeks, who chat about Linux in the background, and are authorized to use their brain on the job.

John Udell laments the tendency for vendors, including Macromedia, Microsoft, and Apple to hype next-generation graphics capabilities with tasty eye candy that doesn’t help users create valuable visualizations, and doesn’t give users a compelling reason to use the technology.
Udell cites Tufte as the guru of graphic communication, suggests the need for easier-to-use new tools. But tools are only part of the answer. Nifty visualization tools have underperformed for about fifteen years that I’ve noticed.
It’s not enough to show pretty pictures — you need to have something to say. Tufte’s perennial complaint is “Chart Junk” — frivolous pictures that don’t say anything. Powerpoint and friends enabled people to make pointless pretty pictures long before the current generation of graphical infrastructure. People don’t know how to tell compelling and meaningful stories with visualizations.
A word processor doesn’t make eloquent prose on its own — and graphical tool tool won’t create meaningful visualizations.
In the social network analysis of Ziff Davis Media, we started with a story — teams of writers, editors, developers, and marketers collaborating across space and group boundaries — and questions about the intensity and frequency of collaboration.
Here’s the picture . And the story.

The two liveliest software development models are open source and agile.
In some ways, these models are orthogonal. Open source is primarily a licensing model. Open source projects can use agile practices — short cycles, test-first, pairing — or they can have long cycles with compartmentalized development. Agile is a set of development methods which can be used with open or proprietary licences.
In another way, they seem to conflict. Classic open source projects are put together by programmers seeking to “scratch their own itch”. Agile projects are oriented around meeting the needs of a customer.
Agile projects bring the customer on the team; make the customer responsible for setting priorities; develop shared understanding of requirements with conversations remembered as stories. The best way to make sure customers get what they want is to give them software soon, and let them respond to real stuff.
By contrast traditional development processes formalize customer requirements in long, structured requirements documents, which get delivered in big lumps of software. The goal of management during the development cycle is to fend off changing customer requests.
The extreme open source position contends that software developers won’t ever develop for other people unless they have to. This can be explained as Asperger’s — a physiological lack of empathy. Or it can be explained as a Romantic/Bohemian view of artistry — true artists paint and poets write for themselves and their muse, and their small group of starving but virtuously anti-bourgeois friends.
The extremes are wrong. Introversion isn’t “better”, open source doesn’t have to be solipsistic, and development for money doesn’t have to be corrupt.
Introversion isn’t better I think that the Romantic view of open source software is as fallacious in software as it is in art. Artists have always had relationships with audiences — Homer was a storyteller, Shakespeare was a crowd-pleaser. There are always “artists’ artists” — those whose work is difficult and revered by the cogniscenti. Software made for customers isn’t guaranteed to be bad any more than art made for audiences.
Open source can have empathy The goodness of the Mozilla project disproves the notion that open source projects make software that only ubergeeks love. The Mozilla crew are building lovely software — see the Scott Collins interview over at Ars Technica.
Commercial development can have integrity Agile development practices are intended to work around structural temptations for commercial projects to be build on lies. First, salespeople lie — they promise things to customers without listening or wanting to believe developers about how long things take. Then, developers lie. Out of eagerness to please or fear, they tell management and sales what they want to hear. Reality intrudes eventually. Customers get mad. Really mad customers sue. Agile planning is based on continual delivery and continual conversation, to avoid the built-in temptations for lies and self-deception.
Money communicates priorities When people are developing for others, money focuses attention. When customers want things that don’t yet exist, dollars vote. Willingness to pay focuses the mind of the customer on what’s important to them, and the developer on what’s important to the customer.
What do you think?

And the other services that require human intervention before an email address is whitelisted.
Don’t folks realize that they have anti-network effects? They’ll work for the first few people who use them. But what happens when a mailblock bounce comes back to another mailblock service?
People will have to wait for the singularity to get their email.