Companies, governments, and other organizations big and small are working with open source to achieve their goals. Teams range from barely considering it to betting their whole business on open source. Putting some structure on this spectrum has helped me think about and evolve Microsoft’s open source program. I’d love to hear if you find it useful, how, or why not.
What’s in a name?
When I first started thinking/talking about this, I use the term maturity with people. That unfortunately implies a judgement and it turns out that people don’t want to think of themselves (or be thought of) as immature. Most of the terms that came up had that same characteristic: sophistication, evolution, depth, … The antonyms are off-putting. Fact is, there is no one right answer here — there is nothing inherently better or worse about being at a particular point on the spectrum.
That led me to engagement. We really are just talking about what kind, what role, how much, … your engagement with open source plays in your organization. Naming is hard. I’d love to hear alternatives.
There has been a lot of churn the community lately with new licensing models, mergers/acquisitions, and many, many new players. Reflecting on how and why organizations engage in open source work helps folks on the inside plot a course, make plans, achieve goals, and helps folks on the outside of an org understand what the org is doing and what they might do in the future.
Remember, this is not about the quality of anyone’s open source code, or community, or the technology at all. Rather it’s about how an organization thinks about and “does” open source — what role does it play in their operations?
The model below captures some discrete states of open source engagement. Most teams are simultaneously at multiple engagement stages. That’s fine. Being proficient is more than adequate for some, while others seek to become masters. You may also want to mix and match characteristics from different stages. Go for it. Make it your own. The key is that your level of engagement matches your organizational goals, whatever they might be.
Microsoft itself is all over the map in how different teams participate in open source. This model helps us understand that and intentionally make changes. Or not.
A great way to use the model is for each characteristic, test how it feels in the following phrases:
- “My team’s approach to open source is _______”
- “The value of open source to my team is _______”
Often these will cluster and give you an overall sense of your engagement. Characteristics where you self-assess lower than others, or where you hope/need to be, represent areas for additional effort.
- Denial – Somehow open source does not apply to your domain or is the wrong approach.
- Prevention – Put up technical, legal/process, or regulatory barriers to considering open source.
- Countering – Attack open source with FUD
- Limited – Use grudgingly allowed in pockets
- Experimental – Some early adopters deeply engaged in isolated areas. Some releasing.
- Ad hoc – Localized processes and policies. Wild west to locked down. Inconsistent outcomes.
- Fearful – Limit risks. Sequester teams. Tightly scope engagements.
- Not rewarded – No career incentives. Even disincentives for undertaking “risky” behavior.
- Silver bullet – Open source is going to transform the company!
- Marketing – All the cool kids are doing it. We want to be cool too.
- Recruit/retain – Emphasis on high profile, high volume “open source” hires
- Incoherent – Engagement not coordinated, localized or no policies/processes
- Systematic – Central policies and processes around legal and security topics
- Tooled – Tooling in place to track and guide open source engagement
- Broad – All teams are free to engage and understand the “rules of the road”
- Engaging – Work with communities, contribute fixes/features
- Efficient – Seen as a valuable tool for “time to market”
- Value – The business understands the value that use/release does and does not bring
- Fundamental – Bet on using or releasing open source for core capability
- Rationalized – Policies and processes are continually reassessed and automated
- Open – Technical and process discussions default to open
- Healthy – Engagement health is integral to engineering/business reporting
- Rewarded – Open source engagement explicitly recognized as a valued activity
- Integral – Open source is integral to business model from the beginning
- Liberating – Business understands its true value-add and builds on that with open source
- Disruption – Open source as a means of disrupting and quantum innovation
- Shared control – Foundations, community initiatives, joint projects, “coopetition”
- Proactive – Engage broadly to improve quality, security, function as a goal in itself
Microsoft and the model
It’s no surprise that you can plot Microsoft’s course in open source quite closely in this model. Not so many years ago we were in denial about the movement if not active countering it. We then transitioned to concurrently being tolerant and driving the hype. We did a few experiments here and there, and went all in on some projects just to see what would stick.
Today I think are getting pretty proficient as a company. We have solid policies and processes with automation thoughout our engineering systems tracking millions of uses of open source. Some 20,000 Microsoft folks have some work activity on GitHub and overall the system is pretty efficient.
Of course, our engagement is not uniform. Some teams are still catching up and others have sprinted ahead to fluency and a sprinkling of mastery. This is a never ending process of revising business and technology strategies, evolving thinking, working with communities. It’ll be very interesting to see where we are in a year.
I’d love to hear what you think of this model and if/how it relates to your organization or view of the world. I certainly don’t claim it is universal or the final word. It’s a stake in the ground that we have found useful. How about you?