Re: Unhappy campers Linux Inside
[Prev][Next][Index][Thread]

Re: Unhappy campers

 In article <205@fishpond.uucp> fnf@fishpond.uucp (Fred Fish) writes:
 >If PH was not granted a monopoly on distribution, it would have been possible
 >for all of the interested minix hackers to organize and set up a group that
 >was dedicated to producing enhanced-minix.  This aim of this group could have
 >been to produce a single, supported version of minix with all of the commonly
 >requested enhancements.  This would have allowed minix to evolve in much the
 >same way that gcc has evolved over the last few years.  
 This IS possible.  If a group of people wants to do this, that is fine.
 I think co-ordinating 1000 prima donnas living all over the world will be
 as easy as herding cats, but there is no legal problem.  When a new release
 is ready, just make a diff listing against 1.5 and post it or make it FTPable.
 While this will require some work on the part of the users to install it,
 it isn't that much work.  Besides, I have shell scripts to make the diffs
 and install them.  This is what Fred van Kempen was doing.  What he did wrong
 was insist on the right to publish the new version, rather than diffs against
 the PH baseline.  That cuts PH out of the loop, which, not surprisingly, they
 weren't wild about.    If people still want to do this, go ahead.  
 
 Of course, I am not necessarily going to put any of these changes in my version,
 so there is some work keeping the official and enhanced ones in sync, but I
 am willing to co-operate to minimize work.  I did this for a long time with
 Bruce Evans and Frans Meulenbroeks.
 
 If Linus wants to keep control of the official version, and a group of eager
 beavers want to go off in a different direction, the same problem arises.
 I don't think the copyright issue is really the problem.  The problem is
 co-ordinating things.  Projects like GNU, MINIX, or LINUX  only hold together
 if one person is in charge.   During the 1970s, when structured programming
 was introduced, Harlan Mills pointed out that the programming team should
 be organized like a surgical team--one surgeon and his or her assistants,
 not like a hog butchering team--give everybody an axe and let them chop away.
 
 Anyone who says you can have a lot of widely dispersed people hack away on
 a complicated piece of code and avoid total anarchy has never managed a
 software project.  
 
 >Where is the sizeable group of people that want to evolve gcc in a way that
 >rms/FSF does not approve of?
 A compiler is not something people have much emotional attachment to.  If
 the language to be compiled is a given (e.g., an ANSI standard), there isn't
 much room for people to invent new features.  An operating system has unlimited
 opportunity for people to implement their own favorite features. 
 
 
 Andy Tanenbaum (ast@cs.vu.nl)