Open sourcing your company’s software is a great way to showcase your technology and attract new talent.
But traditional enterprise organizations often bristle at the idea.
I learned this when I joined my current company, AXA. I never imagined I’d end up working for an enterprise. In truth, I was hoping to work on the start-up scene, and couldn’t picture myself wearing a suit and tie. But, I was talked into an interview by a recruiter and eventually won over by the surprisingly great work they were doing, and the opportunity to work with engineers worldwide (and the lack of ties).
As an engineering manager, my role included hiring talent and engaging with our global engineering community. As part of that initiative, I began exploring how open sourcing our software would allow us to contribute to the community, generate more interest in our technology, and attract more potential new hires.
Predictably, I faced resistance at first, especially from folks in non-technical departments who didn’t fully understand the open source concept. But, together with a group of other interested colleagues, we managed to get the project off the ground and were soon open sourcing some small projects as proof of concept. Fast forward to today, and we’ve successfully open sourced many projects and are beginning to see the knock-on effects on recruitment and community engagement.
If you’re looking to kickstart an open source initiative in your enterprise organization, the good news is it can be done! Here I’m sharing my quick guide to getting started. I’ll begin by laying out the benefits and the risks (and how to mitigate them), before sharing my seven steps for launching open source within your nervous enterprise.
The benefits of open sourcing your technology
So, why think about open sourcing your projects in the first place? The benefits are many and will vary depending on your organization, but here are the five that were most relevant to AXA:
- Talent attraction
To reiterate, open sourcing projects is a great way to showcase your technology and engage with the engineering communities. The success of an engineering org depends on its engineers, and finding and recruiting great people isn’t easy. Publishing your technology on open source allows you to reach more people who aren’t already in your network. - Fixing or improving existing open source projects
Across the AXA group, we use hundreds of open source libraries and tools in our development and day-to-day engineering activities. Open source is a wonderful way to share knowledge and bring together different technologies to build better software. As users of the system, it’s our responsibility to give back, either by submitting fixes for bugs or security issues, or enhancing the original library or project with additional features. - It can help the community
Publicly sharing small (or large) pieces of the projects or products we develop can greatly benefit other folks in the community. This can be challenging if there are concerns about sharing pieces of particular projects, but it’s just a matter of properly isolating the parts you’d like to share from those you want to protect. - Contributing to research papers and experiments
Some of our teams actively collaborate with universities on research papers, proof of concepts, and experiments. By open sourcing the code related to these experiments, they can be easily tested, extended, and other developers or researchers can learn and replicate them as needed. - Allowing for projects that must be open sourced by their strategy
There are some projects that by their nature must be partially (or completely) open sourced, such as those that aim to have a wide adoption or are being co-developed publicly with another partner. Being shared publicly not only increases their adoption, but also engages further with the developer communities (for example, in the case of SDK or APIs) and boosts transparency.
The potential issues and how to mitigate them
Of course, open sourcing your software also creates some potential issues. These were the most significant risks for AXA, and this is how we mitigated them:
- Technology that isn’t suitable for open source
Is a project coupled to other internal services or not engineered to be shared? In this case, projects might need to be adapted before being open sourced. - Projects that aren’t appropriately maintained
When we share small utilities that have a different lifecycle to our more products, they may not be maintained regularly. To mitigate this, we aim to share projects that are actively maintained, where issues, questions and pull requests submitted by external contributors are addressed in a timely manner. If we’re sharing a no-longer maintained project that might still benefit the developer community, we clearly flag that it’s not actively maintained to avoid frustration. - Legal risks
It’s vital that we use the right license when publishing via open source. To mitigate this, we should educate ourselves, automate as much as possible, and also raise awareness to our engineering teams about the different kinds of licenses and their implications. - Violations of code of conduct
Open source exposes our engineering teams to the public, so it’s important to create a safe space for them as well as our external contributors and users. Make sure you’ve defined a code of conduct and a process to escalate any problems in the case that it is violated.
Launching open source within your enterprise
Now that we’ve established the benefits and risks (and how to mitigate them), it’s time to start thinking about launching your open source initiative. Here I’m going to walk you through how we did it. Again, this process will vary from enterprise to enterprise, but you may find it helpful to consider our seven key steps:
- Getting buy-in from senior leaders
This step can’t be overestimated. Having sponsorship from senior managers is key. I found that documenting and sharing the above benefits and risks/mitigations with senior managers was enough to reassure them and get their buy-in. Of course, remember to curate your list of benefits and risks based on your specific context. - Getting formal validations and setting up your open source program
Next, to formalize the initiative, I defined and created an ‘open source program’ together with some other interested colleagues. Together, I worked with this group to run the entire project. This stage includes onboarding the right people and following any internal processes to formalize and validate the program. - Defining the open source process and its governance
This stage involved defining what process teams have to follow to open source a project. Remember to maintain this process and keep it up to date. We defined our process together with some development teams and kept it as simple as possible (engineers submit a request to the open source program; we vet the project’s suitability and/or help the team adapt it; we seek approval from senior leaders in the case of large or strategic projects; we check third-party licenses, open source compatibility, and software engineering practices that can help the developer community use it and contribute, such as documentation and testing; and we work with the team to launch the project). - Creating and maintaining the common files and templates
Next, we created and maintained documents such as the code of conduct and open source licenses. We aimed to adopt widely-accepted standards and practices rather than creating our own. To keep things streamlined, we reuse these files and templates across all teams willing to open source (though development teams can still customize them if their project requires it). - Raising awareness
Then we worked to raise internal awareness of open source opportunities. To do this, we explained the above benefits and risks to both technical and non-technical people across all layers of the company. Not everyone has an engineering background, so we started with the basics and never assumed folks have knowledge. For example, what is open source? Why do we want to open source some assets? What do we need to be careful of? - Supporting development teams
Even some development teams have little experience contributing to open source so it was important to educate them on open source best practices (for example, I organized a few sessions around open source licenses), support them on how to interact with third parties and/or external contributors, and make sure they have a clear understanding of the definition and application of a code of conduct. Also, it might seem obvious, but without the explicit means (time and sponsorship, etc.) to work on open source topics, development teams will not succeed. - Spreading the word
Finally, we needed to spread the word across the organization. To directly reach the engineering teams, I organized regular presentations at internal events (such as the global engineering summit) and across our global communities (including engineering and data science). At the end of the day, the engineering teams will be the folks actively working on projects that might potentially be open sourced so your main efforts should focus on them.
Reflections
In an enterprise organization, the road to open sourcing technology can be long. Even now, we have the foundations in place, but there’s still a lot more work to do. We have to iterate the defined process on a continuous improvement cycle, finalize the publication of some of the projects in our pipeline, and continue to raise awareness internally so that more folks adopt the practice. But we are well on our way, and I’ve learned that it is possible to launch open source within a large company. If you’re starting out on a similar journey, I hope you can learn from our experiences.
