Aptira is in an interesting position in the Open Source market, because we don’t usually sell software. Instead, our customers come to us seeking assistance with deciding which OpenStack to use, or how to embed ONAP into their nationwide networks, or how to move their legacy networks to the software defined future. Therefore, our most common role is as a trusted advisor to help our customers decide which Open Source products to buy.
(My boss would insist that I point out here that we do customisation of Open Source for our customers, and have assisted many in the past with deploying pure upstream solutions. Basically, we do what is the right fit for the customer, and aren’t obsessed with fitting customers into pre-defined moulds that suit our partners.)
That makes it important that we recommend products from companies that are well engaged with their upstream Open Source communities. That might be OpenStack, or ONAP, or even something like Open Daylight. This raises the obvious question – what makes a company well engaged with an upstream project?
This line of questioning is what saw me writing what comes out as being close to a manifesto earlier this week. These are the tests that I apply when trying to decide what companies are going to be able to meet the needs of our customers during a product selection process.
With no further introduction, but with apologies to RFC 2119…
A well engaged Open Source vendor must:
- Employ an upstream team responsible for working on upstream features, even if those features do not immediately benefit items on the vendors’ product roadmap. For example, paying down technical debt, structural work to position future development, and code review of other vendors’ contributions.
- Participate in community design discussions for new features, with the best interests of users (and not their own product roadmap) as their primary concern.
- Support community provided stable branches instead of maintaining their own. This includes backporting patches, reviewing others’ backports of patches, and serving on the vulnerability management team.
- Develops patches for their own features in public, with an open design review process as well as iterative development of the code for the feature. This includes ensuring the feature is adequately documented in the upstream documentation when implementation is complete.
- Contributes resources other than developers – product managers, tech writers, devops, et cetera. Upstream projects are more than just their code, they are the ecosystem of documentation, examples, and user support that allows people to actually use that code.
A well engaged Open Source vendor may:
- Carry private patches against released upstream code in order to support their customers. They only do this when absolutely required (critical security fixes, stable branches no longer supported by upstream), and disclose to upstream when this has occurred. These patches are merged back into upstream as rapidly as possible, with customers being supported to transition to the upstream patches.
A well engaged Open Source vendor should:
- Provide continuous integration testing resources to upstream. This takes the form of both hardware and staff time. This item is a should because some smaller vendors might find this requirement unsustainably expensive.
A well engaged Open Source vendor must not:
- Compete with upstream via proprietary add-ons, even if these add-ons are released as Open Source once they are no longer a competitive advantage.
- Develop new features in private.
- Take upstream code and commercialise it without engaging with the upstream community (the attributes listed in the “does” section above).
Do you need help embracing Open Source to get whatever cool technical thing you’re working on done? Do you need a hand? Why not give us a call at 1800 APTIRA (within Australia), or drop us a line at info@aptira.com? We’d love to chat.
Up next.. Selection Criteria for Adopting Open Source Projects
