PostgreSQL global development team

In late 1996, we changed the name from Postgres95 to PostgreSQL. It is
a mouthful, but honors the Berkeley name and SQL capabilities. We started
distributing the source code using remote cvs, which allowed people to
keep up-to-date copies of the development tree without downloading an entire
set of files every day.

Releases occurred every 3 to 5 months. This time frame consisted of 2-3 months of
development, a month of beta testing, a major release, and a few weeks
to issue subreleases to correct serious bugs. We were never tempted to
follow a more aggressive schedule with more releases. A database server
is not like a word processor or a game, where you can easily restart it
if there is a problem. Databases are multiuser, and they lock user data inside
the database, so we had to make our software as reliable as possible.

Development of source code of this scale and complexity is not for the
novice. We initially had trouble getting developers interested in a project
with such a steep learning curve. However, our civilized atmosphere, and
our improved reliability and performance, finally helped attract the experienced
talent we needed.

Getting our developers the knowledge they needed to assist with PostgreSQL
was clearly a priority. We had a TODO list that outlined what needed to
be done, but with 250,000 lines of code, taking on any to-do item was a
major project. We realized developer education would pay major benefits
in helping people get started. We wrote a detailed flowchart of the back-end
modules. We wrote a developers' FAQ to answer some of the common questions
of PostgreSQL developers. With this, developers became more productive
at fixing bugs and adding features.

The source code we inherited from Berkeley was very modular. However,
most Berkeley coders used PostgreSQL as a test bed for research projects.
Improving existing code was not a priority. Their coding styles were also
quite varied.

We wrote a tool to reformat the entire source tree in a consistent manner.
We wrote a script to find functions that could be marked as static, or
unused functions that could be removed completely. These are run just before
each release. A release checklist reminds us of the items to be changed
for each release.

As we gained knowledge of the code, we were able to perform more complicated
fixes and feature additions. We redesigned poorly structured code. We moved
into a mode where each release had major new features instead of just
bug fixes. We improved SQL conformance, added sub-selects, improved locking,
and added missing SQL functionality. A company formed to offer telephone
support.

The Usenet discussion group archives started touting us. In the previous
year, we searched for PostgreSQL, and found many people were recommending
other databases, even though we were addressing user concerns as rapidly
as possible. One year later, many people were recommending us to users
who needed transaction support, complex queries, commercial-grade SQL support,
complex data types, and reliability. This clearly portrayed our strengths.
Other databases were recommended when speed was the overriding concern.
Red Hat's shipment of PostgreSQL as part of their Linux distribution quickly
expanded our user base.

Every release is now a major improvement over the last. Our global development
team now has mastery of the source code we inherited from Berkeley. Finally,
every module is understood by at least one development team member. We
are now easily adding major features, thanks to the increasing size and
experience of our world-wide development team.

Bruce Momjian
is writing a book about PostgreSQL for Addison-Wesley, tentatively titled, PostgreSQL: Introduction and Concepts.