As open-source becomes increasingly mainstream, communities are growing with people from all around the world who are passionate about code. There's a load of unwritten rules (not to mention insider jokes). New collaborators can butt heads with the old guard, creating conflicts within communities, or worse, driving software forks. Or, in extreme cases, they can kill a project.
In response, Matt Hicks, vice president of engineering for Red Hat OpenShift has created "the eight unwritten rules of open-source that Red Hat believes when followed, will drive innovation, collaboration, and ultimately make for a successful project. I spoke to him to get the lowdown of what they are and why they are needed. But before I go into detail, here's the list:
- Get to know the community and the people who participate in it.
- Put technology before individual business goals.
- Put the community “first” first.
- Beware of “pay for play” and unbalanced communities.
- Be open.
- Think “derivatives,” not “forks.”
- Contribute wisely.
- No crying.
Hicks explained that his role at OpenShift involved responsibility for most of the emerging products. "I love the challenge of how do you really build these self-sustaining healthy communities with a lot of different players in there?"
Hicks explained, "We decided to write down the rules as we see them that can hopefully help make open-source more viable for companies that want to attach to it as well as individuals that fall in love with how it changes software and want to eventually get into it." So, let's walk through the rules...
Get to Know the Community and the People Who Participate in It
Hicks believes that the open-source community is a bit like a family where people are seeking praise and respect from others. "What do you want to do? You want to write code and you want others to use it, and be in awe of it."
However, a healthy community involves a lot of other tasks besides coding, such as adding testing and automation, reviewing other people's code, and going through the documentation. This means people need to consider where their contribution can be most valuable and it might not be in coding. "Doing some of the other tasks shows that you are here to contribute and not just push your own agenda."
Hicks explained that the natural enthusiasm of new people to jump in with code can be problematic:
"You come in with this really, really cool networking revision to make because you’re a networking developer. So you submit that change, but that change has a bunch of knock on effects and maybe you're not an expert in those areas. This can create problems with some of the security configurations or with some of the storage integrations, you can actually make a patch or contribution that actually creates more work for other people. This gets tougher and tougher as communities grow. You can imagine the diligence the Linux kernel has to have. Or a big project going live like kubernetes in the container space, where you really have to make sure that you know not just your little area but the impacts around you. "
Put Technology Before Individual Business Goals
This problem is about the tension between enterprise and open-source. According to Hicks, the most common example is where companies have a million lines of code that they wrote inside the walls of their company. "You think it's awesome and so you dump it on an open-source community expecting that they also think it's awesome. It never happens." It's done with good intentions. "Their perspective is they're making a huge contribution, this is their intellectual property that they're contributing in and in most cases, they really, really want to be well received."
Then there's the situation where communities feel that a vendor offers their code up so that a feature is adopted and its maintained forever. "You get a lot of conflicts. Working with the open-source community, it might be a feature that I want, but how can I do this in a way where it's beneficial to the technology. That’s really the way to do it, so that there's mutual benefit."
Put the Community "First" First
The reason for this step is because companies will say 'ok, I’m comfortable with releasing some code. It’s a big step on my part, I’m going to give away some intellectual property from my business. But it probably means that what I really want is to control the usage of this is to make sure I have a healthy commercial business. I'm going to try to insert control by a specific license or dual license. I'm going to put pretty stiff trademark rules where you can contribute to me but you can't use the name of the project except under my constraints.'
It's a common approach according to Hicks and one that almost always fails.
"You just never see adoption because most of the people that are going to contribute see through it pretty quickly. You have to be comfortable with giving the community some aspect of creativity and control."
Beware "Pay for Play"
Sometimes the benefits of contribution are one sided. When deciding what communities to contribute to, beware of "pay for play" scenarios or communities in which a single entity has an unbalanced amount of control (especially when those entities are for-profit).
Hicks notes, "You could end up with little to no influence over the technology and contribute to a marketing budget for someone else."
Openness is something that people struggle with in a world where we're encouraged to think about competition and competitive advantage. Hicks explains that OpenShift is more open than most workplaces:
"Even in the planning where we determine what we're going to work on, it's open. Our storyboard cards and different functional steps are open because we've found that it's much more effective for us to keep our intentions very clear. We've stitched together a lot of different open-source projects and when you do that I think people can always start to question or doubt what you're trying to accomplish with it."
This is not without moments of anxiety and an awareness of competitors tracking your progress. Hicks concedes, "But if you really embrace this as your development model it's a very powerful development. We try to be incredibly transparent with every aspect of what we do as a company and our community contributions. You understand our priorities and that's going to help us."
Think Derivatives, Not Forks
Forking has been commonplace in open-source communities. "Traditionally, it often meant that when there was an argument, someone cloned the code and started a parallel community."
Then GitHub came along and took the same mechanical step in a more positive way."Having the right to really fork, take the code base, rename it, keep all of the code and do your own thing with that. It's a really powerful aspect of open-source."
Derivatives mean you can specialize. Hicks notes, "If you look the amount of different Linux distributions that are out there, those changes largely all roll back into common projects whether it's the gnu project or the kernel itself. Forks often never come back."
The first problem here is what Hicks refers to as "patch vomit." This is where a code contribution didn’t actually present any value. The other problem with contributions is where someone contributes a lot of code which is heavily assisted to completion by others so they keep submitting more and more. "That's a common mistake that we see and it is often really challenging because it's it's almost never done maliciously. People are excited, they did one thing and it worked really well and they can do a thousand more but when those things start to stack, it often is creating work in other areas with a bottleneck and instead of creating that next patch. You should be helping the bottleneck."
The meritocratic nature of the open-source community can be at odds with the delivery. As Hicks explains, "You're not seeing faces, you're behind mailing lists. You haven't met people. Things can sometimes be a little bit blunt but interpreted as mean. Somebody telling you that the thing you really worked on hard has absolutely no value of a project is hard. Someone saying 'Thanks for your contribution but we’re not going to take it because it has zero value' is difficult to hear, and to some newcomers, it can be really, really insulting."
Hicks continued, "I often explain to people that there are lots of different cultures in the world. Some are very blunt. Some have a lot of ceremony involved before you can even get to be making a material point. Open-source can be a culture all to themselves. Just like we have to respect local culture. And I think this is one where we certainly always have to work to make sure that objective doesn’t get too abusive. You need to have some persistence to understand the culture."
It's clear that open-source communities, whilst sometimes embedded in emotional turbulence, are the backbone of the open-source movement. Without volunteers committed to the principles of open-source, nothing would be possible and it's great to see people like Hicks openly discussing the challenges of such communities with the intent of reducing conflict.