Guidebook: fostering open source in a large corporate environment (part 1 of 2)

8 0

Oct 11 '20

In this series I'll present a guide on how to help your company use open source software responsibly by fully investing in it and contributing to the open source community. I believe that all companies using open source for software development should be responsible for this.

I write this following my very positive personal and professional experience in launching a significant open source initiative within a large enterprise and I hope to inspire others to do the same.

You should read on if …

you work in a large company and want to educate non technical colleagues about open source
you want to promote the use of open source in your company
you want to help your company contribute to the open source community

We'll look at the following topics. In each one I'll suggest how you can deal with some challenges you may experience in a larger corporate environment which is not familiar with the open source philosophy.

Part 1:

Why use open source?: a quick overview of the benefits of using open source. Useful for your elevator pitch when you need to explain it internally.
Open source licensing: licensing basics you should be able to explain clearly to your colleagues.
Choosing an open source tech stack: some simple things to consider when choosing your stack.
Contributing to the community: a look at the easiest way to contribute to open source projects. This is the easiest and fastest way to provide support without worrying about internal approval.

Part 2:

Sponsoring open source projects: sponsoring a project financially to help main contributors dedicate more time to the project, or to help with general project expenses.
Launching an open source project: creating your own open source project by releasing something that has been developed internally under an open source licence.

Introduction to Open Source

Why use open source?

With a quick Google search you'll find a plethora of articles professing the goodness of open source. Here are a few of the benefits that appeal the most to me, and which speak clearly within a corporate environment.

Better together

Thanks to the open sourcing of some amazing projects such as Express.js, Vue.js and Go to name only a few, all developers have free access to some amazing tools. Instead of writing functionality from scratch they can accelerate development by building on something great which is already open source.

Working this way results in better tools available for all as they are improved together by a community. It also promotes inclusivity as the cost barrier is removed for accessing these tools and frameworks.

Community security

All the source code is available to anyone who wants to look at it, including security flaws in the code and vulnerable dependencies. While at first sight this may seem like a security risk, it is actually very beneficial:

Code is visible to everyone, meaning it can be reviewed and issues fixed by many people.
Thanks to these community peer reviews, open source projects must fix their vulnerabilities. There can be no hidden or ignored vulnerabilities, something which is possible in closed source software.

Empowered developers

You'll see this as a common theme throughout this article. Fully embracing open source and encouraging your developers to contribute to the project will be a great motivation for your development team. They have the chance to work on not only your project, but also to make a difference to something bigger. This applies to developers on external contracts too.

Open source licences

You need to know about this because if you want to promote open source development within your organisation, you may need to educate others about different licence types.

When choosing a licence for a new project it's really important to read the detail to know which one suits your project best.
When using open source code you must check the licence to make sure it's compatible with your intended use.

Many licencing models are available for open source projects, which impact how the code can be used and modified by others. Well known licences include MIT, Mozilla Public Licence, BSD and GNU GPLv3. Licences are generally categorised as 'permissive' or 'copyleft', depending on how the source code can be used and whether those modifying the code for their own use must make the changes visible:

Permissive: allows a great deal of freedom with no obligation to contribute code back to the community, or to share modified code. The most well known highly permissive licence is probably the MIT licence.
Copyleft: obligates people improving or adapting the code in an open source project to share their improvements with the community so they can be integrated back into the project.

As I will explain, reviewing the licence is also an important part of choosing your tech stack. There are also tools available to scan your code within to check open source licence compliance. This can be very useful to demonstrate to internal security and legal teams that you're compliant.

Choosing a licence is also a very important part of creating an open source project, because depending on the success of the project it can make a big difference to how people use and contribute to it. In cases where somebody intends to modify your open source code to make a proprietary product, the licence could be a deciding factor in whether to use your code.

More about the different licence types here: https://choosealicense.com/.

Choosing an open source tech stack

When choosing a tech stack, developers and architects have a huge number of open source projects to choose from. Here are a few tips to help you do this in a controlled way.

Standardise your tech stack to focus sponsorship

It's not uncommon for major parts of a tech stack to be based on developer preference. With multiple product teams working in parallel this can lead to many similar but different frameworks being used in your landscape. Assuming you intend to sponsor key parts of your stack, you should aim to standardise those similar parts. For example where you use a Node.JS backend, aim to use the same framework across products, the same goes for your UI components. Doing this will allow you to focus your sponsorship on fewer technologies and give a meaningful contribution to these projects. It also facilitates cross-collaboration between teams as developers will be familiar with the stack used on multiple products.

Mitigate the risk for critical components

You must be careful when choosing technologies for critical components in your stack. You can either make sure you choose a well-supported open source project ensuring continued development and maintenance from the community, or acknowledge and accept the risk if a project is less active but provides a unique feature that you would like to take advantage of.

Some of the metrics that you can use to measure an open source project's success:

Issue turnover: too many open issues can signify a project which is not well maintained, but if no issues are opened at all this may be an indicator that very few people are using the project
Number of weekly downloads: package repositories such as NPM give a simple insight into the frequency that open source packages are downloaded
Contributions to master: Similar to issue turnover, check how frequently commits are made to master (by people, not by bots) - this is a good indication of whether a project is actively developed or not

Check the licence is compatible with your intended use

If you plan to make modifications to the code in parts of your tech stack which you would be uncomfortable sharing with the rest of the world, you should be looking for permissive licenses such as MIT or BSD. If you make changes to the core code on a GNU licensed project for example, you must open source those changes under the same licence. In most cases you'll probably find that there's no issue, but check anyway!

Contributing back to the community

If you got this far, you're probably convinced about the value of open source, both the technological and philosophical aspects. Now that you have your open source tech stack in place, let's look at the easiest way for you to contribute back to the open source world.

Many open source projects have only a few core contributors. These contributors keep the project alive. They do all major development, documentation and maintenance. The simplest and easiest way that you can contribute to open source is to help some of the projects in your tech stack with these activities.

Documentation updates - just do it!

It's easy to get hung up on corporate approval for things like this but in reality this isn't always necessary. If someone from your team finds a mistake in some documentation, it's not necessary to advertise that the pull request you're raising is on behalf of your company. Most likely the developer already has a GitHub account and there's no reason not to just raise a PR for the updated documentation. You'll need the documentation internally anyway, so the only overhead is a few minutes of preparing a well formatted pull request according to the project guidelines. Have a developer update the documentation, and it's done. The dev will feel empowered, you'll feel great having made the first small step on your corporate open source journey, and you've helped out the project core team who have developed this amazing piece of technology for you, for free!

Helping out with support requests

Many open source projects run support either through GitHub issues or a free chat tool like Discord. Your developers are working with the project every day and undoubtedly have valuable knowledge they can share with others. Every time your team ask for help, or file a bug report they're essentially taking advantage of a free maintenance agreement where a member of the community (frequently a core team member) will help you out.

This is another very simple one - ask your dev team to browse the issues channel of one of the projects you're using a couple of times a week. Let them know they are free to answer questions raised by other project users. You're not trying to create a fully fledged support team, you're contributing to a community. Imagine what would happen if everybody did the same.

Bug fixes and enhancements

This is the next step and does require a little more effort from your development team. You'll find most open source communities very welcoming of anyone submitting useful PRs for their project. Your developers will feel great having contributed a fix, and will improve their knowledge of the technology by developing on its codebase. My recommendation to start on this one is when an issue is identified by your team:

Ask your developers to review it together and see if they have an idea of how it can be resolved
You can then raise an issue through GitHub (or whatever the official bugs channel of the project is), and suggest a fix for that issue, making it clear you would like to work on it.
Assuming the proposed approached is accepted, then go ahead and fix it!

Wrap-up

In this first article we've looked at some arguments for using open source within large enterprises, considerations when choosing an an open source tech stack and how to take your first steps into contributing to an open source project. I've tried to make as many suggestions as I can to keep it simple and avoid corporate red tape. Make sure you follow your company's internal rules, but don't be afraid to challenge them if you need to - sometimes it's the only way to make progress.

In part two we'll look at how you can use this information to educate colleagues within your company about open source to help you sponsor some open source projects, and potentially release your own company open source project.

Contents