couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Naming/branding/forking
Date Mon, 09 Mar 2009 00:05:21 GMT
The CouchDB application we are deploying at the moment has a second  
phase that makes it into a generic platform like the Notes Client. It  
involves building a generic OSX/Win32/Linux GUI into which many  
applications written by our client will be deployed. Because our  
foundation application needs a fail-on-conflict bulk op, the CouchDB  
part of the application will be a fork. Because we have to fork it  
anyway, we are also looking at some other changes.

Independent of the CouchDB Ltd issue, we have been struggling with the  
issue of not using the name (and even not using the Futon logo)  
because of the combination of a) using a fork of CouchDB that has (at  
least) not-officially-supported/officially-unsupported bulk-operation  
semantics; and b) our application being a generic deployment platform  
for a significant group of developers.

We view CouchDB more as a toolkit/library than a product, but sense  
that the CouchDB vision is to be a product with universally defined  
and supported semantics and boundaries. And there's the issue of not  
misdirecting our client's developers - we don't want them thinking  
that the CouchDB documentation is 100% applicable. Nor do we want to  
muddy the CouchDB definition. The internal counter argument is that  
using the CouchDB name even at this point has commercial advantage -  
especially useful selling a new technology.

Firstly, are we correct in our assumptions about 'the CouchDB product'  
with universally consistent (i.e. not configurable) semantics being  
'the plan'? What are other people's thoughts/advice about these issues?


Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Plurality is not to be assumed without necessity
   -- William of Ockham (ca. 1285-1349)

View raw message