Hiring Open Source Maintainers is Key to Stable Software Supply Chain

185

This is  the 2nd and final part of a series on measuring the value of open source developers. Part 1 can be found here.

It’s been almost three years since the Open Source Group was established at Samsung. In that time we’ve grown quite a bit. Now that we’ve had some time to get our feet on the ground we’ve decided to take a look back at our impact.

Why do We Need an Open Source Group Anyways?

Samsung is on a multi-year journey to become both a better consumer of open source, and a better contributor and leader in the projects that end up in our products. The reasons for doing so are quite clear to us: While it’s easy to use code that’s made freely available, it’s risky and potentially quite expensive to rely upon it long-term, unless you are proactively working within the community.

The reason it’s potentially risky is actually the flip side of two of the biggest benefits of open source: development moves extremely fast, and a vibrant developer community leads to more diverse contributions. The result of this combination is that the APIs and the features you depend upon today could be entirely different tomorrow, depending upon the will of the contributor community.

On the surface this might sound like a bad thing for developing accurate product roadmaps, but it isn’t; this is a sign that the open source model is working as intended, and that this is probably a pretty healthy and durable community. The companies and individuals who are actively involved and making meaningful contributions to the community get to have a say in the direction of the project, whether this means long-term stable release management or dramatic short-term enhancement.

Mitigating this risk is fairly simple, and it’s the basic premise for the existence of our group. If you want the full economic and technical benefit of consuming open source, you hire people who are already influential in the projects that matter to you. You then ask them to continue doing exactly what they do: write great code, manage great releases, and contribute to the overall stability of the project. This is the single best way to ensure stability and predictability in your software supply chain.

Our Developers Provide Internal and External Open Source Leadership

Our group is largely constructed of maintainers and committers who do just this. They are active in the open source projects that have strategic importance to current or future Samsung products. After three years, we’re finding the benefits to be enormous.

Samsung open source contributions

Our group is highly productive and produces a massive amount of upstream code, given our size. When we look at Samsung’s top 30 strategic upstream open source projects[1], the overall company is responsible for almost 4% of total lines of code committed over the past 3 years, as measured by Jon Corbet and Greg K-H’s gitdm tool. These projects include Blink, BlueZ, Cairo and Cairo/GLES, EFL, Enlightenment, GStreamer, Linux, LLVM, OpenStack, Pixman, Servo, Skia, FFmpeg, U-Boot, Wayland, Weston, Webkit, Xen, and a few other minor projects.Not bad when you consider there are hundreds of other organizations participating in these projects.

Of these contributions, our small group of 18 people has contributed 41% of the lines of upstream code. This is also quite impressive considering we didn’t exist 3 years ago and that we represent less than 4% of the total number of developers from Samsung that contribute to these projects.

Samsung OSG upstream graph

Note: for the purposes of this analysis, we specifically excluded Samsung-initiated projects like Tizen and IoTivity, since we know our contributions to those are very high. That said, each of these (particularly Tizen) makes extensive use of upstream open source.

Each new member of our group brings a great deal of experience on day 1 of employment with the company. We quickly realized there is immense value in sharing this experience internally, as there may be hundreds or thousands of other engineers who rely on the same code. Internally we do a lot of consulting by teaching other Samsung employees to be better at contributing upstream themselves.

Taking this a step further, we also realize that we can never hire all of the maintainers or committers in all of the projects we want to; this is true for any company. However, we can create programs to develop future maintainers from within our own ranks, with the help and guidance of people from our team who have gone through this process.

Open Source Leadership is Immensely Valuable

Pulling it all together, the implications are very clear: If you want to protect your investment in strategic open source, you should have a dedicated team working within those open source communities. Its members need to be competent and respected outside of the company, and need to be given free rein to do their work. At the same time, you should never miss the opportunity to expose others to their talents and experience, because mentorship is how these communities can cultivate  future maintainers. Combined, these things have made a meaningful impact on the way Samsung builds software and how we work with open source.


1: Blink, BlueZ, Cairo and Cairo/GLES, EFL, Enlightenment, GStreamer, Linux, LLVM, OpenStack, Pixman, Servo, Skia, FFmpeg, U-Boot, Wayland, Weston, Webkit, and Xen, plus a few other things like xkbcommon.

This blog is re-published with permission from the Samsung Open Source Group Blog.