There is a bit here open to discussion, but considering recent events I thought it was relevant. While I agree with most, I do believe having a "vision" is a way to realize a goal by prioritizing what needs to be done to reach a viable release. By allowing wild-growth could lead to project instability, but ignoring new ideas can have a negative effect on a project driving contributors away.
Thankfully, OpenMW already follows a lot of these. It moves forward without being monolithic, can adapt to the needs of the community and even different communities by balancing to the need of users, modders and developers alike. We'll always strive for iterative improvement on those fronts. We try to keep things as simple as possible, batteries included, no fancy development requirements.
One thing I thought was interesting was the be pleasant and dealing with bad-actors. It's hard to balance those two without causing drama. You either give abusers a platform for hate chasing away those that would contribute to the project or you'll be accused of being fascists chasing away others that would also contribute.
Anyway, from http://hintjens.com/blog:95
1. People Before Code
This is the Golden Rule, taught to me by Isabel Drost-Fromm. Build community, not software. Without community your code will solve the wrong problems. It will be abandoned, ignored, and will die. Collect people and give them space to work together. Give them good challenges. Stop writing code yourself.
2. Use a Share-Alike License
Share-alike is the seat belt of open source. You can boast about how you don't need it, until you have a bad accident. Then you will either find your face smeared on the wall, or have light bruising. Don't become a smear. Use share-alike. If GPL/LGPL is too political for you, use MPLv2.
3. Use an Zero-Consensus Process
Seeking upfront consensus is like waiting for the ideal life partner. It is kind of crazy. Github killed upfront consensus with their fork/pull-request flow, so you've no excuse in 2015. Accept patches like Wikipedia accepts edits. Merge first, fix later, and discuss out of band. Do all work on master. Don't make people wait. You'll get consensus, after the fact.
4. Problem, then Solution
Educate yourself and others to focus on problems not features. Every patch must be a minimal solution to a solid problem. Embrace experiments and wild ideas. Help people to not blow up the lab. Collect good solutions and throw away the bad ones. Embrace failure, at all levels. It is a necessary part of the learning process.
5. Contracts Before Internals
Be aggressive about documenting contracts (APIs and protocols) and testing them. Use CI testing on all public contracts. Code coverage is irrelevant. Code documentation is irrelevant. All that matters is what contracts the code implements, and how well it does that.
6. Promote From Within
Promote contributors to maintainers, and maintainers to owners. Do this smoothly, easily, and without fear. Keep final authority to ban bad actors. Encourage people to start their own projects, especially to build on, or compete, with existing projects. Remove power from people who are not earning it on a daily basis.
7. Write Down the Rules
As you develop your rules, write them down so people can learn them. Actually, don't even bother. Just use the C4.1 rules we already designed for ZeroMQ, and simplify them if you want to.
8. Enforce the Rules Fairly
Use your power to enforce rules, not bully others into your "vision" of the project's direction. Above all, obey the rules yourself. Nothing is worse than a clique of maintainers who act special while blocking patches because "they don't like them." OK, that's exaggeration. Many things are much worse. Still, the clique thing will harm a project.
9. Aim For the Cloud
Aim for a cloud of small, independent, self-organizing, competing projects. Be intolerant of large projects. By "large" I mean a project that has more than 2-3 core minds working on it. Don't use fancy dependencies like submodules. Let people pick and choose the projects they want to put together. It's economics 101.
10. Be Happy and Pleasant
Maybe you noticed that "be innovative" isn't anywhere on my list. It's probably point 11 or 12. Anyhow, cultivate a positive and pleasant mood in your community. There are no stupid questions. There are no stupid people. There are a few bad actors, who mostly stay away when the rules are clear. And everyone else is valuable and welcome like a guest who has traveled far to see us.
How to manage an open-source project
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
- Thunderforge
- Posts: 503
- Joined: 06 Jun 2017, 05:57
Re: How to manage an open-source project
In reading this, I inevitably compare to how OpenMW is doing with this.
Sometimes I think that this manifests more on the forums and unofficial venues, like Discord, IRC, and Reddit, rather than on GitLab and GitHub. There's only so much we can do about that, but at least we can all do better about explaining rules and enforcing them fairly, rather than creating the appearance of being up to the maintainers' whims.
All that said, I don't see this as a bad thing. Having a unified OpenMW is probably one of our greatest strengths. To use an economics comparison, having a single electricity provider, rather than multiple competing ones, does have a large number of benefits like not having to create multiple power lines.
I think there is a perception among those who are less involved with OpenMW that there is a "clique" in which Zini (as the visible lead of the project) or one of the other maintainers sometimes blocks things solely because they don't like it. While I don't think that this is what they intend, I think we could do better in explaining the reasons we don't want a feature (e.g. "this is out of scope for our 1.0 goals, and not part of our post-1.0 stage 1 plan").psi29a wrote: ↑04 Jul 2018, 08:58 8. Enforce the Rules Fairly
Use your power to enforce rules, not bully others into your "vision" of the project's direction. Above all, obey the rules yourself. Nothing is worse than a clique of maintainers who act special while blocking patches because "they don't like them." OK, that's exaggeration. Many things are much worse. Still, the clique thing will harm a project.
Sometimes I think that this manifests more on the forums and unofficial venues, like Discord, IRC, and Reddit, rather than on GitLab and GitHub. There's only so much we can do about that, but at least we can all do better about explaining rules and enforcing them fairly, rather than creating the appearance of being up to the maintainers' whims.
If I'm reading this correctly, then I think OpenMW is failing miserably with that. OpenMW is a single large project with TES3MP being the main "competing" project (that plans to merge with the large project anyway). We do have submodules in terms of OpenMW-CS and such.psi29a wrote: ↑04 Jul 2018, 08:58 9. Aim For the Cloud
Aim for a cloud of small, independent, self-organizing, competing projects. Be intolerant of large projects. By "large" I mean a project that has more than 2-3 core minds working on it. Don't use fancy dependencies like submodules. Let people pick and choose the projects they want to put together. It's economics 101.
All that said, I don't see this as a bad thing. Having a unified OpenMW is probably one of our greatest strengths. To use an economics comparison, having a single electricity provider, rather than multiple competing ones, does have a large number of benefits like not having to create multiple power lines.
Re: How to manage an open-source project
Cutting down on arguments about whether or not to reintroduce vanilla behavior for gameplay mechanic X would help with openmw's development looking like a clique.
Re: How to manage an open-source project
There is probably not much we can do about the perception of people who are weakly or not at all involved with the OpenMW development.I think there is a perception among those who are less involved with OpenMW that there is a "clique" in which Zini (as the visible lead of the project) or one of the other maintainers sometimes blocks things solely because they don't like it. While I don't think that this is what they intend, I think we could do better in explaining the reasons we don't want a feature (e.g. "this is out of scope for our 1.0 goals, and not part of our post-1.0 stage 1 plan").
As for the two examples you listed, we have stated numerous times what the situation with 1.0 is and with the design document now public we also have stated what our general goals and directions for near post 1.0 development are.
I have gotten tired of explaining the same thing over and over again to people who didn't care to read it. So unless you want to write some boilerplate text that we add to every rejected request (and I really would prefer not to do that because boilerplate text is annoying) I don't see what else we can do about that. Maybe some additions to the FAQ could be made. But then people probably wouldn't read it anyway.
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact: