Re: What can we learn from MySQL? - Mailing list pgsql-advocacy
From | Christopher Browne |
---|---|
Subject | Re: What can we learn from MySQL? |
Date | |
Msg-id | m3wu40suv0.fsf@wolfe.cbbrowne.com Whole thread Raw |
In response to | Re: What can we learn from MySQL? ("scott.marlowe" <scott.marlowe@ihs.com>) |
List | pgsql-advocacy |
Clinging to sanity, greg@turnstep.com ("Greg Sabino Mullane") mumbled into her beard: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >> I'm gonna disagree here. I think that not having a postgresql inc >> to go to means that by the time postgresql becomes ubiquitous, it >> will be like apache. no company behind it, every company using it. > > That's not entirely accurate. Apache has had lots of help from IBM, > as well as a few other very large companies. > >> No need for a postgresql inc to do that, just time, good code, and >> knowledgable DBAs choosing it more and more often. > > Sorry, but technical prowess alone is no recipe for success in > today's marketplace. Things are more complex than that. Yeah, things _are_ more complex than that. But consider also that products that are, in essence, commercial products must be marketing successes in order to persist at all. In order for MySQL AB to get paid, and in order for there to be upgrades to the software, it is _essential_ that their products appear to be vital commercial successes in the commercial marketplace. There's some $19.6M of vulture capital that expresses exactly how essential that is... If they don't achieve the commercial success that the owners expect, technical prowess or lack thereof is an entire nonissue. The fact that there are no "vulture capitalists," no "$19.6M of commercial pressures," and no stockholders means that some of the vital 'criteria for failure' that exist for MySQL(tm) do not exist for PostgreSQL. The criteria for evaluating success and failure _do_ differ. It is wasteful of time and effort to slavishly try to evaluate the differing software on the same criteria. If there is value in any of this exercise, it isn't in finding similarities; it is in finding _useful_ differences. - Useful differences between how aspects of PostgreSQL are presently publicized and how they might be; - Useful differences between the features PostgreSQL and other software that are worth publicizing; - Useful differences between PostgreSQL and other software in terms of "soft differences" such as licensing and cost that are worth publicizing. It is distinctly NOT useful to merely try to find ways to slavishly emulate what other projects are doing, particularly if they require substantial political reorganization or a vulture capitalist with $19.6M to invest. It's hard to push contributors to a free software project. A useful quote: "Feel free to contribute build files. Or work on your motivational skills, and maybe someone somewhere will write them for you..." -- "Fredrik Lundh" <effbot@telia.com> If a 'release manager' is needed, then either you need the venture capital to pay someone to do that, or some serious motivational skills good enough to let you convince people that don't "report to you" to change what they want to do. The ideal thing to do is to try to motivate people to do things that they will find interesting and desirable. I don't see much focus on that approach; rather the contrary. -- "cbbrowne","@","ntlug.org" http://www3.sympatico.ca/cbbrowne/sgml.html Signs of a Klingon Programmer - 2. "Specifications are for the weak and timid!"
pgsql-advocacy by date: