A committee at the Node.js project voted 60% in favour of allowing a developer to stay on with the project.The vote put forward to the committee noted some violations of the Code Of Conduct. The fact there was a vote means that they took the Code of Conduct seriously.
Unfortunately, the code of conduct was shown to have no teeth as the committee members voted in favour of letting the developer stay with the project, as pointed out by core NPM contributor maybekatz (update: maybekatz has also been a node core collaborator, member of a working group, and former Technical Steering Committee candidate):
The lack of enforcement of the Code of Conduct has not only resulted in a fork, it has also resulted in a Node.js committee member resigning from their post on the TSC (Technical Steering Committee).
Here is what the developer had to say:
A recent decision by the TSC leads me to believe that the Technical Steering Committee is making decisions that are not in the best interest of theNode.jsproject. This is not about a specific individual, this is about the values we choose to demonstrate as a project and holding ourselves accountable.
The TSC has final authority over this project including:
- Technical direction
- Project governance and process (including this policy)
- Contribution policy
- GitHub repository hosting
- Conduct guidelines
- Maintaining the list of additional Collaborators
The current decision undermines our Conduct Guidelines, drives away potential contributors, and in my opinion undermines the Committee’s ability to govern.
Driving away contributors can be fatal in the open source world where most developers are essentially using their free time and volunteering to contribute. It is already difficult enough to attract contributors to smaller projects and larger projects, such asNode.js, need to be careful to make all contributors feel welcome.
Codes of Conduct should be adopted by open source projects because they can help contributors feel safe in contributing, they can increase their courage in submitting a patch. Joining a project can be intimidating, the code of conduct can help with that. It is also a good idea to include a “contributing” document that explains how to contribute to a project and where to begin.Anything that can make it easy for people to contribute to open source projects is a good thing.
Update 11:26am 23rd August 2017:ayo.jshas multiple issues opened on github discussing the governance structure and the goals of the project.
One of the issues questions whether re-merging withNode.jsis a goal. The most upvoted answer given is:
I just want shit to be fixed. I don’t care what the project is called or who controls it as long as it serves the communities it has worked so hard to push away.
Another issue discusses governance models, such as BDFL (Benevolent Dictator For Life), essentially a person who leads the project for a long enough (1 to 2 years) term to accomplish the roadmap laid out by the committee and the community. There is a suggestion to have multiple working groups focused on different areas of the project with the TSC (Technical Steering Committee) overseeing and confirming their progress and ideas.
While some may see this as a social/organizational fork that could fade away,my personal opinion is that it is a bet on how much codes of conduct and other tools and tactics can increase contributions and attract more open source developers and retain them.Most open source projects consist of a few developers so our community doesn’t often have discussions about how projects should be organized, about whether more democractic models could work.