3

This question already has an answer here:

Suppose I have an open source project. I have 3 or so friends that have been helping with the development.

My question:

Does having my project open source mean that anyone can contribute to the project (including people I don't want)? Or am I able to select who I want working on the project?

By contribute I mean make changes to the source code.

marked as duplicate by congusbongus, curiousdannii, Free Radical, Martijn, overactor Aug 5 '15 at 15:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    I'd imagine this depends on the license, but I can't think of any license that requires the project owner to merge back changes he doesn't want. For example, on GitHub, you can 'close' a pull request without merging it. Not making this an answer because I'm not very good at the legal aspects of these things. – Undo Jul 22 '15 at 19:41
  • 1
    What to you mean by "contribute", Do you mean: Can I say that outsiders are not allowed to suggest improvements (patches, pull requests, etc.), or do you mean that a fork you do not want to happen counts as a "contribution"? – Free Radical Jul 22 '15 at 19:48
  • It seems to be a common error, to think that the freedoms include the freedom to edit your copy. They do not. You are free to edit your own copy. You are given many freedoms, but not the freedom to control others. Freedom ≠ ability to control. – ctrl-alt-delor Aug 2 '15 at 18:54
  • This is good question but turns out from answers i also didnt know few options. I would like to know why it was downvoted. – Kangarooo Aug 4 '15 at 4:36
8

Every open source project has a policy to restrict who can contribute.

This is mandatory for a project to succeed in the modern era, otherwise random "contributors" would would be injecting malware and spam into every open source project.

In general, the founder of the project will only allow contributions from people they trust. For larger projects they will delegate this work out to other people.

Also many projects have more arbitrary restrictions – WebKit famously will do performance tests on every change and if the performance is slower by even a single microsecond, the change is rejected and the developer must either refactor their code to be faster, or find something else to refactor to improve performance by at least as much as their change harmed it.

Some projects try to avoid trusting "people" and instead focusing on wether or not they trust the code, considering each contribution on it's own merits. But there is still a question of who do you trust to accept/deny a contribution? And will you reject a contribution because it uses tabs instead of spaces? It's up to you.

Obscure conditions may lead to your project being forked by the community and a new project which you have zero control over becoming more popular. Or simply being slow to accept contributions can have the same result.

For example: the only fork I ever made to a project was after somebody didn't reply to my emails asking to get involved - my fork now has dozens of contributors and ~70,000 users. The original project is dead, the source forge page just links to our website.

7

An open source license that satisfies the OSI definition of "Open Source" will allow anyone to fork a project (that is, creating their own version of it). This includes people you may not want to have anything to do with - for instance a group of people you politically disagree with.

You can refuse to incorporate any pull requests or patches submitted by such people into your code base (the one you and your three friends distribute) for any reason. (Bad code quality of probably being the most common ground for rejection.)

enter image description here

(Source: xkcd).

But you can not stop them from creating a derivative by changing the source code, and then go on and distribute their version to the general public.

However, if you're are good maintainer of your project (and that includes accepting sensible patches and pull requests in a timely fashion), a fork has small chances of attracting a following - but you cannot prevent them from happening.


In a comment, ArtOfCode says:

Not that political disagreements are a good reason to refuse pull requests, of course...

That depends: Let's say I create an open source educational simulation software that allows K-12 pupils to run through simulations of historical events, such as WWII. Let's also assume a group of holocaust deniers modifies the WWII part of this simulation to show their alternate version of WWII and Nazi-Germany's treatment of jews - and submits it as a pull-request. If I was the author of such a simulation program, I am pretty darn sure I would reject it, simply because I disagree (to put it mildly) with the politics of holocaust deniers.

However, If I released this (hypothetical) software as Open Source or Free Software, I could not stop this group of holocaust deniers from distributing their own fork of it.

PS: According to Godwin's law, this question can now be closed :-).

2

Yes, anyone can contribute, but not in the way you describe.

  • Nobody can force you to include their code in your project. You are free do publish only code that you are satisfied with. You can even decide not to include any contributions, ever.

  • Everybody can create their own version of your code. This is called a fork. They can keep the fork private or they can publish the fork. If they publish it and it is very good, people may start using the fork instead of your version. As always with Free Software, it is ultimately the users who decide.

Note that forks happen comparatively seldom, because they incur the risk of duplicate efforts in the long term. So they usually happen only if the original project is either dead or badly maintained. In those cases, the fork takes over, no work is duplicated. However, it is also possible that the original and the fork co-exist side by side. The most famous examples are ffmpeg / avconv and ImageMagick / GraphicsMagick. Those projects have to deal with issues like duplicate efforts and a split of the developer community.

-3

http://opensource.org/osd

http://www.unterstein.net/su/docs/CathBaz.pdf

Basically:

  1. You need to submit patches for functionality the owner/mantainer wants or is willing to approve.

  2. Once you have submitted enough patches, eventually one of the patches will not be accepted.

  3. Then ask the owner/mantainer if he will accept that you fork the project.

  4. Rename the project, to make it clear it is not the same project.

  • 2
    This is incorrect. You don't have to submit patches, nor is there a guarantee that any will be rejected, and you certainly don't have to ask to fork the project. – ArtOfCode Jul 22 '15 at 22:28

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