One of the most common tasks in any company’s open source department is evaluating internal software to see if it would be a good candidate to give back to the community. When performing this task at PayPal, we found it useful to take each potential open source project through a vetting process originally framed by Danese Cooper that seeks to answer four primary questions:

1. Who cares?
2. Are we still using it?
3. Are we committed to it?
4. Can it be developed in one public tree?

This article looks at these questions and why they matter.

Who cares?

Who, outside the company, is excited to get their hands on this software? Nothing succeeds in open source without community involvement. If there is no interest from the outside, the odds are slim that you will be able to grow a meaningful community around what you have written. Once the employees who are currently being paid to maintain the project have moved on, someone will need to own the project or it will become just one more piece of abandonware.

There are many ways to get external feedback. Talking to colleagues in other companies, writing blog posts, socializing the idea at meetups, and speaking at conferences are some great ways to get started. Some employees will already be doing this well. Some may need some guidance on what they are able to talk about and how. Some may not be comfortable speaking about their work. Many will simply need someone to tell them they are allowed to talk about their work with the outside world. We have found it useful to provide speaker training for anyone who wants it, or to help developers develop the content of their blog posts.

Are we still using it?

If we are no longer using the software, it always goes through additional scrutiny. If we are no longer actively developing the software, we are unlikely to perform the tasks required for maintaining the project or building a community around it. Should a vulnerability be discovered in a dependent component (or in the software itself), someone has to be on the hook for dealing with it. Not to mention handling tasks like triaging bug requests, mentoring new contributors, and shepherding pull requests all the way through a merge. These things take time, and a company is unlikely to invest time in maintaining software that is no longer in use.

The bigger issue, however, is that only open sourcing your failures is bad corporate behavior. If we have moved on from a solution because it did not meet our needs, it is unlikely that someone else will find it genuinely useful. Open source is not a bin into which we throw software that no longer fits us, like donating clothes to OXFAM. Companies sometimes push out end of life projects to appease the project’s creator. If a company only gives back software it does not want anymore, it would be better for the company to have no open source program at all.

Are we committed to it?

As previously mentioned, maintaining an open source project takes time. How much time it will take depends entirely on the size of the project. A style guide will not require as much maintenance time as a robust application framework, but in both cases some time is required. It is important that the developers and their managers are on the same page here. If the managers are unwilling to allow the developers the time they need to maintain the project, we are once again on the road to abandonware.

When working in an agile context, you can handle this a couple of different ways. If your process relies on stories and sprints, you could add a story to each sprint to cover the maintenance work. If you select work based on developer capacity, you should reduce capacity appropriately for any developers involved in project maintenance. If you are spreading the work around several people, you will want to make sure you know who owns which parts of the process. Otherwise tasks will be easily dropped. Some projects need a full time community steward. If all of that sounds unreasonable or unworkable to the managers, the project needs extra scrutiny.

Can it be developed in one tree?

Is there anything about the code that would prevent us from developing the code entirely in the public view? If the code cannot be developed publicly because of dependence on internal systems, then the dependencies would need to be isolated, abstracted, or modularized. If there is not enough software left to be of value to the external world after this process, then you should consider releasing the internal dependencies that made the project useful. If there is just not enough left to release, then there is no reason to continue further.

More importantly, you cannot develop software internally, put milestone releases out on GitHub with a license, and reasonably call that good open source. External and internal developers must be able to participate on even footing when having design and development discussions or your community will walk away. This means making your backlog something the community can access, holding technical discussions in the public eye, and not biasing contributions that come from inside the company. If the project team is unwilling to do any of these, they may need some coaching on why these behaviors are important.

Conclusion

These four questions do not answer all concerns by any means. Any company will still need to evaluate the project against any intellectual property (IP) considerations they may have. A study of similar open source projects should be undertaken to make sure your effort is not duplicative. The project still has to make sense both for your company and for the open source community at large, but these questions can serve as a good starting point for the conversation and can help filter out projects that are non-starters.