Free Software Community Guidelines

Many developers who are new to free software groups do not yet understand the amorphous and inheritly democratic nature of the projects they're joining. This lack of understanding often leads to misframing of the purpose of discussions, a false view of what authority means, and missed opprotunities to contribute positivly to those groups.

To help these developers, here are a few guidelines for working on free software projects to keep in mind.

The Role of Maintainers

A job of a project maintainer is to provide focus and direction for that project.

For small projects, where a maintainer works primarily alone or with a small group of friends, this role is almost entirely technical. She or he makes releases, serves as a contact-point for patch submittion, and maintains a list of reported bugs to ensure they are looked at.

In larger projects, those involving more than a handful of developers, this role is primarily social. They must possess strong leadership skills, be able to calm and mediate conflicts between developers, and patient enough to work with new developers.

At any scale, a maintainer of a free software project is not the "owner" of that project, only it's leader. Despite who may own the copyright on the software, once it's released under a free software license, anyone can change, expand, and redistribute the project without endorsement or permission from anyone.

The Role of Developers

The job of a developer for any free software project is to write code.

Discussion between developers is of course important, communication being a vital element of collaborative projects, but if it doesn't result in useable code that discussion only serves to take time and energy away from the project.

The Purpose of Discussion

The primary purpose of discussion and proposals within free software projects exist for the discovery of new ideas.

When a developer (see above) opens a discussion or makes a proposal, in labeling that person a developer, we know that the goal of this is for them to write code. If they already had their mind made on what they were going to do such discussion would not be needed, so in the assumption that developers want to make the most of her or his time, any discussion or proposal opened by a developer is a query for new ideas which are often discovered through several developers brainstorming together.

Voting, consensus-reaching, maintainer approval, or any other form of decidion making about an idea is rarely a desired outcome of a discussion or proposal. This is because decidions are made individually by developers, they need no more approval to write code as they do to breath air.

This point is often lost as discussions lead to meaningless power struggles through a false belief that authority is needed for a developer to write useable code. At any point, any developer may branch or fork a project to implement their ideas and others may do the same. This is a fundamental freedom granted with all free software which cannot be restricted by anyone.

The Nature of Branches

Branches are alternative patchsets of a project, often with the only direct developer being it's maintainer, where that developer's code is either not ready to be integrated with the trunk project or when the maintainer of it's trunk project disagrees with the developer.

Often named with the developer's name or the branch's goal suffixed to the trunk's name, branches do not aim to be full projects in themselves, only a development point and prehaps an alternative which users may choose.

For example, Henry believes the CSS rendering of the XFox web browser needs to be rewritten, so he creates a branch called XFox-newcss. After several weeks of work, Henry gets his branch to work properly and solicits help in betatesting it. After some initial resistance, the maintainer for XFox finds Henry's -newcss branch to be well tested and indeed faster, so his changes are integrated to the XFox trunk. If the maintainer decided not to integrate his changes, Henry could keep his branch in sync indefinetly or he could fork into his own HFox web browser project.

It's important to note that in this example, as with any free software project, the developer was at no point restricted from his job to write code. At no point, either, were users restricted from using his code or the maintainer restricted from integrating his code. In fact, because a branch can be made of a branch, at no point are other developers restricted from branching or forking his branch!