[Managing an open source project is not just about choosing your contributors.. Ã…se Stiller, breaks down the complexities of OSS software in the supply chain and introduces a new set of KPIs for evaluating communities.]
As a software vendor or handset manufacturer, your sourcing process starts with choosing your suppliers. More and more often this choice involves use of Open Source Software (OSS): – Handset manufacturers are building mobile phones with more ready-made building blocks – and more ready-made blocks are built with OSS. – More and more important components are coming under an Open Source license. Not just operating systems and application environments (see Android, WebKit, Qt, S60/Symbian, ..) but also low level drivers and critical enabling software.
This is good news for all of those who believe in Open Source as a way to cut costs, improve quality and get away from supplier monopolies and black-box software. With OSS, mobile software companies and handset manufacturers can focus on the real thing; to make money, and not how to squeeze the most out of every license and supplier agreement.
Why open source challenges conventional software wisdom Open Source in the supply chain introduces some interesting challenges; like – how a software vendor can keep ahead of competition when the repositories are public, and – how can they stay in control of the product roadmap, when all the usual control mechanisms lose their charm overnight.
There are a number of aspects in which companies will need to change processes and policies to adapt to this new Open Source world, i.e. – Sourcing process and inbound licensing – Product planning and product control – Project management and production control – Product outbound licensing to customers, partners and open source communities and IP control.
Each of these is a topic for an article by itself, but here I will focus on the first topic; how to manage open source as part of the software sourcing process.
Unfortunately the usual complexity in software sourcing will not go away with Open Source, but the challenges will come in a slightly different flavour.With OSS there will be no more…… but instead we must…Tedious negotiations over details in the contractPut in substantial amount of time to figure out how the license terms will work with the specific component, product and market.Nightly panic attacks over liability clausesSweat over the risk that we lose the rights to use and distributeTravel to suppliers in faraway places to ask nosy questions about finances and quality effortsSpend hours on understanding the impact of Governance models of Open Source projects
OSS or not, when sourcing we still have the same needs for a future proof-solution, technical requirements compliance, legal bullet-proofing and sound financials. But let’s walk through these one step at a time.
Sourcing with Open Source The starting point for software sourcing is the identification of the requirements, followed by the Build Or Buy decision (B/B). The following diagram shows how the sourcing previous works with proprietary software (left) and OSS software (right).
The first action is to capture software requirements; this is no different for OSS than for proprietary software.
Then instead of the usual RFI & RFQ (Requests for Information and for Quotation) the technical investigation of the OSS is managed in-house, and the Total Cost of Ownership is a result of internal budgeting, not the bottom line in a tender.
The licensing of OSS is generally much easier, as all the terms and conditions are known from the start – and that’s a refreshing change! I must admit though that some licenses are tougher than others to analyze, such as GPL. It takes a good technical insight to fully understand the risks.
Another thing to take into account is obligations that will be inherited downstream. The license must be agreeable to all links in the value chain.
Key performance indicators for Open Source projects Now to the most radical change; the supplier assessment and control.
Forget about traditional Key Performance Indicators as assessment tools, they won´t work. We can however attempt to identify a new set of KPIs for Open Source communities; KPIs that are measurable and offer a standardized way to evaluate the governance model. For this we must ask the right questions about the community and convert these answers into quantifiable values.
First let’s identify what is important to know about a community serving as a supplier, and why. How can we assess the community’s ability to deliver according both now and in the future?
The first two community KPIs we need to evaluate are the visibility of plans and the visibility of code.
We then need to evaluate who much influence can we exert of the OSS project development plans (as we won’t have any supplier contracts and control mechanisms). We therefore need to evaluate a third indicator; the influence over the decision process.
Influence as a KPI is multi-dimensional and therefore we need to break it down into measurable components: (the below are a first attempt, feel free to add and suggest better names).
– Decision accessibility: What does it take to get into the deciding team? – Changeability: Can we post a change request? – Openness: Can we contribute a new feature? – Priority: What is our importance to the community?
The questions above are only a subset of a more substantial list of questions that we use, but I won´t bore you with the details here.
The last resort – and one of the true benefits with Open Source from a sourcing perspective is the option to fork. This too must be evaluated and the forkability depends on factors like the modularity and documentation.
When we try to measure the forkability what we are really trying to measure is the cost of the development needed for the branch now and in the future, as well as the cost to backport changes from the tip of the tree into our branch.
In proprietary software sourcing this option corresponds to bespoke customization of the product, and the issues are basically the same. With Open Source there is a chance you will have followers that will share the burden, but worst case you are on your own.
Managing the change OSS software sourcing is a new type of strategic alliance and it takes new ways to evaluate and manage in the supply chain. We are facing a mini revolution and the traditional control mechanisms are becoming obsolete.
In this article I have dealt solely with the impact to the inbound licensing process. Naturally many other working processes are affected and up for re-evaluation in the light of this way to cooperate cross company borders.
Embracing Open Source brings a need for change and change needs to be managed. I´m sure we will see some interesting organizational theories and models dealing with these issues but unfortunately we cannot wait; we must start the change process now not to lose assets, employees or customers.
Looking forward to hearing your opinions and experience on this topic.
Ã…se Stiller
[So, what’s your open source strategy ? VisionMobile’s workshop on Mobile Open Source is an on-site crash course offering a 360° analysis of economics, licensing, governance models, communities, mobile Linux, standards and 10s of case studies and real-world insights.]