Re: PostgreSQL derivatives

On Fri, Jun 13, 2008 at 02:06:01PM +0100, Simon Riggs wrote:
>
> Many others do this also, but my concern is with how we can create the
> right conditions under which contribution is a positive thing for the
> contributor, not just a charitable, and therefore a more optional, act.

We don't need to create those conditions, because they're already
there.

Part of the reason I had a relatively easy time convincing my
management at Afilias to release Slony was the lousy experience we had
with erserver: enhancements were hard, every bug discovered in the
system was one we found, there was no community with whom to discuss
enhancements, &c. Managing your own software is _work_, and if the
code you're using needs to be synchronised in some way with code
coming from elsewhere, you either have to have a really significant
source of income from that private code (which makes the cost and
effort of maintaining your private tree worth it), or else you will
naturally want to find a way to minimise those costs. The obvious way
to minimise them is to make them public, so that the ongoing
maintenance becomes everyone's problem.

This is really one of the core "open source" (rather than free)
software arguments, and one that is often overlooked compared to the
quality argument that is often advanced. But IT departments and
software shops don't care nearly as much about quality, alas, as they
care about shedding costs that they can't attribute to revenue
somewhere. Software is a business. Crappy quality hurts you all
along, but it's hard to measure and the costs are usually not directly
associated (on the balance sheet that lands before the CFO) with the
source of the problem. Keeping people on staff to maintain your own
personal software that is ancillary to your main line of business,
however, is a demonstrable cost that shows up on spreadsheets. It
will get cut, or you'll find a way to attribute revenue to it.

I suspect (but have no real evidence for the theory) that the above
reasoning is why some of the earlier "private" edb enhancements ended
up getting contributed instead. I think it was Neil, upthread, who
said approximately the same thing about Truviso: enhancements that
they make that aren't key to their central commercial problem are
enhancements they don't want to maintain privately, because it's
just distracting. I imagine that Greenplum's problem is that
maintaining Bizgres is too distracting, because not enough of what
they are doing can be released without undermining their own revenue
stream. Since just about no other contributors showed up, there was
little justification for the work on Bizgres.

So I don't think there's an issue here. I think any artificial
efforts to make things "easier" for the firms will not actually have
the effect we want, because the main incentive for company-mandated
contributions (money) is already present.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/