Can I select who can contribute to my Open Source Project?

Question

Take this into consideration:

I post one of my software projects that I had written for school, and give it an open source license, and place it online for people to evaluate and contribute their thoughts. I do this in hopes that other more experienced developers will be able to optimize or add new features to my already existing program.

But how would I prevent malicious people from tampering with that code? If my project is the victim of multiple, continuous attacks and vandalism, it wouldn't be efficient on my part to "rollback" to earlier revisions. Not only would this be an annoyance, but it could make the project look less attractive to prospective contributors.

Can I restrict or "approve" contributors to help me improve the project? I'm nervous that doing so would violate the Open Source concept. As seen on the Open Source page:

Can I stop "evil people" from using my program?

No. The Open Source Definition specifies that Open Source licenses may not discriminate against persons or groups. Giving everyone freedom means giving evil people freedom, too. Fortunately, there are other laws that constrain the behavior of evil people.

Does this apply only to the audiences of my program, or would it apply to people who try to contribute to it as well?

Answer 1

You, as the maintainer, can decide what you merge into your project. That doesn't prevent others from forking and maintaining their own version of the code though.

If you post the code to some place like GitHub or other code sharing service, you are given a set of permissions that determines who can merge changes to your master branch. It is not something that is open to the world. Others can submit pull requests (in the case of GitHub), but you are free to reject them as you see fit.

Answer 2

I think you're mixing up two concepts here. The quote you provided is for people using your software. If you want your software to be open source, you have to accept that everyone is permitted to use it.

Accepting contributions is a completely different cup of tea. As a maintainer you can accept or reject whichever patch you like. Look how Linus does that constantly with Linux.

Still, other people get a right to fork (open source per definition always allows that). So you can't forbid them to release their patches to your software, but you can reject them for your version of the program.

Answer 3

Carefully selecting which changes are accepted, and which are rejected is one way that you control the direction of your project. Accept all submissions, and you'll end up with a mess, or at the very least, something you didn't envision.

Of course, if you document the vision and goals of the project, it becomes easier for you to select submissions, and it becomes easier for contributors to submit changes that align with your goals.

Answer 4

I believe the article What Is The Spirit of Open Source? by Phil Haack is relevant here:

There were those who felt that it was was disingenuous for me to use the term “open source software” to describe a Microsoft project that doesn’t accept contributions and is developed under a closed model, even if it is licensed under an open source license.

Technically, publishing your code under an open source license is all you need to be an open source project. You don't need to accept any contributions at all. That's because anyone else can fork your project and use that.

While some would argue that this may not be in "the spirit of open source", that's not really the right term to use:

But Miguel [de Icaza] thought a better term is “open and collaborative development.” That’s the process that is so closely associated with developing open source software that it’s become synonymous with open source in the minds of many people. But it’s not the same thing because it’s possible to conduct open and collaborative development on a non-open source project.

Answer 5

You can definitely select who contributes to your project. This violates neither the letter nor the spirit of any of the common definitions of free/libre/open-source.

Anyone may use your open source project, even if you don't like what they do with it. That's freedom 0 in the FSF definition, clause 1 in the Open Source Definition, guideline 1 in the DFSG.

Anyone may make a copy of your open source project and modify it in any way they like, even if you don't like the way they modify it. That's freedom 1, clause 3, guideline 3.

You do retain the right to manage your project as you see fit. All open source projects, even the ones that have a publicly visible source repository and an address to submit patches, validate what modifications are accepted, and reject modifications that they don't like. Not all open source projects do accept patches — some just release a new version now and then and do all their development behind closed doors. Public repositories are common nowadays, but this wasn't always the case — in the 1990s, even GNU software was developed behind closed doors, only new releases were open source!

Note in particular that you retain the right to be identified as the author of what you wrote, and conversely of not being identified as the author of what you didn't write. Many common licenses and common definitions of free/libre/open-source allow the original author to make reasonable requirements on attribution, for example:

• rules about how to package a modified version are acceptable (…). Thus, it is acceptable for the license to require that you change the name of the modified version, remove a logo, or identify your modifications as yours. (FSD)

• Clause 4 (“Integrity of The Author's Source Code”) of the DFSG and the OSD. This clause allows the practice that is common in some circles to require that modified versions of a work carry a different name. For example, the LaTeX Project Public License requires third-party modified versions of packages to have a different name unless they are compatible with the original (§6.a).

• You may convey a work based on the Program (…) provided that (…) the work must carry prominent notices stating that you modified it (GNU GPL)

Independently of copyright law, laws about libel and fraud would generally prevent someone else from claiming that their modified version is your project.