About Our Community
The FreedomBox software project is governed by a community that includes part-time volunteers and full-time contributors. In governance, we rely on our written code of conduct and mutually enforced standards. The community aims to make decisions through open discussion and consensus. In cases of disagreement, the community discusses until a resolution has been found or agrees to postpone the discussion. Though a select number of our developers have the power to accept merge requests, anyone is welcome to join our contributor community and submit code or non-code contributions.
Meet the members of our core team! Though several community members make contributions, the core team consists of those who are most involved in the development of FreedomBox.
Sunil Mohan AdapaLead Developer & Code ReviewerEmail
Joseph NuthalapatiDevOps Engineer, Developer, & Code ReviewerEmail | Social | Website
James ValleroyRelease Manager, Developer, & Code ReviewerEmail | Social
Danny HaidarVice President of FreedomBox FoundationEmail | Website
Though our core team is small, hundreds of volunteers have made contributions to FreedomBox throughout the years. Many of those contributors are listed here. We thank them for their work!
How Decisions are Made
Generally, decisions about software development and design are discussed by members of the core team and implemented using our open software development platform (i.e. GitLab). Many of the decisions made by our team are uncontroversial and don’t require extended periods of discussion.
But sometimes, extended periods of discussion are necessary. For proposals that could plausibly be subject to disagreement, we use a “Request for Comments” (RFC) procedure. RFC’s should be posted to one of our open development platforms (i.e. Gitlab or the forum) and should include (1) a written summary, sketch, or mock-up of the proposal, (2) a brief explanation of why the proposal is needed, and (3) a list of action items required to implement the proposal. Optionally, one may also include in the RFC a fourth item: a suggested timeline for the discussion process in order to prevent unnecessary delays. Sometimes, disagreements make it difficult to follow prescribed timelines; in such cases, participants should make efforts in good faith to compromise and, failing that, can extend the discussion.
Improvement by Revision
In general, when proposals regarding software development or design are accepted, these proposals are treated as revisable, not permanent. This improvement-by-revision approach to proposals enables us to accept generally solid proposals without dwelling on minor details. Minor tweaks to accepted proposals can always be made later instead of upfront. Like the original proposal, revisions are subject to discussion and can’t be made unilaterally. In the spirit of experimentation, we embrace revisability in order to foster incremental improvements to our software.