Sum­mary

I pro­pose a default “Con­sti­tu­tion for Gov­er­nance of Open-Source Projects”.

Back­ground

I recently got involved in the OSQA project, which is a fork of CNPROG, which in turn is a clone of the Stack­Ex­change Q&A forum software.

Note that the OSQA project has no for­mal “home­page”, or instruc­tions on how to get involved. I only dis­cov­ered by chance that there is a mailing-list (unar­chived) and devel­oper chat room. Nor was it imme­di­ately clear which OSQA github fork should one use.

This is because OSQA grew organ­i­cally from one con­trib­u­tor to a hand­ful, and devel­oper involve­ment was an after­thought in this project. Not that there is any­thing wrong with that.
How­ever, now that a hand­ful of peo­ple are involved in the project, and more peo­ple are try­ing to get involved, we have begun dis­cussing gov­er­nance and decision-making poli­cies on the mail­ing list. In fact,
Evgeny Fadeev poses this very ques­tion on Stack­Over­flow, and pro­poses some poten­tial answers.

I believe that, by default, there are some sim­ple but clear prin­ci­ples that should be enun­ci­ated. I hereby pro­pose my

Con­sti­tu­tion for Gov­er­nance of Open-Source Projects (v20100227)

Let it be affirmed that the pri­mary goal in insti­tut­ing gov­er­nance of an open-source project be to ensure the long-term health of the project.

Accord­ingly, the default bias should be towards open­ness and inclu­sive­ness.
How­ever, pol­icy should be changed as issues present them­selves, in order to main­tain the long-term health of the project.

For the model of deci­sion mak­ing, we favor a “do-ocracy”.
The peo­ple who con­tribute the most gen­er­ally com­mand the respect of the com­mu­nity.
Alien­at­ing them is the best way to derail the project.

The repos­i­tory should be open the com­mit­ters, given that com­mits can eas­ily be reverted and commit-access eas­ily revoked. This is prefer­able to alien­at­ing poten­tial committers.

To ensure trans­parency for devel­op­ers new and old, and allow them to decide their involve­ment in a project based upon the his­tory of the project, their should be trans­parency and ope­ness in the inner work­ing of the project. For exam­ple, the email archive should be public.

Lastly, let us remem­ber that too much red-tape gets in the way of progress. So red-tape and other bar­ri­ers to con­tri­bu­tion should be avoided, and only added as issues present themselves.

This Con­sti­tu­tion can and should be amended as issues present themselves.

There­fore be it resolved.