Organizing Principles
for Community Software

What follows is a series of five Principles, the adoption of which I believe is integral for any truly community‐led software movement to emerge.  They are developed largely from my experience within the open‐source software project Mastodon (and various forks thereof), and build upon the ideas and experiences of others both in the software community and with respect to community organizing as a whole.

It is the current trend in software development for communities to form around software and not the other way around.  These Principles, and the designation « community software », presumes the opposite:  First the development of software communities, and then the development of software movements within and across those communities, and then—finally—from those movements, the development of individual software projects.  Attaining this in practice is made difficult by the fact that software development culture is presently incredibly egocentric—to the extent that a developer volunteering labour to work with and assist an existing community and movement to develop a compelling product from scratch is essentially unheard of.  On the other hand, developers volunteering labour to their own pet projects, or to other software projects serving their own particular interests and purposes, happens all the time—this only serves to consolidate power within those with development skills while preventing any real community opposition from emerging.  Consequently, the first priority of any software community should be to help educate and train labourers dedicated to their cause.

The Principles presented below exist in sharp distinction with, and in contrast to, the existing trend of Codes of Conduct within the open‐source software movement, such as the Contributor Covenant, of which I am respectfully critical.  In particular, it is my opinion that these Codes fail on three accounts:—

  1. The presence of Codes within project spaces normalizes the broader systemic discriminations which take place in software communities, more generally, outside of the scope of any particular project, by establishing them as the unspoken norm.  In essence, this allows particular project communities to convey a progressive patina without interrogating the larger cultures to which they belong.  In some senses, this might be said to be a pragmatic survival strategy, as surely having some—at least nominally—inclusive spaces is better than having none.  However, the question is still open as to whether such spaces could possibly be created through other means, and without normalizing their inverse.

  2. Codes of Conduct fail to address fundamental inequities in project goals, structure, or direction, at worst serving as little more than a blanket allowance for the oppressed to give their labour to the very systems doing them harm.  They purport to seek inclusion and diversity but make no assurances that those so “included” will be heeded in any material way.

  3. More broadly, the liberal accommodationist strategy of a Code of Conduct masks and upholds a centralization of power around the software project and those who control it (who have complete and total jurisdiction over the enforcement of said Code), placing oppressed parties in a position of service and subservience rather than working to ensure their own empowerment and self‐determination.

Nevertheless, adoption of these Principles do not in any way preclude the additional adoption of such Codes should those participating in a software movement feel they are necessary.

The five Principles are as follows:—

I.  Educate the Masses

Education is the first Principle of community software, as it is a prerequisite for many of the Principles to follow.  This Education should extensively cover many subjects pertaining to the software movement, including all of the following:—

  1. Education on the purpose of the software and its usage
  2. Education on the goals of the software movement and its trajectory
  3. Education on the mechanisms by which the software is implemented
  4. Education on how to effectively engage and participate within the software movement and community
  5. Education on these Principles and how they have been applied to the particular software movement in question

It is not a requirement for all participants within a software movement to be educated on all topics, but information should be available for any interested person regarding the history, operation, rationale, and organization both of the software itself and of the movement which produced it.  This information should be available at both introductory and advanced technical levels, and in multiple formats, targeting as broad an audience as possible.

Decisions cannot be effectively made if educational materials are not available regarding the current state of the software.  Consequently, this Principle is of the utmost priority.

II.  People before Project

The purpose of a software movement is to serve the community to which it belongs.  The purpose of a community is not to serve or develop a particular software project.  The purpose of a community is to meet the needs of its members, and of humanity as a whole.

Consequently, the futurity of any particular software project within a software movement—as well as the futurity of the movement as a whole—must always come second, after the present needs of those community members which it is intended to serve.  A software project which successfully serves its purpose and is then dismantled is a successful software project.  Software projects must not be continued after their ability to serve their communities has ceased.

III.  From the People, to the People

All ideas for a software movement should come from the people within the community and serve their interests.  It is not expected, or required, that those within the community necessarily know the finer details of how their interests might be served by a particular software project.  Consequently, a cycle resembling the following must be established within a software movement:

  1. Community concerns are listened to and prevalent ideas are studied and investigated.

  2. Those working closely on a software project, who are familiar with its systems, interpret the ideas of the community in the context of their knowledge and reach a solution.

  3. This solution is then brought back to the community, either in the form of a plan or a software implementation, to seek feedback and new concerns.

This cycle gives those familiar with a project the ability to use their knowledge in the betterment of the peopleʼs interests while ensuring that any implementation is given the opportunity for critique and revision by the community it is intended to serve.

IV.  Rise together

Belongingness within a software community should be predicated on agreement and adherence to community goals and principles, not on individual identity or ability.  Implementing software features which serve a particular subset of a software community before prior features are accessible to all others in the community leads to stratification and division within the community as a whole.  Consequently, it is imperative that the accessibility of all existing software features be ensured before new developments ensue.  This accessibility includes:

  1. Accessibility to non‐technical, casual, infrequent, and new members of the community in addition to technical, dedicated, frequent, and established members.  This is a matter of both design and education.

  2. Accessibility and ease‐of‐use to all possibly‐relevant community members regardless of individual ability or capability, without the need for particular technical skill or knowledge of a sort not expected of other members.

Meeting this Principle may at times require devoted listening to the particular subsets of a community for which accessibility has not been attained, at the exclusion of the interests of other members for whom accessibility has already been established.  The restriction on new development while accessibility work is underway is intended to help mitigate the conflicts that this situation may bring.

V.  Acknowledge difference; allow dissent

Software communities are not singular, and solutions to community problems should incorporate a multiplicity of perspectives.  Software movements should not simply chose the easiest or most popular solution to a problem, but work to integrate multiple solutions and consider the many different environments in which a software can or will be used.  Frequently, this will mean actively soliciting ideas from specific subsets of the software community in order to better understand their particular needs.

Even as software developments should aim to serve as many community members as possible, the door should always be left open for others to take a different approach.  Software movements should, through both education and the investment of labour, actively assist dissenting projects from within the software community in attaining autonomy.  Where possible, interoperability and solidarity with such dissent should be designed for, even as accommodation within the framework of a particular software project may not be possible.

(The above specifically applies to dissent from within a software community; namely, dissenting groups whose goals align with the community at‐large but whose needs cannot be accommodated by the software project as it currently stands.  It does not apply to conflict from outside of a software community; communities are under no obligation to accommodate those working in direct contradiction to their interests.)

Postscript:  Applying these Principles

The above Principles are a framework and an ideal, which may or may not be perfectly attainable in any given real‐life situation.  Software movements should be designed in such a way so as to be held accountable to their communities for their conformance to the Principles, such that it is the community (and not any particular project) which is the arbiter of when acceptable compromises can be made.

In general, “time” is not an acceptable reason for a compromise.  The Principles above demand at‐times extensive labour to uphold, which will necessarily slow the speed of software development.  However, compromising on Principles for the sake of development speed means performing development while the project is in a state of inequity, allowing power imbalances to emerge and take control.  It is almost a guarantee that the benefits of any new features gained through a forgoing of one or more Principles will not be gained by the entire community equally.  Continuïng development in such a state risks leaving portions of the community behind, weakening the software movement as a whole.