Why Open Source Succeeds Where Offshore Fails

The Agile practice of keeping the whole team together has many benefits, and many people consider it essential part of any software development effort. But if this practice is so critical, how is it that open source projects, whose team members may never even meet each other in person, seem to be able to deliver working software? Through my experience as an agile coach, open source developer, and participant in many multi-location projects, I've developed some theories over the last few years that may explain this difference.

I haven't ever met a developer working on an open source project that didn't use the tool themselves. Open source projects all have an onsite customer...themselves. This means that the communication that does occur between developers is usually more of a debate about what the software should do, rather than simply a unidirectional communication of requirements. This has many benefits, not the least of which is the fostering of bi-directional communication. If a commercial developer misunderstands a requirement, and the effort required to clarify it is too high, they might say "well, that seems silly, but I guess it's what they want" and implement it incorrectly. If an open source developer sees a similar request on the project mailing list, a lively argument will ensue, usually resulting in a clarification or adjustment of the requirement that makes the product better.

A typical open source project is, by and large, a leisure activity. The goal is to have fun and make useful software, not turn a profit. This simplifies the constraints considerably. Successful commercial projects must serve two masters. Developing a useful product is not good enough. You must have a business plan that lets you get the most out of your investment, which can be considerable. Successful companies must find ways to keep these goals aligned, but open source projects don't need to worry about it. If the developers make a useful tool, they feel good about their work. Whether or not that product can be monetized is irrelevant.

Open source projects are self organizing. Remember, the people working on it are doing it for fun. Granted, there are a few lucky souls who are paid to work on open source projects full time, but most of these developers have attained this positions by contributing hours of their own time first. So just as the members of community softball team are likely to have a few things in common and be able to communicate well (especially about softball), the developers on an open source project tend to have a lot in common. The only thing keeping them on the project is the camaraderie and peer recognition they get, so if they don't work well with the team, they just stop working.

All of this means that that the barriers to effective offsite communication are much lower for open source teams. When an open source developer sends an email to another about the XYZ widget in module ABC needing to be cleaned up, the full meaning of that message is much more likely to be understood than a similar email sent from one commercial developer to another. That's because the open source developers are more likely to read the same blogs, like the same development tools, and (most importantly) have a common understanding of the value that their project delivers. This easy, cheap, but effective focus on value delivered is what keeps open source projects a step ahead of their commercial counterparts when it comes of offshore development: Commercial developers have to be paid to care, open source developers would have to be paid not to care.

Comments

[Hans Loedolff]

Nice writeup! I think your analysis is very insightful! I wonder how you define failure vs. success of an open source project? Commercial projects can probably be said to succeed if they have a positive return on investment, but how would you objectively measure success in an open source project?

I'm also wondering what percentage of open source projects "succeed" or "fail" vs. percentage of offshore projects that succeed or fail? Given the number of open source projects out there, a very small percentage actually garner much interest.

[Ben Rady]

Hans,

Unlike commercial products, where there is pretty much one objective standard for success, I think open source project success is context sensitive. As an open source developer myself, I define success for my projects differently, depending on the project.

Some projects may be considered successes simply if they are fun and interesting to create. Whether or not anyone uses them is secondary. Some projects are done to promote a particular technology, and they have their own goals. Others may be done to explore new ideas, or new techniques and technology.

Generally, I think most projects want 3rd party validation in the form of a healthy user base. However, I think most open source developers would cringe at the thought of supporting a community of millions of users all by themselves. There is definitely a "sweet spot" there.

In the context of comparing offshore to open source development, I think adoption and use would be a fair metric. However, software gets written for lots of reasons and commercial interest is only one of them. The other reasons are as varied as the individuals who are contributing.