Part 1 - Structuring for your Open Source Project
This is part of the ongoing series I introduced in my prior post. I would love to hear from other open-source developers as to whether they agree/disagree with my analysis.
So
you've decided to join the world of open-source software developers;
welcome! As you may or may not realize, there are a lot of things to
consider when open-sourcing a project. It isn't simply a matter of
setting your code free into some anarchic void. For starters, you need
to consider a software license, the means of distribution, creating
documentation, how to manage contributions and whether you intend to
offer support. Also, keep in mind that when we refer to open-source, we
don't necessarily mean free. If I haven't scared you off already then
let's get started.
Step 1: Structuring Your Project
Depending
on how and why you started your project will likely influence how you
choose to structure your project. More than likely, you've probably
started your project for one of three reasons:
- You created the project for yourself and decided to share.
Of all the categories of open-source projects this one is probably the most numerous. For example, you create a tool for your day job and decide that others may benefit, so you release it (with the full knowledge and permission of your employer of course). While there may be many of these projects, they often fail for lack of time and attention - often because the author(s) didn't realize how much effort the project would take once people started actually using it. - You created the project due to a perceived community need.
In this scenario, you recognize that a particular type of software is lacking in your language of choice - either altogether lacking or lacking in a free and open-source version. For instance, in the ColdFusion world, the cfCommerce project began because a number of individuals recognized the lack of an open-source e-commerce package in ColdFusion. Unfortunately, many of these projects languish due to people having day jobs and/or a lack of an organized team or clear means of contribution. - You are open-sourcing an new or existing commercial project as part of a professional open-source software business plan.
While open-source business plans seem to be quite popular these days, this is still likely the smallest category of projects. This type of project generally supports itself via support contracts or training. Some projects, like MySQL for example, also make money through paid contracts offering a less restrictive open-source license. While this group is small, but growing, it also generally contains many of the larger, most comprehensive and well-documented projects.
Some
commercial projects are open-sourced as a means of end-of-life-ing an
unsuccessful or outdated product, such as Spectra, but we'll overlook
this group since they don't succeed as open-source generally by design.
Keep in mind that while your project may begin life as a Type 1 or Type
2, it could become a Type 3.
Solo Developer
Typically
Type 1 projects are created and maintained by a solo developer. This
can be sufficient for small projects that are limited in scope, but its
important to consider that the workload tends to increase the more
people use the project. Generally, if your project has garnered some
limited acclaim you will be able to find people willing to contribute
but, in my opinion, transitioning from a solo project to a project with
multiple contributors is difficult (and at first doesn't necessarily
reduce the workload). I will be covering managing contributions in more
detail in a future post.
Multiple Contributors
Type
2 projects are occasionally solo projects, but more often, in my
experience, they are group efforts comprising anywhere from 2 or more
developers. This is partially because the Type 2 project is open-source
by design (while Type 1's are generally open-sourced after the fact).
This allows the time and consideration for the organization and scope
of the project prior to creating it where the project organizer seeks
the input of interested contributors. Its important though to ensure
that the people joining the project (including yourself) have the time
and a real desire to contribute as many of these projects stagnate in
the planning phase.
Type 3 projects are
almost always multiple contributor projects whose structure is dictated
by the business they are associated with. Some professional open-source
software projects are a single product released by a company with a
larger scope of business and in other cases they form the core of the
business plan. For example, in the ColdFusion world, there are a
handful of these projects including FarCry, Razuna, Transfer and
ColdBox. FarCry and Razuna were commercial products that were
open-sourced as part of a revised business plan for the product.
ColdBox and Transfer were open-source projects that grew to have a
large user-base and are in the process of transitioning to a POSS (i.e.
for profit) model based upon offering training and support options.
In the next edition we will discuss the Holy Grail of open-source topics, choosing a license.
Kudos, very interesting read! As I've also (gently) entered the world of open source developers (http://code.google.com/p/tandem) I am looking forward to the upcoming posts.
Regards,
Daniel
Great Series, can not wait to see more.
Nice post. I think the only way a open source project, be it type 1, 2 or 3, can survive and gain some market share is by building a community. Sounds like a easy thing, just release the code and see how it does, but building a community is one of the biggest challenges for any open source project.
Looking forward to the licensing post. I have gone into lengthy discussions before releasing Razuna about licensing. It might be interessting to see your findings.
Thank you for mentioning Razuna.
Not so much about open source as preparing yourself for the opportunities a successful open source project might bring your way!