Establishing an Open-Source Community Inside an Organisation

Transcript

Shane Hastie: Hey, folks. Before we get into today's podcast, I wanted to share that InfoQ's International Software Development Conference, QCon, will be back in San Francisco from October 2 to 6. QCon will share real world technical talks from innovative senior software development practitioners on applying emerging patterns and practices to address current challenges. Learn more at qconsf.com. We hope to see you there.

This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I'm sitting down with Nate Belay. Nate is in East Coast USA and has been doing work on setting up open source communities within organizations. Nate, welcome. Thanks for taking the time to talk to us today.

Introductions [00:52]

Nate Belay: Thank you, Shane. It's really an honor to be part of this podcast and speak to the InfoQ community. Thank you for having me.

Shane Hastie: The place I like to start is who's Nate? Tell us a bit about yourself and your background.

Nate Belay: Nate is a recent grad, 2020, from college. I have three-years’ experience working in the software technology realm. For a couple years, I worked as a program manager where I was overseeing the R&D teams, the engineering teams, and making sure that they deliver some of the innovative products that we were working on. It was for a company that was based out of Boston called PTC. There, I was exposed to a cultural shift within the organization in terms of development as they were moving to a SaaS development model. And there were inklings about could we adapt some open source development models? They were very early on in their lifecycle for that.

Then after working there for two years, I moved to Google as a technical program manager in the Android organization. Being embedded in the Jetpack subteam, I was exposed to a lot of open source development. The team, I realized, was very mature in their open source development lifecycle and it's embedded within the culture and the ethos of Android. I had the experience to experience both worlds where one company was early on and the current company is very mature in that. That's what inspired me to come here.

Shane Hastie: Why would an organization embrace an open source culture? Perhaps one step back, what is an open source culture?

Defining an open source culture [02:33]

Nate Belay: I look at open source as really taking a step back from technology. I look at open source as an opportunity for a group of people to collaborate, to develop and improve any kind of artifact. It could be a recipe for food or it could be a Wikipedia page or it could be a software product. It's a very open platform for creative people, like-minded people to create a community, and then contribute to the betterment of whatever artifact that they're working on. That's how I look at open source from that lens. Within the organization, that type of mentality really helps make the culture of the company be more open and transparent. My argument is the principles and the guidelines of open source could be applied within an organization, within the context of an organization, and make that really an open culture within the organization.

Shane Hastie: For an organization to move in this direction, you mentioned open source principles. What are some of those key principles that they would need to bring in play?

The need for clear open source principles [03:44]

Nate Belay: Some of the core principles that they need to bring in play is having a clear mission. To become an open source, you really need clearly defined mission of why you're doing it and who you're doing it for. One of the reasons that you want to do that is as you're managing a community at scale, you would want to instill some of the best practices and values that community stands for. That's really easy for a community to diverge from what you want, especially if you are a company that has an open source product and the community that you're supporting does not align with your values, that could reflect on the brand of the company. You want to be really careful about who you're targeting or who the open source project is for and some of the contribution guidelines for that. I think clear mission is very important.

The other one is having, I kind of mentioned this, but clear guidelines. These guidelines could be three types, in my opinion. One is about the ethos of the community or the product that you're trying to build, which I touched upon just now. Then the second one could be technical guidelines and principles. These could be best practices around, for instance, API design. When contributors of the open source community try to merge in code, you can have best practices embedded either within the development workflow or something that's written down so that those contributors can have an understanding of what's expected of them as they're contributing. Very technical type of guidelines and principles to do that.

The third could be about code of conduct. In my opinion, this means how the community works together among themselves. This could be being respectful, being inclusive, and things like that. Because one of the challenges with open source is the lack of face-to-face communication. You might be working together or getting pulled requests from someone from across the world that you've never met. As you're reviewing code, the likelihood that the review could be very challenging or can be uninclusive is very high. You might need to have code of conduct to instill the principles of when you're referring to people, these are the accepted values that you can't violate those, and you need a community manager to make sure that those are adhered to.

Having a technical understanding of the values from technical perspective that you want to instill on the product that you're building, code of conduct for the community members to work together. And also the ethos of why you're building the product and who your core customers are or who the core consumers of that product are so that people can build empathy. There are a few things that I can touch upon as well in addition to the guidelines. One of them is making sure that open source community that you're trying to build that starts within the organization is not affected by the org structure that you have within the organization.

Meaning, I believe it needs to be very separate and a flat hierarchy where people are seeking out other people based on their expertise and not their level at the organization. Even if a VP tries to submit code, they'll need to go through the same process that has anyone else would do. They would need to go through code reviews and things like that. Because in a community, the need of the community comes before the need of the individual. We need to make sure that people are seeking out other people because of their expertise.

The last one is very product-centric. Meaning as you're building the product, you need to make sure that all the products that you're using, the third-party products that you're depending on are also open source. Because if you're trying to build a thriving open source community, and if the only people that are able to use that or able to build on top of that are within the organization, meaning that's behind some API gateway and you need to pay for access or whatever, that doesn't provide a very thriving community. All the kind of resources, as much as possible, all the dependencies that you have need to also be open source so that anyone can check out the code build, test merging code. Those are the recipes that an organization can think about before starting an open source community.

Shane Hastie: How can this go wrong?

Pitfalls to avoid [08:12]

Nate Belay: That's a good question. I think if the organization is not ready, it is very easy for things to evolve into a closed source system. Meaning it starts off to just get some eyeballs and improve the brand of the company and people start to rely on the product that's being open source. There's a whole community around that. And if the major contributor to that community is one organization or a couple of organizations, they might choose to change that to be closed source. At that point, external people who were depending on that, now all of a sudden don't have access. We've seen that happen a few times. For different reasons, this could happen. That's very detrimental, in my opinion, to the organization that's doing that and also to the community that was relying on that.

Another way it could go wrong is if the code of conduct doesn't get adhered to. Meaning if you're seeing that in code reviews, people are giving really harsh and mean, rude feedback on a code that you're trying to merge, the likelihood that you'd merge a code next time is very low. If the contributors are not there, then really it doesn't really make sense to have even an open source community and invest in that. Those are a couple of things that could go wrong. Obviously, there could be more, but I think those are the highest priority.

Shane Hastie: Turning that around, let's take the way we give feedback, for instance, on pull requests, on code reviews. You mentioned guidelines. But what level of enforcement? Or is it enforcement? Who takes ownership when they see things not going the way they'd like?

There needs to be stewardship of the community [09:53]

Nate Belay: I think the ownership should be whoever is the steward of the community and the community members themselves. For instance, it's very common for a project to be open source, but it's one company that's doing majority of the development. Anyone can look at those source code and merge changes, but the main steward could be one company. In that case, it's up to that main steward to be able to make sure that those are adhered to. With the current evolution in AI, for instance, a lot of that can be automated. We have tools right now to track specific keywords and that could obviously get even smarter to understand context so that it automatically flags that.

It is upon the main steward of the community to make sure that there are tools and practices in place to enforce the community guidelines. But a step further than that is if people are bought in into the community that they're contributing to and they see behavior that's not in line, I would argue it's also on them as they also have a responsibility to flag those to the community manager or whoever is in charge of facilitating that community to a program manager or whatever. I think a combination of tools, automation, and self-flagging, a lot of that could be weeded out.

Shane Hastie: You mentioned that you feel that this needs to be separate from the organizational hierarchies. If I'm a leader in an organization and I want to get the benefit of even internally open sourcing the work on producing, whether it's code or whether it's other artifacts, other types of work, this means we've got to actually step back from, perhaps, some of the organizational structures and incentives and rules, perhaps.

Open source can exist alongside organisational structures [11:51]

Nate Belay: I think that both could be true. I think the open source community could be happening in parallel to the organizational structure. Meaning the VP or whoever is in charge could give the blessing for that community to get started and then to also become open source. Because within the context of our organization, I can't start an open source community just because I want to, because there might be things that I'm not aware of. For instance, regulatory issues or secret projects or whatever. First of all, you need to get alignment with the hierarchy that you have already to rely on that to get started.

But once you have started, the community should have its own charter and should have its own leadership. Not in the original sense of have a boss, to have your own boss, but a group of community experts or experts in that specific topic can have their own forum to manage that community. But to get started, I think you need a blessing from someone within the organization who has authority to get that kick started. But as soon as that happens, it is important to make sure that those are very separate and would have their own charter. It is possible that after that community has started, that open source project started, that leadership might decide, "Okay, I am investing in people who are working on this but we are making the code available for everyone. Why should I do that?"

If the open source community is thriving, let the open source community do that, that is possible, and pull the plug on the project. There's no way around that. Other than that, hopefully, the community outside of the company is strong enough to carry on the work. But that's definitely the constraints that we're working with, because at the end of the day, they have to approve the budget. But hopefully, people work under best intentions in mind and when they start these projects, they're intentional that we want this to be very separate from what we're doing inside of this company.

Shane Hastie: Again, from a leadership perspective or even as an individual contributor, what proportion of my time and effort I would be putting into the open source versus my paid job? Or if, really, both is part of my paid job, how do I allocate my time?

The dilemma of time allocation [14:16]

Nate Belay: I think it depends on the value of the product. Let's say the feature that you're trying to develop really belongs to be open source, like part of the open source, and what is the priority of that feature. It's not a question of what percent of my time doing open source work versus what percent of my time should I work on the internal projects, but more of I have a feature deliverable that I need to get out now, where does that belong and where would the end user benefit the most if I put it inside of the company or more become open source? That's a decision that needs to be made at the start of a project.

But after that, it is possible for you to spend 100% of your time doing the open source project as long as you're delivering that feature. Because that feature could be helpful both not just for the open source community but the company itself because we might have other products that are going to rely on that feature. When we are doing our annual planning, when we're doing our feature planning, whatever process that we are using, we should decide, "Okay, where should this live? Do we have any competitive edge on it?" If not, then as much as possible, we can push things out to be open source and we can dedicate most of our time there. If it's not, and that feature should be developed inside because of proprietary knowledge, then we can balance that as needed. I would say I would take that more on a feature-by-feature basis and not as a blanket percentage of time commitment.

Shane Hastie: What are the other gotchas? What are the things that you've seen that people need to be aware of before they go down this path?

Some potential mistakes to avoid [15:55]

Nate Belay: I think that the biggest one is not having a clear what the end product we want is. We assume that just because we have loose connections between, "I think a community kind of exists, let's get that rolling." Without really doing the research of, "Okay, how many people would be interested in this?" Because there's going to be a lot of investment. If you try to do an open source community, most of the time, that ties together with having other investments like a common infrastructure for building and testing code for instance. That has its own cost associated.

Let's say you go through all of that set up, getting approvals from legal and whatnot, but the community is not there really and no one really benefits from it, I think that could be a wasted effort. Although I think that's rare because most of the time, having things open, someone would find it helpful and learn from it at the minimum. But before doing a lot of investment, I would encourage people to actually do the legwork of, "Is there a community around us and should I continue my infrastructure related investments to support the community?"

Shane Hastie: Anything else you'd like to tell the community about being part of and establishing open source within our organizations?

Benefits for the organisation and the community [17:18]

I think I can expand a little bit on why someone would want to go down this path. I touched upon it throughout my conversation here a little bit. But why would you want to set up an open source community? It seems counterintuitive, especially from the context of an organization. Some people refer to this as inner source for the project is open within the organization, but it's not publicly available. I tend to see them with the same lens because they should have the same guidelines and principles. I think before, one of the benefits of setting up an open source community is the sense of inclusion and ownership that employees would feel if you start an open source project within the organization.

One of the reasons is if you ask people... Because if you have open source and you merge a change, you're displaying the values and the core principles of that community. So naturally, that code would go through rigorous testing and reviews and that would really help other people understand the work that you're doing. And also, if I'm reviewing someone else's code and I'm giving them feedback and they immerse that code, even though I'm not directly working on that feature, if that feature ships, I have, "I've made an impact on someone else's product." And it makes someone feel fulfilled at some level.

Another thing is also it provides inclusion. Like if the organization has this kind of development model, open source thrives on meritocracy. Like I said earlier, it's not really based on the organizational hierarchy, but what can you do to the community and what's the quality of your contribution. That ignores some of the biases that other people have. At the same time, it could be a problem as well. It's a double-edged sword. I talked about the downsides of the risks of it being very hidden or not knowing who the other person is, but it can also have a benefit because you are judging someone solely by their output. That's one of the benefits why someone could go down this path of it provides your employees with inclusion and a sense of ownership.

Another one is better resource neutralization and resource as an infrastructure resource. What I mean by that is usually, open source ties itself with a shared infrastructure for development. If we have each developer provisioning their own VMs and running jobs there, that inspires and motivates low quality code development because you're not really incentivized to optimize resource usage. As companies move to an open source model, they usually also have a central infrastructure management unit that manages the servers for them. What that gives benefit is each person's job to the server, each person's request to the server can be dynamically scaled up or down.

That also speeds up the cloud readiness, the digital transformation of an organization because the actual development model supports that type of infrastructure. It doesn't need to be the big cloud vendors, but an organization can have its own server pool, and then provide service to developers in a fair way where users can be scaled up and down based on the community usage or your usage. That way, you're also having an impact on the environment. Because as teams move towards a shared infrastructure and a cloud type of infrastructure, their compute energy usage goes down. So you're using less energy, which translates to better environmental impacts.

There was one study that Etsy reduced their compute energy usage by about 50% by switching their development to the cloud. That can help an organization speed up their cloud migration if they actually change their development model to become open source. That is if you want to put numbers onto why would I want to do this. There could actually be some cost savings. In addition, for instance, you might not even need to buy expensive laptops for the developers.

If you have a server pool that you can build things on, you can have a laptop on the lower end for the developers and they can send a request to the server for the actual build and testing. That way, you minimize the cost of the laptops that you need to provide for the employees as well. So there are some cost savings by going through this migration. Those are a couple of things that I don't think I mentioned about the benefit of why encourage teams to go to the open source development model.

Shane Hastie: Thank you very much. Some interesting things and some ideas that people can explore. If people want to continue the conversation, where do they find you?

Nate Belay: I'm on LinkedIn. Natnael, N-A-T-N-A-E-L, Belay. I believe we can link it on this episode.

Shane Hastie: I'll put it in the show notes.

Nate Belay: Also, I can have my email as well on the show notes. I'm open for discussion. Like I said on my introduction, I'm now responsible for the Android Jetpack Program, which is an open source so I get to interact with the open source community. I also had an experience where trying to start an open source development model within an organization was challenging. I've kind of had an experience of both worlds. I'm happy to engage with other people who have similar or very different experiences or any questions around this because it is an evolving artifact and we're seeing more of this in the world with open source AI models. Everything going open source. This is definitely more of a trend now. I'm sure people have experienced their own experience, so I'm happy to engage in conversations there.

Shane Hastie: Right. Well, thank you very much indeed.

Nate Belay: Thank you. Thank you for inviting me over. Let's continue the discussion with anyone who's interested. Thank you for having me on the show and thank you to the listeners.

Mentioned

• Android Jetpack Program
• Nate Belay on LinkedIn