How New Companies Can Contribute to Open Source



Swapnil Bhartiya:

I remember when I started my own journalism career, it was 13 or 14 years ago. I completed my course and the first job I got was with Linux For You Mag, so from day one I've been an open source journalist. Back in those days, one of the challenges was that we had to go out and educate companies that why you should use open source, what are the benefits. But now, almost everybody is using open source. The question is "who is not using it and why not?". So the new challenge that we see is that these new users of open source don't actually understand how the open source process actually works and why you should send your developers to events or why they should contribute in their office time. So, since you have been for so long and you deal with a lot of customers and clients, do you see this pattern there? The companies don't understand?

Jacques Nadeau:

Yeah, I think so. Let me say that at the start you're absolutely right, which is that one of the good things that has happened with open source is that most enterprises now have an open source first strategy and it's the only time they're doing a technical evaluation. They need to also look at what options available open source. And so that level of corporate top-down pay, this is an important part of business strategy and should be considered. I think it's very good. I think that businesses are very good at taking care of themselves, and so that's kind of the nature of a commercial entity at some level. And so I think that people are very much like they appreciate all of the benefits of open source, because open source allows you to protect yourself against lock in, the ability to extend a product if you need to and the ability to just solve a problem if you can't get someone else to solve it for you because it's super important to your business. And so I think that a lot of people appreciate that part of open source when they're looking at it from a commercial organization's perspective.

I think that people don't really understand how it works. I think that at the end of the day- I think there's two parts to that. First of all, realistically, if you look at most... well, I don't know if it's most. A large number of the Apache projects that have been started in the last five years or so are developed probably... maybe 70-80% of the development time that goes into those projects is by one or more companies that are directly benefiting from the success of those open source technologies. And so it's a form of paid open source or sponsored open source, right. And so the idea that all open source is done by people in their free time in their garage is not true for a lot of these projects, the super special projects that are given a lot of options. It does exist, and there's definitely cases where they're very successful.

And so my perspective on it is that if you think in that context, it's not going to be realistic that every organization is gonna be able to invest developer time directly against adding new features to open source projects, but I actually think that the easier win for most organizations is that they can contribute to the quality of open source projects. Making sure that you are reporting back things you see and collaborating to fix them and probably helping apps to fix them sometimes is I think what would be the goal. I would first say, it should be a goal for most enterprises using open source software is that if you're benefiting a lot from this, find the time to help with quality. I think that realistically most organizations, unless they have a really important feature that they need are not going to be able to contribute the amount of time that it takes to build something from scratch, but they can definitely improve their product. And that is true both providing bug reports, but also when possible trying to allow people a little bit of time to help fix things.

There's actually a funny situation that just happened very recently. We had a customer who found an issue with our product and then it turned out that it was actually an issue with the open source library that we were working on, and so the customer actually went and patched the open source library themselves because the engineer was like "Hey, I see what's going here, and I think I can fix this". So, fixed it and then we were able to incorporate it faster and give it back to them. And so, that's a nice thing when it happens. As people driving open source, you can't expect that to happen very often, but it's really when it does, and I think just try and embrace that.

Swapnil Bhartiya:

Right. I've talked to a lot of people, the way some people sum it as that if you are consuming in open source, there are two ways you can contribute. One is either through currency or through code. And as you rightly mentioned that not a lot of companies do have developers resources that they can actually invest, so either they sponsor product, or when they work with a vendor who is either maintaining or contributing to the upstream. So they are indirectly, through currency, supporting that work, because you are working with a vendor. That vendor is, as you gave an example that the developer patched, so you are giving feedback to that vendor and that vendor is putting all those changes to upstream. So I really don't think that if you're touching open source in any way, unless you're just taking the whole code, forking it, running it your own fork, then you are creating a lot of technical dirt, then you will not even survive, no point.

But I think if you consume open source, you are going to help open source one way or the other, there is no escape; you will be working with a vendor who will help. I think that's a neat thing people don't understand but it happens you gave a very good example there.

Jacques Nadeau:

I think you're right, and I think the other thing that's interesting is one of things that Apache really focuses on is community over code. Which, people who are not familiar with it, it's probably a little strange when they hear it but it's the idea that the success of our project is driven more by the community that's working on the project and their collaborations intentions and driving towards good solutions then it is about one piece of code. So we actually talk about it in many cases that are PMC and or so committers to a project that don't write code. They might provide documentation, packaging, they may just help out a lot in testing.

And so I think it's very important to appreciate all of those things and that's actually something, they go at people who are using open source as well. Even if you can't sit down and be a developer who's going to write the next future or fix this bug, that doesn't mean you can't add value to open source and help this community adapt. In many cases, those things are actually sorely missed in this community. You've got developers that are happy to write code but are less comfortable writing documentation, so if someone else can cover it and say hey, here's a couple of quickstarts or a tutorial, that can help out a project a lot.

Swapnil Bhartiya:

Right. So if there's a company who is using open source and working with a vendor or something like that and the company itself, they don't have developers, they're a small start-up, a small company, they don't have enough developers. When they don't have developers they cannot even become part of the community to go in there and... So how can they realistically contribute even a bit, what are the options? Since you have been in the community for so long, what are the kind of opportunities for them to participate with how creating it as you know "why should we even bother with that, we can just pay somebody and be done with it". But, how can they get involved?

Jacques Nadeau:

I think going back to what I was saying is that it doesn't have to be a developer that's writing code. Right? If you have a person who's using your product, like use case is a good example. One of the challenges open source people have is that they want to figure out ways to test their product, and so they can come with all sorts of unit tests and synthetic data. I work in data a lot, so you're always coming up with synthetic data sets, some are examples of potential problems. Customers can sometimes, depending on where they are, share their use case and share details of their use case. And that can help the customer, because it means that the open source project can incorporate that set of use cases into the test suites that are run every time someone does a release, so that helps out the users, but it also helps out the community leave the product in the better, the quality of the project can improve.

So that's one example but there are many examples of "Hey, come in and tell us what you're doing. Tell us what's good with the product, what's not good." Remember that many people are volunteering on a project. One of the key things is that Apache, well, there are many people that are paid to work on Apache projects. Their relationship to the Apache project itself is something that is a person to the chair of the organization. So it's that relationship that actually defines what they can do. So while they may be being paid by someone because that person is very interested in adding certain features or functionality to an open source project, the relationship is a personal one and so that person at the end of the day is the one who's actually making that commitment.

So you come into a community, appreciate those people for what they're doing, where they're giving their time, when they're spending their time and what they're caring about because open source development, while it may be in many cases paid, is still something you have to be passionate about in order to do a good job in the community. Coming into the community and saying "Hey, these are the things that I learned, these are the things that don't work well...", these are all really good things to do. Say "Hey here's some documentation. I just wrote up a short thing about how we do our use case and how we use the product to do that use case.". Do a little video. All of those things are very helpful to open source and can be done by anybody, it doesn't have to be done by somebody.

Swapnil Bhartiya:

Right. And it doesn't cost anything, you're just sharing your... I was talking to someone a few weeks ago at DockerCon and when I asked, his thing was "The biggest challenge for us is that..." because they are fully open source project and they're like "I wish that our customers would just tell their story, we don't want anything else. Just come out and tell that you're using our product, how you are using it, what problems you faced, how you solved them. You go ahead, download from GitHub, we don't care, but at least tell us the story. That will help a lot and Mindshare and developers to get feed- Yeah, that's excellent point.