BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Everyone wants to use and participate in an open source software environment but sadly not everyone knows how to do it right. This is the perspective of Matt Hicks, vice president of engineering for Red Hat’s OpenShift. So he reached out with his 8 unwritten rules of Open Source. “These are just really good life rules but they work if you apply them to open source too,” Hicks said in a recent interview.
The rules seem straightforward enough:
*Get to know the community and the people who participate in it
*Put technology before individual business goals
*Also put the community “first” first
*Beware of “pay for play” and unbalanced communities
*Think “derivatives,” not “forks”
What drove him to come up with these rules is the growing popularity of Open Source, which brings with it numbers of people who really don’t know how it works. “Here’s what makes really good communities thrive and how to have more influence when you work with it all day,” he explained. “People get frustrated. They came in, submitted a patch and no one listened to them. I spent my time and built this thing and Open Source doesn’t want me. I felt the impetus to break down the rules. It’s great that we’re getting contributions in but it takes more than just writing the code and submitting it to GitHub. These are commonsense type rules but it’s surprising how many get missed.”
I asked him about my favorite of the rules — no crying. Hicks explained that the “maintainers,” who have the job of overseeing any and all proposed changes, can be “terse and dismissive” of suggestions that don’t fit or won’t work. And that new contributors simply cannot take that personally. Maintainers are busy, and newbies need to understand it can take time and patience and understanding of the bigger picture for their suggestions to be heard.
Hicks’ favorite rule? Putting the community first. “We see someone who’s done really good work but it breaks a lot of other things,” he said. “Sometimes we just can’t take them because the cost of addressing other edge cases is too high. Don’t just think of the things you want to get in. Think of the other things that might break.”