Re: Steering committee responce to Great Bridge LLC

From: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>
To: PostgreSQL-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Steering committee responce to Great Bridge LLC
Date: 2000-05-09 17:55:48
Message-ID: 20000509125548.B23566@rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-announce pgsql-general

On Tue, May 09, 2000 at 10:46:01AM -0400, Bruce Momjian wrote:
> In January of this year, the PostgreSQL steering committee
> (http://www.postgresql.org/devel-contrib.html) was approached by
> Landmark Communications (http://www.landmarkcom.com) to discuss the
> creation of a new company to provide commercial support for PostgreSQL
> and other open-source software.

Now we will see the real world test of the (occasional) license debates
that have occured in the postgres community. One of the major points made
by the Berkeley/X license proponents is that these licenses are more
acceptable to commerical enterprises, since they allow the commercial
concerns to keep their changes private. The major complaint from the
GPL crowd has been that that these licenses allow commerical concerns
to take the existing code private, along with their changes.

From reading the PR materials available, it sounds like GreatBridge wants
to Do the Right Thing. I'd like to see a little more up front about what
being 'active contributing members of the [pgsql] community' means:

Will GB follow the RedHat model, and commit to releasing code to any
changes they make? (Note that RedHat has no choice in this for the Linux
kernel) Or will there be a 'GreatBridge' version of pgsql, perhaps with
extended features? I hope GB realizes that trying to take on the 'big
boys' with proprietary extensions is unlikely to be a winning strategy.

> Landmark has expressed interest in hiring PostgreSQL developers to work
> for their new company. Some individuals are already in negotiations
> with Landmark and will make announcements at the appropriate time.

Here lies the potentially most exiting, but also most dangerous part,
for the pgsql public at large: the core team has done amazing work,
in their spare time. Imagine how productive they'd be working on pgsql
full time! However, the big fear is: will GB take pgsql effectively
private, by hiring away key developers?

Even if GB commits to making all the code they develop available under the
existing license, this has a more subtle downside: schedule pressure. As
an avocation, pgsql benefits from the 'inspirational' effect: when the
developers are inspired by a good idea, they work long and hard. If
the creative juices run dry, it can be put aside. As vocation, there's
always deadline pressure. We've already been seeing some of this, as
various people deploy pgsql in mission critical locations: sometimes,
they need a feature, and need it now, no matter if the implementation
isn't the best for future expandability.

Hopefully, this sort of degradation of the codebase can be minimized by
open source's main virtue: peer code review. Currently, nothing goes
in the tree (or at least, stays in the tree very long) if it's a poor
implementation. This is the gate keeper function that Linus plays for the
Linux kernel, and our core plays for us, (although Bruce has said he's
never meet a patch he doesn't like, Tom, Marc, Thomas, or someone else
will usually jump on anything he commits that's a bit dodgy, like my
code ;-) I hope they all maintain this same level of commitment to code
quality, regardless of where their paycheck comes from. Having followed
all the existing open source/commerical development projects currently
under way, I think it's critical that GB not only adopt the open source
license, but the open development model that has been so successful for
pgsql to date.

What about if/when they go public? The legal commitment to maximizing
stockholder value can play havoc with the best of intentions. I can only
hope the the principals at GB have a real understanding of open source and
open development, and remember the story of the goose and the golden eggs:
short term gain could lead to long term loss.

As a sometime patch contributor, but not truly a pgsql developer, yet
(although I like to say 'we' and 'our' ;-), I will commit to continuing
as I have: to learn as much as I can about pgsql, help out on the
mailing lists, and develop new functionality that I need for my uses
of postgresql, hopefully to be included back into the main tree.

Welcome to GB, their people, and their new commitment to postgresql. We'll
all be watching you closely, hoping you all can live up to the promise of
helping make pgsql the success we (as it's users) know it can be. Also
know that if need be, we can fork the project, and carry on in your
absence, as we have up until now. Not a threat, just a friendly reminder:
it's a major strength of open source, to not be tied to someone else's
corporate goals.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

In response to

Responses

Browse pgsql-announce by date

  From Date Subject
Next Message Tom Lane 2000-05-09 19:19:48 Re: Steering committee responce to Great Bridge LLC
Previous Message The Hermit Hacker 2000-05-09 16:33:49 PostgreSQL Global Development Group Releases v7.0

Browse pgsql-general by date

  From Date Subject
Next Message Ramses v. Pinxteren 2000-05-09 18:12:20 pg_database file problem,
Previous Message Tom Lane 2000-05-09 17:35:01 Re: Query bombed: why?