mission statement/goals
Al Guerra has written up a pretty nice set of goals (sort of like our
mission statement but more detailed) - in terms of stuff like how much
of a priority it is for us to be compatible with Unix and so on.
Here's an HTMLized version (edited hardly at all), any reactions to
putting it up on the web in this form (especially in terms of the
content)? (mechanics question for Dan Quinlan and/or Stuart Anderson:
if there are no objections, can I just check it into sourceforge - or
is there another step?).
Index: index.html
===================================================================
RCS file: /cvsroot/lsb/website/index.html,v
retrieving revision 1.2
diff -u -r1.2 index.html
--- index.html 2000/01/07 18:35:34 1.2
+++ index.html 2000/01/19 19:37:21
@@ -33,6 +33,7 @@
software applications to run on any compliant Linux system. In
addition, the LSB will help coordinate efforts to recruit software
vendors to port and write products for Linux.
+<a href="mission.html" >Details</a>.
<P>
<br>
Index: mission.html
===================================================================
RCS file: mission.html
diff -N mission.html
--- /dev/null Tue May 5 13:32:27 1998
+++ mission.html Wed Jan 19 11:37:21 2000
@@ -0,0 +1,127 @@
+<HTML>
+<HEAD>
+<TITLE>LSB Mission</TITLE>
+</HEAD>
+
+<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EF"
+ VLINK="#51188E" ALINK="#FF0000">
+
+<H1>LSB Mission</H1>
+
+<p>Here are a set of goals which are more specific than our overall
+mission statement on the home page:
+
+<p>1. Select the components/features/API of a model Linux system so
+application developers know what the target system will include, what
+the behavior will be, and how to package it so that it can be installed,
+executed, and removed from the system.
+
+<p>Rationale: A single Linux model allows an ISV to know in advance how a
+conforming linux system will behave to (a) minimize issues in porting
+code from another platform, and (b) allow a package to perform the same
+way regardless of the linux distribution.
+
+<p>Test Criteria: Are proposed components/features/API being selected? Are
+proposed components/features/API being rejected?
+
+<p>2. Develop the documentation for the components/features/API of the LSB
+as well as their respective behaviors.
+
+<p>Rationale: The LSB spec must be presented to distribution implementors
+and ISVs in a format other than source code.
+
+<p>Test Criteria: Is each component/feature/API documented clearly,
+completely and accurately?
+
+<p>3. Advance the state of the art in Linux by incorporating desired
+components/features/APIs into the LSB spec.
+
+<p>Rationale: The world is a moving target, and we have competitors outside
+the Linux arena. To provide a compelling reason for the adoption of
+Linux we should take advantage of new ideas and technologies as well as
+target new markets and industries.
+
+<p>Test Criteria: Is there a component/feature/API which would provide a
+clear improvement over the existing Linux environment?
+
+<p>4. Advance the development of applicatons for Linux by providing
+improved compatability with existing standards or platforms.
+
+<p>Rationale: By providing ISVs with an execution environment which is
+compatible with an existing standard or platform we garner a greater
+number of applications or software solutions, providing users with
+greater incentive to adopt Linux and abandon their current platform.
+
+<p>Test Criteria: Are there existing standards or platforms and does the
+model Linux system match their behavior?
+
+<p>Given these goals, and please add/modify goals as needed, I'd like to
+suggest the following draft for the selection criteria for determining
+what should be included into the LSB spec, in decreasing order of importance:
+
+<p>1. Whatever currently exists in the Linux world in source code form and
+is redistributable via a GPL-like or BSD-like license.
+
+<p>2. Whatever is currently being actively developed in the Linux world
+which will conform to another existing standard and be available in
+source code form within six to twelve months after the finalization of
+the LSB spec and is redistributable via a GPL-like or BSD-like license.
+
+<p>3. Whatever is currently being actively developed in the Linux world
+which will advance the state of the art and be available in source code
+form within six to twelve months after the finalization of the LSB spec
+and is redistributable via a GPL-like or BSD-like license.
+
+<p>My reasonings for the selection criteria and my views on the goals are
+as follows:
+
+<p>1. We need to develop a single model Linux system. One that can be
+adopted by the various distributions with little difficulty. This is the
+single greatest goal that we must achieve. Anything which interferes
+with this goal should automatically be eliminated.
+
+<p>2. We have to work with what we have. While we may have the skills
+necessary to develop the code to fulfill whatever wish list and
+whiz-bang feature we might desire, we most certainly will not have the
+extra time needed to do it in a timely manner after finalizing the spec.
+Therefore we should restrict the list of components/features/APIs
+considered for inclusion in the LSB spec to whatever we currently have.
+
+<p>3. We are not required to conform to any standard except our own. This
+includes the POSIX stuff. Yes, it would be nice to meet any or all other
+standards, but it isn't possible for LSB 1.0 to meet it at this time and
+there's no sense in pretending that it will. ISVs are more concerned
+with having multiple Linux distributions and the lack of a well-defined
+standard than in the existence of yet-another *NIX-like platform for
+which to target. We are not the standards body for POSIX. There is
+already a group for that. We are the __Linux__ Standards Base
+Organization. We are not a rubber-stamp for anyone else. If we meet
+POSIX, terrific. If not, let's just accept it for now. Hopefully the
+maintainers of the appropriate Linux portion will target POSIX in the future.
+
+<p>4. There's a lot of cool stuff that can be done to Linux. Let's leave it
+to be done. Let's not dictate that now. We can't tell how Linux will
+evolve over the next five years. Our job is to make a single Linux model
+for ISVs to target NOW, not worry about how the new jaw-enabled joystick
+will be supported. People came up with several really cool and excellent
+ideas at the NY meeting that got shot down by the group for a very good
+reason: THERE'S NO IMPLEMENTATION! No one else can see for themselves
+how it would work out! If someone believes in their idea, they'll
+implement it and let it face the scrutiny of the rest of the community.
+The bazaar development model allows several similar projects to develop
+simultaneously, competing for resources, ideas, attention, etc. based on
+their merits. Some make it. Some don't. Let some dreamer show us the
+possibilities. When he does we can either say, "Cool! We want that to be
+standard.", or "Yawn...Next!"
+
+<p>5. We need to eliminate from the spec prospects those items that are
+inferior to those of a like nature, or group their functions into a
+minimum requirements spec for its package. For example, there are
+multiple formats for distributing packages, multiple X window managers,
+multiple shells, etc. While it isn't always beneficial to lock users
+into a single system (eg, KDE vs. GNOME, or bash vs. csh), we should
+specify the minimum requirements and capabilities of such a system so
+that the interfaces and behavior are well-defined.
+
+</BODY>
+</HTML>
Reply to: