King GitHub

Open source – publishing

In the last two articles in this series, I looked at the benefits of open source, how to deal with licenses, and what to consider if you want to contribute. Here, I am going to talk about publishing new Open Source projects.

It’s easy to create a new open source project: Open a GitHub account, create a project, and push some code.

King GitHub

Before you do that for anything you seriously want other people to use, there are a few things to think about to make sure your project doesn’t end up with complicated legal issues preventing it from becoming as popular as it deserves, or even end up like many open source projects: as abandonware.

At King, we wanted to get to the point where we could publish entire new projects based on systems and code we use internally. Because we had already taken the first two steps of the journey, it was technically quite straightforward to take that last, big leap as well – the main effort was in articulating why it’s worth doing, and how to manage the value-versus-risk trade-off.

Why open source anything at all?

Our developers come up with lots of cool tech across the company, and we think that releasing some of that as open source will help us in three primary ways:

  • It helps us demonstrate to the world the kinds of code we develop at King, in a way that no marketing or recruitment brochure ever could;
  • It lets other people improve our code! Yay!
  • It lets us give back to the open source community

What kinds of projects to publish?

We have developed and use a lot of systems, tools, and integrations at King. Which ones are good candidates for publishing as open source?

Our answer here is still evolving as we consider projects from across King, but we have a few guidelines we use when looking at a proposal:

  • Is it something we use at King, or plan to sometime soon?
  • Is there something unique or compelling about it that makes it stand out as useful to others?
  • Is it put together in a way that makes us proud?
  • Is there an internal champion (a person or a team) that wants to make it a success?

If the answer to these questions is Yes, we’ll seriously consider it. The last criteria we apply is one related to risk: Is releasing it likely to harm King in some way? If yes, then we will probably not release it publicly.

What about the risks?

Publishing systems that we use carries some real potential risks. Before publishing a new project as open source, we look at whether publishing it is likely to harm King in a significant way.

For example, a project might inadvertently reveal a critical detail about how we make things work at King, or it might attract a patent troll by showing how we have inadvertently implemented something that has been covered by someone’s software patent.

We might also release a system that has a big security hole in it, which means that someone might exploit that hole rather than help fix it. This is definitely something where more eyes on the code would help.

Practical considerations

Once we decided it would be a good idea to publish our own open source projects, we needed to think about a lot of the things that go into a real open source project. Below is a list of what we did, and how we did it.

Which licence to use?

There are lots of OSI-approved licenses from which to choose, and for us it was key that the licence used would encourage as many people as possible to use and contribute to the software.

This means that it needed to be permissive rather than restrictive, be well known, and widely used, and not have a strong ‘copyleft’ element to it. In the end, we settled on Apache 2.0 as meeting all of these criteria – it’s a great, simple, and very permissive licence.

What about a Contributor Licence Agreement (CLA)?

As discussed in the second part of this series, many open source projects have a separate agreement that regulates contributions to the project – so we also needed to create our own!

Fortunately, there are great resources available that help with this, including a site that has a Contribution Agreement Builder.

In the end, we created an individual and a corporate CLA that we believe give the correct protections for all parties – contributors, King, and the project itself. Feel free to have a look at the previous links.

Where should we publish our projects?

There are lots of sites that host open source projects, but the choice was very easy for us. As we have recently migrated most teams to Git for source control and to GitHub Enterprise internally, we chose https://github.com.

It’s a great, modern, distributed system that works really well, after you put a little effort into learning how it works.

GitHub also allows you to set up a company portal, and ours is at http://king.github.io/.

Managing approvals

Like we do for many internal processes at King, we created an Open Source Project project in the same system we use to track defects and projects: Atlassian JIRA.

This facilitated anyone proposing a new open source project very easily, and allows everyone at King to see which projects are being proposed, weigh in on the proposal if they want to, and see what decisions were made in the past.

Once a project has been approved, the last and perhaps most important step remains – making sure the project does not suffer the slow death of ‘open source software that nobody knows about.’

Publicity

The minimum publicity we expect when publishing a new open source project is an interesting blog post on our Tech Blog, explaining what the project is, why it’s interesting, and who it’s for.

The developer or team that published the project are also expected to spend some time on the project, interacting with people using it, perhaps tweeting about it, and otherwise nurturing the community around it.

King Open Source projects

A few months after going live with the process, we have published our first three projects, and more are in the process of being evaluated or made ready for open sourcing.

Apache Software Foundation

Please check back here and also follow TechAtKing  to see what the innovative teams at King come up with over the next few months!

Final thoughts

Open source software is thoroughly mainstream today, but a surprising number of companies are still reluctant to go all the way. They shun open source because of the perceived risks rather than find ways to manage those risks pragmatically, and in the end lose out on what is arguably the biggest source of awesome software available to anyone.

Do you have a story to tell, or a question to ask? Feel free to get in touch with allan.mertner@king.com.

Allan Mertner

About Allan Mertner

As VP Engineering at King, Allan tries to help all of the development teams to be the best they can. This means providing a great environment in which to work, relevant training, awesome systems and tools for everything from builds to collaboration, quality assistance services, subject matter experts on a wide variety of topics, a relentless focus on quality, and support for a healthy, agile ways of working. Allan lives in the UK but has also lived and worked in Denmark, Germany, France, and Canada at various times, so his origins are somewhat obscure. A hint may be that he enjoys salty liquorice more than almost anyone else.

Leave a Reply

Your email address will not be published. Required fields are marked *