Microsoft Open Source Blog 
- Community diversity, velocity and governance;
- The ability to purchase vendor support, without lock-in;
- Capability of existing or local partners to accelerate delivery;
- Ensure licensing provides appropriate flexibility and protection.
Community
In my opinion, the choice of open source project/community is one of the most important choices and should be weighted accordingly in any open source project selection criteria.
Diversity
Diversity in a community is important, both in number of individual and vendor contributors. Diversity helps both with the number of people able to contribute; the size of the engine, but also the variety of use cases that are catered for and this will ultimately drive a wide and flexible feature set.
This will also give an indication of whether the project can maintain its velocity, especially in the context of any one person or vendor leaving the community.
Velocity
Release Cadence
This will give an indication of the cadence of the project, whether it is releasing every 2/3 months, 6 months or more. Some projects don’t have a strictly regular cadence, but the historical release schedule should give you a good indication.
This will be important to consider if you have a feature pull request (PR) yourself, or are working with a partner/vendor on a PR, in order to understand when it might be available and integrated into the overall project; especially if you’re looking for support from the partner/vendor.
Significant Features per Release
If you’re comparing projects and there’s certain feature gaps, the size of releases and added functionality will be important to you and an indicator (combined with release cadence) as to when those feature gaps might be closed.
Release Stability
Having lots of releases with significant feature adds/improvements is worthless if the releases are unstable and break backwards compatibility.
Governance Model
Having a sizeable and diverse community is great, but there needs to be a clear governance model to make unbiased architectural decisions. In a large and active community, differences of opinion will occur, and should be considered healthy, but the last thing you want is for the project to fork in separate directions.
A healthy and mature community will have multiple project maintainers and may even have a technical governance board comprised of major contributors and vendors.
Larger open source projects will often be governed by a foundation, which entails a higher level of formality and process. This may involve financial commitment from vendors (but not individuals) that want to be involved where legal obligations and things like trademarks are important.
Vendor Capability
Ability to purchase a supported product
If you’re not a significant contributor to the project and it doesn’t relate to your core business, you should outsource development and support to a vendor; I cannot emphasise this enough.
Communities provide support, but no Service Level Agreement (S.L.A.). How do you plan to respond to production support incidents?
If you aren’t a major contributor, how do you plan to develop required code fixes or drive new P.R.s that deliver important new functionality for your business?
Even if you have a smart team of people that could do this, it doesn’t mean you should. I recommend that you divert your team’s expertise and capability to having a significant impact on the value your business delivers to your customers, rather than focusing on work that is not driving direct value and that can be out-sourced.
Aside from providing enterprise testing, packaging, support and documentation vendors will typically provide a value added layer over open source projects. This could be as simple as user interface improvements on top of the native API, or more complex in terms of an additional orchestration layer that provides more advanced build, deployment and life-cycle capabilities.
Standards, Openness & Portability
Ease of migration/upgrade to a vendor product from an open source project shouldn’t require you to re-factor your workload.
Migration from an open source project, to a vendor product, really boils down to the availability and implementation of the open source code, APIs and any applicable standards.
Ease of Migration Between Vendor Products
My personal opinion is that you should make a vendor selection based on your criteria and stick with that solution, creating a long-term partnership to drive future requirements. You’ll waste precious cycles flip-flopping between platforms that could be spent focusing on delivering increased value to your own customers.
With that being said, if this kind of flexibility is important to you, then you should take note of how the core project and standards are implemented in each product. Especially to understand and test how easy it would be to both migrate your workload, and your delivery pipeline, between platforms.
Partner Capability
Partner Delivery Capability
If you want to focus on leveraging the platform to accelerate your business, and not implementation, then having an experienced and capable delivery partner will be key.
Even if you do plan to implement the platform yourself, you should understand if there are partners available as you might need their assistance in order to scale and/or meet reduced timelines.
Partner Support Capability
While a vendor will provide incident support and patches, you’ll still need someone to manage day-to-day operations of your platform. You’ll need to have in-house capability for this, or outsource it.
I’m certainly a believer that wherever possible and economic to do so, you should consume platform as a service capabilities or managed services, rather than building and managing services yourself. You should focus your efforts and your development cycles on value adds for your customers, not on maintaining the plumbing necessary to deliver this value.
This may not be something you need/want today, but having the option in the future will provide you the flexibility to adapt to future business requirements.
Licensing
You’ll want to ensure the project has a standard open source licenses that provide you the rights to use the software for commercial purposes.
You can find a good starting point on the main license types from the Open Source Initiative. This lists licenses that “comply with the Open Source definition”:
“In brief, they allow software to be freely used, modified, and shared. To be approved by the Open Source Initiative (also known as the OSI), a license must go through the Open Source Initiative’s license review process” – Open Source Initiative
Some vendors also provide additional protection and indemnity against patent litigation, such as Microsoft and Red Hat.
In summary, when selecting an Open Source project I recommend that you also consider some of the non-functional areas including Community diversity, velocity and governance; Vendor capability; Partner capability and Licensing.
Ultimately this comes down to firstly understanding exactly how you leverage an open source project to deliver value to your customers. Secondly, identifying and outsourcing any areas that don’t directly increase this value (such as support, delivery, development) to the community, partners and vendors wherever possible so that you can focus on your core business and leveraging the project to provide competitive advantage.
What other areas do you consider when selecting an open source project?
Photo credit: Gil , licensed under creative commons.
Opinions expressed are solely my own and do not express the views or opinions of my employer.