Product SiteDocumentation Site

4.8. Choose open tools that can be extended

Don't choose tools just because your small team knows them the best. Be careful of choosing something because you are in a hurry and need something quickly.
When it comes to tools, talk with trusted community leaders about what you should use. Even if you choose something out of step with other community members, you will at least know why you did and be prepared to mitigate risk.

It is risky to choose closed tools ...

It is risky to choose closed tools that a community cannot easily scale itself.
Implementation needed
Example needed

4.8.1. Make sure everyone has an equal and clear method for access to write-commit to open tools

Principle needed
With version control under code and content, you can open access to more people. For example, don't require people to go through a lengthy process or to "prove" themselves with X number of patches. Give people access to whatever they need to make a difference, even if they don't use the access.
Wikipedia is a prime example here. They use the power of the community size to police bad content changes, rather than limiting the community size behind rules of what it takes to write content changes.

More people want to do good for your project ...

More people want to do good for your project than want to do bad. Don't punish the do-gooders because of the potential evil someone might do.