4

Some projects only allow committers to submit patches because they wish to keep their IP "clean." not only can non-committers not submit patches, but committers are forbidden from looking at your code lest they become tainted by intellectual property of unknown provenance.

instead, you are invited to start a discussion on their listserv or submit a ticket, and then the committers will decide if your feature is worthy.

Improve this question
6
  • Bad open source maintainer there! Besides, the whole idea of a committer is pretty obsolete.
    – alternative
    Apr 19, 2011 at 21:11
  • 1
    Do you have a specific example? I'm curious to see what kinds of software packages have these restrictions.
    – chrisaycock
    Apr 19, 2011 at 21:24
  • 5
    Two responses: a) Say, "You're losing talent," and move on with life, or b) Create your own branch of the project and allow patches to be submitted from other people. Let them drown in their own bureaucracy while you take over the market share.
    – riwalk
    Apr 19, 2011 at 21:43
  • 2
    Projects like these are open source in name only. Why do you need a "retort"? This isn't debate class. Just walk away.
    – Rein Henrichs
    Apr 19, 2011 at 21:47
  • @Stargazer712: Wasn't that one of the issues in the Gnu Emacs/XEmacs split?
    – David Thornley
    Apr 19, 2011 at 21:51

4 Answers 4

Reset to default
5

The problem of patent attacks towards FOSS is real. Some projects, like those of the Apache Software Foundation, require contributors of any kind to sign a contract in which the contributor assumes all responsibility in case of litigation (actually, you declare that your contributions are in good faith and legal).

That kind of contractual agreement may seem harsh for someone that just wants to contribute, but doing it that way protects the community and the software:

  1. There's not a large organization to sue.
  2. Individual responsibilities dilute as the software is changed.
  3. The community gets protected from malicious contributions.

The SCO case proved that FOSS can be the target of (unfair) legal attacks, and projects adopt the means they find best to protect their work. The SCO case was about copyright; patent cases should be even more complicated.

Companies like IBM have helped protect FOSS that they're involved with by giving away patents, resigning to others, and also keeping a solid portfolio that they selectively license to FOSS projects.

Improve this answer
2
  • Except this isn't about commit rights, it's about patch submission.
    – Rein Henrichs
    May 1, 2011 at 14:21
  • 2
    @Rain It's the same. FOSS projects don't mind about how a change gets into the sources. They care about the source of and rights over the contribution.
    – Apalala
    May 6, 2011 at 22:20
3

You should always be able to submit a patch, and then it is up to a maintainer to decide whether the patch should go in the repository.

If they do not want patch submissions, then they have to write everything themselves. Some do that, but those are rarely those making most releases.

Improve this answer
3

How about "Why do I need to be a committer to propose a patch? Is there something we can do about that?" Projects are run in cathedral mode for reasons. They may be bad reasons, but you need to know them if you want to change somebody's mind.

Improve this answer
1
  • the stated reason (as I originally posted) was that they wanted to "keep the IP clean."
    – rbp
    Apr 25, 2011 at 14:07
1

I suspect some of the most common responses would probably be:

  • "How do you expect to get an open source project off the ground if you're not open to submissions from the community?" (This one isn't very helpful, but probably common...)
  • "What form would I need to fill out to assign copyright to [one of the developers/some trusted organization]?" (The FSF uses this method to keep their IP clean)
  • Do as they say and start a discussion on the listserv/post a ticket and hope they fix your issue themselves.
  • To take a response from a related question: you could fork the project (and either run it publicly with a more open submission policy or just maintain a local fork for yourself only). Unfortunately, this is likely too much work if you only want to submit one (or a few) patches.

If none of the above seem to be appropriate (or they just don't work), the best course of action might just be to pretend the project doesn't exist and look for an alternative.

My personal suspicion (and hope) is that any at least moderately popular open source project, run like this for any amount of time, will eventually fork once enough "outsiders" get tired enough of their attitude to do something about it.

Improve this answer

Your Answer

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

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