Professional PHP

Jon Udell and John Montgomery are taking a private conversation about open source public:

I’ll continue one argument I was having with Jon in the open, just to see what happens. The premise: Open collaboration can relentlessly commoditize things that require a lot of work — like deep integration — just because it can mobilize the resources.

My response: In my experience, that hasn’t been the case. In fact, the “open collaboration” model tends to leave things at the “good enough” point too often. Look at most open source software efforts: very few large-scale projects get beyond looking like bunches of different applications created by different people. Nearly none actually demonstrate things like common user experience paradigms, consistent APIs, or uniform management.

John goes on to describe four types of open source projects:

• Cloners – so many of these.
• Standards built – such as apache or mozilla.
• Competitive Devaluation – closed source projects that become open source to gather a larger audience.
• Invention – “Not quite like anything that came before.”

I think its worth noting that of these four kinds of projects, the top three share the characteristic of having well defined requirements. These are the projects where parallel collaborative development can excel.

The fourth kind of project, Invention, is a different beast entirely. I’ll argue that the open source projects in this category that end up actually succeeding are the ones run by a single benevolent dictator, or a small tight team. Thats because large groups are not good at setting cohesive goals. (ever watch CSPAN?) A strong goal and a strong vision, more than any other factor, determines the success of a software project.

Again and again I see various forums, mailing lists and news groups spawn open source projects, but if they don’t fit into the clone this or implement this standard variety, they usually die away. Thats because they lack a clear vision and a participants lack a willingness to commit resources to achieve that vision.

Communicating a vision such that people are willing to invest resources in realizing that vision is hard. The coin of the realm in open source is, of course, source code. The best communicator of a vision is code that solves a problem or provides value. Without that seed of working, valuable code, most open source projects never move beyond their creator.

Innovative open source projects face the same problem that a small business faces trying to get a a loan from the bank. The more you need the money, the less likely the bank is to give it to you. Similarly, potential contributers to an innovative open source project need to see that the goal of the project offers them value and that the project already has enough resources committed to potentially achieve that goal. Only then are they willing to commit their own resources to the stone soup.

Given the difficulty of communicating a common vision, I think its no surprise that “common user experience paradigms, consistent APIs, or uniform management” are not necessarily natural strong points of open source software.