Nobody has ever achieved success without making some mistakes, and writing off a few failures. But just as we (hopefully) learn from our own mistakes, we can also learn from the mistakes made by others, helping us sidestep failure by knowing what to look out for, and how to respond/react.

The purpose of this article is not to scare you away from launching your own OSS project, but rather to highlight the most common causes of failed projects, and to offer some guidance in avoiding them.

The 3 Primary Types of Open-Source Software Projects

Without wanting to over-simplify things, most OSS projects can be graded as follows:

• Easy Projects – dubbed easy because they are relatively simple to create and maintain. These projects mature quite quickly, after which there is seldom a need for any major refactoring, and they continue to perform solidly for many years.
• Small to Mid-Size Projects – these are projects that are fairly complex, and require a high-level of maintenance in order to continue working well within an ever changing technological landscape. Examples include small libraries such as NumeralJS, and projects like JADE.
• Large-Scale Projects – these are projects that (whether planned or not) evolve to be so complex and vast that they are no longer able to be maintained by a single developer. The only way these projects avoid a total collapse is by going commercial, or through the involvement of a passionate community who all work together to develop and maintain the project. Good examples of these projects include Bower, Grunt, popular CSS and JS frameworks, content management systems (CMS), and projects such as CKEditor, HighCharts and Handsontable.

Common Causes of Failure

Although there are many reasons why any venture could fail, when it comes to OSS projects we are able to split the reasons between one of two categories that influence the cause of failure.

Developer/Author Related Failures

• Lack of Interest – this is specific to a lack of interest by the original developer/author, not users or the community. Whatever it is that causes the developer/author to start losing interest in the project, it inevitably ends with the project being abandoned.
• Lack of Patience – some users and communities can be quite demanding when it comes to requesting features and updates, and a developer without the temperament to manage this will more than likely walk away (and worst-case scenario, delete the project too).
• Lack of Time/Money – all open-source projects require the developer/author to invest time. But some also require a financial investment, either direct in the form of paying for services and infrastructure, or indirect by turning down paid freelance work. If either one of these is more than what the developer/author can afford, the risk of the project being abandoned increases.
• Change of Profession – any change in career or profession by the developer/author can jeopardise the future of an open-source project as their priorities and focus shift.
• Creative Differences – any open-source project worked on by two or more people risks facing a creative differences moment which, if not managed properly, could lead to a split, and the project being forked. And if the community is too fragmented after the split, both projects risk being abandoned.

Project Related Failures

• Technology – as a developer you would need no reminding that technology is constantly changing, and even large corporations can be affected by this, as evidenced by Adobe Flash and Microsoft Silverlight effectively killed off by HTML5.
• Scale – sometimes what starts off as a small project eventually evolves into something too large for a single developer to manage, and unless the community steps in and assists, the project risks limping towards abandonment.
• Legal Problems – very few open-source software developers have the resources to confidently respond to legal challenges from larger businesses, inevitably resulting in their project being abandoned and deleted.
• Acquisition – standard acquisitions don’t necessarily mean a project has failed, especially if the original project remains largely open-source, but with greater access to resources. But there is a trend towards acquihiring, where the original project is shut down, and the developers assimilated by the new company.
• Poor Documentation – documentation that is either difficult to understand, or written by a non-native English speaker can hurt an otherwise great piece of software, especially if it is then ignored by the community.
• Poor Execution – similarly, a project that fails to deliver will eventually be ignored by the community too. These includes projects that are difficult to install, setup and use, poorly coded projects, and projects that still use old technology.
• Usurped by competitor – developers always need to be aware of what their competitors are doing, and this includes indirect competitors. Failure to do so can result in a competitor releasing a far superior product that includes features your users have asked for, but you have not yet implemented.

How to Avoid Failure

Careful planning and a solid development roadmap can help you somewhat in avoiding failure; but awareness, acceptance, and humility are just as important. This means knowing and accepting when:

• You start losing interest in the project.
• The project starts becoming too big for you to effectively manage on your own.
• Your skills start limiting what you are able to achieve on your own.
• The project starts costing you more time and/or money than you can afford.

and it means having the humility to turn to the community and ask for help. Help from the community can take the form of:

• Handing the project over to the community by asking them to fork and maintain it.
• Hiring developers to help you, or asking the community for help in overcoming development roadblocks.
• Adding a commercial element to your project , so that you can generate revenue; making it easier to commit more time and resources to the project.

Depending on how many people use your software, asking for help can deliver some amazing results. Just remember that transparency and honesty go a long way in helping you retain the support of the community, as does a reputation for stable releases ahead of frequent updates.

Conclusion

The risk of failure should never deter you from doing something new, or following your dreams. Especially if you know what some of the risks are, and how to mitigate them. Highcharts started out as a side-project for Torstein Hønsi, and since 2009 Highsoft has grown its client-base, product range and staff compliment. Similarly, Handsontable also began as an OSS project, and has grown to include commercial features, and more team members than they first started out with.

You determine how your own story ends, so what are you waiting for?