Re: beta testing version - Mailing list pgsql-hackers
From | The Hermit Hacker |
---|---|
Subject | Re: beta testing version |
Date | |
Msg-id | Pine.BSF.4.21.0012031724220.468-100000@thelab.hub.org Whole thread Raw |
In response to | Re: beta testing version (Don Baccus <dhogaza@pacifier.com>) |
List | pgsql-hackers |
On Sun, 3 Dec 2000, Don Baccus wrote: > At 11:00 PM 12/2/00 -0800, Vadim Mikheev wrote: > >> There is risk here. It isn't so much in the fact that PostgreSQL, Inc > >> is doing a couple of modest closed-source things with the code. After > >> all, the PG community has long acknowleged that the BSD license would > >> allow others to co-op the code and commercialize it with no obligations. > >> > >> It is rather sad to see PG, Inc. take the first step in this direction. > >> > >> How long until the entire code base gets co-opted? > > > >I totaly missed your point here. How closing source of ERserver is related > >to closing code of PostgreSQL DB server? Let me clear things: > > (not based on WAL) > > That's wasn't clear from the blurb. > > Still, this notion that PG, Inc will start producing closed-source products > poisons the well. It strengthens FUD arguments of the "open source can't > provide enterprise solutions" variety. "Look, even PostgreSQL, Inc realizes > that you must follow a close sourced model in order to provide tools for > the corporate world." Don ... have you never worked for a client that has paid you to develop a product for them? Have you taken the work you did for them, that they paid for, and shoved it out into the community to use for free? Why would we do anything any differently? Your clients ask you to develop something for them as an extension to PgSQL (its extensible, ya know?) that can be loaded as a simple module (ala IPMeter) that gives them a competitive advantage over their competitors, but that doesn't require any changes to the physical backend to implement ... would you refuse their money? or would you do like PgSQL, Inc is doing, where we do a risk-analysis of the changes and work with the client to make use of the "competitive advantage" it gives them for a period of time prior to releasing it open source? Geoff explains it much better then I do, from a business perspective, but any extension/application that PgSQL, Inc develops for our clients has a life-span on it ... after which, keeping it in track with what is being developed would cost more then the competitive advantage it gives the clients ... sometimes, that is 0, some times, 6 months ... extreme cases, 24 months ... Nobody is going to pay you to develop X if you are going to turn around and give it for free to their competitor ... it makes no business. In alot of cases, making these changes benefits the project as some of the stuff that is required for them get integrated into the backend ...
pgsql-hackers by date: