My colleague Jeff recently shared an outstanding model to assess organizational readiness, challenges and aspirations when it comes to participating in open source.
I was familiar with this model since Jeff has driven it at Microsoft for a while and I've had a chance to learn from him and his team, and I was immensely happy to see him share it in long form with the world.
Shortly after there was a provocative follow-up question by LFDL's Ibrahim Haddad: how do you advance in this ladder? Ibrahim offered some ideas that range from securing executive support to being involved in the TODO Group and having a comprehensive component inventory.
Inpired by all of this, I wanted to share some of my experiences after ~10 years driving open source change at Microsoft. Many learnings are our own, some come from our partners and even from customers that often cross-pollinate our mutual open source journeys.
Embrace the branches
The journey to pervasive open source engagement in an organization isn't linear. Imagine this.
Some years from now we'll reflect back on how hard it was to move past the initial frustration with open source. You helped hire a dream team of open sourcerers but not much change was happening. Everyone was on their own mission, and at times you felt hopeless. But today, what a difference! You operate proactively, control your own destiny and people know you and come to you for guidance.
Until they don't. Often times, a new "hype" branch will stem from a more mature stage in your open source journey triggered by a competitor, a new product, a new market or just the ups and downs of this crazy industry of ours.
Resist the need to exercise extreme control over branches. Ask your mentors what would be a reasonable level of structure you can offer to the branch, then aim even lower: anything growing rapidly or moving a lot of resources carries politics that will only drag you down.
At Microsoft, I've had the privilege to collaborate on projects that range from bland components in places like Windows Update to cutting-edge research projects and anything in between whether under the Office brand, the Microsoft brand or even no brand.
I work on Azure, but in my head I've known at least 4 Azures since PDC09. I lived through Microsoft Open Technologies, Port 25, the Open Source Technology Center, the Enterprise Open Source Group and many other, more obscure acronyms.
Each one of those branched in hype more than once but all of those branches contributed to the corporate culture and organizational knowledge and proficiency we have on open source today.
So branches eventually merge. And the best that you can do is to showcase the business value of engagement maturity and capture the learnings: at times, I've had to engage my colleagues at the Microsoft Library or the Microsoft Archives to "deposit" some knowledge that is too fragile for our document management and retention systems.
Secure a bench
There's no escaping it: executive support is core to the success of your open source strategy, regardless of the organization. Maybe the CEO is your sponsor and the ideologist behind your open source strategy. But even if she isn't, you don't always need "inorganic" (authoritative, mandated, dictated) executive edicts.
Sometimes you can create the conditions for executive support without calling in the air cover. You should still actively advocate but by bringing an external perspective, maybe shining a light on what a competitor or an adjacent industry are doing with open source, you can generate enough energy for executive support.
That's why I often suggest that internal open source advocates remain fully informed of their context: industry, trends, market research and intelligence. I fully believe a market research engine focused on open source technologies is part of the charter of those in charge of open source strategy, in no small part because they can attract and retain not only tactical executive support but a support bench that can serve the strategy long term and across the spectrum.
Invest in the program
You can have the vision and the sponsors, maybe even the hero hires, but if you don't have the program and the resources for the program, you'll always depend on heroics and coin tosses - and open source always outpaces chance.
Ibrahim recently shared his take on the responsibilities of an open source program office. I don't see program offices as the place "where open source happens" but rather the place "where we invest so that open source happens".
That doesn't mean it's where all the decisions are made, or where all the talent is hired. It's not where other teams dump or outsource their duties. It shouldn't be a bottleneck and it only makes sense if it scales to "community scale". It's not only a place for people to come, but a launchpad from where people goes to the rest of the organization.
And even with the program and the funding it's in the execution of an open source program (the tooling, the processes, the compliance efforts...) that a competitive differentiator can be made. No wonder so many in the industry collaborate in the TODO Group to do so: to elevate the initial bar.
There is no shortage of debate on what success looks like for an open source program office. But I think the program must enable the organization to know where they are in the engagement spectrum at any given point in time, anticipate where they want to be and what is in the critical path to get there.
Without the program, the organization is instrument flying and everything is opportunistic. You wouldn't short change your organization in security response or customer support - don't do so in the open source program either.
Care about the product
Whether it's disruption, competitiveness, engineering economics or something else, organizations look at open source to derive value from it and make them better at doing what they do. This is why open source programs should deeply care about the product, whether that's a solution, a technology portfolio, a societal value proposition or something else.
The program will often times need to have an opinion on whether open sourcing is appropriate for a particular initiative, or how exactly to adopt what types of open source components to get something done. They need to understand the business imperatives for the product, and need to read the product tea leaves.
To me, this means spending quality time with product leaders, developers/engineers and everyone else that makes the business tick. You might not establish a functional relationship with those individuals, but a personal one is worth the time investment.
What are their top technical dilemmas? What keeps them up at night? What resource challenges do they have? What are some types of fire drills or distractors they face? And then, more specifically, what types of communities their members are part of, where do they get external direction or pressures?
I might be biased since I'm a product person, but in growing open source programs I believe having product management types can be really helpful, maybe even developing "product advocates" (on a rotational basis) that can represent and advocate for product when the program conducts business with their natural partners.
This might derive into actual work for the open source program office. For example, if different teams are building in diverging build systems, or obtaining components from disparate sources, or lack alignment in terms of tooling, the open source program office is often times expected to resource, develop and maintain services for product units. Product is always a customer of the program office.
Finally, caring about the product as an open source subject matter expert also means being able to discourage the business from doing things that only look good in form.
I spent the first half of my career at Microsoft advocating for open source by hyping it up, and the second half advocating for it by keeping teams away from pitfalls. For example, our team has written "why NOT" guidance that sets realistic expectations for teams.
This raises the bar so that the projects where we invest become more clear and our participation in the community is deeper. It also strengthens the case for resource asks, or makes it clear there wasn't a case to begin with.
There is business value, in pushing for maturity and sophistication: teams can no longer afford to be the "hype laggards" of an organization, let alone an industry, so you're helping them hit the market at an advanced stage, too.
Develop the culture
I'm often reminded by Stephen Walli of the famous "culture eats strategy for breakfast" lemma. At some point you realize your organization is well disciplined and resourced to execute most of the things we expect an open source program to do (it might even be in autopilot) but there's no purchase order you can approve for culture.
An open source culture permeates the entire organization. It should be an integral part of recruitment and talent development: that certainly hasn't gone unnoticed for Facebook. Conversely, the absence of it -or lack of authenticity- can alienate your value chain. If you sell software, it certainly aggravates the enterprise sales problem described by Luke Kanies.
At Microsoft, I spend a significant amount of my time talking to others about open source culture and taking concrete steps towards developing said culture. Developing an open source culture should be an observable event, and while you can measure many aspects of it, I've often found success best described in terms of moments of truth that should be as easy to digest and understand as the culture itself.
A powerful mechanism I've found is to structure most training and communications around the culture theme. Often times, this takes the form of sharing learnings: finding culturally-relevant events in our open source journey that can serve to illustrate what we mean by a fledging (or failing) culture instead of trying to enumerate or dictate the aspects of the culture that we find strategically convenient. It is true: culture is on a low-strategy diet.
In times of change it's hard for organizations to find their internal or external voice and this is why functions like PR or Marketing are such an important part of developing an open source culture. In absence of cultural tenets and a strong "why we do this", those functions operate opportunistically with the results that we all love to critique.
Something that has worked wonders for us is developing talent as ambassadors of the culture, equipping them with that voice. PR and Marketing and other functions can facilitate this, understanding that we lead with a transparency and enablement spirit.
When speaking, I spend little time introducing myself before showing a collage of thousands of Microsoft contributors on GitHub. When it comes to culture, my goal is to speak on their behalf and the other way around. Over time, I've found this speaks louder and more institutionally than one-offs, and one-offs can go wrong at any time, but especially when your maturity tree has a lot of hype branchs and people organically stay on message, less because of the policing and more because the message makes sense.
Don't go in alone
Yours is not the only organization trying to derive value from open source. Your competitors certainly are, but so is everyone else in your value chain. Chances are that anyone that Accounts Receivable or Accounts Payable is touching is also trying to do something with open source. Therefore, units like partner and business development, customer success, customer support, etc., must all think ecosystem first.
And by ecosystem of course I mean commercial and community partnerships. We talk about open source foundations and some working groups as if they're extensions of the standards work of the nineties, but ecosystem is far more complicated than that. Venture capital is a reality in open source today, and we can expect academia, government and system integrators to play an increasingly stronger role in this phase of the cycle.
Final thoughts
If you've read this far, you've probably noticed I've mentioned a good number of functions that, in any medium- to large-sized organization, are performed by different (maybe even competing) divisions and disciplines, so you might be wondering about how open source change agents in an organization can or should work with their colleagues.
I've been fortunate enough to have worked with open source at Microsoft across the entire org chart: field sales, corporate marketing, business planning, talent development, partnerships, product strategy... and with and across disciplines ranging from legal to customer support. In those capacities, I've interacted with different shapes of an "open source program" sometimes running in parallel and sometimes not running at all. And I've done so since 2010, under evolving leadership and evolving internal perceptions about open source at Microsoft.
I can talk at length about those experiences in the hallway track at many upcoming open source conferences and I certainly look forward to collaborating with thought leaders to document some learnings. But one of the most inspiring leaders I know at Microsoft summarized what best describes the mechanics of an impactful cross-boundary open source collaboration: being humble, helpful and harmless.
This is why sharing cultural learnings is so powerful: you let someone else tell the story for you, and it's invariably helpful because it's immediately relatable. This also means that I proactively look for opportunities to find out those learnings. I proactively seek to participate in RCAs and post-mortems, and in those efforts I mostly stay silent (=harmless)
Yet I can confidently say that it is in and through those painful moments that I've felt we've made the broadest, most authentic and longer-lasting cultural changes with open source at Microsoft.
In summary:
- The journey to pervasive open source engagement isn't linear. Don't try to control a hype event, just observe it.
- Sometimes the case for executive support is self-evident. Develop an open source market research engine.
- You can have the vision and the sponsors, but you can't shortchange your program. Operational excellence is the next frontier of differentiation.
- Product empathy isn't optional for an open source program office. Knowing what's a non-ideal case for open source can be very valuable: people can't afford to lag in the engagement model.
- Lead with culture and don't go in alone!
Top comments (0)