chapter3.pdf

(383 KB) Pobierz
CHAPTER THREE
ON FORKING WORDPRESS, FORKS IN GENERAL, EARLY WORDPRESS,
AND THE COMMUNITY
By January 2003, b2 was dormant. Michel,
michelvaldrighi,
hadn’t
been online for months and no one was maintaining b2. The blog-
ging software at the core of the growing community was no longer
evolving. The web, and blogging, was moving forward, but b2
had lost its driving force. The community was concerned.
Michel
blogged at the end of December 2002
and then didn’t post again
until 2004. Where was he? Was he okay?
On his blog,
Matt
wrote a post called “The
Blogging Software
Dilemma,”
in which he first mentioned forking b2; the post that
led to the creation of WordPress. At the time, he was concerned
1
about his website’s forward compatibility.
Jeffrey Zeldman’s
For-
ward Compatibility: Designing and Building with Standards
had
influenced his thinking. Zeldman’s book covered how to create
standards-compliant websites that would work across browsers and
devices. Matt had already converted most of his site to XHTML
1.1, but none of this mattered with b2 dormant. Michel’s disappear-
ance, however, didn’t have to mean the end of the software. Matt
wrote:
“b2/cafelog is GPL, which means that I could use the exist-
ing codebase to create a fork, integrating all the cool stuff
that Michel would be working on right now if only he was
around. The work would never be lost, as if I fell of the face
of the planet a year from now, whatever code I made would
be free to the world, and if someone else wanted to pick it
up they could. I’ve decided that this (sic) the course of ac-
tion I’d like to go in, now all I need is a name. What should
it do? Well, it would be nice to have the flexibility of Mov-
able Type, the parsing of Textpattern, the hackability of b2,
and the ease of setup of Blogger. Someday, right?”
2
The next day, from Stockport, UK, Mike Little,
mikelittle,
re-
sponded:
“If you’re serious about forking b2 I would be interested
in contributing. I’m sure there are one or two others in the
community who would be too. Perhaps a post to the b2 for-
um, suggesting a fork would be a good starting point.”
Forking is the act of bifurcating a free software project, taking
it in a new direction. The word fork derives from computing lan-
guage in the 1960s. In Unix-like operating systems, the
fork()
system call causes a process to split into two by copying itself, re-
sulting in parent and child processes. By the mid-1990s, fork was
being used to describe a split in an open source project. It was of-
ten frowned upon in the open source community. Eric Raymond,
an open source leader and author of
The Cathedral and the Bazaar,
writes about the taboos around forks in his essay
Homesteading the
Noosphere.
“The open source culture has an elaborate but largely
un-admitted set of ownership customs,”
he writes.
“These customs
regulate who can modify software, the circumstances under which
3
it can be modified, and (especially) who has the right to redistribute
the modified versions back to the community.” Raymond outlines
some of the taboos around forking:
• Social pressure often prevents project forking. Usually
forking only happens out of “dire necessity, with much
public self justification, and requires a renaming.”
• Except in cases such as porting trivial fixes, distributing
changes without cooperation from the original developer is
frowned upon.
• Removing a person’s name, history, credits, or maintainer
list is not done without the person’s consent.
In general,
forking was considered “a Bad Thing,”
to be avoid-
ed at all costs to prevent splits in the development community and
arguments over successor legitimacy.
A
2012 study of 220 software forks
and their outcomes took a
less dim view. To be a fork, the study outlines, the project should
4
Zgłoś jeśli naruszono regulamin