Re: Steering committee responce to Great Bridge LLC - Mailing list pgsql-general
From | Ross J. Reedstrom |
---|---|
Subject | Re: Steering committee responce to Great Bridge LLC |
Date | |
Msg-id | 20000509125548.B23566@rice.edu Whole thread Raw |
In response to | Steering committee responce to Great Bridge LLC (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: Steering committee responce to Great Bridge LLC
|
List | 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@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
pgsql-general by date: