The growing stature of open source in APAC

In the early 2000s, when open source was just starting to pick up, there was a lot of fear, uncertainty and doubt cast around it by some proprietary software suppliers.

But in the last decade or so, there has been wide adoption of open source software and it is now powering much of the world’s cloud infrastructure, as well as tools and methodologies that continue to shape the way software is developed.

In an interview with Computer Weekly, Sam Hunt, vice-president of GitHub in the Asia-Pacific region, offers insights on what top corporate executives, or CXOs, are thinking about open source software, the defining characteristics of open source culture and what enterprises should consider when contributing to the open source community.

What are CXOs thinking in terms of open source adoption? Or does it even matter at all, whether their software is open source or not?

Hunt: I think they’re looking to be informed. When we speak with CXOs, they are largely unaware of how much open source is being consumed within their organisation, even paid products. It’s a real eye-opener for them. Most of the conversations are around understanding how open source code is going to help them transform and deliver at speed and at scale.

The reality for any organisation is that roughly 80% of their code is based on open source projects. It’s interesting that you mentioned the early days when I was, back then, fighting for the open source cause. Now we see a complete turnaround from the likes of Microsoft, which is the largest contributor of open source on GitHub and has open sourced much of the proprietary code for its core products.

How are CXOs managing some of the open source initiatives that are going on in their organisations?

Hunt: I think that’s the struggle right now. CXOs are grappling with what open source means to their business, so they are trying to identify and understand how open source is being used. What we talk a lot about is what we call the open source enterprise, which has three key pillars.

The first is consumption – most CXOs now find that they’re consuming a lot of open source software. The second one is contribution, with a lot of them looking to put code out there for either the greater good of their industry, or their product and community.

The reality for any organisation is, roughly 80% of their code is based on open source projects

The last pillar is culture and I think that’s what most are struggling with. They are trying to understand the culture that their developers want, and how they can nurture and support that culture as an organisation. We spend a lot of time with CXOs, helping them to find a path to a supportive and open internal open source approach. The market calls that inner sourcing, but we think inner sourcing is only one part of a big puzzle. That’s why we focus on open source enterprise transformation as a priority.

Let’s dive a little bit deeper into the open source culture. What would you say would be the defining characteristics of such a culture?

Hunt: It’s a quite a simple one. The traditional nature of software development in large enterprises is to close projects out and, upon request, open them up. Open source flips that around and opens everything up and closes it upon request. So, it’s getting transparent with the code and the projects that are going on in your business for all your developers, regardless of what they work on.

There are many good reasons why they should do that. What rings true – and is of interest to many CXOs – is that when they hire developers for a project, it’s for a specific purpose and they usually have no idea what other skills that developer might have. In an internal open source ecosystem, these developers may contribute code substantially to other projects. This helps to speed up the delivery of projects without adding more developers, and that’s a big interest point for most CIOs in particular.

You talked about opening up source codes. What should CXOs consider when deciding if they want to release something as open source?

Hunt: That’s a good question. I think it comes down to the individual organisation. But if it were me, I would look at the cost of maintaining that code. Is it in line with current alternate offerings? And does it pose a competitive threat if I give it to my competitor? If the answer to those questions is not really, then they probably want to consider open sourcing it.

We’ve seen this in the automotive industry, where a lot of the artificial intelligence (AI) that goes into autonomous cars gets open sourced to get quicker and better inputs from the community. And they can still deliver a product because people aren’t buying the AI per se – they are buying a car that is well-equipped from an AI perspective.

It’s similar in banking. If you’re maintaining some closed source API (application programming interface) code, then you are probably leveraging some open source projects. But if it’s costing you a lot to keep it up to date, then that can be open sourced. We see a lot of open source API projects that are shared across countries and organisations such as banks that are transacting with each other.

One of the observations I’ve made about the types of software that are being open sourced is that most tend to be on the infrastructure side, and not so much on applications. Do you see that as well?

Hunt: If you look into it, there’s probably a statistic that says it’s relatively even. But when you’re developing an application, some of that code becomes your secret sauce, so it’s the stuff you don’t want to open source.

In addition to that, we’ve seen a real trend towards infrastructure as code. I think the industry has started to realise how good it is to use code management for replicable infrastructure. We are used to managing code for applications, and now we’re managing infrastructure as code in open source projects. It’s also less of a secret sauce-type situation. For GitHub, we have parts of our product that are open source, but we also have some secret sauce that we don’t open source.

I’m sure you know of open source suppliers that provide enterprise-level support for companies. How should CXOs decide if they want to work with those suppliers versus doing some of the work themselves?

Hunt: The key here is what should your developers be working on? If it’s supporting an open source project, then they probably shouldn’t be working for you. That’s not your core business. Organisations like the Monetary Authority of Singapore and the Australian Prudential Regulation Authority require that open source products being used within a bank are supported, so if you’re in industries like financial services, supporting open source software shouldn’t be your focus.

Instead, your developers should focus on your business and what’s driving your business forward, not maintaining products that could be purchased as support services elsewhere. I think that’s important. It’s the same reason why they turn to open source in the first place – they’re not rewriting something. They’re leveraging an open source library or an open source project, because they don’t want their developers to reinvent the wheel.

Let’s talk about what some cloud players are doing with open source projects. There has been criticism about cloud players trying to replicate some open source projects and turn them into proprietary equivalents. What are your thoughts on that, especially around criticism that they are also cherry-picking projects that generate the most economic value?

Hunt: It’s interesting and there are a couple of points here. One, the minute you cherry-pick something and start closing it off, you’ve lost connection to the source. You’re not going to get the community-based vulnerability fixes and advancements in that project. So, you’re effectively losing all the value of that open source project.

It needs to be understood that there’s nothing wrong with taking an open source project to use in your business and just relying on the open source community for updates. But if you take it and then fork it, you’re losing the collective intellectual property of the developer ecosystem. It’s a big mistake that will cost you if you do it consistently. And then, if you try and put that back out, that project might pivot dramatically and becomes invalid.

The second one is that open source projects still have licence control. And that’s something that continually gets misunderstood by businesses. We encourage those who put an open source project on GitHub to review open source licences and make sure they include a licence file in their project, because that technically and legally dictates the terms under which people can use that open source project.

Could you talk about some of the initiatives that GitHub is working on to support the open source community?

Hunt: We continue to make sure that the commercial functionalities in our product are made available 100% to our open source community free of charge. That’s the priority for us. The other is to maintain the connection between the open source community and the commercial consumption of open source software. From a developer support perspective, we want to make sure developers are getting the tools they need to maintain, iterate and innovate on open source projects.

So, nothing that we release in our product is excluded from our open source community, including things like actions, mobile applications, package dependencies, security and vulnerability scanning. That’s all included in every open source project on GitHub. It is important that we continue to maintain that because that is the heart and soul of what GitHub is all about.

What are some of the security measures that GitHub has put in place to make sure projects are secure?

Hunt: We are continually working on our security. As you know, GitHub hosts its own datacentres and we’ve released things like encryption at rest. We are constantly testing security on our own products, including security vulnerability checking. We’re increasing the value of that through our acquisition of Semmle last year and its integration into GitHub Advanced Security. That product will be used heavily to help secure the world’s open source code on an ongoing basis.