Your Patch Sucks

The realities of contributing patches to open-source projects is this, they...

• generally fix a symptom, not the cause
• often miss the spirit and intent of the original code
• will complicate Intellectual Property rights if not done right
• often complicate the code base if relatively large
• are often contributed by people who will not maintain or support them

These criticisms translate to bugs and instabilities that will cost the project community time and money.

For sufficiently large projects like Apache Hadoop, these are necessary evils the Committer community must overcome otherwise Hadoop would probably not exist. Across all the Committers, millions of dollars a year is spent developing and testing Hadoop so the sponsoring companies can indirectly benefit from the efficiencies it provides.

Cascading is different. It is a Java library and is extensible and not tremendously complicated like Hadoop and other projects. You do not need to patch Cascading to make it do what you want 99% of the time, just implement some interface and hand it back to Cascading to use. Integration with external systems is a perfect example.

Because of this, my saying I don't accept patches is silly since I rarely receive them.

That said, I do get approached by people who want X or Y feature. And this leads me to another point.

First, all projects have three communities associated with them. The User community, the Committer community, and the Contributor community. Sometimes there is a fourth, the Customer "community".

So people can get involved by participating in each or all of those aspects of the project. Helping other users or publishing code that extends a project.

That is, Users use and help other aspiring Users, Committers are the core developers taking responsibility for their code, and Contributors write and publish extensions or submit patches to the project. Oftentimes Contributors need to find a sponsoring Committer to get a patch through else it will likely sit in limbo.

Many companies get into open-source so they can monetize their Users. Smart companies create a Customer community and let the User community migrate naturally to it.

But here is an interesting reality about Contributors. The contribution they wrote likely cost someone money.

So as a business, do you let your developers spend time writing a patch to add a feature that will trigger one or more of the above Patch criticisms, or do you just pay a Committer to do it the "right way"? Sometimes this is under the guise of Support, but often just a simple contract programming job.

I think the later option, paying Committers for changes, is the most healthy for small self contained projects like Cascading or other similarly complex projects (like maybe Elastic Search) until relevant pressures push the projects to new levels of complexity.

But if you want to contribute because you need some feature to improve your business, recognize your company will be paying for it. Either they will pay you your salary to do something tangential to your job, or they can pay a Committer to do their job of adding features.

I suspect the long term investment in paying Committers for Features in a project will turn out to be cheaper for all parties. But sometimes that's not the point.

Projects grow and improve from all kinds of contributions, both direct patches to the core, and through indirect contributions like extensions, documentation, or even blog posts promoting some interesting feature or innovative use.

This is the best way to prove yourself to the Committer community. Get involved by lifting a burden from the community, or by growing the community through evangelism.

So yes, the Cascading project really does want your contributions and eventually your patches. But like all projects, you need to prove that you will stand by them.

Drop me a note if you want ideas on ways to participate in the Cascading community, I really would love the help.

So when I say "your Patch will suck", I'm really challenging you to prove me wrong.