Getting the right kind of contributions

Getting the right kind of contributions

Posted May 30, 2008 0:43 UTC (Fri) by giraffedata (subscriber, #1954)
Parent article: Getting the right kind of contributions

Most free software projects encourage contributors—it is the rare project that has an overabundance—but contributions vary greatly in quality.

I think the right way to say this is that most free software projects encourage high-quality contributors and rarely have an overabundance of those. And of course, the quality standard is specific to the project.

Because the big, popular projects do tend to have an overabundance of contributors and do a lot to discourage them. These are the projects where the few people in control reject patches that aren't perfect or aren't submitted according to procedure, and don't help people understand the code, but quickly reject a patch when it's wrong.

When the Linux kernel first became one of those, Linus made the statement that a maintainer's job is mostly saying no. Put another way: rejecting contributions.

The Linux kernel isn't entirely that way now; I recall the x86 maintainer saying recently that he never rejects a contribution just for style reasons -- he just fixes it himself (or something like that). But most projects don't have that kind of maintainer resource.

When I add to an open source project, I take a few minutes with the mailing list archive to see if it's one of those that already has too many contributors. If so, I just keep my work to myself.

---

(Log in to post comments)

take the Linus quote in context. he was saying that it's not the maintainers job to write
code, but to make sure that the code that's accepted is the right thing to do.

he was mostly talking about the functionality, not submission process or code style.