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:

Previous
From: "Andrew Payne"
Date:
Subject: Re: What can we learn from MySQL?
Next
From: Bruce Momjian
Date:
Subject: Re: What can we learn from MySQL?