The case for the One-Click Installer - Mailing list pgsql-advocacy

All,

Selena pointed out that the current argument about procedure is
pointless.  She's right.  Therefore, let me explain *from an advocacy
perspective* the reason why the one-click installer is important.

Not that this means that we need to have EnterpriseDB do our installers,
but it explains what would have to be replaced in a non-EDB community
installer.  And, for that matter, why I encouraged EnterpriseDB to build
a one-click installer for community PostgreSQL last year.

When I was working in the MySQL department at Sun last year, I got an
earful on the things the PostgreSQL project had done wrong which MySQL
AB had been able to take advantage of.  There were some interesting
surveys on why people chose to adopt MySQL over PostgreSQL (and I'll
tell you that most of the reasons discussed here or on planetpostgresql
are missing the point).

One of the biggest reasons for people choosing MySQL was the "some
assembly required" nature of PostgreSQL: the requirement to find and
download 5 to 20 separate components, often from separate web sites, and
compile and integrate them yourself.  Further, even where operating
system packages provided a lot of these extra components, the set of
components available and what they're called varied widely between
packages.  And many components were simply not available on Windows.

For a developer who "just wants a database" that approach is
intolerable, and they'll use anything else which provides them a
"complete package".  As of 8.2, this issue was possibly the largest
single blocker to increased PostgreSQL adoption, probably greater than
built-in replication or any of the other technical features we like to
talk about.  Discussions about installers and packages on -hackers and
other lists largely petered out without anyone offering to help.

Therefore, we needed a "just install it" package.  If I had been able to
build this using the Sun team, I would have.  However, only EnterpriseDB
was in a position to supply the staff and technology.

Since 8.3, the One-Click installer has been wildly successful in
bringing in new users.  On IRC, I'd estimate that 50% of new users
showing up used it to install (higher on Mac or Windows).

Therefore, any replacement of EnterpriseDB's "one click installer" needs
to be able to replace the "just install it" functionality.  And it needs
to work as well as the One-Click does.

Because EDB is a VC-funded company and may someday be sold, I agree that
it's not healthy to be dependant on them for installers.  One way to
resolve this is for more people to help and get Dimitri's extension
packaging system finished; if we had that, the issue of packaging all
drivers and components would be come vastly decreased, and supporting
multi-operating-system installers much easier.  However, I've yet to see
anyone arguing for an change of installers on this list volunteer to
help Dimitri, and his project is liable to not complete this year due to
lack of help.

Further, let me point out again that the MSI installers were dropped
because *absolutely nobody* wanted to put any work into them other than
the EDB staff.  So it's not like we're drowning in installation
contributors.

In other words, if you care about the installer situation and want to
change it, the way to do so is to put in some work building installers,
module packagers, or other tools to improve the community installation
situation.  *Not* shouting arguments about what EDB ought to do.

I'll admit that I'm fundamentally lazy and would prefer to work on parts
of PostgreSQL which EnterpriseDB isn't taking care of, like autotuning
and tutorials.  We have a TODO list long enough for 100 times the
contributors we have now.  But how any contributor spends their time is
up to them.

(and can I just say how much the arguments on this list sound like the
"Red Hat is taking over Linux" of 2001?)

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com