You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Ted Husted <te...@gmail.com> on 2006/02/26 16:03:20 UTC

How the ASF works (was In search of a release cycle ... )

On 2/26/06, Allen Gilliland <Al...@sun.com> wrote:
> I am new to the ASF so I apologize for my ignorance, but how is the PMC
> our core customer?  Who is the PMC you are talking about?

The best starting point to learn more about the ASF, and Project
Management Commitees (PMCs), is

* http://apache.org/foundation/how-it-works.html

The ASF sprang from the Apache HTTPD project.  Because HTTPD had
become a high-profile product, the original "Core Group" wanted to
shield themselves from personal liability. The Core Group also wanted
to share the "Apache Way" with other development teams. Raymond's "The
Cathedral and Bazaar" paints one picture of open source development (
"benevolent maintainer"). The Apache Way paints another (meritocracy).

* http://www.catb.org/~esr/writings/cathedral-bazaar/

Apache HTTPD came about because Brian Behlendorf needed a scalable web
server to meet the high-volume needs of a new website his company was
building. He had some patches to the NCSA web server, and he knew some
other engineers working for other companies that also had some
patches. This initial group began trading patches over email, and
ultimately created the first Apache server.

But, the "core group" was not doing all this to fill a need in the
"marketplace". They were filling their own need for a better web
server. Not for someone else's benefit, but for the benefit of the
core group who were developing the server. We eat our own dog food
because we are the dogs.

The "prime directive" of an ASF project is not to simply create
software for lurkers to download. We are creating software for our own
use -- the use of the committers -- and sharing that software with the
general public. Why do we share? Why do we support users? Why do we
add some features we might not use ourselves? Why do we do all of our
development in public?

We share our work with the general public so that we can attract,
interview, and train new committers -- both to expand our core groups
and to replace members of our core groups that go off to do other
things. Another reason we share is to proselytize "meritocratic
development" as an alternative to the "benevolent maintainer" model.

They say the proof of a pudding is in its taste. From an ASF
perspective, the proof of a community is in its ability to attract new
contributors. Not new lurkers that simply download the software and go
on their way, but new contributors who help us create an even better
product. The cornerstone of meritocracy is the belief that we can
build a better product working together than any one of us could
create on our own.


> but in any case my only
> goal is to provide quality blogging software.  personally, my motives
> are inspired by blogs.sun.com, but not limited to or entirely controlled
> by blogs.sun.com.

In a volunteer project, motives are very important. A commercial team
is motivated by a paycheck. But what motivates developers working for
a non-profit organization with no paid staff?

Most of us are motivated by the need to use the software at work
(where we do get a paycheck). But, we don't want projects controlled
by short-term commercial interests. We want projects controlled by the
people who actually write the code. People like Dave, and Allen, and
Avil, and Matt, and Henri, and Elias, and Lance.  We want the
decisions to be made by engineers, not by marketing departments. We
want the lunatics to be in charge of the asylum

Because our focus in on the volunteers, not the employers, we don't
consider "blogs.sun.com" to be the actual customer. Sites like
"blogs.sun.com" are simply places where some of our
volunteer-customers deploy the product we create and maintain.

Since the volunteers do the work, in our eyes, the volunteers earn the
merit. If the volunteers are clever enough to get paid while they do
the work, that's great, but that's between the committers and their
employers. If a volunteer changes employers, the volunteer is still a
committer (and the former employer is still *not* a committer).

-Ted.