The 5 Types of Open Source Projects

by Josh Berkus

Perhaps two years ago, Bruce Momjian went to Japan to educate Japanese executives about open source. Like many US business executives, these Japanese managers had heard of Linux and maybe Apache, but had no conception of the amount, let alone the diversity, of open source projects out there. So I wrote Bruce a slide for his presentation called "the six types of open source projects".

With almost a hundred thousand projects just on SourceForge, it would be possible to classify projects in a myriad of ways. They can be categorized by license, by origin, by collaboration architecture, by communication method, or even by geographic epicenter of development.

Here I am looking at organizational classification. Who makes the decisions in the project? How does a contributor join the project? How does code get approved? How are strategic goals, if any, set?

Examining the world of open source in this light, every OSS project I've encountered to date can be fit into one of only five categories, or as a hybrid of two of the five. They are:

Solo
Monarchist
Community
Corporate
Foundation

I've numbered them 1-5 above because the numbering indicates a general tendency towards increasing formalism. That is, Solo projects are, in general, very informal and have little beaurocracy, and Corporate and Foundation projects tend to have written requirements and rules and extensive internal politics which are unavoidable by participants. Also, projects tend to move "up" but not "down": a Community project might become a Foundation, but is unlikely to become Monarchist. There are, obviously, some significant variations in this. Now, some definitions:

1. Solo

Description: By far the numerical majority of projects (90% or more), Solo projects have only one or two developers who are responsible for 100% of the code, decisions, and support of the project. They generally consist of one or two programmers who decided to open source a custom project they did in hopes of improving their professional image and/or attracting other developers to help out. Some Solo projects are forks of other projects where one developer who disagreed with the rest of the project decided to strike out on his own.

Joining: Solo projects tend to be either extremely easy or just about impossible to join. In most cases, the project developers are thrilled to have help and interest and will be extremely responsive: after all, they open-sourced the code in order to share. Sometimes, particularly in the case of forked projects, the developer/owner of the project can be a prickly, unapproachable personality.

Support: Owners of Solo projects tend to be extremely responsive to user requests, partly because many of these projects have few users. Some, however, are either abandoned by their creators (as Flexbackup was for several years) or belong to anti-social or overworked programmers who are completely unresponsive. Sending a few messages to their mailing list will tell you quickly what you're dealing with.
The main issue for adopting software from Solo projects is the possibility that the single developer will lose interest, have personal troubles, or even die, breaking off all support for the project. As such, businesses looking to incorporate Solo-produced software into their infrastructure or products should make sure that they can either hire/contract the project owner, or that one of their staff is sufficiently skilled to take over the project in the event it fails.

Examples: Bricolage is pretty much a Solo project, with 90% of the code written by David Wheeler and his employee. For other examples, browse SourceForge and Freecode: you'll see thousands of Solo projects like iBookshelf, joe text editor, dbmail, and Framewerk.

Notes: There is a tendency in the press to paint Solo projects as less legitimate than larger projects. This is rather unfair; often these projects are extremely useful, and sometimes there is only one developer because only one is needed. For most of them, it's simply because the project is very new.

2. Monarchist

Description: A Monarchist project is usually a Solo project which "succeeded" and developed a large community. While these projects can involve large numbers of contributors, all decisions are made by the project lead and a small number of "lieutenants" whom he/she appoints. Strategic goals, and political disputes, are always settled by the lead developer or the responsible lieutenant.

Joining: Joining Monarchist projects is relatively easy. You merely need approach either the project lead or one of his/her lieutenants with a request or a code contribution, and they will make decisions immediately. For larger, more popular projects, the lead him/herself will not respond to contacts at all because he/she is too busy. In general, the tight hierarchical structure of these projects results in very little politicking: any long-running disputes will be settled by the lead programmer quickly.

Support: Monarchist projects, being larger than Solo projects, will often be proportionally more formal. On the mailing lists, you will often receive more responses from your fellow users than from developers unless you are a contributor to the project. For bugs, Monarchists will often have and require the use of a formal bug-tracker, such as Bugzilla.
For corporate-level support, the accepted practice is to hire or contract with the lead developer or his company, or hire/contract with one of the lieutenants or their companies. In fact, some companies will keep a project lead or lieutenant on their payroll just to be able to offer full support for the software to customers.

Examples: Many programming languages, including Perl and Python, are Monarchist projects. The paramount other example is Linux, but OpenBSD, Memcached, and Bittorrent are other popular Monarchist projects of varying size.

Notes: The growth of Monarchist projects usually depends heavily on the lead developer's ability as a manager and inspirational leader. This also means that personality conflicts between lieutenants and the lead often result in project forks.

3. Community

Description: Community projects have a significant number of contributors who run the project democratically as peers. While occasional majority votes may be taken, most decisions are made by a combination of volunteerocracy and consensus. Larger projects may have a steering committee of senior members who decide strategic direction, contributor disputes, and who gets commit rights.

Joining: Community projects generally are extremely welcoming to new contributors, and generally have no formal process by which you are "accepted." Instead, new members are encouraged to make project contributions and those contributions are vigorously (sometimes harshly) peer-reviewed. Once you start, your voice within the project is generally determined by a combination of your seniority, the quantity and quality of your contributions, and your eloquence online. Any executive decisions made without discussion will be highly suspect and can result in flamewars or ostracism.

Support: Because of this intensely social process, Community projects generally rely on extremely active mailing lists, forums, and/or chat tools, sometimes adding up to thousands of messages a week. These media are also your main support channel, so getting peer and developer support for bugs and instructions requires you to participate in the social process. For greater levels of support, you generally hire a major contributor to the project, or one of several company participants.

Examples: Large Community projects are relatively few due to the political balancing required to keep them stable. PostgreSQL and Linux Terminal Server Project are good examples of the type. Debian is also a Community project but has the politics of a Foundation according to many people, and FreeBSD is Community but has recently incorporated as a non-profit.

Notes: Community projects operate by a general synergy, and as a result tend to have no detailed strategic plans. Rather than working towards specific goals, communities focus on recruitment to advance the project by acquiring code and ideas as rapidly as possible.

4. Corporate

Description: Corporate projects generally consist of code which was open sourced by a private company but not completely alienated from them. For many, it can be hard to tell the difference between the project and the company: the majority of programmers are company employees and the company's marketing department determines strategic direction for the project. Sometimes these projects consist of older or unprofitable code the company has pushed out into the public sphere for PR or strategic reasons. Other Corporate projects are part of a growing class of small companies who see open source as the best distribution method for their products: the "Dual Licensing" companies.

Joining: it is often difficult or unpalatable to participate in Corporate projects, which is why they generally fail to attract many independent contributors. Generally one has to go through a formal process of application including assignment of rights to the sponsoring company. Further, outside contributors will usually be closed out of decision making within the project as decisions originate from the company. Thus most third-party contributors tend to focus on add-ons to the central software.

Support: a variable amount of peer support will be available on mailing lists and other public forums, depending on the popularity of the project and the amount of time the company lets its developers spend dealing with the public. Reliable support is often only obtained through a support contract or commercial license with the sponsoring company.

Examples: This is a popular type for databases: MySQL, Firebird, BerkeleyDB and Ingres are all Corporate projects, the first three of the "Dual Licensing" variety and the last an example of a large corporation reviving older code by open sourcing it. Compiere and Red Hat Fedora are other examples, as is the other Dual Licensing headliner, JBoss.

Notes: OpenOffice.org, as a large and very popular Corporate project, has arrived at a peculiar structure with a large and vocal user community in dialog with the sponsoring corporation. Despite the vibrancy of the user community, though, all major contributors remain employees of Sun.
It's also worth noting that Corporate projects are alone in having an organizational model which requires a particular license. Almost universally, they either use the GPL or LGPL (in order to compel contribute-back) or a Mozilla-like license that maximizes credit for the company.

5. Foundation

Description: a non-profit foundation can be thought of as the end point in formal organization of open source projects. Such projects are incorporated with officers and directors and all decision-making formalized by the necessities of corporate structure. Often this is done in response to the project being critical to several large companies, who use the formal structure to protect their mutual interests and ensure themselves a voice. Sometimes Foundations originate when well-established Community projects feel that they need the advantages of legal structure and the ability to hire staff. Finally, a few Foundations are the result of a company alienating a Corporate project's code and setting up an NPO to safeguard it.

Joining: Foundations generally have a formal application process which includes, like Corporate projects, a document assigning contributor rights. In some corporate-created foundations, individuals cannot participate in the governance process, only representatives of companies and groups. This means that you must join as sponsor of the project in order to participate fully. Others have taken the step of splitting off small sub-projects which operate much like Monarchist or Community projects individually.

Support: Often Foundations will have lists of sponsors who also form the core of commercial support for the project. This makes it relatively easy to locate paid support. Unpaid support varies: some Foundations behave more like Communities, and some more like Corporate projects, channeling requests towards paid support.
Foundations are the only type of project to engage in systematic fundraising. Users will be encouraged in many public forums to donate towards the project.

Examples: The Apache Software Foundation the uber-Foundation, using its formal structure to govern not just itself but numerous sub-projects such as mod_perl and SpamAssassin. The Mozilla Foundation is growing in the same way. Other Foundations include Gnome, the Gnu project of the Free Software Foundation, and the The XFree86 Project.

Notes: Please note that the mere possession of incorporation papers does not make a project Foundation in structure. Linus Torvalds works for OSDL, and yet Linux remains mostly Monarchist, and Firebird Database is non-profit incorporated, yet remains in the control of the private consulting company IBPhoenix.

Keep in mind that the organizational structure of a project is not static; many, if not most, projects are one type and in the process of becoming another type, such as Bricolage which is Solo but becoming Community, or FreeBSD which is Community becoming Foundation. A few projects are even hybrids, such as the PHP language, which maintains a balance between the Zend-dominated developer core (Corporate) and the large number of outside contributors (Community). And, of course, my categorization of projects is largely subjective, so be sure to check things out yourself.

Further, the vibrancy, durability, and adoption of an open source project (success, in other words) is not dependent on the organization type. It depends on a variety of factors, most of all good leadership by the project leads/owners.

Source: http://powerpostgresql.com/5_types archive.org^[link1]

Links

[link1] http://web.archive.org/web/20071012183238/http://powerpostgresql.com/5_types