From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: "Producting Open Source Software" book and distributed SCMs
Date: Mon, 30 Apr 2007 01:20:42 +0200 [thread overview]
Message-ID: <200704300120.42576.jnareb@gmail.com> (raw)
I have read lately classic book "Producing Open Source Software. How to
Run a Successful Free Software Project" by Karl Fogel (2005).
Among others, author advocates using version control system as a basis
for running a project. In "Choosing a Version Contol System" he writes:
As of this writing, the version control system of choice in the free
software world is the Concurrent Versions System or CVS.
Further on much of examples of managing project and managing volunteers
revolves around the idea of "commit access", and it is assumed
implicitely that version control system is centralized. It is
understandable, as in 2005 there were (according to Linus) no good
distributed version control systems (SCMs). Also Karl Fogel writes in
preface that much of material came from the five years of working with
the Subversion project, and Subversion is centralized SCM meant as
"better CVS" and used itself as revision control system; any experience
described had to be with centralized SCM.
The distributed SCM is mentioned in footnote in section "Comitters" in
Chapter 8, Managing Volunteers:
http://producingoss.com/producingoss.html#ftn.id284130
[22] Note that the commit access means something a bit different in
decentralized version control systems, where anyone can set up a
repository that is linked into the project, and give themselves commit
access to that repository. Nevertheless, the concept of commit access
still applies: "commit access" is shorthand for "the right to make
changes to the code that will ship in the group's next release of the
software." In centralized version control systems, this means having
direct commit access; in decentralized ones, it means having one's
changes pulled into the main distribution by default. It is the same
idea either way; the mechanics by which it is realized are not
terribly important.
I'm interested in your experience with managing projects using
distributed SCM, or even better first centralized then distributed SCM:
is the above difference the only one? Linus has said that fully
distributed SCM improves forkability:
"Re: If merging that is really fast forwarding creates new commit"
Message-ID: <Pine.LNX.4.64.0611070841580.3667@g5.osdl.org>
http://permalink.gmane.org/gmane.comp.version-control.git/31078
Time for some purely philosophical arguments on why it's wrong to have
"special people" encoded in the tools:
I think that "forking" is what keeps people honest. The _biggest_
downside with CVS is actually that a central repository gets so much
_political_ clout, that it's effectively impossible to fork the
project: the maintainers of a central repo have huge powers over
everybody else, and it's practically impossible for anybody else to
say "you're wrong, and I'll show how wrong you are by competing fairly
and being better".
According to "Producting Open Source Software" it is very important
feature for an OSS project. See section "Forkability" of Chapter 4,
Social and Political Infrastructure (beginning of chapter):
http://producingoss.com/producingoss.html#forkability
The indispensable ingredient that binds developers together on a free
software project, and makes them willing to compromise when necessary,
is the code's _forkability_: the ability of anyone to take a copy of
the source code and use it to start a competing project, known as
a fork. The paradoxical thing is that the _possibility_ of forks is
usually a much greater force in free software projects than actual
forks, which are very rare. Because a fork is bad for everyone (for
reasons examined in detail in the section called "Forks" in Chapter 8,
Managing Volunteers, http://producingoss.com/producingoss.html#forks),
the more serious the threat of a fork becomes, the more willing people
are to compromise to avoid it.
Besides that, what are the differences between managing project using
centralized SCM and one using distributed SCM? What is equivalent of
committers, giving full and partial commit access, revoking commit
access? How good support for tagging and branching influences creating
code and build procedure? Is distributed SCM better geared towards
"benovolent dictator" model than "consensus-based democracy" model, as
described in OSSbook?
Thanks in advance for all responses
--
Jakub Narebski
ShadeHawk on #git
Poland
next reply other threads:[~2007-04-29 23:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-29 23:20 Jakub Narebski [this message]
2007-05-01 9:35 ` "Producting Open Source Software" book and distributed SCMs Johannes Schindelin
2007-05-01 15:23 ` Theodore Tso
2007-05-01 15:45 ` Johannes Schindelin
2007-05-01 18:30 ` Jakub Narebski
2007-05-01 23:13 ` Linus Torvalds
2007-05-01 16:15 ` Linus Torvalds
2007-05-01 22:27 ` Jakub Narebski
2007-05-01 22:45 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200704300120.42576.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).