open road One of the things I have discovered while working with mapping platforms like OpenStreetMap is that there really isn't anything like a straight line in the world.

You think there are lots of straight lines out there—streets, property lines, boundaries—but there is really no such thing at all. Some of the deviations are geographical, with rivers and mountains and valleys carving up the world. And some are purely political; Mark Stein wrote a whole book on How The States Got Their Shapes, detailing the boundaries of various U.S. states and the historical and political intricacies of why the states are the way they are.

For instance, the reason I don't live in Michigan right now is that Indiana wanted more access to Lake Michigan, so the border was moved north 10 miles when Indiana was made a state in 1816. In 1835, Michigan claimed similar access to Lake Erie's shores (and the location of present-day Toledo). This did not go over well with the folks in Ohio, and led to an actual shooting war that summer. Eventually a compromise was reached, and when Michigan joined the Union in 1837, its border with Ohio was also moved to the north, making Toledo a part of Ohio. As a result of these two compromises, Michigan was given what is now known as the Upper Peninsula from the Wisconsin Territory.

There are stories like this all over the world; whenever people live near each other, there are always little aspects of the world around them that cause them to want more or less than what they have. This is a part of being in any community. In open source software projects, it's not about lines and borders so much as the more nebulous quality known as turf.

Turf wars usually start out innocuously. Someone puts in a lot of time and effort on a given aspect of a project and invariably someone comes along and wants to help. If everything goes well, the help is welcomed and new ideas are shared, making that part of the project stronger. Unfortunately, egoism can come into the mix and then there's a problem.

This is where strong governance and cooler heads can really save the day. Having an established set of rules in place to settle disputes is key to resolving disputes. If a community has guidelines in place, there won't be cries of "foul" or "favoritism" (or, if there are, they will be less justified). If a conflict starts, community members can get through it following the previously established rules.

Rules aren't just about resolving conflicts... sometimes they need to be in place just to avoid confusion. I've been working with the Fedora Project to figure out how they can set up a system to keep the passwords to their various social media accounts safe and yet accessible by the people authorized to use those accounts. This requires using a decent software package (RatticDB is my current recommended option) but also managing the authorization process? Who gets access? How do you avoid duplicate posting? What happens if someone posts something inappropriate? And so on.

Governance in free and open source projects is one of those things we know we need, but the meritocratic and libertarian aspects of our communities tend to lean us away from actually setting up such frameworks. After all, I just want to code in peace.

That's a worthy goal, but we are not working alone. Our definition of peace may scuff up or outright trample the peace of others. Hopefully unintentionally, sometimes not.

When my desires conflict with those of my neighbors', I have been lucky to settle things over a shared beer and look at the issue at hand over the fence line. But I know that should things not be so easy, there are laws and methods at our disposal to resolve things peacefully.

Communities of all stripes need these kinds of avenues in place, so that we can get on with the business at hand and make great things.

Image available under the CC0 Public Domain Dedication license.


About the author

Brian Proffitt is Senior Manager, Community Outreach within Red Hat's Open Source Program Office, focusing on enablement, community metrics and foundation and trade organization relationships. Brian's experience with community management includes knowledge of community onboarding, community health and business alignment. Prior to joining Red Hat in 2013, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.

Read full bio