I had two interesting conversations today. One with Patrick Moran of NASA’s World Wind project, and one with Ryan Waite who works on Microsoft’s High Performance Computing platform. I’ll be posting the full transcripts in the future, but here are some random observations.
In Open Source, You Democratically Elect Your Dictator
You can choose to run Linux, or not. You can choose to use MySQL, or not. You can choose to run OpenOffice, or not. Whenever you choose a product, you’re throwing in with its dictator maintainer. In the case of the Linux kernel, that maintainer is very conservative about what goes into the kernel. Conversely, the Message Passing Interface (MPI) for high performance computing is pretty liberal about including new functions. At the end of the day, the maintainer decides what’s in and out.
What If Your Dictator Isn’t Enlightened Enough for You?
There is a check on the power of the dictator. In a worst-case scenario, the community can exercise the nuclear option of forking the product (with a new maintainer in charge of the fork). If successful, this deposes the original maintainer, but this can take a long time to shake out. These civil wars occur, but they’re not terribly common. If you run off with your own fork, you also have to woo much of the user and developer base over. This splits the resources available, making it harder for either version to get as much done. Despite the obstacles, forks happen, and sometimes over (apparently) trivial differences. Take the FireFox forks, for example. Gnuzilla IceWeasel removes the artwork and plug-ins which aren’t considered “free software”. The Debian IceWeasel also removes the FireFox branding . Take that, evil foxy overlords!
With Closed-Source, You Vote With Your Dollars
In the closed-source world, you evaluate different versions of costly software, and pick the one that’s the best fit. You probably also check out the open-source alternatives to see if one is “good enough”. If so, you’ve saved licensing fees, and you don’t have to fight to get a PO opened. Sometimes, there isn’t an open source product that works, so you purchase a solution from a vendor. In this case, vendors who can garner sufficient market share, at a high enough profit margin, grow. Others go out of business. In some markets, the water gets pretty red.
What If A Vendor Has A Monopoly?
Then (by definition) most people will choose that vendor’s product. There aren’t a lot of true monopolies, but there are areas where a certain vendor has the lion’s share of the market. Microsoft dominates the desktop operating system and office productivity applications. Google owns search. Adobe has a lock with the Portable Document Format. The LAMP stack is pretty popular for powering the Web. Today’s monopolies aren’t necessarily tomorrow’s. Dell is now selling systems with Linux. Microsoft is making in-roads into the High Performance Computing arena. FireFox nibbled away at Internet Explorer’s market share. It’s hard to get on top, and once there, it’s hard to stay on top. For just about any application, you have choices, and you’re not required to use the front-runner.
Open Source Improves Incrementally
Because open-source is built over a mailing list, there’s a focus on the most bang per line of code. Many of the patches make incremental improvements to the product. These patches accrete to form a release. Corporate sponsors may staff development efforts for larger undertakings, but even so, the delta between releases tends not to be huge. This greatly reduces the cost of upgrading to the latest and greatest, but it also reduces the incentive to upgrade because the latest release may not have many “must have” features. Often the “must haves” are critical bug fixes, which typically aren’t back-ported. If something really significant is going to happen in the open source world, it typically appears as something completely new, rather than an improvement to something existing.
Closed Source – Boil the Ocean
Vendors who sell products are often competing with their previous version. They are driven to pack big new features into each release to entice you to pay for the upgrade. Often vendors set off on massive “boil the ocean” improvements, which may ship and be wonderful, or may end up on the cutting room floor.
By Developers, for Developers
On many open source projects, you have to have the inspiration for a new feature, and the ability to code it. This effectively limits who can propose new features. A person building a new feature often builds exactly what they need, and they code it in the way that’s easiest for them to implement. If their need is common, the feature is a perfect fit. If their need is unique, then the feature is either rejected, or the product builds up esoteric behavior over time.
The Closed Source Leap of Faith
Because closed source products are trying to do something compelling for their next version, they often make big bets on what their customers will want. The people spec’ing the features are trying to get into the heads of the customers. The people spec’ing the features are not the people who will be coding those features. This can be benificial, as developers often code what’s easy, and can loose sight of the customer’s needs and ease of use concerns. If proprietary software vendors nail it, they can add value beyond what’s otherwise available. If they guess wrong, it’s a lot of development effort down the drain.
