You have 1 article left to read this month before you need to register a free LeadDev.com account.
When we think about the complexities of the open source ecosystem, there are two words that come to mind: transparency and empowerment.
In my recent LeadDev articles on open source, we explored how being transparent about the purpose of a project lets people understand the goals of a project and what to expect from it. Transparency can empower everyone involved in contributing to open source software with the information they need to participate successfully. It also empowers people integrating projects into their own applications with the ability to evaluate potential projects based on the criteria that they consider important. Last time, we examined ways that transparency in a project encourages a thriving community.
Open source software doesn’t magically appear out of thin air as fully baked projects that are ready for production use. Sometimes it seems that way, because society loves a visionary who appears to get it right the first time. As a consequence, many open source projects start in private, with creators working alone or with a few trusted colleagues until they feel confident enough to make it public.
However, open source is seeing a bit of a culture shift where creators are more comfortable starting projects and initiatives in public, with the understanding that they may or may not be successful.
Varying states of done
This means that we may see projects in various stages of development.
Unlike proprietary products that often mark the ‘doneness’ of products with labels such as alpha, beta, and generally available, open source projects have no agreed upon vocabulary. Without this vocabulary, adopters of open source software oftentimes have to use a ‘best guess’ approach when making technology decisions.
Sometimes, people will add warnings to their project’s README files, indicating that it is not production-ready. At times they might add an ‘under construction’ gif (warning: flashing visuals and a generally overwhelming page) to underscore the point. Others will point to their LICENSE file, nearly all of which say something that absolves the maintainer of any responsibility for the functionality of the project.
The fluidity of open source and flexibility of its development makes it difficult to identify the maturity or status of a project. To complicate matters, it is a twofold evaluation: the status of a project and the maintainers’ interest in continuing the project.
Nine possible project states
As we continue to create projects in the open (which is a psychologically interesting expression of vulnerability), it becomes increasingly beneficial to proactively signal their current status.
Without digging too much into the semantics of individual terms, let’s look at some different states that maintainers might want to communicate to their project’s community.
Unlike the prior pieces in this series, we won’t look at specific projects in these various states, because they are inherently subjective evaluations.
1. Idea
A project in an idea state is just starting out. It may not work yet, have documentation, or be anything beyond an experiment. Open source projects with this status may not respond to reports of issues or accept contributions, as they may not be ready to do so. They are still figuring things out!
Projects marked as ideas don’t necessarily have to ever move out of this state.
2. Prototype
Projects in a prototype state are a little bit farther along than ideas. Oftentimes, they are a proof-of-concept and their primary purpose is to validate an approach that the author aims to take. At this stage, the maintainer(s) may still not be accepting contributions, but they may be open to feedback.
Prototypes generally should be treated as not yet being ready for prime time.
3. In progress
A project that is in progress is still in development, but it has a direction and people are working on it. It may still not be fully functional, but maintainers are more likely to accept contributions, help, and feedback.
4. Paused
If a project indicates that it’s paused, development is on hiatus but the maintainer(s) plan to resume at some point. For most grassroots open source projects, paused is the default state since development depends on individuals having the time and capacity to dedicate to it in their free time.
Projects that are in a paused state will probably be slow to respond or unresponsive to issues raised by the community.
5. Active
An active project is one that’s functional but still actively developing new features. Maintainers for these projects aim to be responsive to community needs (to varying degrees) and the project has stable releases.
6. Stable
A stable status denotes that a project is effectively complete. Maintainers of a stable project are happy with its current state and aren’t looking to make any major changes. They may still respond to community issues, patch security flaws, and address other bugs.
Projects marked as stable often get (mis)characterized as being inactive, which is misleading (and quite interesting from a sociological standpoint).
7. Relinquished
A project that has been relinquished is one that the maintainer no longer intends to develop or maintain. This type of project may still work perfectly well, but users looking for an active contributor base might want to look elsewhere – or volunteer to take over maintainership!
Another way to interpret a relinquished status is ‘in search of a good home’.
8. Archived
An archived status describes a project that was once active, but is no longer being developed in any way. Archived projects may or may not be read-only, but the maintainers do not intend to fix any issues (security or otherwise) or support users.
9. Static
Static projects are ones that were essentially archived immediately after initial publication. A static state is both a starting and ending state.
Existing status models
Luckily, we don’t have to start from scratch when it comes to identifying statuses for projects; this is not a new area. Some existing models exist, and even come with fancy badges to add to your README! Here is some inspiration:
- Box’s project status badges – five statuses specific to Box’s open source projects
- repostatus – eight statuses based on a traditional project life cycle model
- Twitter’s project status badges – eight statuses, with some that are Twitter-specific (disclosure: I was a minor contributor to this effort)
Conclusion
A project’s potential state and its purpose are linked, and it may be the case that the state machine for one type of project includes only a strict subset of the states listed above. While a project’s purpose indicates its goals and intended direction, the project’s status communicates the maintainer’s assessment of its current condition and circumstance. However a maintainer assesses their project’s state, communicating its status gives its community a final piece of information to determine if it is a good time to jump in and contribute or rely upon the project.
This article wraps up our series on the social model of open source. But we should all continue to drive towards transparency and empowerment in open source. This work is, and should be, a never-ending story, and our journey isn’t over (archived).
