Open source projects: criteria for success

by Randy Metcalfe on 9 February 2006 , last updated 6 October 2008

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.

Introduction

The marker of success in an open source business is the same as that in any business: profit or loss. An open source software development project is not a business. Indeed, even when a single business lies behind the majority of the development work, I would argue that the software development project is still not itself a business. What counts as the marker of success for open source software development projects must therefore be something else.

Open source development is not business

Any business whose business model depends upon the use or development of open source software is an open source business. Such business models are necessarily symbiotic upon open source software development projects. Yet open source development succeeds or fails irrespective of the businesses that are directly associated with them. This is a crucial point to acknowledge. The constructive exploration of sustainability with respect to open source software development depends upon it.

Clearly the failure of a business intimately tied to an open source software development project can mean tremendous upheaval for that project. Paid personnel will cease to participate in the project. The project may become leaderless and stagnate. Even the name used for the project may need to be changed. Project names are typically trademark and thus not covered by the licence on the code itself. Surely this must mean the end for the project.

Projects and open source development

An open source software development project can only ever be a singular instance of many possible developments of the code. Indeed this is what the use of an open source licence guarantees. Everyone who has a copy of the code has the potential, written into the licence itself, of developing that code themselves. This is the permanent possibility of the code-fork. Often seen as a potential threat to open source software development projects that incur the wrath of the open source community, the permanent possibility of the code-fork is also the guarantor of continuity. It is the reason why an open source software development project cannot be equated with the development of the code itself. Any particular project may ultimately be a cul de sac of development. If a different project took the code forward successfully, the code would progress. Projects are mechanisms for development. An open source software development path might therefore conceivably move from one project to another over time.

A business that fails may lead to the demise of a project. But that will not entail the demise of the open source software development path. The licence ensures that continuity of development can be reknit by a new project that takes the code further.

Projects or open source development?

Accepting the distinction between projects as particular instances of open source development and an open source development path itself will not change the issue at hand. Our concern must be for the criteria for success of projects. The sustainability of an open source software development path is effectively beyond the capacity of analysis by case study or example. Either the code continues to develop regardless of which project is taking it forward, or it does not. However, the likelihood that no single project will carry the code throughout its entire development path does suggest additional considerations that a project may need to take into account, in effect, to honour the code.

Criterion of project success

Business has the advantage of a very simple and clear metric for success. Although the success of projects cannot be measured in terms of profit and loss, there is a criterion of success that is both simple and clear. Either the project retains the trust and good will of the open source community and thus remains the lead on the development path of the software or it does not. If no one is willing to invoke the option of the code-fork, then the project must be considered a success.

This is a useful criterion despite potential limitations. An open source software development project which has no user or developer base will be successful by default. The worst that can be said about such a technically successful project is that it is uninteresting. By contrast a project with an extremely active development community will be at greater risk of failure using the above criterion. It will, correspondingly, also be of greater interest.

Another potential limitation on this criterion of success is the very diversity of project types that may be found in open source software development. Can a reference implementation or a proof of concept project be judged by the same criterion of success as a large end-user project? The former might count merely as delimiting cases, as before. The difference is that these projects may be merely a stage on the large open source software development path. The fact that at some point they hand on the development lead to another project does not diminish their success against the criterion at an earlier time.

All successful projects fail

They also force us back to the distinction between the development path and the development project. A successful reference implementation project may advance the software development path even if some other project arises which carries the software beyond the reference implementation stage.

Projects of different types have different limiting conditions even if they may all be assessed by a common criterion of success.

The success of failure

There is a strong likelihood that no single project will carry the code throughout its entire development path. In a sense, every successful open source software development project will eventually fail. Remember, it fails when some other project takes on the lead in the development path. But that new project will also fail at some point.

The intimate relationship between open source software development project success and failure should prompt a re-evaluation of the meaning of success for projects. Any project that holds the lead in an open source software development path is by definition successful. Some projects hold the lead and carry it for significant periods of time. In this sense they might be considered to be more successful than other projects. But it is clear that only time will tell the relative success of the projects.

Preparing for the success of failure

The test for any successful project is whether or not it stands at one point along an ongoing development path. If the project comes to an end and there is no continuance, no new project that will carry the code development further, then that software development path has truly ended. Surely the earlier success of the project is tainted by this state of affairs.

Projects can mitigate against this unsavoury end by preparing in advance for their own failure, and thereby their greater success. How should a project prepare for its eventual demise? By honouring the code. If it is the software development path itself that concerns us, then anything that assists that onward movement will be a benefit. For example, supplying sufficient comment within the code itself in order to make it easy to read by others increases the likelihood that someone else will take the code further. Structuring the code into comprehensible units is another way of honouring the code. Documenting the full history of the code’s development and ensuring that this will remain publicly accessible again aids the possibility that a new project may arise to take the code development further down the path.

Conclusions

Open source software development projects do not share the same criterion of success as the open source businesses that may be associated with them. An open source software development project can only ever be a singular instance of many possible developments of the code. The permanent possibility of the code-fork guaranteed by the use of an open source licence is also a guarantor of the continuity of the open source software development path across different lead projects at different times.

The criterion of project success is whether or not it retains the trust and good will of the open source community and thus remains the lead on the development path of the software. Since no project is likely to sustain the lead on development forever, any successful open source software development project must encounter its own failure. The successful preparation for failure and transition of the software development lead marks an even greater success for an open source software development project.

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.