I am a strong believer in community-driven, open source innovation, especially for intelligent, software-defined networking (SDN). No network engineer today can be successful without some level of open source engagement, be it as a contributor, a user or both. Before you take the open source step, allow me to share three lessons that I have learned over the last 20 years of deep engagement in over a dozen open source and standards initiatives at various stages of maturity. Failure in one or more of these can make your investment a waste of valuable time.
Over the last 24 months, I have been contributing time to help incubate and grow new collaborative efforts within the software defined networking space. This focus on helping new initiatives become material across the networking industry sharpened my thoughts on what ‘really’ matters when you make the difficult choice to join one or several of the open source networking initiatives.
Such clarity is important. Much discussion is generated about corporate logos associated with a new initiative, projects entering and leaving news cycles, journalists pitching one project against another in an effort to gain more eyeballs, the responsible management of (increasingly large) membership fee budgets, adherence to intellectual property rules (IPR) and the folks that run a particular project.
These points are important, however, none of them should be used as indicators for success.
When confronted with a number of announcements at networking events earlier this year, I reflected on the objective and measurable criteria an open source and standards community should use to measure success, especially from the perspective of the majority of participants in the vendor community.
In my mind, it comes down to three main criteria; get these right and community success follows:
Criterion 1: Prove that incremental CAPEX spend is unlocked by the community project.
The key word here is ‘incremental’. For example, a number of recently launched community projects have been seeded by the conversion of code previously released under a proprietary license to a common open source license (e.g. Apache License, Version 2). If the code was previously authored by or on behalf of the set of organizations providing the economic pull function in the project (often operators or enterprises paying commercial vendors to purchase the project’s code and support), then the CAPEX spend potential has already been realized. In other words, if a supplier such as a software vendor or system integrator already invested to realize a potential ROI against the proprietary code base, then the fact of open sourcing it does not create any new value per se. For the supply chain, the project participation decision and pre-sales incentive must change to how quickly and broadly the project opens up to positively impact new business opportunities that are incremental to any existing supply contracts against the proprietary code base.
In addition, while the size of the incremental CAPEX budget matters, it is equally important to consider the number of points of purchase that are created by the project. For example, a project that has multiple points of purchase (e.g. through an operator with many globally-located, independently-run subsidiaries) can be significantly more profitable for the supply chain participant than a project concentrating the buy in a single purchasing organization potentially demanding large volume discounts.
Criterion 2: Check that the project governance model provides economic opportunity for all within the membership fee cycle.
Who benefits, and when? This is a question that any company considering participation in an open source project needs to consider. It is not simply a question of justifying increasingly steep annual membership fees charged by some hosting organizations. The answer to this question more fundamentally impacts the economic potential of creating commercial products and solutions from a specific open source code base or the business benefits from augmenting such code bases in a more complete solution. In a code conversion scenario, the providers of services to create the original proprietary code may hold an expertise advantage that then gets converted into decision positions within technical steering committees, community boards, marketing work groups and individual code modules. If those positions of influence are tied up during the incubation phase of a particular project, then careful analysis of the governance model of the project may be required to identify its longer-term power position structures (beyond simplistic claims of meritocracy) and a newcomer’s ability to attain them over a given period of time and level of investment.
Criterion 3: Verify that there is a stream of continuous contributions of innovative and quality code, quality assurance (QA) and marketing.
Clearly, the commonly quoted statement that ‘code is the coin of the realm’ has profound validity within open source projects. Given the fact that companies and individual contributors can fade in and out of projects, it is important to go one level beyond this statement, however. I believe that a priority analytical factor needs to be how the project is setup to attract a continuous stream of quality code contribution. An initial dump of hundreds of thousands or even millions of lines of code only increases the investment and time required to understand its utility, and future additions can cause both parameters to snowball quickly. As a lead architect at an Asian operator recently shared with me following the release of an uncommonly large seed code base for a new project: ‘this code is so complex that we estimate that a 6 months review investment will be required before we may decide on an approach for what to do with it’. In addition, statements of modularity and pluggability need to be proven with easy-to-repeat demonstrations, public interoperability tests, API specs and a clear technical and governance approach to accommodate both open as well as proprietary extensions.
The need for continuous QA and marketing contributions should not be underestimated. To simplify the point, without a consistent engagement of expert QA engineers, few open source projects create impactful releases. The larger and more complex the code base, the greater the need for continuous and, ideally, fully automated, system-level QA. Companies investing into QA contributions are often those that aim to benefit from monetizing commercial distributions of the code base; understanding their investment levels and motivations is often a good indicator of the viability of the project overall.
Similarly, open source communities seem to have taken a bifurcated approach to marketing. On one end of the spectrum, a high percentage of membership fees (sometimes in excess of 50%) collected by the hosting organization is spent on headcount and promotional activity related marketing initiatives (and this does not even include developer events that are incur separate fees!). The other end of the spectrum belongs to projects that rely on the volunteer contributions of participant companies to externally represent their initiatives, accomplishments and recruit new members. While achieving continuity in marketing contributions is hard in the latter scenario, I would strongly recommend to favor projects that invest membership fees to create an efficient technical framework for development first, and rely on the economic value of the project to incentivize marketing contributions from engaged community members.
Making a decision to invest into an open source project is complex. Creating a clear top 3 list of decision parameters among the long list of data points and assumptions associated with a particular new project can be a daunting task in itself. The above thoughts have been helpful to guiding my approach to new projects; I hope they can be useful to yours as well.