5. Am I free to contribute my improvements? Copyright assignments get in the way, as does any mandatory agreement that will require legal review. I contribute back to reduce my maintenance and refactoring burden so that it's not only philanthropy. It's reasonable for a community to expect me to demonstrate competence before giving me commit rights, asking me to channel my work through others initially. It's much less reasonable to insist I have to assign ownership of my work to a "project owner." That chills participation, both by forcing me to effectively pay to participate and by forcing me to get legal advice first.
6. Am I treated as a development peer?Changes that are conducted in private, then "thrown over the wall" to the community rob potential collaborators of the confidence they have space to innovate. Why would you invest in significant new work, only to find the "project owner" rendering all your work moot with a bolt-from-the-blue code update? When the only way to be sure you've permission to innovate is to enter into a bilateral agreement with one company, you're being treated as a client or partner and not as a community peer.
7. Am I inclusive of all people and skills? How do you license your documentation? Can I contribute to it? What about your user support community? Can I join in both to get and to give help? Do you have policies to discourage harassment of people who don't seem to fit into your community norms? If people need to ask for any of those, that's a lack of permission in advance as well.
Using the lens of "permission in advance" turns out to be an easy and useful tool for diagnosing your community governance. The seven points here aren't the only concerns; which do you use for your own purposes? I would be interested to hear what tests others apply to community and project governance to determine whether there is truly freedom to collaborate.
Sign up for CIO Asia eNewsletters.