Date: Tue, 7 Aug 2001 21:51:53 -0400 From: Charles Shannon Hendrix <shannon@widomaker.com> To: freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? Message-ID: <20010807215153.B9801@widomaker.com> In-Reply-To: <3B7024D9.55EAFBDD@mindspring.com> References: <003f01c11cd7$563d7860$1401a8c0@tedm.placo.com> <3B6EAD30.8161F4E5@softweyr.com> <3B6F9145.54945750@mindspring.com> <20010807121133.A73889@dogma.freebsd-uk.eu.org> <3B7024D9.55EAFBDD@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 07, 2001 at 10:26:49AM -0700, Terry Lambert wrote: > I remain convinced that the major limitations in Open Source > developement models are emergent properties of the tools that > are being used. [snip] > In FreeBSD's case, it's mostly an issue of the tools being unable > to handle multiple lines of developement, which has resulted in > the "One True HEAD Branch" phenomenon, where work not occurring > on -current is often discarded, due to the emotional investment > people have in -current. I have always wanted a tool that scaled well from just me, to a team, and did so without putting some draconian in charge of releases. If a team is well disciplined and has good leadership, the tools created generally follow and the project has little need for the kingdom-builders that infest so much corporate work I've been in. It's quite true that there isn't a lot of software to support some things that are beginning to become more of a problem: * very large projects * very complex projects * ...which last a long time * ...where team members come and go, maybe even the leaders * ...which need to maintain patches against multiple releases * ...which need discipline * ...needing to produce very, very reliable work I don't really see this as an open source vs commerical problem since there aren't many tools _anywhere_ that sucessfully handle these problems. Most good projects succeed because they have really great leaders and a small number of heroic developers, often in spite of their tools and management. Maybe if open source projects started working harder on their management, the tools would follow, but an effort to address tool issues should be made anyway. Open source isn't necessarily new, but having open projects on the kind of scale we have today is <10 years old, so it might just be we are still learning. As an industry, we seem to be very bad about not learning from our mistakes. Are there any projects out there working on tools to fix problems with scale, multiple-branches, discipline, and the now-common situation where project members come and go? > Although the company I work for seems willing to let the code back > into the main line FreeBSD tree after two product release cycles, if > only to offload the maintenance burden, and so our implementation > "wins", it will probably not make it back into FreeBSD, since the > changes are against 4.3-stable, not -current, and -current is moving > at what commercially can only be considered a reckless speed, in > directions not entirely justified by research or the Computer Science > literature (certainly, no one is citing papers or research which > justify the design decisions being made). This is a problem with a large number of projects out there. I would say that Gnome has this problem, but much, much worse. Maybe with large companies getting interested, they will help change that. Evidently Sun has recently issued a paper or something with a list of changes needed in Gnome. It's very easy to let a project get into an extended (possibly endlesss) phase of tacking on features or putting out fires. Not much difference between the two in terms of what it does to a project. Really "designing" software isn't easy, not matter how easy it might seem on simpler projects, where pure zeal might get you through it. I think a lot of the open source world still needs to learn this lesson. > So getting back to the inital point, I think it is a tools issue, > probably more than anything else, which has the emergent property > of selecting one "blessed" branch, and sending all the rest off to > Coventry. My biggest problem with the tools when working as part of a team is the difficulty in managing branches of the code base. I don't just mean a "one head" problem, I mean any kind of branching. Some concepts of branching are needlessly difficult to get your head around, and mistakes are very, very easy to make even if you have been doing it for years. CVS, for example, has done little to make the old RCS branching methods any easier to work with. Most commercial tools seem to solve development problems by beating them to death. When I was forced to use PVCS, I kept my own tree managed with some shell scripts. Like a lot of tools, it was heavy on features for the designated overlords, but few for the programmer (that worked). I have heard good things about some other tools, but often they are not universal or are too expensive for me to even afford a single user copy. That's definitely going to be a barrier to open source projects using them, and in the end I really think open source needs an open tool to use. > It seems like several commercial companies have latched onto "the > complexity defense" to throw up barriers to entry, in an attempt to > keep Open Source out of their mainstream commercial markets. I > watch the IETF very closely, and participate when I feel it's > needed, and I have to say I've recently seen some of the most > arcane and unnecessarily complex RFCs shoved through the IETF > standardization process by large companies working in concert, in > what can only be described as protectionist tactics. No doubt about it. Also, often those companies can manage the resulting projects through abuse of their labor force, not better methodology. Just about everywhere I have worked there is this pool of code-monkeys who will foolishly do 70 hour work weeks without overtime. It was fear, not tools, that enabled them to complete complex projects. As long as they can get away with that, they'll continue to stupidly reinvent the wheel and produce complexity instead of sophistication. Obviously you cannot do that to open source volunteers, nor should you want to. I think we'll find better ways, and the really good companies will too, since eventually the monkeys get ticked off and quit. Eeeeeee eeeeeee eeeeeee... :) > Hopefully, Open Source will be able to overcome its inherit > handicaps; it may be that FreeBSD switches to using Perforce, or > some other tool that gets rid of the "One True Head Branch" > phenomenon, despite the commercial use pain that such a switch > would entail (P4 is free for Open Source, but not for commercial > companies tracking an Open Source project, whose repository is > only available in P4). I would worry about committing to a tool that may or may not remain free in the future. It would be better to come up with an open solution. -- "I wish life was not so short. Languages take such a time, and so do all the things one wants to know about." - J. R. R. Tolkien ______________________________________________________________________ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010807215153.B9801>