0:18
We got our start in the early days of the web as a group of disaffected webmasters
who were using a piece of freely available web software.
But I had difficulty with it.
We were fixing bugs, we were sharing these big fixes
with each other like baseball trading cards, if you will.
These patches, as it's called.
And one day we discovered the group that put out the web server that we were using
basically folded when all their developers left to go
join a brand new company called Netscape.
So a bunch of us decided that hey, we're dependent upon this software.
We don't want to become full-time web server developers,
but we want to be able to use this thing that we've had for free,
and be able to improve it, and all that kind of stuff.
We looked at the license of the code.
And the license said, here's this software, do whatever you want with it.
Don't blame us when it breaks.
Right?
And we said, hey that's a pretty good bargain.
Why don't we pass the same bargain onto the next group of people?
Right?
So, we formed a mailing list.
Right? And this was mostly, again, webmasters,
and people working at some early Internet service providers or
website design companies or places like Amazon or the Internet Movie Database.
And we combined our patches together and
decided to call it Apache Server for that reason, and it went forward.
And really the model of how we worked was based upon us as a group, as peers.
Proposing ideas, vetting each other's ideas and patches, and
fixing bugs as a group, as a team.
None of us had met in person, well some of us have met, but as a group we didn't
meet in person until 1998, really three years after we got our start.
And long after, by the way,
we had become the most predominant web server product on the planet.
And yet at this time still no money, no dime.
Not direct to us from this piece of open source software, but
plenty of us made our living off of building things on top of this piece.
And that's really the story, I think, of successful open source projects writ large.
Which is people working together on common technologies to solve common problems,
so they can go off and make money on other places.
Or so they can have fun, they can try new ideas, they can be experimental.
Right?
And that's really the same story of Apache and of Linux and
all these other open source projects.
It turns out to be not that hard to be able to work together when
people have the same common goal,
which is let's build a product that does all of this great stuff.
One thing that we did do that made it easy to make some of these decisions was to
have a very modular API.
Which made it easy for us to be able to say,
hey, if you want that special cool feature, do it as a separate thing
and make it successful and we'll decide whether to bring this into the product
once it's become successful or not.
Right?
Another key thing that plays into this that is true to all open source projects
is that an open source license like we had on ours, that Linux has,
et cetera, carries with it something called the right to fork.
Which means that if I were to go all Colonel Kurtz on the project and
start saying we're going to go here and no one else wanted to follow.
Well, all of those other people could decide to pick up the code and
go start a different project somewhere else.
If they couldn't kick me out,
which is probably what they would have tried to do first.
Right?
This right to fork means that you don't have to have any tolerance for dictators.
You don't have to deal with people who make bad technical decisions.
Charles SeveranceAssociate Professor
