mattdorn.com

I recently had to add CSV logging functionality to the PloneFormMailer product for a customer. This isn’t the first time we’ve wanted to add some customization to an Open Source project. The temptation in such situations is always to simply make your changes, and maintain your own personal fork of the project. That’s generally the quickest way to get your own project squared away with the least expenditure of mental energy, but it doesn’t show a lot of foresight.

Leaving aside the ethical obligation of contributing back to a project which you’ve benefited from, there’s a self-interest element at work as well: If you don’t contribute your changes to the project’s main branch, then every time you want to take advantage of, say, a bug-fix release or a release with some new enhancement you need, you have to undertake to merge your own customizations, which can end up being pretty time-consuming.

The dilemma comes when you customize an open source project in some way that’s not likely to be of interest to other users of the project–any patch you may contribute will be unlikely to be accepted to the project, probably because the risk of introducing new bugs into the system outweighs the relative advantages of the new functionality.

But if your own contribution is of sufficient interest to the general user base of the project, you ought to be able to get it included the project’s main branch. Still, the maintainers of any Open Source project are likely to review patches from third parties with a lot of suspicion, so you’ll want to take extra care to make it as easy as possible for the maintainer to approve any contribution you make.

Some guidelines can be found here: http://www.kegel.com/academy/opensource.html

In the case of the CSV enhancement to PloneFormMailer, it seemed like a really common use case, so I wrote to the project maintainer and he responded that he was indeed interested in a patch.

My understanding is that typically such patches are done against the latest release, not against some unreleased repository branch. In this case, though, the maintainer requested that any patch I supplied be created against the trunk.

Because I know that the product is now being maintained in SVN at svn.plone.org, I used svn to create the patch, which will make it as easy as possible to merge the changes:

cd /svn/working/directory svn diff > /tmp/csv_logging.diff

That created a patch for both of the two files I modified in the product’s root directory.

I also wrote a unit test based on the PloneTestCase framework (in the absence of any test suite in the last release), but discovered that in the trunk a test suite had been begun using doctest, which I’m not familiar with.

Whether the patch is accepted or rejected, I’ll update here with any lessons learned from the process.