Rehost And Carry On

I spent time this week in Brussels with many of the key participants in the OpenESB Community. OpenESB is a large software subsystem that conveniently allows all kinds of applications to communicate with each other across networks. We spent two...

Share

I spent time this week in Brussels with many of the key participants in the OpenESB Community. OpenESB is a large software subsystem that conveniently allows all kinds of applications to communicate with each other across networks. We spent two days discussing the status of the project.

It was created by Sun, but since the Oracle acquisition it has, as the former Sun project leader (now at Google) wrote eloquently, languished in the decline reserved for projects which are no longer wanted but have important customers who need supporting in the short term. We heard that there's likely to be a consolidation release with bug fixes in it and there will probably be a trickle of big fixes in future as customer support continues. But there's the soft sound of footsteps backing away to eventually leave it in splendid, unannounced isolation. Meanwhile, the community around OpenESB is actually fairly active, and they want OpenESB to stay around.

Rehost And Carry On
What do you do if a project is hosted under the control of a disinterested party? There's no huge crime or disagreement to "justify" a fork of the code in the way that's usually understood. On the other hand, any new plans really will need the source code and the community presence hosted in ways that allow the residual interested parties to change and improve things. Doing so can't be at the discretion of effective outsiders. Having to wait to get replies to requests and risk having them declined if they are deemed inconvenient is just not acceptable.

That's why the topic under discussion in such circumstances is probably not best termed "forking" - the remaining community is not divided - but rehosting. That's also how I would characterise what ForgeRock (where I work) has done with OpenAM (formerly OpenSSO) and OpenDJ (formerly OpenDS). No conflict, no malice, just a desire by the remaining community to carry on in the aftermath of the main sponsor changing their involvement in an important way, even if it's not a bad or hostile change.

The ability to "rehost and carry on" is a key strength of open source software in business. With proprietary software, the decision by its vendor to end the product is pretty final. Even if you had an escrow arrangement with your supplier, the practicality of continuing to use the code is likely to be negligible. Commercial use of software is more than the code - it's also the availability of support skills and of sustaining and new development.

But with open source software, in the event that the business interests of crucial participants change, the code is still free software under and open source license. As long as there are enough people who each have an interest in the code, it can always be rehosted and the project can carry on as the synchronisation point for those shared interests.  It's a kind of "community escrow", with the ability to keep going protected by the existence of a diverse community of varied interests.

So, if you want security, the answer is not necessarily a big vendor with big promises. Look instead for a project with a diverse co-development community which can provide "community escrow" so that, when apparent disaster strikes, they can just rehost, carry on and keep you running. It's almost worth paying extra for that freedom.


Follow me as @webmink on Twitter and Identi.Ca


"Recommended For You"

Oracle might not keep OpenOffice.org alive Do We Need a Covenant for Open Source Businesses?