At 2002-02-28 10:51 -0600, guitarlynn wrote:
>On Thursday 28 February 2002 08:29, Mike Noyes wrote:
> > 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.

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" 

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.


>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.


> 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.


>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.

>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. :-)


Leaf-devel mailing list

Reply via email to