At 2002-02-28 10:51 -0600, guitarlynn wrote: >On Thursday 28 February 2002 08:29, Mike Noyes wrote: ><snip> > > Lynn, > > Your description above closely resembles what SF calls a Foundry. I > > believe we are more than that. In your opinion, are we a "Linux > > Embedded Appliance Foundry", or are we a project that uses evolution > > as a development model? In my opinion, we are the latter. > >I think of LEAF more like the Gnome or KDE projects.
Lynn, Gnome and KDE are single platforms that developers can write to. They use a monolithic development model for the base. Their base is then used as a resource to build things. Are different Gnome/KDE bases available to choose from? If not, they don't correlate well to our project. > > My resistance to the idea directly relates to the amount of time and > > effort that went into gathering everyone under one roof. I'm leery of > > anything that might lead us back to the fragmentation of the past. > >That is completely understood. I think the maturity and tolerance of >other ideas are far more accepted with LEAF than were constrained >within the limitations of the past. The fragmentation in the past >seemed to be developers going directions that were not accepted under >the opinion of the person hosting/controlling the "project" site. Was >Matthew's, Coyote, George Toft's, David D's, or Charles' branches ever >hosted on the LRP site, or any one site for that matter? Not that I can >remember. They were treated more like what LEAF refers to as "affiliate" >versions. They weren't even given that much recognition. The only thing allowed was mailing list use. As a result, fragmentation ensued. >I believe that is a profound and clear fundamental difference that has >no predecessor with LRP. Agreed. >The acknowledgement and existance of LEAF "affiliates" assumes the >position that you seem most concerned with, and the only seperation >between release and affiliate here appears to be the opinion and >process of the individual lead developer. Correct to some extent. However, most of our affiliates crate components (specifically firewalls) that our developers make use of when creating releases/branches. This means we don't have to create something from scratch, and allows for a faster development cycle. It also provides a synergy between the affiliated projects that is beneficial to both. There are a couple of other levels of involvement. Pim van Riezen [1] decided not to join or affiliate with us, but he does participate on the mailing lists. Ken Frazier [2] decided he didn't want anything to do with us. [1] http://freshmeat.net/projects/cish/ [2] http://www.frazierwall.com/ > From your theory of the project "evolution" model, I would assume >includes by definition that one release would eventually "eat up" >other releases. I don't see this happening per se because of the >different directions that everyone is headed. Think of evolution within a family/species, not food chain. As I sated previously [3], releases/branches survive on their merits, and the willingness of their lead developer(s) to continue working on them. [3] http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg04417.html >As directions from different projects head towards the same direction, >some may merge together (or rather join forces for development >reasons). Most won't! The reasoning for this, in my mind, lies in the >simple core target media .... a single floppy disk. This target media >will always promote different ideas and process direction. This sounds like healthy evolution to me. :-) You forgot one important thing that will prevent infinite release/branch creation. There are limited resources (developers/users) in our environment (LEAF). Mind share will prune the week eventually. Developer(s) will only work on a release/branch as long as they receive recognition of their effort. I see this every day on the SF support lists. Abandonment of unused projects is common. >Has the process of the past ever proven evolution were targets and >evolution were the same? The mere existance of LRP, Coyote, what-ever >Matthew will call his new router-system, Mosquito, Duckling, and >associated releases of LEAF (not to mention countless others) >thoroughly proves otherwise. Some simply will not exist in the umbrella >that we call LEAF and the simple existance of any or all of these >denies the concept of evolution itself as being a driving force >between LEAF releases. You just proved that evolution works on a macro level. We are using it within this project on a micro level. I doubt we're the first project to try this, but I was unable to locate an example of a prior attempt. However, I was able to locate a paper describing the benefits of chaotic evolutionary development. http://papers.maxwell.af.mil/research/ay2000/awc/hept.htm >The maturity, selflessness, and tolerance of the lead developers make >LEAF what it is, including you Mike ..... there are fundamental >differences in you having the power over this site w/o having a release >that has never happened before. Trust among different releases at the >mercy of site admins and their opinions, this doesn't exist anywhere >else. You figure out the reasons for the "glue". 1. Use of evolution as a development model. 2. Tolerance for new ideas and differing opinions. 3. Full control by lead developers of release/branch direction and purpose. >My point ..... all paths lead to the same destination. >Does my opinion matter? >Not really, I'm not a lead developer or a project admin. >;) As Charles admonished me earlier, I now do for you. All of our opinions/ideas matter. Whether you're a lead developer or project admin has nothing to do with the validity of your opinion/idea. BTW, this reply took me almost two hours. Your post was very thought provoking. Thanks. :-) -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000&page_id=4 _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
