Lifecycle of an open source project

I’ve had several people ask me about the state of various open source projects that I’m involved with or advocate.  They ask questions such as “Is it alpha or beta?”, “Should we start using it?”, and “Where can I get started learning more?”.

I find these questions difficult to answer since they’re very relative and subjective depending on your environment, tolerance for change, tolerance for bugs, issues with “bleeding edge” technology, etc. 

In an effort to try to come up with a more objective framework for answering these types of questions, I decided to take a stab at putting into words my experience with various frameworks and how they have progressed in their lifecycle.

Phase 1: Concept

Some ideas have been kicked around by a few people. Some spike code has been written. A project site is up (Google Code, CodePlex, etc) and there is maybe a working prototype to show off and talk about.  Definitely no documentation, wiki, or anything like that. There may be a blog post or two about the concepts.

Phase 2: Bootstrap

There are one or two serious authors/committers.  There might already be one or two actual users experimenting with the framework.  The build is continually in a “works on my machine!" state.  Some more blog posts have been done and maybe a wiki with a few articles, but otherwise no docs to speak of.

Phase 3: Early Development

A few more committers have signed on, but still there is only one or two primary contributors. A few more users have started playing with it now and are providing feedback.  A mailing list has certainly been set up by now, if not earlier. The build is more stable and works in many environments.  More blog posts and wiki articles have emerged, but still no serious documentation effort yet.

Phase 4: Early Adoption

More committers are signing on now and contributing more and more.  The project is at a state with many of the baseline features are done and the product is quite usable now.  There are a few dozen users experimenting with it and even building some interesting applications upon it.  Multiple people are blogging about it. The wiki is starting to materialize into categories and sub-topics.  Some sparse documentation has started to emerge in the form of some limited API docs and some FAQ’s and getting started guides.

Phase 5: Development

There are several devoted committers now, cranking out serious features and functionality.  There are dozens of users – approaching 100 or more.  There is an automated (nightly?) build. Binaries are available for download regularly.  Many people are blogging about it and buzz is growing.  The wiki is really taking shape and being fleshed out.  At this point documentation is “moderate” and is growing into more scenarios and topics.

Phase 6: Adoption

Many people are submitting patches and other forms of contributions. The inner circle of committers is growing.  There are more than 100 users, perhaps several hundred.  There are frequent “point” releases available for download. There’s now likely a basic installer which helps configure your environment for the framework.  Frequent, in-depth blog posts by noted authors.  The Wiki is now very rich and there are frequent contributions.  Documentation at this point is “adequate”.  You would likely start seeing “contrib” projects sprouting up here and there and coalescing .

Phase 7: Maturity

There are so many patches and contributors that a hierarchy has been set up to evaluate and approve changes.  Multiple releases creates management issues with patches and defects requiring more organization. There over a thousan users by now and like thousands.  There are releases and installers for various scenarios (maybe x86/x64, or a Mono compatible release, etc).  There is lots of documentation activity and many contrib projects have emerged.

Phase 8: Mainstream

By now, many of the original contributors have moved on or are less involved. A new generation of contributors have taken over and are taking the project into different directions and expanding it greatly.  There are hundreds of thousands of users. Perhaps there are even consulting companies forming business services around the project and offering commercial support.  There are now multiple “dot-oh” releases. There is no doubt this project is here to stay and provides real value to people.  The project has its own active web site with lots of content, guides, add-ons, forums, blogs, etc.

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    About Chad Myers

    Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
    This entry was posted in Open source. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • http://www.sullivansoftdev.com/blog Brian Sullivan

      Interesting taxonomy! Where would you put Fluent NHibernate right now? Maybe around a 4?

    • http://www.lostechies.com/members/chadmyers/default.aspx chadmyers

      @Brian: FNH is at least a 5, but has aspects of 6 except it doesn’t have the “point” release schedule (yet?)

    • Ben Hyrman

      I have no qualms using FNH in production. There’s one other concern I have with adoption that isn’t explicitly addressed above but I have a feeling it’s taken care of sometime between 5 and 6… how stable is the public API. For instance, With FNH, I’m confident the team has tests to ensure that adopters don’t get caught with some nasty bugs in prod. As important, though, while I know the internals will change drastically, it feels like the public API won’t change much.

    • http://ferventcoder.com Robz

      This is an awesome post and dissection!

      Automated builds could be solid even as early as phase 2.

      If you can get open source to start their builds with UppercuT (http://uppercut.googlecode.com) and then mold it to their needs, you won’t have to deal with that “works on my machine” issue.

    • http://www.lostechies.com/members/chrismissal/default.aspx Chris Missal

      At which phase is it when I switch the setting in the mailing list to give me daily abridged emails, rather than one per thread? :P