3

I am starting new open source project, where contributors may not know how the processes work. I would love to reference some short easy to understand set of rules so that people feel comfortable to contribute and use the product. Some explanation of who is maintainer, that maintainer is decision maker, but they are highly interested in alignment with community, and there is always possibility to fork code.

I want this set of rules to address concerns like:

  1. Anyone can change it the way they want, so I do not want to rely on it
  2. Someone will change something in a wrong way and I will not even be notified
  3. I will take dependency and then project will go to wrong direction

I do not want to reinvent the wheel, but i cannot find anything.

Is there such thing?

Improve this question

2 Answers 2

Reset to default
4

The simple answer to your question is "no such set of rules exists". I think there are a number of reasons for that.

Firstly, some of things that you list are not a requirement of open source: this particularly applies to

that maintainer is decision maker, but they are highly interested in alignment with community

There are plenty of open source projects where the maintainer is explicitly or implicitly not interested in alignment with the community; practically this applies to a lot of hobby projects, where in a lot of cases the maintainer does stuff that interests them personally rather than what the community wants. And for avoidance of doubt, this is completely fine - if you're not paying me, you don't get to decide what I spend my time on.

Secondly, I don't understand why you feel your numbered points are things that need to be made clear to contributors. I think some of this may be due to a language issue so I feel slightly bad nitpicking on these.

  1. "Anyone can change it the way they want, so I do not want to rely on it" - it's absolutely correct that anyone can change the code, but I don't see why you need to state that you won't rely on it. As the maintainer, you always have the option of rejecting a change you don't want - i.e. this is a problem for you, not for the contributors.

  2. "Someone will change something in a wrong way and I will not even be notified" - again, I don't see why you not being notified of something is a problem for the contributors; either people are going to be using your "official" release, in which case you certainly have been notified, or they're using a fork. If you're worried about people obtaining "unofficial" releases which may contain bugs, there's a pretty strong social consensus in the open source community to make it very clear that something is a fork.

  3. "I will take dependency and then project will go to wrong direction". I genuinely don't understand this sentence. "Taking [a] dependency" is not a phrase which really makes sense in (British) English.

Improve this answer
4
  • 1
    "there's a pretty strong social consensus in the open source community not to make it very clear that something is a fork." Is this line wrongly negated? I think you may have meant that there is a consensus for clearly marking forks, not the opposite.
    – ecm
    Commented Jun 16 at 21:02
  • @ecm 100% yes, too many rewrites! Thank you and edited.
    – Philip Kendall
    Commented Jun 16 at 21:03
  • 3
    The wording is indeed confusing, but I think the numbered points are from the perspective of a potential user. That is, polina-c's concern is that someone considering using their project might think to themselves "I can't rely on this project because anyone (e.g. lead developer polina-c) can change it however they like", or so on for the other points, and that potential users might be scared away by that risk. And polina-c would like to set out a contribution policy that promises things like that won't happen.
    – David Z
    Commented Jun 17 at 6:01
  • 1
    @DavidZ Ah yes, that makes a lot more sense. But as Basil points out in their answer, those concerns aren't open source specific.
    – Philip Kendall
    Commented Jun 17 at 7:48
2

On concerns 1 and 2,

  1. Anyone can change it the way they want, so I do not want to rely on it
  2. Someone will change something in a wrong way and I will not even be notified

these're problems not of open source per se, but of managing versions, breaking changes and expectations.

I advise you to choose a versioning policy, document it and stick to it.

For libraries, SemVer is an excellent choice. It specifies that, when a breaking change occurs, a major version should be incremented.

When users depend on your library, they specify a major version to use. So, when a new version with breaking changes is released, it won't be picked automatically. And when users notice a new major version, they go check out release notes to figure out what was changed and how to migrate to the new version.

So, yes, anybody could change anything, but only together with the version number. And when they do, everybody else knows the severity of the changes.

For applications, the same policy could work, but you have to explicitly define what is your interface (that is kept backward compatible), and what parts are internal implementation and could be changed freely. Or the policy could be more complicated, for example, see Gradle Feature Lifecycle.

Your VCS (git) branching strategy should also follow the versioning policy. As an example, GitFlow says to collect breaking changes in a separate branch to release them together in the next major version.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.