On avoiding accusations of forking a project

Sometimes forking a project is necessary to reassert community control over a project that has become overly dominated by a single corporate rules: see OpenIndiana and LibreOffice for recent examples. And in the world of distributed version control systems, forking is viewed positively; it's a form of evolution, where experimental branches that lead to new features or a stabler system or better performance get grafted back onto the accepted authoritative branch.

Yet a negative connotation can also be associated with forking a project, particularly if the word is whispered behind closed doors as an accusation of the behaviour of one or more parties in the community. Particularly in a small community, where development resources for a project built on the principles of software freedom from the ground up are relatively scarce, the spectre of a development effort based on that project that is not publicly visible can be troubling and opens the door to the accusation: FORK! Organizations that have staked their customers' satisfaction, and their own reputation, on free software that they expected to see flourish as others joined in the development effort, fret and worry that they'll be left behind with just the base for another organization's project and no easy way to reconcile the two.

In the Evergreen community, we're fortunate that we're small enough that we should be able to avoid these concerns. The Evergreen "trunk" code repository has been hopping; just take a peek at the revision log to see the rather torrid pace of development. Some major features are taking shape, such as acquisitions with EDI support, first-class serials management, outbound telephony, and more - evident in the Evergreen 2.0 alpha 3 release that the development team put together today. This is not a minor release!

And yet, and yet... during the exciting KCLS migration live-blog, Lori Ayre felt it necessary to write:

The answer is that much of it is already in trunk, and if it isn't there now, it will be very soon. None of this work is being held back. There is no KCLS fork. This is all Evergreen and anyone who knows how to download from trunk will be able to get at this code in very short order.

Well, I know that everyone involved with the KCLS enhancements are good people, and that that it is certainly their intention to make any of the enhancements available, and there is no intention to fork Evergreen. I know! Ironically enough, however, due to the prior actions of proprietary companies such as Relais' "announce that we will open source our ILL product in 2008; freeze the market; announce in 2010 that maybe we'll have something by the end of 2010" strategy, the broader library community has become more skeptical and susceptible to disinformation and FUD. I can't imagine who would want to sow discontent among the community of a rapidly maturing ILS project, other than perhaps proprietary competitors who have forgotten how to compete on the merits of their product rather than negative marketing. (Just a guess, mind you!)

Still: until the code for any remaining enhancements is available under an open source license, the possibility that those whispering, Saruman-like voices could be right remains an actual possibility. My suggested remedy for the easiest way to dispel those concerns, now and in the future for any project (Evergreen or otherwise), is to simply develop in the open:

• Create a public repository - SVN (Evergreen contributions), or Bazaar (Evergreen LaunchPad), or git (Gitorious), or what have you. Put a README in the top directory of the repository specifying that the contents are licensed under the "GPL v2 or later" or GPL-compatible license.
• Announce the repository on the Evergreen development mailing list. If you tuck your repository in an obscure location and don't tell anybody about it, it might technically be open, but that's not really the spirit of openness. You're also depriving your effort of possible collaborators, and possibly duplicating effort if somebody else is working on the same feature.
• Watch the rumours disappear and the fame, glory, and accolades roll in. (Oh, and don't forget to invite us to integrate the fruit of your labour into the core of Evergreen!)

Sure, there might be some material that you don't want to share: trademarked institutional logos or the like. But the bulk of what we collectively create should be able to be openly shared, not just when things are perfectly baked, but all the way through the process. Release early, release often, and keep the spooky whisperers at bay.