Recent commentator and remarkably cool guy, David Eaves, drew my attention to his article “Community Management as Open Source’s Core Competency.” It got me thinking about the properties of open source projects that make them successful.
Successful products are usually made by a tiny team of very focused individuals - in David Kelley parlance “hot teams”. Ideo is my favourite example of a company that is famous for its products but no one can name them. Ideo uses a hot teams which is pulls from various staff members, usually volunteers, to work on a project coming in. These teams never get huge - multiple hundreds of members are out of the question, yet the quality (and complexity) of their work is staggering.
The question I had to ask David Eaves was what was the definition of successful open source software? Ambitious programs that are complex and/or difficult that get made despite the odds? Applications that are very popular, used by millions of people? Applications that are innovative and way ahead of their time?
Firstly, I might point out that open source has serious problems with that last category. Open Source is the generics if software were pharmaceuticals, cheap knockoffs that cost less (or nothing) then the trend setting originals. Often because it’s difficult to generate the buy-in required to produce a product without precedent when you’re dealing with people giving their time away for free. If I were programming something at IBM that had never been made before and may not work at all, at least I can collect my pay cheque at the end of the day.
Secondly, when I think of an open source community I think of it in its totality - user groups, support areas, fan clubs, localization groups, feature-lobbyist organizations etc. The developers are just one part, a rather central part, of the group.
“Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package.”
This is a fascinating statement and I agree to it instinctively. However, this is analogous to saying GM is not a car company but an organization who owns factories and employs workers to happen to make cars. One could get more abstract and say that GM doesn’t make cars it makes money THROUGH cars. But that brings up an important distinction within open source, profit vs. non-profit.
Linux is non-profit in and of itself - Debian especially but many others - BSD for another. Firefox is designed to make revenue, as is RedHat’s use of Linux as a product to service. JBoss is supposed to make money. Sun Microsystems bets the bank on open source. To these groups, the software is about the money it can make - good software usually makes more money (certain applications from Redmond, WA excepted).
I’ve worked on several open source projects, even started and managed a few small ones. What I discovered is the diversity in how people derive utility from contributing to open source. Some like to experiment with new tech, others liked the nature of the project and wanted to see it succeed even if they didn’t use the product, others wanted to build a portfolio, etc. The most common reason, by far, though, was that contributors wanted a good piece of software they could use and keep for free - they didn’t want anything else available or were unwilling to pay for it. This is apparent when one notices the most common short comings of completely grassroots open source - hideous or absent documentation, poor/unintuitive interface design, useless support.
Oddly, I cannot recall anyone ever mentioning they wanted to be part of a community of like minded people as a reason to get involved in open source. It’s a valid reason, but one I haven’t stumbled across.
As far as commercial open source it’s obvious that the software itself isn’t used to generate revenue but things surrounding the service that do. This is old hat for technology markets - most PCs don’t actually generate profit but printers, mice, service plans and software do. The community needs to be fostered to keep the golden goose laying but this feeds back into the quality of the software.
Although, if the quality of the software were very high one might not feel the need to get involved in improving it whereas if the quality were below the obvious potential of the software you’d spark involvement.
One mustn’t forget that software development is not sweatshop labour - it’s not cheap nor is it something programmers would only do if paid. Even within companies development teams are treated more as communities than employees because these people could more readily quit and move on than a successful accountant, so the lessons learned there are just as important here and the problems described by Mr. Eaves are true even for small teams.
As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.
Poor software planning leads to situations like this, I don’t think it a by-product of developer mass (to use eXtreme vernacular). Whenever one designs software one must be clear about specification and definition. When a requirement is put in place it defines what an application must do in quantifiable terms. Someone should be able to sit there with the requirements and use the application and check off each item without any real judgment or inference required. The important part is what many forget, anything not in the requirements is NOT being developed - that’s why it’s kind of important to get requirements right and to work iteratively.
David Eaves articulates a sentiment I’ve felt since I’ve been involved in open source technology - even just as a user. There must be a more rigorous process of design and development, one that is involved, efficient and effective at producing great software. Just hit up sourceforge.net to get a taste of how even the best tools can be wasted on unmotivated teams.
I’m sure someone’s done it, but some Rational expert out there should concoct an Unified Process instance specifically geared for open source development.
What’s encouraging to me, was how Mr. Eaves and I articulate the same problem, that is poor leadership and communication, in two different ways - his issue is with community management and mine is with software design and engineering rigor. Shows that I’m not off my chump.