New directions for the Etherboot project

Hello Everyone,

I've been thinking a lot lately about how to extend the infrastructure 
needed to serve Etherboot's diverse user and developer communities, and 
to build for the future.

It's taken some time, but I think I'm getting some clarity, so I'm 
writing to share some ideas, and to start a conversation within the 
Etherboot community, which includes developers, users, and people who 
are generally interested in network booting technology.

__Growth and Expandability__
Etherboot has grown lot, and is constantly gaining capabilities.  This 
is a good thing, but after a while a single program can attempt to do 
too much, and become difficult to maintain and use.

The inventors of Unix recognized this, and created a highly modular 
operating system with pipes for inter-process communication.

The Linux kernel was once monolithic, but soon became modular to 
support an avalanche of drivers and features that were contributed. 
Most Linux distribution are package-based, allowing a diverse user 
community to select features that they find appropriate for their 
individual situations.

The Mozilla project first created Mozilla, which included web-browsing, 
mail, html page composition, and IRC chat.  Later, using Mozilla code, 
Firefox (with a plug-in architecture) and Thunderbird were born, and 
have flourished.

In a similar way, I believe that Etherboot has grown to a point where 
it is time for us to generalize our code, and more importantly, 
ourselves.

__What Is Etherboot?__
In thinking about this, I've started from the following essential 
points:

* We are the Etherboot Project.

* We create Free network booting code, and have done so for over 10 
years.

* Our products include Etherboot (a network bootloader), mknbi (an 
image creator), and rom-o-matic (a web-based interface for making ROM 
images).

A key insight that this reveals is:

     The fact that one of our products has the same name as our project
     does not limit us to a single product!

For example, in the same way that the Mozilla project now has several 
readily-identifiable products, each with its own purpose and name, the 
Etherboot project can have more than one product, each of which does 
something useful. Further, each one can have a name that separately 
identifies it or what it does. This is a model that already exists and 
is accepted in the larger Free Software community that we occupy.

__What Does This Mean?__
As I mentioned above, the code base (product) called Etherboot has 
evolved and grown over time, such that it now incorporates many 
different capabilities. It is also, therefore, difficult to maintain. 
Its richness of features can also make Etherboot difficult for people 
new to the project to understand, configure, and deploy.

At the same time that Etherboot has been evolving and growing, PXE 
support has become a de-facto standard for commodity i386 hardware. 
With our newest release, Etherboot has a significant amount of support 
for PXE, but it is bundled with many other features. People who need 
PXE support often do not need a lot of the other features that 
Etherboot can provide (and possibly vice versa).  This is true, even if 
the PXE code within Etherboot leverages a lot of Etherboot code that 
non-PXE features also use.

I think it's time we create a new product. Let's call it gPXE.

gPXE will be a GPL'ed version of PXE.  Core objectives for gPXE will 
include a high level of interoperability with existing PXE bootloaders 
and implementations, and reasonable compliance with the PXE 
specification.

gPXE will be a product of the Etherboot project, and generated from the 
same code base (tree) as Etherboot, but will use a different 
configuration file, and possibly a different binary directory from 
Etherboot, to make it easier to configure and collect binary output.

__Why should we do this?__

Reason 1 -- We appeal to a wider audience

Let's face the fact that PXE compliance is something that most people 
have come to expect from a network bootloader, and beyond that, they 
require interoperability with existing PXE infrastructure.  They also 
reasonably expect that if something works with their Intel or 3COM PXE 
cards, it will work with gPXE.

SAMBA comes to mind as an example of interoperability that benefits 
lots of people.  I'd like to see gPXE offer a similar high level of 
compatibility.

Reason 2 -- We avoid confusion and create a new product identity

Etherboot has a wide reputation for being "not PXE".  This has 
dramatically changed recently -- we are now working diligently to be 
compliant with the PXE specification, and to be interoperable with 
other PXE infrastructure and workflows.

But, because there's so much existing information about Etherboot that 
says we don't do PXE, we need to create a name that counters the 
perception that we are only grudgingly implementing PXE support. 
Without that, people wanting a Free PXE implementation might not 
discover that Etherboot supports PXE, or might assume that Etherboot 
PXE support is "chancy".

Naming one of our products gPXE will help do that, and will make it 
unequivocally clear that we are creating a Free PXE compliant network 
bootloader.

Reason 3 -- We preserve our existing code base

Etherboot can continue to exist as our "Mozilla". There are people who 
wish to use it, and there are people willing to maintain it, if it is 
reasonably easy to do so. Improvement to a unified code base will 
benefit both products, if we take some care.

This will allow us to keep legacy Etherboot features functional even as 
we focus on new development.

Reason 4 -- We have a lot of the code we need

We already have a lot of the code necessary to do gPXE.  We are making 
the necessary changes to the build system to support more generalized 
builds from the code base.  There don't currently appear to be any 
insurmountable technical obstacles to making this work.

Reason 5 -- We build and expand our community

By welcoming in people who need a PXE compliant network bootloader, we 
expand our user and developer communities, and increase interest in and 
respect for Free Software.

Reason 6 -- It's an interesting technical challenge

I have confidence that we can do this, but it is by no means an easy 
task.  As developers we will need to learn new tools and techniques to 
make this work.  We may face some tough technical challenges, but I 
believe we can overcome them.  We will need testers and people willing 
to write documentation of new procedures. It will be fun to figure this 
all out, and to create something Free and useful.

================

So there it is, the beginnings of a plan to generalize the Etherboot 
Project to produce another product, gPXE, from our existing code base.  
A way to preserve the old, while working on the new.  A way to expand 
our user and developer communities by creating a product that appeals 
to a wider audience, and using a name that is unambiguous about what we 
are trying to accomplish. At the same time Etherboot -- both the 
project and the existing product -- lives on with equal vigor.

I think we can do this, and more importantly, I think we _should_ do 
this.

What do you think?

Marty

-- 
     Try: http://rom-o-matic.net/ to make Etherboot images instantly.

    Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
          Cambridge, MA 02139; USA
   Voice: (617) 491-6935; Fax: (617) 491-7046
   Email: [email protected]
     Web: http://www.etherboot.org/



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20