When it comes to formal-but-not-formal rules, baseball is king. Don’t talk about a no-hitter in progress, don’t steal a base in a blowout and so on, all getting into the minutiae of the game. But baseball isn’t alone in the world of invisible manuals; the technology industry has their own set of these hidden guidelines. Open source in particular—the transparent world of collaborative code that has birthed such IT miracles as Linux and GNU—follows a strong set of unwritten rules that allow communities to coexist, projects to evolve, and innovation to flourish.
And just like baseball, discussion of open source’s unwritten rules is heated.
(Related: Open-source government software makes sense)
Open-source software is typically developed by diverse communities of developers, heterogeneous coders with a common goal to build a technology to address a specific need, like big data analysis or virtualization. The resulting project is then made available under one of many open-source licenses, which govern how it can be used, distributed or built upon. This leads to an innovation like Linux serving as a foundation for more innovation, like Linux containers.
As open source becomes more and more mainstream, more and more people want to engage, and that’s a great thing from a community perspective. More voices, more diversity, and more arms and legs are always good, but this also means more friction within communities. New entrants to the space oftentimes butt heads with the old guard, creating tension within communities, or worse, driving software forks (competing projects built from the code of an original project). Or, in extreme cases, they kill a given project.
To further complicate things, we are entering a new wave of open source. The first wave was with the creation of the GNU System and Linux—the open-source projects that practically define how we view open source today. Linux creator Linus Torvalds went against what most others would have done, giving up commercial backing to keep Linux open and free, and never allowing corporate interest to sway his vision or governance.
The next wave came in the form of open software foundations, such as the Apache Software Foundation. This provided structured governance, with the community agreeing on who makes decisions, and the community in turn receiving consistent licensing and controls.
The third wave gaining stream now is corporate-driven foundations. These can bring benefits in the form of marketing budgets and corporate alignment on technologies, but can bring challenges around governance. In some cases the founding organizations can obtain too much power, or for the community to become “pay to play,” where money, not skill or contributions, is a major factor for influence.
To fully participate in open source, companies need to understand what open source really is and how to follow what are, more often than not, the “eight unwritten rules.”
Get to know the community and the people who participate in it. Just as in any workplace or team, open-source communities operate in a certain way, and each one is slightly different. It takes time to figure out how questions are asked and answered and whom to talk to for what. It’s important to understand how the community is governed so you don’t make any missteps. Conversely, it is important for the creator of the technology to understand what the community wants and needs in order to keep everyone happy.
Put technology ahead of business goals. Sure, open source and other technology might be driving many of your strategic business endeavors, but any contributions to or interactions with the open-source community should be anchored in what’s best for the technology, not your business. The community cares about how the technology is driving the industry further, not the valuation of a given organization.
But also put the community “first” first. Building a community requires serving the community. In other words, your work with the community should be focused on letting it deliver on its goals. If you try to control the community via licensing or trademark, the community will usually self-destruct, fizzle out or move on… and your open-source reputation will suffer.
Beware “pay for play.” 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). You could end up with little to no influence over the technology and contributing to a marketing budget for someone else.
Be open. The “open” in “open source” is there for a reason. In a strong open-source community, all aspects of the community/project are transparent. Participants must likewise be forthcoming about all development, planning and focus for future releases. This can make it challenging from a competitive perspective, but the benefits are worth it.
Think “derivatives,” not “forks.” Derivatives and specializations are a good thing. They show the diversity of the software and contribute to the growth of the project. The right to fork – to use the source code of an existing project to start a new version – is granted under most open source licenses. However, forking can lead to redundant efforts and bad blood. A healthy open source project uses the structures that allow derivatives to occur.
Contribute wisely. Strong open-source projects are widely used and see significant contributions. They also demonstrate that they value these same contributions. Work to ensure that any code that you commit to a project is usable, not just by your company but by the community as a whole.
Lastly, but most importantly, there’s no crying in open source. It’s important for communities to be a productive place. You made the choice to be open, and many contributors have worked very hard to make an addition to or new solution for your technology. Complaining and creating a negative environment will only drive members away.
The evolution of open source has been a huge boon for developers and enterprises alike. It has fundamentally shaped the way business is done, and has sped up the rate at which new technologies are created and improved. To keep this momentum (and to get the most out of open source), everyone needs to ensure that they are playing by all the rules—unwritten and otherwise.
