Re: PostgreSQL derivatives - Mailing list pgsql-advocacy
From | Andrew Sullivan |
---|---|
Subject | Re: PostgreSQL derivatives |
Date | |
Msg-id | 20080613141546.GB12690@commandprompt.com Whole thread Raw |
In response to | Re: PostgreSQL derivatives (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: PostgreSQL derivatives
Re: PostgreSQL derivatives |
List | pgsql-advocacy |
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@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
pgsql-advocacy by date: