Re: PostgreSQL derivatives - Mailing list pgsql-advocacy
From | Simon Riggs |
---|---|
Subject | Re: PostgreSQL derivatives |
Date | |
Msg-id | 1213391894.25121.253.camel@ebony.site Whole thread Raw |
In response to | Re: PostgreSQL derivatives (Andrew Sullivan <ajs@commandprompt.com>) |
List | pgsql-advocacy |
On Fri, 2008-06-13 at 10:15 -0400, Andrew Sullivan wrote: > 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. Well argued, that all makes sense. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
pgsql-advocacy by date: