Re:So You Want to Be An Open Source Rockstar...
on
Open Sources 2.0
·
· Score: 1
Heh, got my own subtitle wrong: it's "How to Run a Successful Free Software Project" not "How to Manage...". Sorry about that. You can catch a glimpse of an earlier stage in the title-choosing process through that error.
Re:So You Want to Be An Open Source Rockstar...
on
Open Sources 2.0
·
· Score: 1
Well, there's "Producing Open Source Software: How to Manage a Successful Free Software Project", by yours truly. It's just been published by O'Reilly, and it's online at http://producingoss.com/. It's under a CreativeCommons license, so yes, the book itself is open source:-). Hmmm, let's make that URL stand out a bit more:
That's the web site for the new O'Reilly book "Producing Open Source Software: How to Manage a Successful Free Software Project". The book's content is all there online, under an open copyright. Even when I was writing it, I was thinking of the classroom as one place where the book might be useful. Have a look and see what you think.
The article has the sequence of events wrong: what actually happened was that BitMover Inc changed the BitKeeper license to shut out developers who work on competing open source systems, and BitMover did this only after Linus had selected BitKeeper as the version control software for the Linux Kernel.
The discussions the kernel team had about choosing BitKeeper were based on the assumption of zero-cost licenses for all open source developers who wanted to contribute to or follow kernel development. At this time, there was nothing in the BK license about excluding developers who work on competing software.
Then, later, BitMover changed the license, after Linus et al had gone to the trouble of making the switch. There's a term for this: "bait and switch".
"Unusably slow" over a thousand files or so is totally unexpected, and not my experience at all.
The Subversion tree itself has more than a thousand files, yet we don't have any speed problems. I'd like to know exactly what you're observing, and what might be causing it.
keesh, would you mind describing the your slowness problems on users@subversion.tigris.org? Thanks.
Not sure why the original poster said Subversion came from "the people who maintain CVS". They are two separate developer groups -- as far as I know there is no overlap between the currently active developers of CVS and Subversion.
Also, he was early:-). Subversion 1.0 wasn't actually out yet when he posted. We had released a beta prerelease, and were careful to say that 1.0 itself wouldn't be out till Monday. Oh well, win some, lose some.
Copyright law has been extending its domain since its inception. This process has been driven by corporate interests -- not, as the RIAA would have you believe, by creators and artists trying to "protect their rights".
If, even after the RIAA lawsuits and now this, you still think that copyright is basically a socially good idea that just gets taken too far sometimes, please see
A number of posters ask why would one even want to use CVS considering its known faults? Although I'm personally partial to Subversion, choosing CVS doesn't seem unreasonable. CVS is no less useful today than it was (say) two years ago, before Arch or Subversion or any of the other new kids on the block were ready. If you want something that does the job and whose problems are known, CVS is not a bad choice.
But on to the real reason for my post:
Some of the posts here make simply wrong statements about Subversion. Below are corrections.
1. Subversion does not require a Unix user account per vc user. Furthermore, this is true not just with the WebDAV (http://) access method, but also with the svnserve (svn://) method. Some posts said otherwise; not sure why.
2. Subversion does *not* require Apache, nor does it require you to use the WebDAV protocol for repository access. Apache/WebDAV is one of two entirely independent network access methods. The other is a custom protocol (think of it like CVS pserver) using a custom server (svnserve) and its own URL space, "svn://".
3. Subversion is not in Alpha anymore, it is in Beta. This was a recent transition, so it's understandable that people wouldn't have known about it.
4. Someone said you can't make client-side graphical reports about revisions and differences, because the client doesn't have access to the right information. I think this person must have read and misunderstood a highly technical mailing list thread. The client does have access to the necessary information already (see 'svn log -v' for starters).
People with further questions about Subversion should please come to users@subversion.tigris.org, or irc.freenode.net, channel #svn. Hope to see you there!
By the way, I have not used Arch in a long time, so can't comment on the differences between it and Subversion.
I feel a bit embarrassed now:-), because it looks like I wanted to keep half the book proprietary, even though I didn't (in fact, it is all free now, I just haven't had a chance yet to get the other chapters online yet... RSN, though).
The original division into free and non-free chapters was the result of a compromise between the publisher and me. They originally had wanted to publish a book about Open Source practices, under a standard proprietary copyright; I wanted to write a book about CVS, under a free copyright.
The result was a book about both. I wasn't able to persuade them to put the whole book under the GPL (I tried), but was able to get the CVS portion free. Since that was the book I really wanted to write, I felt this achieved my goal, even though there were these other chapters to confuse the issue:-).
Since then, I've realized that the compromise was, well, compromising, especially since more people people than I expected liked the Open Source chapters (I guess this means Coriolis' original plan was a pretty good one after all). I wish now I'd pressed harder for making the whole book free, though it's still unlikely that they could have been persuaded at the time.
Paraglyph Press (http://www.paraglyphpress.com) is republishing the entire second edition of the book, the one revised by Moshe Bar. Paraglyph was really impressive -- they didn't hesitate a bit when I told them the entire book was now under the GPL (I hold the copyright, and my contract with Coriolis long ago expired). They said they were very happy to publish the whole thing under that license, and then they put their money where their mouth is: they emailed me all the.pdf files they got from Coriolis, that is to say, I now have the entire book in the electronic format used by the publisher, and I can put it online. Haven't done it yet, only because I've been busy, but I will get the stuff up there, along with an explanation of the whole tortured history:-).
Desiring recognition is different from desiring the right to prevent others from sharing. If I write a Free book, for example, I might still object if someone else started distributing it with their name in place of mine as the author, even though I'd have no objection to them distributing it otherwise. There's no inconsistency here.
Stallman is not being hypocritical. He realizes that credit (reputation) is a finite resource: the degree to which another person takes it is the exact degree to which the original person loses it. But the work *itself*, be it software or prose or sheet music, is an infinite resource, in the sense that exisiting copies are in no way diminished when a new copy is made.
When someone steals credit, it's known as "plagiarism" and it's a separate offence from copyright violation. The law has always understood the distinction between the two. Plagiarism is more like simple lying than it is like theft of property. Stallman is quite right to object to it -- it's an offense against truth, not against property rights. (Whether you agree that Stallman deserves credit for everything he claims credit for is a different question; I happen to think he does, but even if he doesn't, his sin would be something other than the hypocrisy you accuse him of).
The Subversion project has been self-hosting for almost a year now -- that is, the Subversion source code is kept in a Subversion repository (at http://svn.collab.net/repos/svn/), and we all use Subversion working copies to do development.
Sourcecast provides automated mailing list support, bug tracking, and the like. It's not part of Subversion, it's just other software we use. (E.g., It's kind of like saying "I heard they don't use Subversion themselves, they use GCC!":-) )
Huh? Cheap, unobtrusive branches are what Subversion is all about. Not sure what is meant by "adopted the Sourcesafe model". We certainly didn't mean to; at the time we designed Subversion, we knew mainly CVS, certainly didn't know enough about Sourcesafe to design anything intentionally like it:-).
I think you may be misunderstanding Subversion's branching model.
I hope both systems (Arch and Subversion)
get some widespread use. Like a lot of
Subversion developers, I'm genuinely curious
to see a) how well the Arch model works in
practice, and b) how well Arch's implementation
of that model works out. If it turns out to
be winning, then that'll be a big step forward
for collaborative projects & free software.
Arch sounds a lot like Bitkeeper
only without the license problems, and I've
talked to some happy Bitkeeper users before
(a small sample, so it's hard to know whether
we're dealing with a Shift To Better Paradigm
or just good software).
Subversion was deliberately designed to
address CVS's shortcomings, not to break new
ground. Our philosophy was essentially
conservative: CVS basically works, but has
some bugs and maintainability problems. Let's
keep the model and fix the problems. Result:
Subversion.
The ideal situation is a world where both
models have good, free implementations. Then
we'll all very quickly find out which model
works better.:-)
Imagine that the expansion of Pi were infinite
and non-repeating, but coincidentally never
contained the digit `8'. As you can see,
there's no contradiction there -- such a string
is possible, although it happens that Pi is
not one such.
Therefore, any data with an `8' would not
be locatable in Pi.
The conclusion that all possible data sequences
appear in X because X is infinite and
non-repeating is the misstep. (I once came
to that same wrong conclusion myself, but
a fellow named Dave Kuhl corrected me, thanks
Dave!:-)
For myself and a number of friends, Lisp/Scheme programming has for too long been a kind of mystical Eden, fading in our memories, from which we have been mostly banished in our professional lives. But we can still recall how it felt to work in a language able to shape itself to any pattern our minds might ask: coding was more interesting and more expressive, and the rate of increasing returns over time was tremendous, because fine-grained -- almost continuous -- abstraction was in the nature of the language. Life was just more fun, frankly.
Alas! In our jobs and even in our personal projects, we are often forced to use C, C++, Java, Perl, or Python -- not because we prefer to write in those languages, but for two much less satisfying reasons: first, everyone else knows those languages, so we'll get more developers with them. And second, you can't count on users and testers having the right environment to run programs written in Lisp/Scheme, so right away you take a portability hit if you choose to develop in them.
Do you think there is a chance of Lisp/Scheme becoming "mainstream" again? That is, when someone contemplates starting a project, it would be as realistic for them to consider Lisp or Scheme as, say, Perl, without worrying about losing developers or initial testers? What will it take?
Is the idea that a package won't get listed
until someone out there submits it for
inclusion? I was somewhat surprised to see
that CVS, certainly a well-known and stable
piece of software, is not in the database.
-Karl
I wanted to make the entire book free, but the publisher wasn't comfortable with that. However, they were enthusiastic about making the CVS- specific portions of the book free. In fact, they may have suggested it before I did.
I think the logic was that CVS is free, so the documentation about CVS should also be free. It was certainly more important to me that the CVS portions be free than the rest, although I wish the entire thing could have been free.
Deep down, I think intellectual property is a contradiction in terms, but in order to get this book published I made a compromise.:-)
Fortunately, it looks like Coriolis has no reason to regret their agreement to release the majority of the book for free. Sales are doing well, and it's already into reprint. Long live dead trees!
Go lends itself much more naturally to standalone "puzzler" problems. Also, the proportion of Go players is higher -- and growing -- in hackerdom than in the general population, so it's not as off-the-beaten-trail as one might think for Slashdot.
The immediate readership for Go problems may be smaller than for chess, but those readers will be much more passionate participants, proportionally, and their numbers will be increasing all the time...
There's some good stuff in that book, but a number of the essays are essentially marketing propaganda for whatever open-source company that essay's author happens to be associated with. Personally I don't feel any need to reward good PR...
I believe Linus decided against CVS for the kernel
on
Free Books Online
·
· Score: 1
...with some justification, IMHO, Linus decided that CVS could not handle the Linux kernel (it's just too many files). And it is true that on a large project with lots of history, certain CVS operations can become might slow. I'd love to see it in CVS too, but I can't deny that Linus' complaints are valid.
If I remember correctly, the Linux kernel is (or soon will be) in BitKeeper, which was specifically designed with the Linux kernel in mind, although it is supposed to be of general utility too. Unfortunately, BitKeeper's license is not completely free, which I think prevents its wider adoption. I have no idea of its technical merits, never having used it myself, but from what I've read at their web site they appear to be thinking carefully about how to do revision control.
Liked the article a lot, found it very clear and well-written. However...
I don't think the facts are quite straight regarding FSF Emacs vs XEmacs. Questions of history aside, the main thing preventing a merge right now is that the XEmacs folks don't have legal papers for all their contributions. The FSF requires these for code it releases; hence, no merge into FSF Emacs, at least not in such a way that the FSF will serve the result from their servers.
The statements about the current maintainability of XEmacs vs FSF Emacs are also suspect. I don't think FSF Emacs is so complex as to require a "genius level" maintainer -- and, as far as I know, Stallman is not in fact its primary maintainer right now, although he is involved. (The fact that multiple people are involved in FSF Emacs's maintenance is a testament to its maintainability... as is its 20 year age!)
Also, with regards to GCC->EGCS->GCC, I don't believe Stallman ever did anything to delay the arrival of Pentium optimizations. Rather, the GCC maintainer (who was not Stallman) did not fold in patches he received for these optimizations Out of impatience, the EGCS team forked and made their own version of GCC. Eventually the FSF (i.e., Stallman) decided to make EGCS the official FSF "GCC". Far from being a resister who tried to keep the optimizations out of GCC, Stallman was responsible for a major step in the EGCS->GCC transition.
Well-written article, just don't want to see Stallman get blamed for stuff he's not responsible for.
Slashdot Mirror
Heh, got my own subtitle wrong: it's "How to Run a Successful Free Software Project" not "How to Manage...". Sorry about that. You can catch a glimpse of an earlier stage in the title-choosing process through that error.
Well, there's "Producing Open Source Software: How to Manage a Successful Free Software Project", by yours truly. It's just been published by O'Reilly, and it's online at http://producingoss.com/. It's under a CreativeCommons license, so yes, the book itself is open source :-). Hmmm, let's make that URL stand out a bit more:
http://producingoss.com/
There. Hope this helps!
-Karl Fogel
This is a completely shameless bit of self-promotion, but:
http://producingoss.com/
That's the web site for the new O'Reilly book "Producing Open Source Software: How to Manage a Successful Free Software Project". The book's content is all there online, under an open copyright. Even when I was writing it, I was thinking of the classroom as one place where the book might be useful. Have a look and see what you think.
Best,
-Karl Fogel
/me blushes in embarrassment
Thanks, ninjagin.
The article has the sequence of events wrong: what actually happened was that BitMover Inc changed the BitKeeper license to shut out developers who work on competing open source systems, and BitMover did this only after Linus had selected BitKeeper as the version control software for the Linux Kernel.
l
The discussions the kernel team had about choosing BitKeeper were based on the assumption of zero-cost licenses for all open source developers who wanted to contribute to or follow kernel development. At this time, there was nothing in the BK license about excluding developers who work on competing software.
Then, later, BitMover changed the license, after Linus et al had gone to the trouble of making the switch. There's a term for this: "bait and switch".
See also http://subversion.tigris.org/subversion-linus.htm
-Karl Fogel
[Disclaimer: my viewpoint only, not speaking for my employer.]
"Unusably slow" over a thousand files or so is totally unexpected, and not my experience at all.
The Subversion tree itself has more than a thousand files, yet we don't have any speed problems. I'd like to know exactly what you're observing, and what might be causing it.
keesh, would you mind describing the your slowness problems on users@subversion.tigris.org? Thanks.
Not sure why the original poster said Subversion came from "the people who maintain CVS". They are two separate developer groups -- as far as I know there is no overlap between the currently active developers of CVS and Subversion.
:-). Subversion 1.0 wasn't actually out yet when he posted. We had released a beta prerelease, and were careful to say that 1.0 itself wouldn't be out till Monday. Oh well, win some, lose some.
Also, he was early
Anyway, it's almost Monday now, so check back soon at http://subversion.tigris.org/.
Nothing new here :-(.
. html
Copyright law has been extending its domain since its inception. This process has been driven by corporate interests -- not, as the RIAA would have you believe, by creators and artists trying to "protect their rights".
If, even after the RIAA lawsuits and now this, you still think that copyright is basically a socially good idea that just gets taken too far sometimes, please see
http://www.red-bean.com/kfogel/writings/copyright
for a possibly eye-opening history (and a blueprint for change).
Best,
-Karl
A number of posters ask why would one even want to use CVS considering its known faults? Although I'm personally partial to Subversion, choosing CVS doesn't seem unreasonable. CVS is no less useful today than it was (say) two years ago, before Arch or Subversion or any of the other new kids on the block were ready. If you want something that does the job and whose problems are known, CVS is not a bad choice.
But on to the real reason for my post:
Some of the posts here make simply wrong statements about Subversion. Below are corrections.
1. Subversion does not require a Unix user account per vc user. Furthermore, this is true not just with the WebDAV (http://) access method, but also with the svnserve (svn://) method. Some posts said otherwise; not sure why.
2. Subversion does *not* require Apache, nor does it require you to use the WebDAV protocol for repository access. Apache/WebDAV is one of two entirely independent network access methods. The other is a custom protocol (think of it like CVS pserver) using a custom server (svnserve) and its own URL space, "svn://".
3. Subversion is not in Alpha anymore, it is in Beta. This was a recent transition, so it's understandable that people wouldn't have known about it.
4. Someone said you can't make client-side graphical reports about revisions and differences, because the client doesn't have access to the right information. I think this person must have read and misunderstood a highly technical mailing list thread. The client does have access to the necessary information already (see 'svn log -v' for starters).
People with further questions about Subversion should please come to users@subversion.tigris.org, or irc.freenode.net, channel #svn. Hope to see you there!
By the way, I have not used Arch in a long time, so can't comment on the differences between it and Subversion.
I feel a bit embarrassed now :-), because it looks like I wanted to keep half the book proprietary, even though I didn't (in fact, it is all free now, I just haven't had a chance yet to get the other chapters online yet... RSN, though).
:-).
.pdf files they got from Coriolis, that is to say, I now have the entire book in the electronic format used by the publisher, and I can put it online. Haven't done it yet, only because I've been busy, but I will get the stuff up there, along with an explanation of the whole tortured history :-).
The original division into free and non-free chapters was the result of a compromise between the publisher and me. They originally had wanted to publish a book about Open Source practices, under a standard proprietary copyright; I wanted to write a book about CVS, under a free copyright.
The result was a book about both. I wasn't able to persuade them to put the whole book under the GPL (I tried), but was able to get the CVS portion free. Since that was the book I really wanted to write, I felt this achieved my goal, even though there were these other chapters to confuse the issue
Since then, I've realized that the compromise was, well, compromising, especially since more people people than I expected liked the Open Source chapters (I guess this means Coriolis' original plan was a pretty good one after all). I wish now I'd pressed harder for making the whole book free, though it's still unlikely that they could have been persuaded at the time.
Paraglyph Press (http://www.paraglyphpress.com) is republishing the entire second edition of the book, the one revised by Moshe Bar. Paraglyph was really impressive -- they didn't hesitate a bit when I told them the entire book was now under the GPL (I hold the copyright, and my contract with Coriolis long ago expired). They said they were very happy to publish the whole thing under that license, and then they put their money where their mouth is: they emailed me all the
Desiring recognition is different from desiring the right to prevent others from sharing. If I write a Free book, for example, I might still object if someone else started distributing it with their name in place of mine as the author, even though I'd have no objection to them distributing it otherwise. There's no inconsistency here.
Stallman is not being hypocritical. He realizes that credit (reputation) is a finite resource: the degree to which another person takes it is the exact degree to which the original person loses it. But the work *itself*, be it software or prose or sheet music, is an infinite resource, in the sense that exisiting copies are in no way diminished when a new copy is made.
When someone steals credit, it's known as "plagiarism" and it's a separate offence from copyright violation. The law has always understood the distinction between the two. Plagiarism is more like simple lying than it is like theft of property. Stallman is quite right to object to it -- it's an offense against truth, not against property rights. (Whether you agree that Stallman deserves credit for everything he claims credit for is a different question; I happen to think he does, but even if he doesn't, his sin would be something other than the hypocrisy you accuse him of).
Absolutely wrong :-).
:-) )
The Subversion project has been self-hosting for almost a year now -- that is, the Subversion source code is kept in a Subversion repository (at http://svn.collab.net/repos/svn/), and we all use Subversion working copies to do development.
Sourcecast provides automated mailing list support, bug tracking, and the like. It's not part of Subversion, it's just other software we use. (E.g., It's kind of like saying "I heard they don't use Subversion themselves, they use GCC!"
Huh? Cheap, unobtrusive branches are what Subversion is all about. Not sure what is meant by "adopted the Sourcesafe model". We certainly didn't mean to; at the time we designed Subversion, we knew mainly CVS, certainly didn't know enough about Sourcesafe to design anything intentionally like it :-).
I think you may be misunderstanding Subversion's branching model.
-Karl
Hard to believe they chose it, but they did.
Subversion was deliberately designed to address CVS's shortcomings, not to break new ground. Our philosophy was essentially conservative: CVS basically works, but has some bugs and maintainability problems. Let's keep the model and fix the problems. Result: Subversion.
The ideal situation is a world where both models have good, free implementations. Then we'll all very quickly find out which model works better. :-)
-Karl
No -- the first boldface assumption is not true.
:-)
Imagine that the expansion of Pi were infinite
and non-repeating, but coincidentally never
contained the digit `8'. As you can see,
there's no contradiction there -- such a string
is possible, although it happens that Pi is
not one such.
Therefore, any data with an `8' would not
be locatable in Pi.
The conclusion that all possible data sequences
appear in X because X is infinite and
non-repeating is the misstep. (I once came
to that same wrong conclusion myself, but
a fellow named Dave Kuhl corrected me, thanks
Dave!
-Karl
For myself and a number of friends, Lisp/Scheme programming has for too long been a kind of mystical Eden, fading in our memories, from which we have been mostly banished in our professional lives. But we can still recall how it felt to work in a language able to shape itself to any pattern our minds might ask: coding was more interesting and more expressive, and the rate of increasing returns over time was tremendous, because fine-grained -- almost continuous -- abstraction was in the nature of the language. Life was just more fun, frankly.
Alas! In our jobs and even in our personal projects, we are often forced to use C, C++, Java, Perl, or Python -- not because we prefer to write in those languages, but for two much less satisfying reasons: first, everyone else knows those languages, so we'll get more developers with them. And second, you can't count on users and testers having the right environment to run programs written in Lisp/Scheme, so right away you take a portability hit if you choose to develop in them.
Do you think there is a chance of Lisp/Scheme becoming "mainstream" again? That is, when someone contemplates starting a project, it would be as realistic for them to consider Lisp or Scheme as, say, Perl, without worrying about losing developers or initial testers? What will it take?
Is the idea that a package won't get listed until someone out there submits it for inclusion? I was somewhat surprised to see that CVS, certainly a well-known and stable piece of software, is not in the database. -Karl
was discovered, if 3 moons were discovered in
1979?
Pick them nits,
-Karl
I wanted to make the entire book free, but the
:-)
publisher wasn't comfortable with that. However,
they were enthusiastic about making the CVS-
specific portions of the book free. In fact,
they may have suggested it before I did.
I think the logic was that CVS is free, so the
documentation about CVS should also be free.
It was certainly more important to me that the
CVS portions be free than the rest, although I
wish the entire thing could have been free.
Deep down, I think intellectual property is
a contradiction in terms, but in order to get
this book published I made a compromise.
Fortunately, it looks like Coriolis has no reason
to regret their agreement to release the majority
of the book for free. Sales are doing well, and
it's already into reprint. Long live dead trees!
-K
Apologies for the broken links at
cvsbook.red-bean.com, the problem is now fixed.
-Karl
Go lends itself much more naturally to
:-)
standalone "puzzler" problems. Also, the
proportion of Go players is higher -- and
growing -- in hackerdom than in the general
population, so it's not as off-the-beaten-trail
as one might think for Slashdot.
The immediate readership for Go problems may
be smaller than for chess, but those readers
will be much more passionate participants,
proportionally, and their numbers will be increasing all the time...
Vote Go!
There's some good stuff in that book, but
a number of the essays are essentially
marketing propaganda for whatever open-source
company that essay's author happens to be
associated with. Personally I don't feel any
need to reward good PR...
...with some justification, IMHO, Linus
decided that CVS could not handle the
Linux kernel (it's just too many files).
And it is true that on a large
project with lots of history, certain
CVS operations can become
might slow. I'd love to see it in CVS too,
but I can't deny that Linus' complaints
are valid.
If I remember correctly,
the Linux kernel is (or soon will be) in
BitKeeper,
which was specifically designed with
the Linux kernel in mind, although it
is supposed to be of general utility too.
Unfortunately, BitKeeper's license is not
completely free, which I think prevents its
wider adoption. I have no idea of its
technical merits, never having used it myself,
but from what I've read at their web site
they appear to be thinking carefully
about how to do revision control.
Liked the article a lot, found it very clear
and well-written. However...
I don't think the facts are quite straight
regarding FSF Emacs vs XEmacs. Questions
of history aside, the main thing preventing
a merge right now is that the XEmacs folks
don't have legal papers for all their contributions. The FSF requires these for code
it releases; hence, no merge into FSF Emacs, at
least not in such a way that the FSF will serve
the result from their servers.
The statements about the current maintainability
of XEmacs vs FSF Emacs are also suspect. I don't
think FSF Emacs is so complex as to require a
"genius level" maintainer -- and, as far as I know, Stallman is not in fact its primary
maintainer right now, although he is involved.
(The fact that multiple people are involved in
FSF Emacs's maintenance is a testament to its
maintainability... as is its 20 year age!)
Also, with regards to GCC->EGCS->GCC, I don't
believe Stallman ever did anything to delay the
arrival of Pentium optimizations. Rather, the
GCC maintainer (who was not Stallman) did not fold
in patches he received for these optimizations
Out of impatience, the EGCS team forked and made their own version of GCC. Eventually the FSF (i.e., Stallman) decided to make EGCS the official
FSF "GCC". Far from being a resister who tried
to keep the optimizations out of GCC, Stallman
was responsible for a major step in the
EGCS->GCC transition.
Well-written article, just don't want to see
Stallman get blamed for stuff he's not responsible
for.
-Karl