Version 0.8, 2024-09-19
Copyright Naoki Shibata 2024.
This document is licensed under CC BY-SA 4.0.
These are non-binding community guidelines intended to be used as a code of conduct for OSS projects. The guidelines have the following features.
- The guidelines aim to alleviate burnout problems for OSS developers.
- The guidelines are designed to avoid adding new responsibilities to the project maintainer.
- The guidelines are written to be as objective as possible.
Please copy CODE_OF_CONDUCT.md into the root directory of your project. It is distributed under CC BY-SA 4.0.
As the number of individuals from diverse backgrounds participating in open-source and free software projects continues to grow, an increasing number of such projects are adopting a code of conduct with the objective of ensuring that all participants have equal opportunity to contribute to the project.
A code of conduct is a set of rules that defines the normative behavior and responsibilities of individuals, parties, and groups. Typically, they are created for employees of a company in order to protect the company and to inform employees of the company's expectations. In general, codes of conduct in OSS projects state the following items [1][2].
- Respect and welcome diversity.
- Be patient, kind, do the best for the community, be considerate and cooperative.
- Condemn sexist/racist language, insults, jokes, violence or threats that harass marginalized people.
- Report unacceptable behavior to a specific group of team members who usually have the authority to determine appropriate action.
However, the issues addressed by these codes of conduct are not novel. Rather, they are long-standing concerns that have been present for some time, and these issues have been acknowledged and addressed to some extent. The recent emergence of these codes is perplexing. What prompted the introduction of these codes, and what are the benefits of having a code of conduct? What would be the consequences of not having one? There are numerous questions that remain unanswered.
In fact, there are OSS projects that oppose the introduction of such a code of conduct, and some strong opponents explicitly choose "No Code of Conduct" for their projects [1][3].
I have the following concerns in introducing a code of conduct to my project.
The most important thing is that the basic human rights of each member are guaranteed. From the standpoint of guaranteeing freedom of speech, it is rather better not to have rules or anything like that restricting speech in non-project related venues. From a no-punishment-without-law standpoint, the project should not impose private penalties for offensive comments made by members on social networking sites that are not related to the project. Even if a member's non-project-related behavior has been found by an official agency to be illegal, whether the project should take any action in response is a matter for careful deliberation. It is the role of the authorities to punish members for illegal behavior, not the project maintainers, unless the authorities ask the maintainers to do something specific. The only thing that members of the project, including the maintainers, should do is to preserve evidence and to report any ongoing illegal activity related to the project to the public authorities.
Even if the code of conduct can restrict some actions of members, it is only on the web pages related to the project. The mere maintainers of an OSS project do not have the authority to tell project participants what to or not to say on social networking sites unrelated to the project.
Banning a member in a project should be done out of necessity in order to defend the project, not to punish the member. Maintainers are not there to punish members. The idea of secretly telling the maintainer about the victimization and asking the maintainer to resolve it seems terribly childish. Maintainers are not the parents of the project members.
The resolution of disputes between individuals is often a very sensitive matter. It is a difficult task just to simply make factual determinations in cases of suspected illegal activity, and OSS project maintainers are typically not trained to do such things.
When the person alleging victimization secretly consults with the maintainer, it is often not easy for the maintainer to respond to that consultation. For example, if the claim of victimization is not valid, the maintainer needs to convince the consulter of this. In this process, if the maintainer inadvertently chooses wrong words, or even if everything is handled properly, the maintainer could also be accused of being a perpetrator.
Professional expertise is required in some cases to provide appropriate consultation, such as when the consulter suffers from a mental illness. It is not easy for an untrained maintainer to notice the mental illness, but the maintainer may still need to take responsibility for any problems that arise as a result of the consultation.
We should be well aware that people with excellent specialized skills are novices in fields other than their own. Even in major media outlets, there are cases where people with specialized skills comment on issues outside their field of expertise. This is very disappointing, and comments on issues outside of one's expertise are often misguided. The correct professional response would be to refuse to comment on issues outside of one's expertise. It also goes without saying that we should not ask people with great expertise to do work that is outside their expertise. Thus, it is not appropriate to name untrained maintainers as a consultation contact, but rather, it should be clearly stated that maintainers are not a consultation contact.
Maintainers have no incentive to take their time to resolve disputes between individuals. The existing codes make the maintainers bear the cost of ensuring the diversity of the community. It is hard to imagine that forcing the maintainer to deal with the difficult problem of resolving disputes between individuals without paying any compensation would work. If a project member believes that he or she has been victimized, he or she should not expect the project's consultation service to function properly, but should seek an official contact outside the project. Also, if a project truly values the diversity of its members, it would be more constructive to promote the establishment of a consultation service for OSS projects by an organization that can be trusted to some extent. There is no guarantee that fair decisions will be made in such services, but if trained experts are consulted, better results can be expected than relying on novice maintainers. It is also expected that the criteria for judgment will become relatively uniform. To hire such an expert, however, funds need to be raised.
For consulters, it is important to note that the maintainers should not be trusted unconditionally and there is no guarantee that the maintainers will side with the consulter. If some rules contain penal provisions with ambiguous criteria for violation, such provisions can be arbitrarily administered by decision makers simply to impose private penalties on members they don't like. And that is often a reality. To avoid arbitrary enforcement of rules, the criteria for violation need to be objective.
Maintainers may want to make the rules that allow the maintainers to make arbitrary decisions to allow for flexible operations in unpredictable situations. Unfortunately, such rules and their operation are in fact quite common outside of the Internet. However, if the maintainers have no intention to make an objective decision from the beginning, then everything will ultimately be determined by the likes and dislikes of the maintainers. Members other than the maintainers have no choice but to trust that the maintainers will make a fair decision, and there is no difference between having rules and not having rules.
The only thing maintainers can do is to ban violators, which is not much of a deterrent to violations
If the violator participates in a project using pseudonyms, it is easy for the violator to return to the project pretending to be a new participant after being banned from the project. This has happened countless times in the past. The "consequences" of banning violators sounds just ridiculous. Nowadays, it is not uncommon to be banned from social networking sites for incomprehensible reasons. Since being banned is the most you can get, such "consequences" are equivalent to nothing.
Frankly, I cannot help but be surprised that so many prominent OSS projects have already adopted such codes of conduct that are ambiguous and of questionable effectiveness.
A quick way to improve community diversity would be to ensure transparency in all important deliberative processes. However, such an operation will undoubtedly lead to an increased workload on the maintainers. I believe that we should start by improving the treatment of maintainers.
If a code of conduct is to be considered a binding contract, it will be necessary to clarify how it is positioned in relation to the software distribution license. It would also require a reason to add a further agreement in addition to the distribution license. It may be possible to incorporate the code of conduct into the software distribution license.
On the other hand, it is also possible to make the code of conduct a non-binding goal of effort, and only aim to get the members to agree with the philosophy. In this case, the code of conduct could include the kinds of things that are usually not included in software distribution licenses, and thus issues that could not be solved by a software distribution license alone can be addressed.
The specific problem I am having with my project is what is called the burnout of OSS developers [4, 5, 6, 7], and this is not what is written in the existing codes of conduct, etc. In OSS projects, software needs to be maintained continuously, and this requires a continuous effort to be devoted to the maintenance. This becomes especially evident when the software being developed in a project becomes large in scale. However, OSS developers have little or no financial incentive to continue maintenance and development. Many users of OSS expect the projects to be maintained for a long period of time, even though they do not pay a fee. The result is that many OSS developers stop maintaining projects and developing new features much sooner than users expect. This may not be a very new problem either, but there is no established way to solve it.
The Community Guidelines for Sustainability of Open-Source Ecosystem aim to solve the OSS developers' burnout problem. It sets the goal of the project members' efforts to promote the awareness that if a company makes a profit from the commercial use of OSS, they should contribute to relevant projects. The adoption of the guidelines by a large number of OSS projects will make the general public at least aware of the burnout problem of OSS developers.
One reason why companies have not provided substantial financial support for OSS projects in the past may be because there was no infrastructure for this purpose. If a company actually wants to provide financial support to an OSS project, the simplest way is that the company provides support to each individual contributor. However, this requires that the company knows the status of the project in detail. Especially if the project is dependent on other projects, a very large number of contributors can be candidates for support. It may be too complicated for each company to evaluate a large number of contributors and determine the amount of support for each.
If companies provide bulk support to each project or a set of related projects, it will be necessary to establish criteria for fair and objective distribution of funds among and within projects. This requires an objective and fair method of evaluating each member's contribution to the project. For example, if the contribution of each member is simply evaluated by the number of lines of source code rewritten, this is hardly fair and will lead to rampant and meaningless rewriting of source code, resulting in many complaints from project contributors. Objective evaluation of contributions is not simple and requires academic research. At first glance, the construction of such an evaluation method seems not easy.
I expect that as firms offering the above services emerge and compete with each other, capitalist mechanisms will optimize the criteria for the distribution of funds. In this scenario, several firms offering the above services will first emerge. Each of these firms will implement different distribution criteria for funds and publish those criteria. The firms will then start services to distribute the funds according to their criteria after charging a fee. Each OSS project designates the firm it considers to have the best criteria when it receives the funds. Firms that implement better criteria and services will earn more fee income as they are used more often. In this way, the criteria for distribution of funds are optimized by capitalism. Also, public disclosure of the amount of support for projects by each company using OSS would give a promotional meaning to the company's support for OSS projects. This would be expected to stimulate more support for OSS projects.
In any case, the first step is to make it commonplace that companies that use OSS provide financial support to OSS projects. Then, firms that provide the above services would start to emerge.
If a company provides financial support for a project as a donation, various restrictions may arise in some countries.
Here we consider the case where a company does not make a donation to a project, but instead enters into an agreement to contract out the development to an individual developer. Under this arrangement, the company would spend the funds under a category such as "research and development expenses." However, the contract would have to be for some large, collective modification to the software. In addition, since it is not known whether the development will succeed or not in advance, it becomes troublesome to make agreements related to the development process, such as the establishment of the purpose of development.
One way to avoid this complication is to have the company pay for the management and operation of the CI system operated by the project. In this method, the maintainers and developers involved in the project jointly manage and operate the CI system, and the project requires the use of this CI system when committing the code as a project policy. In this way, the fee for the use of this CI system can be set up as financial support for the project from the company. This usage price can be set freely according to the situation, independent of the frequency of use of the CI system.
One of the advantages of adopting the method in which companies pay for the management and operation of CI systems is that it is clear from the beginning that the purpose of paying fees is for the management and operation of CI systems, and there are no complications in making agreements regarding the implementation of the contract. Since there is relatively little need to add value to the CI system by newly modifying its functionality, and the benefits to be gained by entering into a contract are clear from the start, the contract can be simple and straightforward. In addition, unlike methods such as selling advertising space on a project's website, it is possible to set the price as a discretionary price, and this has the advantage of allowing the price to be set freely.
In general, companies tend to avoid signing contracts directly with individuals. Therefore, it may be easier for companies to pay usage fees for CI systems to some legal entity, and then that entity pays the fees to the maintainer and developer. In this scheme, the maintainer and developer sign an agreement for the management of the CI system with this entity and receive a fee from this entity. Alternatively, the maintainer and developer may become employees of the entity and receive fees in the form of salaries. This legal entity may be a corporation established by the maintainer and developer. Services provided by an outside vendor may also be used for the payments in this scheme. Depending on the form of the contract, default may occur if the management and operation of the CI system is not successful. Default will almost never occur if the payment for the management and operation of the CI system is made in the form of deferred payment after the contract period is over, and the contract is renewed every month. In addition, various tax-saving measures can be taken with this scheme, but these are not discussed here because circumstances differ from country to country.
I thank Mr. Eiji Ito for his expertise and assistance in writing this document.
[1] Tourani, Parastou, Bram Adams, and Alexander Serebrenik. "Code of conduct in open source projects." 2017 IEEE 24th international conference on software analysis, evolution and reengineering (SANER). IEEE, 2017.
[2] https://en.wikipedia.org/wiki/Code of conduct
[3] https://github.com/domgetter/NCoC
[4] https://www.businessinsider.com/open-source-developers-burnout-low-pay-internet-2022-3