Principles

Introduction

Those principles are adapted from Organizing Principles for Community Software by Margaret Kibi a·k·a Allie Hart used under CC-BY-SA. They are considered a living document and can be further edited to suit the needs of the community.

I. Educate Everyone

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:

• Education on the purpose of the software and its usage
• Education on the goals of the software movement and its trajectory
• Education on the mechanisms by which the software is implemented
• Education on how to effectively engage and participate within the software movement and community
• 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.

Over time, we'll establish a cycle where:

• Community concerns are listened to and prevalent ideas are studied and investigated.
• 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.
• 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:

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.

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. We should not simply choose 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. We 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.)

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.

We'll work to design plaits such that those building the tool can be held accountable to the community for our conformance to the Principles listed here.

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. Continuing development in such a state risks leaving portions of the community behind, weakening the software movement as a whole.