When evaluating whether to adopt an open source solution in a software project for the first time, here are some basic questions you should ask:
1. What business problem are you trying to solve, or what business opportunity are you trying to address?
This is the fundamental question for any software project. If you don’t know the answer, your project is at risk.
2. What are the relevant open source solutions?
We default to open source solutions in Red Hat IT with great success. I recommend you always ask what open source alternatives are available when you initiate a software project. This analysis should consider both unsupported open source projects and commercially-supported open source products.
3. Can and should you start an open source project to address your specific need OR can you contribute to a relevant project?
If you don’t identify a relevant open source project or product in step two, determine whether your business need is relevant to others. If so, consider open sourcing your internal project to accelerate development, benefit from the features added by others, and to reduce your cost to maintain the solution.
As an example, in Red Hat IT we’ve created an open source project called lightblue which is highly relevant for us, and we believe, others. We needed a general purpose Red Hat product and MongoDB-based solution to access data on our enterprise service bus. Rather than simply building an internal application, we built an open source project, and we’ve already had external contributors improving that project.
Open sourcing our project makes our solution better, gives it better sustainability, and lowers our maintenance costs. For us, it was worthwhile to make the investment. It might not be worthwhile to make the investment in open sourcing something that was absolutely specific to our business, but by making it general purpose, we’re able to garner the benefits of an open source community.
Alternatively, if there is an existing open source project that is close to meeting your requirements, consider contributing software to the project which will adapt it to your needs.
4. How can you obtain technical support for your initiative, and when will that support be needed?
If you’re going to start small, build a solution, get it working, and deploy it in production, you must have a strategy for how you’re going to support it. You don’t need to spend a lot of money buying support for a proprietary product. You don’t need to hire 100 technical people to support it on day one. But, don’t get caught in the trap of “it’s great, everybody loves it,” but you can no longer support it because you didn’t have a plan, and now you’re scrambling to keep up. Plan ahead so you know how you’re going to scale up from that initial success to a supported enterprise solution.
5. How sustainable does the solution need to be, and how will you sustain it?
This comes back to having a strategy for supporting your project. You may not need to focus a lot on sustainability if you’re writing a solution for a one time event. That may just be a quick deployment and retirement, unless you plan to use it for the next event (or your internal partners ask you to), then you may want to build a sustainable solution.
On the other hand, if you’re making a five-year investment in a new database to capture information coming from a high-volume and very expensive scientific experiment, and that data is going to be useful for 25 years, you need to take a different approach to thinking about the sustainability of your solution and how you’re going to maintain it.
A benefit of open source in general, and commercial open source in particular, is that you have the support of others as well as the ability to do the maintenance yourself.
I hope these questions will help you determine whether open source is a good fit for your next software project. Let me know if there are other questions you would add to this list.
Lee Congdon is responsible for Red Hat’s global information systems, including the technology strategy, enterprise architecture, information technology governance, solutions delivery, and systems operations supporting the company. His role includes enabling Red Hat’s business through services, such as knowledge management, technology innovation, technology-enabled collaboration, and process improvement.
