Re: PostgreSQL derivatives

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 Sup****t


-- 
Sent via pgsql-advocacy mailing list (pgsql-advocacy@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy