Problem solve Get help with specific problems with your technologies, process and projects.

Red Hat's 8 rules of successful Open Source

This blog post is part of our Essential Guide: Red Hat Summit 2017: Inside the latest with open source tech

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
*Be open
*Think “derivatives,” not “forks”
*Contribute wisely
*No crying

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.”

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close