SEUL: Help, the Cathedral, and the Bazaar

[Erik Walthinsen <omega@omegacs.net>]

> One acronym: HTML.  Develop a web browser, and allow it to use a
> help:// protocol or something like that. Make a browsable help index
> and include some cgi (or java) to allow searching of the 
> help database.  I don't know.  I hope that these are
> good ideas.
I'm not sure I'd want a help browser to have to use network sockets to read 
help files.  It introduces too many possible problems, i.e. what happens if 
you misconfigure your web server?  How are you going to read the help files 
telling you how to fix it?

I'd prefer to put all the help files on disk and have the help browser load 
them directly.  If we want to support remote help, fine, but it shouldn't 
be the primary method.  (remote help might be cool in a NC-ish office 
environment where you can't or won't NFS export all the help files, or you 
have some random server in Timbuktu that has bandwidth for HTTP, not NFS)

> Take a look at how KDE has structured its help system.
That's something someone needs to do for -dev-help.  Exhaustively review 
all existing help systems, in a format similar to Donovan's editor review 
page.  GNOME's upcoming help system, which I'd like to merge with xhelp if 
possible (bazaar dictates a throwaway version..), is based on a much faster 
and more robust HTML display widget, native Gtk code, which if made 
pluggable, along with access method .so's (disk, HTTP, etc.) might make a 
very cool system.

> Why not decide on a universal interface standard, which programmers
> should use to develop software for seul?  Then, make software which
> follows these standards available from the seul website, and put
> a seul "seal of approval" on them or something?
That's kindof the idea.  Commercial apps are the primary target, where we 
would provide the libraries, exhaustive documentation, and general 
interface specifications to make sure their app fits in with everything 
else, and can interoperate.

Again, this is where GNOME comes in.  They've already got things almost to 
that point.  They simply need some larger apps, plus commercial support.  
This is where SEUL comes in, getting office apps and commercial vendors to 
work within the GNOME framework, as well as helping it to mature into a 
full network-object system (as its name implies).

> Since software is GPL'ed, you could have developers who work
> to make sure that applications conform to these standards.
Yup.  That's what maintainers are for.  Debian uses this method, with a 
maintainer for each package.  Most maintainers are in contact with the 
'upstream' developer (i.e. the author of the package), but I have a feeling 
that link isn't utilized to the fullest.  There are still patches galore to 
put Debian together.  I'd like to see those patches generalized, and make 
thier way into the *primary* distribution.

The other shortcoming of the Debian mechanism is that packages are not 
stored in a central location at all times.  Only the resulting packages 
make their way to the site, usually, which means that if someone disappears 
after changes have been made, but before they make it to the site, they get 
lost.  SEUL will have a CVS repository containing the *entire* 
distribution, and packages will be built automatically, repeatably, by the 
system.  That gives us more stability, better maintainability, oh, and 
version control... ;-)

> Some standard libs for developers wold be a nice idea too.
That's the idea behind the Core/Layers concept.  A specification document 
defines what the Core and various Layers provide (not how), and a reference 
implementation is constructed to provide for the basis of SEUL.  My goal is 
to eventually standardize the Core/Layers such that commercial developers 
can code against the standard and *know* that their app will install and 
run on any compliant system.  Eventually, other distributions would almost 
be forced to be compliant.  However, I don't want that to happen, as I 
would like other distributions to be involved in the process of writing the 
Core/Layers spec.

> I do't thin that it's possible to maintain a complete bazaar-like
> atmosphere, and have universal standards.  Not unless you own
> every shop in the bazaar.
Right.  Though universal standards aren't the goal, necessarily.  
Competition is good, and I have little doubt that some distributions may 
prefer to go their own way (I won't mention any, you can probably guess).  

I do want to make the point that 100% bazaar development isn't going to cut 
it for SEUL.  There will have to be some structure, else nothing that needs 
to get done, will.  At the core of bazaar-style development is the belief 
that everyone is coding to scratch their own personal itch, be it 
technological or philosophical.  While this is still the case for SEUL, 
either one way or the other depending on the individual coder, there are 
just some things that can't be done by general "yeah, I want to do this" 
concensus.  Standardization (i.e. a consistent interface) is one of those.

We (luka and I) will be continually reviewing our processes, with the goal 
of making things work as smoothly as possible.  Common sense dictates that 
this will be very close to bazaar-style development.  I won't tell you that 
it'll be 100%, but as close as practical in order to acheive our goal.

TTYAL,
     Omega


     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user