From Zero to Open Source Hero
The open source movement is one of the most exciting and important collaborative initiatives in technology today; and every aspect of our digital lives now weaves open source software or technology into the software and hardware stacks which deliver the experience we interact with. As open source software continues to play a strategic role in the construction of the technology platforms and services, it has become paramount to integrate engagement with open source into the overall engineering experience to ensure you can innovate faster and to retain key engineering talent.
At the September 2022 Linux Foundation Open Source Summit in Dublin, I spoke about Fidelity’s journey to embed open source contribution into our engineering culture. In this article, I will expand on some of the key topics I touched on during the presentation including key planning considerations, the challenges you may meet, and how to measure success.
Culture Shift
When our journey began, Fidelity had a newly formed Open Source Program Office (OSPO). The OSPO was tasked with advocating for open source contribution across the organization, setting the guardrails, and defining the processes. Having this support was essential to kick-start our journey and to reduce the cognitive load on our engineers, especially when working with our broader organization and reducing the potential friction between the developer and the open source community.
The first step on our journey began by us looking at scope. With open source, it can be tempting to focus on contributing big features right out of the gate. But to affect the foundational change open source requires, you need to start small, understand the core elements of your challenge, learn from the experience, then think about scaling. By creating a three-month pilot program with a small group of engineers, we were able to gain experience with key building blocks such as how to engage with the open source community and reduce friction in our process.
As we progressed through our pilot program, a few clear challenges began to emerge:
- Working on small changes proved very time consuming. A great deal of effort was spent casting a wide net, researching a wide breadth of small changes, and learning the unique ways each open source developer community functions.
- Small changes can be perceived as not delivering big value. Articulating the value of small contributions would be paramount.
- Scalability was a challenge. Even with small changes, you still need a robust method to assign engineers to changes so they can make their first contributions.
Building a Strategy
As a result of our learnings from the pilot program, we created a three-stage model which aligned with the outcomes we wanted to achieve.
Stage 1: Nano Contributions
The first stage in our model, centred on enablement, closely resembled the work we did in our pilot. There were several key criteria we looked for when identifying opportunities for change including the following:
- Each change must be able to be completed in 1- 3 hours. So why this period? At Fidelity, we are fortunate to have learning days every Tuesday — an entire day dedicated to learning — and we wanted our engineers to be able to complete their changes within that day.
- Each change must be able to be completed by first time contributors. Although engineers tend to make several nano contributions before graduating to more complex changes, the aim of this tier was to get engineers started.
- Each change must promote the practice of open source development as a new way of learning. We wanted open source contribution to be a way for our engineers to learn new skills, both to apply newly learned knowledge but also to bring the open source practices into how we worked.
- Each change must help demystify the process of contribution. With each new contribution made, open source as a practice became less daunting.
Measuring Success
To measure success, we leveraged the Objective Key Results (OKR) model. I am a huge fan of this model as it translates goals into tangible outcomes. We had a single objective and three Key Performance Indicators (KPIs) that produced easily identifiable trends and were easy to communicate across the organization. Our KPIs were as follows:
- Total number of contributors
- Total number of contributions
- Drop rate (ratio of unsuccessfully started contributions vs. successful ones)
The drop rate proved critically important as we identified areas for improvement as we optimized our process with the OSPO.
Overcoming Challenges with Teamwork
One of the initial challenges that surfaced in the nano contributions stage was the drop rate. If a contribution took more than a single learning day to complete, it tended not to get completed at all. More often, this would happen not because of a lack of technical knowledge, but rather because of the learning curve or understanding of our process. An additional challenge was that our initial contributions pace was only a steady trickle. We needed to do something more to generate excitement. Enter: the “Mini-Jam.”
Facilitated by seasoned contributors, the “Mini-Jam” was an activity which ran multiple times a month to bring first-time committers together to work on their contributions in a group setting. This created a space to ask questions, seek help, and get quick feedback. In addition, it was a terrific way to ensure the tacit learnings from our more experienced committers were shared with those new to the process, building a ground up community around the activity.
Stage 2: Project Clusters
In the Nano Contributions phase, we identified our KPIs and generated the excitement needed to kick-start our contributions. But our next challenge was to start building expertise in projects which were aligned to the products and services we build at Fidelity and to contribute more complex changes. Enter: Project Clusters.
Project Clusters focused on building expertise in key projects linked to the work we do.
For example, if you are working in the observability space, you may focus on projects in open telemetry. Or if you are building platforms underpinned by Kubernetes, you may focus on a subset of this ecosystem. Focusing on a limited set of projects creates more focused learning which, in turn, enables you to contribute larger bug fixes (small features) and begin to increase the impact you have in the community.
We focused on a few key objectives in this stage including the following:
- Increased expertise: As changes become more complex, they help the engineer gain greater expertise working with that particular open source community and projects.
- Increased impact: With more complex changes comes more impact on the open source project itself.
- Channel for learning: As with Nano Contributions, the Project Cluster stage was yet another opportunity for engineers to learn new skills and build their knowledge of how the open source community works.
In this Project Cluster stage, we continued to track the overall number of contributors and contributions; however, the one metric that mattered (OMTM) was the number of active contributors being recognized by the community for our contributions. This simple metric enabled us to understand if our impact needle was moving in the right direction.
Challenges with Scalability
A key challenge at this point in our journey was to continue to scale. When we began to spin up project clusters, our steering group quickly became overwhelmed with coordinating activities aligned to continue enablement and with running numerous Mini-Jams which cut across all the stages. To address this challenge, we moved to federate the steering group model.
Creating small steering groups around each project cluster allowed our engineers to have full autonomy in the areas they were passionate about and to be free to determine what was needed to succeed in that space. Each project cluster steering group was chaired by an engineer who maintained close alignment with the central steering group to ensure consistent direction.
Reflection
In retrospect, there are four key areas which have been critical to success.
Time
As mentioned previously, at Fidelity, we have an entire day each week dedicated to learning. This time was the springboard to catapult our contribution strategy. As the time is “timeboxed” for learning, it enabled us to ensure developers had the time to engage with the communities. In the absence of dedicated learning time, ensure your developers have time to contribute. Perhaps seek dedicated days for open source contribution (dojos, hack-a-thons, etc). If you have community of practices, these could be an alternative vehicle to help carve out time for contribution.
Communication and Support
Communicating the importance of open source contribution as a practice is something which you will need to do consistently. Be clear in your goals, in your strategy, in your measurement, and in communicating success stories. Forming our steering group, with developers passionate about advocating and promoting our open source efforts, enabled our success in driving the change.
Measurement
Before you start, identify what initial success looks like using mechanisms like Objective Key Results (OKRs). Pin outcomes to KPIs to help communicate success and understand where improvements need to happen. Progress is a great motivator.
Rewards & Recognition
Embedding open source contribution into how you work changes how you work. And like all engineering change, it is important to celebrate the behaviours you want amplified across your organization. Be consistent and open, using a variety of mechanisms to do this to ensure you shine the spotlight on your change agents and empower them to continue to move the process needle.
Embedding open source contribution into the DNA of an organization’s engineering culture has many benefits including accelerating innovation in products and services and enabling engineers to apply learning and to bring the “outside-in” to continually improve how you work. Though with change comes challenge, it is important to remember: every journey starts with one, single contribution. So, use it as the springboard do amazing things!
’Til next time.
