How to manage an open-source project

Not about OpenMW? Just about Morrowind in general? Have some random babble? Kindly direct it here.
Post Reply
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

How to manage an open-source project

Post by psi29a »

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.
User avatar
Thunderforge
Posts: 503
Joined: 06 Jun 2017, 05:57

Re: How to manage an open-source project

Post by Thunderforge »

In reading this, I inevitably compare to how OpenMW is doing with this.
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.
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").

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.
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.
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.

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.
User avatar
wareya
Posts: 338
Joined: 09 May 2015, 13:07

Re: How to manage an open-source project

Post by wareya »

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.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: How to manage an open-source project

Post by Zini »

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").
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.

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.
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: How to manage an open-source project

Post by psi29a »

Zini wrote: 05 Jul 2018, 12:05 Maybe some additions to the FAQ could be made. But then people probably wouldn't read it anyway.
That would be an best-effort approach and just refer to the FAQ.
Post Reply