… Google no longer provides automatic links to the definition of search terms that end in S … Gary speculates, among other possibilites that “At Google’s heart, the regex !^(?i)[a-z]+s*$ has lost a slash, banning all pluralization!”
via Mr. Weinberger
Meanwhile 5 kind people have provided fixes for typos on my blog in the first 12 hours. Thanks!
Jamie is one of my heros and he sure can write, but I’m not impressed by his recent fun raining on the parade of his friend’s open source groupware project. All he’s doing in his fun rant is revealing his loyalty to a world view that treats groups as so vile the only exception to the rule is getting laid and or just possibly going out to dinner with friends. We have milked that stone dry. The PC revolution was two damn decades ago. Get your hands out of your pocket. Playing with your handheld will make you go blind.
Groupware is not about empowering the lord’s castrate to chase check boxes around conference room tables. Groupware is about collegiality. Groupware is about focusing common cause. Groupware is about manufacturing abundance from the aggregated contributions of the many. Groupware is about creating a vibrant scale free civic society. Groupware is about searching the space of solutions to the all the corrosive forces that destroy civility. Groupware is about turning coordination problems into dance square dancing.
This is were the excitement is. This where wikis, and del.icio.us, and flikr, and meet up, and open source, and yahoo groups, and mailing lists, and discussion boards, and peer to peer, and file sharing, and voice IP, are. This is the single most fun real estate the Internet has enabled.
On this one, Jamie is just plain wrong. The dialectic is not between project managers and the noble free spirited creative individual. The dialectic here is between those forces that kill groups and those that make them thrive. Groupware is a tool in that battle. Dilbert’s coworkers are as much a threat to vibrant groups as Dilbert’s boss. Getting laid is not the goal. Raising the babies of common cause is the goal.
In my father’s day every scientist and engineer paid a regular tax to CRC for access to his table of logarithms, etc. His copy of that book which he gave me when I went off to engineering school is so worn that he rebound it in a piece of cordoroy. These days many pay a tax to Wolfram for something analogous. So that CRC considers Wolfram a very threatening competitor shouldn’t surprise anybody.
What a sad story! It’s really amazing how common this pattern is; a public good emerges. A private entity finds a means to gain ownership of it. Private entity then proceeds to destroy the public good. It’s enough to make you adopt the GNU license.
Ted put’s it well.
So, the next time you hear “open source development”, think “the most economically efficient method for matching resources to construct information products”. The next time you see “XXX Software Foundation”, think “people constructing a software commons (protected by intellectual property laws) that the rest of use can use and extend”. There are more things that you should think, but that’s enough for one post.
Matthew Langham over at The Silent Penguin stirs the pot with a seemingly radical idea: Opening the business plan?
Absolutely!
Consider this list from Michael Porter. It enumerates reasons why firms in an industry remain fragmented. For example if most of the value your firm creates comes from personal service there is little benefit to be gained from merging a number of such firms into one big firm. It’s a good list.
In a stable fragmented industry the firms are safe in their niche. Porter goes on to mention that fragmented industries are more collegial – which I read to be a sign of open collaboration. Of course competition is only one reason why actors like to keep their privacy. Just to give one example – fear of embarrassment is a good reason to retain a lot of privacy.
That leads me to assume that members of a fragmented industry can be substantially more open about their business with each other. If the firm has three functions, A, B, C and A is such that it keeps the industry fragmented the firms can collaborate on how to execute on all three functions because improvements in any of these functions don’t lead to increased competition.
It appears that this would lead to a situation where fragmented industries are much more creative than concentrated one. The N firms in a fragmented industry each search for innovations independently. Their search is informed by close contact with the customer/problem. When ever they discover some improvement, or even an idea for an improvement, they take it back to one or more of the industry forums and “trade it” or throw it into the collective pot. This process tends to the practical.
Highly concentrated industries who fear the other members of the industry have a harder time doing that and they have to adopt the R&D lab approach for seeking innovation. That tends to ivory tower irrelevance.
What bemuses me is that standard rules of engagement in a concentrated industry encourage keeping secrets. There, knowledge exchange with peer firms is a sin. Meanwhile, members of fragmented industries are convivially exchanging knowledge because it’s vital to their rapid evolution.
This all blows up in your face when somebody discovers a way to consolidate an industry that is currently fragmented. When Home Depot or Staples, to take two examples, rolls up the hardware and stationary store businesses for example.
Way way back in the 1960s the university where I used to punch cards and hand them thru the little window to run my batch jobs bought a new computer. The disk drive was so massive that when they brought it into the building the drive grazed the edge of the door way knocking off the frame and a few rows of concrete block. The drive was undamaged.
Shortly after that machine arrived a guy showed up. An hour later the machine ran much faster. Apparently the salesman had recommended him. The machine was the low end model and if you wanted it to behave like the high end model all you needed to do was cut a resistor or something.
Apple segments their market for the MacOS into three bundles: Darwin, MacOS (client), and MacOS (server). The function of segmented marketing for a vendor is to capture more of the revenue/benefit available below the willingness to pay curve. Given that most markets have a few customers who will pay a lot (desperate customers, rich customers, etc.) you want to have a product variant that you can sell them.
At the other end of the spectrum you get customers who have little willingness to pay; a cheap product offering may capture some value even from those guys. Network effects make things more complex. The customers willing to pay nothing may still add value for the vendor; by increasing his network and thus attracting other customers with deeper pockets. This creates the curious effect that some markets the right price point for the low end product is free – it’s not actually free the customer is bringing himself to the party as payment.
The practical advice given to vendors about segmenting a product line is to be very careful to watch costs. If your lucky the expensive product should cost little more to make and distribute than the mid-priced product. That advise leads to the common stories folks tell about computers who’s speed could be doubled by cutting a resistor. Back at the vendor the discussions about what to bundle with each version of a segmented product are painful for people with ethics. Once you work thru the ethical puzzles there is actually a very interesting design puzzle in designing segmented products – i.e. how to assure that you capture the maximum network effects across the whole product line. If you get it wrong the segmented products start evolve into distinct specie and you get three separate markets. That’s already happened to Apple between Darwin and MacOS(client).
Another problem, though generally a small one, is that some clever user discovers how to cut the resistor. Suddenly their expensive product is just as good as the mid-priced offering. This tends to be more an embarrassment than a revenue problem. I own a big fat phone, a Treo, and the geek community around it keeps working around all the functionally limits that it’s vendor was forced to stick into because his real customer are the phone companies, not the end users.
The story from my youth has another chapter. At the time I was told that the reason for resistor cutting guy was that early customers of that line of machines had written into their purchase contracts a clause along these lines. Sure we will pay a huge amount for the first few of this machine, but latter if you succeed in selling a large number and your prices fall we require you to give us a refund of the price difference. The vendor was dodging the clause in the contract by creating a lower price segment in his market and then leaking the recipe to enhance the model back toward the original model.
Recent events in the around the Treo (a hack to enable bluetooth data, and a hack to enable wifi support) reminded me of that story; and then this morning I say this neat trick to let me get some of the features of MacOS(server) to work on my MacOS(client).
When these hacks for breaking down the barriers between a vendor’s segmented market emerge it’s always interesting to think thru what might be the motivation. Is it just some hacker having a good time? Maybe it’s the vendor trying trying to assure he gets the maximum network to emerge around his product. Maybe it arose out of the vendor’s cost saving. Maybe the vendor is trying to work around customers who’s goals are not in synch with your best interests (as in the two examples above). All these and other reasons are likely in play which makes the stories more interesting, but harder to tell.
Moments such as when Archduke Franz Ferdinand or John F. Kennedy got shot are oft considered so significant a fork in the road that people expend pages imagining alternate histories. I can’t help thinking that today we are at just such a moment. Consider this quote from the New York Times article that appeared as part of the PR campaign around Google’s plan to scan the collections of some of the major libraries.
“Within two decades, most of the world’s knowledge will be digitized and available, one hopes for free reading on the Internet, just as there is free reading in libraries today,” said Michael A. Keller, Stanford University’s head librarian.
Can you see what’s horribly wrong with that sentence?
The steward of one of the worlds richest repositories of human knowledge says “one hopes for free.” In effect he’s saying that no, the deal does not assure that.
I would love to be convinced that these librarians didn’t do what I think they did, but it looks to me like they just sold their collections to Google for cheap. It appears that they taken the public good that they, their predecessors, their donors, and their institutions, all of mankind have labored to create and assemble over the millennium and handed it over into private ownership.
I’m sure that the folks at Google are the nicest people, but that knowledge is mankind’s, and it shouldn’t be a matter of “hope” that it be available for free. If there is one lesson that open source has taught us it’s that it is surprisingly easy to capture a public good by the adding of the smallest bits of technology.
If my fears are well founded then this is a very black day in mankind’s history.
“Culture of Asynchronous Communication” was for many years a cornerstone of open source development. It’s notable how little analysis has gone into that. Most open source projects are coordinated with amazingly low bandwidth and extremely high latency. This is often one of the most difficult cultural conventions for people emigrating in from other software subcultures.
One neat, but certainly unintended, consequence of that was it created an audit trail that social scientists could pick apart.
We do not know if this is a necessary element to a high functioning open source project. Is there a sweet spot in the space of bandwidth and latency? What aspects of the task domain shift the location of that sweet spot?
I am confident there is a complement to Brook’s insight that “Assigning more programmers to a project running behind schedule, could actually make it even more late.”
Adding more bandwidth and lowering latency to collaborative work can make it less collaborative.
This posting is about two things. I can’t or I uncomfortable with teasing them apart. One part is about how a firm blocks out the choice to add a feature versus how an open source project makes the same choice. For example if we have the bundle of software used to run a handheld computer and are are trying to decide about adding a Postscript viewer to the bundle.
The second aspect is about network effects. In our example if the viewer is added to the base system it will create a much stronger network. That results in an interesting tension in the community around our example handheld. One camp would love to see the addition of a viewer while another camp is ambivalent. Call these camp A and camp B. The tension arises because it’s a lot more fun for camp A if the entire community gets the new feature. If camp B doesn’t get the viewer then camp A won’t be able to casually exchange their Postscript files with the entire community.
Rereading Oz Shy’s wonderful little book on network effects triggered this posting. He outlines a market failure where a firm fails to reach customers with a cool feature because the firm can’t figure out how to structure their pricing so that camp A pays for the viewer while camp B doesn’t.
I’m often asked by clients if open source can help them create a network they desire. So I got to wondering about the analogy between Shy’s example and open source scenarios.
So let’s try to map his example onto an the analagous situation in an open source project.
The commerical vendor does a cost/benefit calculation. It costs so much to add the feature, and so they need to raise prices or market by a certain amount to justify the effort. The analogy in open source is that you need to find a team, call it team X, who desire the feature sufficently to cooperate to add the project.
In Shy’s example the two camps are have different willingness to pay for the feature; i.e. we have a demand curve with a step function. One camp has high willingness to pay and the other has low or zero. Team X, in the open source, case is analagous to camp A; but different.
When I read Shy’s point about how the firm has a pricing problem my first thought was: “Ok, what’s the demand curve really look like? Are there some extremely desperate folks in camp A?” Because if there are just a few desperate folks they may be willing to pay for the firm to do the whole work and then give it away to the entire installed base. For example it is possible to image a handheld firm finding a single fortune 500 company that would be willing to write them a check to do the work. That depends on the shape of the demand curve.
Folks unfamiliar with open source often assume that Team X is an extreme form of camp A. They assume team X must be really desperate since they are willing to build it! That’s not entirely true, rarely true in my experiance. In many cases Team X is unique not in their willingness to pay but rather in how easy it is for them to build it. They have extreme talent (of a very narrow kind) as a substitute for extreme desire.
That’s important. It means that your drawing the members from team X out of a population distribution that suprisingly independent from the one that was simplified into camp A and camp B.
Either high desire, or low cost increase the probablity that a member of the project community will join a collaborative attempt to add the feature.
The standard way to visualize willingness to pay is a demand curve and we can draw a similar picture for talent to implement (and other skills that increase the chance that team X succeeds). Unlike your typical economics text book these curves are not straight lines. The forture 500 company above illustrates that. I suspect these curve are typically power law in form.
You still get failures analagous to Shy’s pricing problem. First you get failures becaue getting Team X to form is hard – i.e. finding elite members of the desire population and the talent population isn’t trivial. The open source project provides a point of rendezvous but it doesn’t necessarilly engage in directed search for oportunities with the same focus that a firm is assumed to.
The second stage of the analogy comes from returning to the issue of the network effect. Members of team X desire a large network as do members of camp A. They are seeking a distribution channel that can give them a means to that end. The open source project offers the option of getting that. Gaining a chance to try and exercise that option pulls team X together. This substitutes for the commerical firm’s directed search for features that will make them money.
For the commercial firm a feature with network effect is a pricing problem; for an open source project a feature with network effect is a team builder.
Cool, Laszlo has played the open card.
I am not surprised, but I am very pleased.
It’s tough creating the buzz of activity and complements around a tool like Laszlo. Worse, if you don’t create that good-olde network effect then your stuck. You maybe able to have a certain level of success but that even that’s not durable over time.
Laszlo is a very elegant work. For example: play with the examples of constraints that appear on this page in the manual.
Opening up Laszlo could create bloom of new UI. There are some huge pools of data out there that could get a new presentation skin. Google, eBay, delicious, movable type, word press, … it’s not a short list. There are early examples of this kind of UI out there. Go look at flicker for example.
I had been hearing VC talk about how flash was going to disrupt the client side; i had been discounting that – self interested speakers an all that. I need to revisit that chatter.
Putting on my health of the industry hat, or my paranoid CTO hat, the thing I notice about Laszlo is the dependency on Flash. It really is amazing that the folks at Macromedia have managed to get such a huge piece of real estate on the installed base of client side machines. How did that slip past the guards at Microsoft! Adobe tried, with SVG, but that certainly didn’t work out. I tip my hat to them!
For years and years the GPL community was very careful to avoid standing on top of Motif because they didn’t perceive it as being sufficiently open. A similar careful critique should now be made of the Flash platform. We have suffered a lot because the client side fell into the hands of Microsoft; handing it over to Macromedia would be better but it wouldn’t necessarily be good.
Recently I have been looking at RDF. I blame Stefano. RDF strives to displace the HTML/XML as the canonical data model. That’s a tall order. HTML seized that turf because it was simple enough because it was presentation oriented. XML hides behind HTML’s success. RDF, well it’s not clear what “go to market” benefit is.
One of the wonders of the HTTP/HTML bloom has been how it created a huge amount of casual revealing of information. The presentation standard, HTML encourages casual revealing in a form that automation can swallow. This created the landscape (the platform) for the search engines. It’s not clear if that landscape will survive a transition to a richer presentation platform. Data hides behind UI. It’s not clear if that landscape will survive a transition to a richer data exchange protocol – particularly if it’s name is SOAP.
Data hides behind UI.