7.4 KiB
＋＋＋ ＋＋翻译中 +++++ The 6 unwritten rules of open source development
Do you want to be a successful and valued member of an open source project? Follow these unwritten rules
Matt Hicks is vice president of software engineering at Red Hat and one of the founding members of the Red Hat OpenShift team. He has spent 15 years in software engineering with a variety of roles in development, operations, architecture, and management.
The sports world is rife with unwritten rules. These are the behaviors and rituals that are observed but rarely documented in an official capacity. For example, in baseball, unwritten rules range from not stealing bases when well ahead to never giving up an intentional walk when there’s a runner on first. To outsiders, these are esoteric, perhaps even nonsensical guidelines, but they are followed by every player who wants to be a valued teammate and respected opponent.
Software development, particularly open source software development, also has an invisible rulebook. As in other team sports, these rules can have a significant impact on how an open source community treats a developer, especially newcomers.
Walk before you run
Before interacting with any community, open source or otherwise, you need to do your homework. For prospective open source contributors, this means understanding the community’s mission and learning where you can help from the onset. Everyone wants to contribute code, but far fewer developers are ready, willing, and able to do the grunt work: testing patches, reviewing code, sifting through documentation and correcting errors, and all of those other generally undesirable tasks that are required for a healthy community.
Why do this when you can start cranking out beautiful lines of code? It’s about trust and, more important, showing that you care about the community as a whole and not developing only the features that you care about.
Make an impact, not a crater
As you build up your reputation with a given open source community, it’s important to develop a broad understanding of the project and the code base. Don’t stop at the mission statement; dive into the project itself and understand what makes it tick outside of your own area of expertise. Beyond broadening your own understanding as a developer, this helps you gain insight into how your code contributions could impact the larger project, not only your little piece of the pie.
For example, maybe you want to create a revision to a networking module. You build it and test it, and it looks good, so you send it off to the community for more testing. As it turns out, this module breaks a security setting or causes a major storage incident when deployed in a certain manner -- issues that could have been remedied had you looked at the code base as a whole rather than your piece alone. Showing that you have a broad understanding of how various parts of the project interact with others -- and developing your patches to make an impact, not a crater -- will go a long way toward making your contributions appreciated.
Patch bombing is not OK
Your work is not over when your code is submitted. There will be discussion about the change and a lot of QA and testing yet to be done if accepted. You want to make sure you are putting in the time and effort to understand how you can move your code and patches forward without them becoming a burden on other members.
Help others before helping yourself
Open source communities aren’t a dog-eat-dog world; they’re about putting the value of the project before individual contributions and individual success. If you want to increase your odds of being seen as a valued member of the community (and get your code accepted), help others with their efforts. If you know about networking, review networking modules -- apply your expertise to make the whole code base better. It’s no surprise that top reviewers often correlate to top contributors. The more you help, the more valued you are.
Address the edge
As a developer, you’re likely looking to contribute to an open source project to address a particular pain point. Maybe your preferred operating system isn’t supported or you desperately want to modernize the security technology used by the community. The best way to introduce changes, especially more aggressive ones, is to make them impossible to refuse. Know enough about the code base to think through every edge case. Add capabilities without breaking existing functionality. Pour your energy into the completeness of your feature, not only the submission.
Don’t give up
Open source communities have plenty of fly-by-night members, but with commitment comes credibility. Don’t merely walk away when a patch is rejected. Find out why it was rejected, make those fixes, and try again. As you work on your patch, keep up with changes to the code base and make sure your patch remains mergeable as the project evolves. Don’t leave it to others to patch up your patch. As the author, take the burden on yourself and keep other community members free to do the same with their work.
These unwritten rules might seem simple, but too many open source contributors don’t follow them. Developers who do so will not only succeed in advancing a project for themselves; they will help to advance open source in general.
作者：Matt Hicks 译者：译者ID 校对：校对者ID