By Nithya Ruff
More than ever, traditional companies are embracing open source and find that it can get out of control if they don’t have a coordinated plan to manage it. And what do I mean by a traditional company? Companies that are pre-open source (or born before 1995). Also companies that are not in the hardware or software product space, but more in the services space – financial, telecom, healthcare etc.
These companies often do not have open source development models or knowledge in their DNA. They either did almost all proprietary development or bought from proprietary vendors. IP and patents are very important and open source is often seen as a risk. There are very few open source savvy people in the company and case by case handling of open source questions. Legal teams are nervous and engineering managers don’t have time to deal with the implications of using or contributing to open source. Customer support and an accountable vendor with a support model is highly important to these companies.
In today’s age of cloud and web-scale, traditional companies find themselves using open source to build, deploy and manage products and services. This introduces an often foreign way of developing, supporting and engaging with developers. Companies find that they need a more systematic way to scale this across the company or it introduces risk and conflicts in engagement. In this new world, a lot of the components used in product development or tools comes from outside the company through downloads or third party products. Practically all product development today includes some open source libraries or code. This is new and needs to be managed. Internal developers need to know how to use these open source tools, extend them for use and know how to engage with community on changes. Support model in terms of how to get and deliver support to customers will need to change. Through all this, business leaders have a sense that open source is everywhere and they need to do something to work with open source but don’t know where to begin or what to do.
This is how we found ourselves at SanDisk (A Western Digital Brand) a few years ago. We found that we were consuming more open source and needed to understand and manage it better. Further, we could not get our work done without contributing back. And we wanted to establish ourselves as an open source friendly company and provide visibility and clarity on our role to the community. We had not participated in open source forums and were virtually invisible to the community. And like in other companies, the legal teams were the ones who raised the flag that there was a lot of usage and that a higher order function was needed to coordinate open source in the company. Engineers also had limited time and did not want to deal with the legal and community engagement side and were eager to have a function that handled this. There was a need for broad education across the company on what open source meant and how to work with it.
Once we realized that we needed to have a strategy around our consumption and contribution, we started with an Open Source Working Group (OSWG) at SanDisk that included those who were using and could be seen as champions and knowledgeable. Next I stepped into the role of Open Source Officer and defined the role and started chairing the OSWG. My legal partner had already established a compliance review team called the Open Source Steering Committee so we now had the key components in place. The Steering Committee created a usable policy and training for all developers in the company. The OSWG serves as the clearing house for open source news – use, issues, new contribution candidates and best practices. This allows us to leverage learnings across the company and also to weigh in on questions and potential contributions. My role became the center of all things open and provided a one place to go for open source related issues inside the company and for external parties. This created coordination across 6 dimensions which I call consumption, compliance, contribution, communications and collaboration. Foundations such as the Linux Foundation and OpenStack Foundation provide a great umbrella for collaboration, events and best practices and we became members and more visible through these bodies. My other task has been internal evangelizing and communications as well as advising strategy and business functions on the role of open source in our business strategy. The strategic aspects of the open source office should include discussions on business models, business case for open source, and marketing of the open source engagement
Open source program offices can take the load off of engineers and lawyers to bring a more holistic perspective and mentoring to open source engagement. They often do not have a legal or engineering bias and can take a more strategic and broad approach to open source. More importantly, they can enable the company to be a member of the community. Open source program offices also create alignment with the business strategy and product strategy which leads to better decisions on where and how to engage with the community and on which projects. This is critical for traditional companies who are not natively open source and need to be intentional in how they work with open source. If you want to learn more about open source offices, you can read more from the blogs on this site or attend my talk at the Red Hat Summit on June 29th in San Francisco.
This article originally appeared at TODO
