Here in Paddy Power Betfair, we have a small open-source movement.
We have a Github organization with a small number of projects. We also have a small group of developers who contribute from time to time.
Today I’ll describe how it started, why it started and why I believe it plays an important role.
Why did it start?
Two reasons !
Create a place where we can party!
The first reason was to create a place (github.com) and a set of tools (Github, Slack, our technology blog) where a dev culture could form that was independent from our company’s project obligations and procedures.
I believed the motto “if you build it, they will come” and the kind of people I hoped would come, would be enthusiastic and generous with their time and knowledge. It didn’t matter how many people joined.
The second reason for creating an OSS movement was to help make knowledge sharing as easy as possible. Let me elaborate!
Our open-source projects should be as self-describing as possible.
- Awesome README.md pages
- Code samples
- Stable well written unit tests
- Projects that are easy to fire up and start using.
When a project presents itself this way, and when the whole world can see it and explore it without requiring explicit permission, it allows developers to lurk, learn and one day contribute! And when you remove as many barriers as possible, you increase the chance of attracting the type of developers you want.
Let’s contrast this with a more traditional set of projects.
- Each project is assigned a group of developers.
- Each dev group is explicitly granted access to the source code.
- Individual developers are focussed only on their own code base and there is no obvious way to explore other code bases.
- There is less motivation to create first-class documentation for each project because the respective developers know their project well and the benefits of great documentation are not as obvious.
- Knowledge silos can build up and good dev practices are less easily advertised.
How did it start?
Our colleague, Rob Delaney, announced PPB’s second Hackathon of 2017. Together with another colleague, Ainul Habib, we used the hackathon as an opportunity to open-source a simple test library.
As simplistic as this may seem, the following steps were enough to successfully open-source our first library!
The building blocks were:
- Ownership of the Github organization https://github.com/PaddyPowerBetfair.
- A licence under which our code would be open-sourced.
- A code of conduct.
- A description of how individuals can contribute to this project.
How to keep it going?
I have describe how it started. Now to describe how it was sustained over the following six months.
A library to showcase the benefits
Now that we had the proof-of-concept behind us, we needed to open-source something meaningful. We needed to have some skin in the game!
I chose a project called
Open-sourcing this library provided the following benefits.
- We moved code that had no official steward into the public eye.
- We created documentation that did not previously exist.
- We created a pipeline that ran unit tests, integration tests and static-analysis tests.
- As this library was written in Scala, we created a
rabbitmq-clientbuild for Scala 2.11 and Scala 2.12. This allowed us to effortlessly migrate applications that depended on
rabbitmq-clientfrom 2.11 to 2.12.
We now had concrete evidence that open-sourcing was a perfectly valid way to manage our code!
Growing the community
Given that our OSS community was less than 10 people, all of whom were PPB employees, I created a PPB Slack channel dedicated to open-source conversations.
At this point, the channel more closely resembled a Twitter account than a healthy Slack channel as it mostly comprised short announcements of little achievements and the occasional request for help.
The channel gradually gained more followers and, to my relief, the occasional conversation broke out from time to time.
Planning the next six months
With two projects successfully open-sourced, it was time to look to the future.
To this end, I accepted an offer of help from our Agile Coach, Cristiane ‘Coca’ Pitzer.
Together, we created a series of monthly milestones leading up to the June 2018 timeframe. The overall goal was to create a vibrant OSS community where code and development practices were created, maintained, discussed and shared.
Some milestones were missed and others were achieved but overall, the OSS movement gradually improved with each passing month.
Examples of milestones included adding missing code samples, adding missing documentation or writing a tech blog. Taken separately, these were small tasks but over time, they improved the projects and helped grow the community.
PPB Technology Blog
There is a synergy between the practice of contributing to open-source and blogging.
In my case, I had a need to document how our
rabbitmq-client pipeline published newly built artifacts to maven-central.
Since every part of this pipeline was open-source, there was no requirement to hide this documentation in our internal wiki. This was an opportunity to publish it on our newly established tech blog at https://ppb.technology.
There are benefits in knowing that your blog post will be available for the whole world to see, for all time.
- You try extra hard to get your facts straight.
- You try to capture all relevant details on a single screen. The end result hopefully something readable with a beginning, middle and an end.
- Googling your blog post is probably easier than using the search engine in your company’s wiki.
Discovering Inner Source
One of Coca’s initiatives was to reach out to her LinkedIn network and set up some video-conference calls with people who had experience building open-source communities. It was during one of these calls that we first heard the term “Inner Source”.
Inner Source refers to the practice of managing your company’s internal projects as if they are open-source projects.
- A documented governance model
- A guide on how to contribute
- The same awesome documentation, code samples, tests and ease of discovery that you would expect of any good open-source project.
Many companies have projects that have been in “maintenance” for a long time. The code is still in production but there is an inch of dust on the code pipelines and documentation. PPB is no exception.
The potential benefits of “inner sourcing” some of these legacy projects is genuinely exciting and something that we hope will spawn future blog posts.
The driving principle behind everything you have just read is to enable knowledge sharing!
When knowledge is highly available:
- Knowledge silos are harder to form.
- Developers may come and go but the knowledge is always right there with the project.
- Good practices are advertised. Bad practices are called out.
- Developers can lurk on interesting projects and, one day, contribute.
Without this underlying principle, a project may gradually shift focus and become something else over time. This can disorient contributors and users and negatively affect how the project is perceived.
It is important to keep this principle in strong focus. This is where governance comes in!
The project must be guided by some governance model (for example a Benevolent Dictator for Life or a Technical Committee) and if something occurs that violates this principle, it is called out and fixed.
Our governance model is very much in its infancy and we welcome any feedback from anyone with experience implementing governance models in open-source projects.
We plan to open-source another library. This time, however, we want to share the experience with our community. Let me explain!
As previously mentioned, an open-source project contains documentation, code, tests and a pipeline. This is more work than can be achieved in an 8-hour day with a group of people who are new to open-source.
The plan is that prior to the event, we will complete 90% of the work required to open-source a new project. On the day of the event, we will help attendees to assemble these pre-made pieces of work together. Our job is to ensure that everyone feels like they experienced the whole process while contributing something important.
We will consider it a success if everyone enjoys the day and understands the steps needed to create a new open-source project.