Post by Gianugo Rabellino (@gianugo), Sr. Director, Open Source Communities at Microsoft Open Technologies.
Five years ago I was flying back from my interview at Microsoft and jotting down a pros and cons list. I ended up focusing on one item. It was on both columns and it was staring at me.
Joining Microsoft to help their open source efforts was becoming a realistic, exciting, and scary option. "Come help Microsoft change its approach to open source" is a powerful sales pitch, yet quite the tall order.
As I signed my employment agreement I knew that the company was starting to make significant changes to embrace open source and I was joining the right team at the right time. We just had to figure out how to make it happen even more so.
There are many big companies out there but Microsoft is peculiar, not to say unique. Policies and marching orders won't get you far in a group of thousands of skilled, smart and opinionated software engineers with a culture promoting healthy debate. We decided to eat the whale one bite at a time and focus on the one thing that matters in open source: participate and let code do the talking. Start with creating, document and systematize later: data first, structure next.
We must have done something right. Our participation in open source increases by the day, innovation almost everywhere in Microsoft defaults to open source and the culture of openness has prevailed. We made it work, now it's time to make it scale.
We are focusing our scale strategy in three key areas:
Inform. This is what you would expect in terms of documentation, policies, training and tools. We have that in spades – plenty of places where Microsoft employees can learn more about internal processes, get acquainted with open source best practices, request approvals, find software, consult dashboards and the like.
Connect. This is crucial: Microsoft is so big that at any given time there will be at least three groups using the same open source technology. We cannot understate how important it is that those group connect with each other to ensure not just internal streamlining but also a cohesive approach to community participation.
Support. There is only so much you can disseminate with broadcast tools such as internal websites or packaged training. Many of our open source engagements clearly need one-to-one guidance and support. Even when we come in as consultants we strive to "teach to fish" so that our assistance can scale beyond the specific group we are helping.
We don't treat those areas in isolation and we know that a successful model has to be bigger than the sum of its parts. More specifically, it has to address the single most important issue and quite possibly the happiest problem every complex organization has to face in their journey to openness once it reaches critical mass.
Open source is easy to grasp, yet deceptively hard to master. Everyone is a book or a handful of web pages away from acquiring the basics of open source licensing, community management and contribution mechanics. Armed with the impression of "getting it," it's really easy to be carried away and jump into open source too much and too early: hey, after all is free, right? Yet, those relatively simple concepts can interact in unexpected ways and turn easy sailing into rough waters: this is where you need guidance from a group that has built experience in open source over the years and the scars to prove it.
The key in changing Microsoft as a company has been finding the right mix of bottom-up engineering and top-down executive support, focusing relentlessly on well-known open source best practices: code talks, release early and often, iterate on feedback. With that in mind we are continuously evolving an open source program that will help Microsoft to go beyond learning bare mechanics to fully internalize the spirit of open source.
One bite at a time.