Free Newsletters

   All InfoWorld Newsletters
Open Sources | Rodrigues & Urlocker » Asay: So you want to start an open source project...

October 01, 2005 | Comments: (0)

Asay: So you want to start an open source project...

Just finished reading Matthias Sturmer's (153-page!) paper, "Open Source Community Building." Sturmer does a decent job of providing a high-level view of what attributes successful open source projects share. I'm not sure that Sturmer breaks new ground, but I'm also unaware of anyone else that has attempted to synthesize commonalities between successful open source projects. Thanks for doing the work, Matthias.

Sturmer reviews the following open source projects: Plone (CMS framework), Magnolia (CMS), Cocoon (Web application framework), Kupu (WYSIWYG browser editor), Lenya (CMS), Typo3 (CMS), eZ Publish (CMS), and Xaraya (CMS and application framework). Aside from a common content management theme, with a mostly European base, Sturmer chooses a nice cross-section of open source projects.

His findings (with my comments)?

[More at AC/OS.]

  • "Success" [which I'll define as "lots of people use it, commercially and non-commercially] is always somewhat serendipitous, as are market timing (unless you're Tim O'Reilly) and the mix of people involved. As is to be expected, Sturmer finds that positive human character traits (Commitment, experience, helpfulness, patience, etc.) all bode well for a project's chances. He also points to public demand for a project's features which, as with proprietary software, is very difficult to predict or fulfill. Moving on to things over which one has more control....

  • Architecture of participation. Sturmer doesn't state it this way, but much of his findings have Tim's classic phrase all over it. Want lots of people to contribute (bug fixes, extensions, etc., since I think it's pretty clear that most code on a given project will be created by a small, core group of developers)? Write good documentation, use an accessible programming language (C and PHP are good candidates), have a modular framework, etc. Each of these things facilitates the influx of newbies and casual, drive-by developers/bug finders/bug reporters/bug fixers.

  • Choose your license carefully. As Gregor Rothfuss, core developer on the Xaraya Project, relates to Sturmer,
    "The GPL sort of forces community building for legal reasons because people have to give back their code changes of GPL projects. That's different with the Apache License. Somewhat exaggerated, GPL communities are sort of forced communities and Apache communities are voluntary ones." (46)
    The thought that comes out of Sturmer's research is that for a newbie project, a GPL approach is more likely to succeed than a more open, BSD approach. The GPL operates much like traditional copyright, except it's inverted. But the same rigid control persists by forcing competitors to divulge modifications.

  • Great initial source code. It's hard to attract a community to rubbish. You need to start with quality code to attract quality contributions. Eric Raymond has said that a project must begin with "plausible promise," even if it's buggy and incomplete at first. Developers have to catch the vision of good things to come, or they won't help to kickstart the project.

  • Degree of applicability. An interesting point that should be obvious, but it's not. Sturmer writes that "the breadth of applicability determines the potential user community of the open source project" (e.g., supporting various platforms increases the range of developers who will have use for and interest in the project) (104).

  • Modularity of code. If I had to rank these attributes, modularity might well take the number one spot. It is critical to a project's success that it scale well, both in terms of functionality (and the code that goes with it) and in terms of outside contributions. Apache has been phenomenally successful, at least in part, because the core web server is kept so small with various other pieces (Cocoon, Lenya, Geronimo, etc.) serving as separate but integrated (or, rather, integrate-able) extensions. Linux? The kernel is kept small, and is expanded through classes, etc. Mozilla? Same thing - plug-ins, themes, and extensions. Good projects lower the bar to outside participation, and modularity is at the very heart of this principle. Even Microsoft is getting the modularity religion, as Jim Allchin recently told the WSJ.
Of course, even with all these things going for a project, serendipity will have a lot of sway. I once complained to Tim O'Reilly that his "architecture of participation" wasn't prescriptive - it is descriptive. What can I do with it, I asked?

The answer, of course, is that you can create the highest possible chance that your project will succeed, once chance/luck/serendipity drop by. Of course, as Sturmer's open source interviewees also said, great code and a good architecture are only the beginning: old-fashioned marketing (done, perhaps, in new-fashioned ways over the 'Net) is indispensable. Ultimately, there are no shortcuts in open source.

Posted by Matt Asay on October 1, 2005 07:14 AM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS





Microsoft Mini Spotlight
  • Get Started
  • Port 25 Blogs
  • OSS News
  • Join a Project

{Open Source} Heroes Happen Here

Start today and order your own Hero Hack Pack – which includes Getting Started with Open Source, Windows Server 2008 and Visual Studio 2008 Trial. Each pack is a chance to win a free pass to OSCON 2008.







Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links