From: Jeff Miller <email@example.com>
On Mon, Feb 07, 2000 at 02:18:58PM -0800, Eric Armstrong wrote:
> > Maybe he was. Maybe he's an RMS who never found his ESR.
> Now you got me. What's an RMS? What's an ESR?
I don't know wether your serious or joking. so...
Richard Stallings (www.gnu.org) and
Eric S Raymond (http://www.tuxedo.org/~esr/)
> Definitely a strong proposition. However, their revenue-proposition
> lacks a little. I think there must be a way to combine "open source"
> with a "profit proposition", but I'm not sure what it is just yet.
If you find it tell me. I trying to find it also.
> 2) But when it comes to arriving at a consensual understanding of
> a problem you aren't sure how to tackle, I think the kind of
> system we are talking about will prove to be worth it's weight
> in gold.
> Example: There are many parts of the application that I am
> really unfamiliar with: mail protocols, for example. We have
> dozens of people with expertise in different areas, and we need
> to hammer out a design that works. That kind of collaborative
> design should be enhanced with this kind of system.
Agreed we seem to have the expertise mix needed. What we don't have is the
seed to start this project growing.
> When no code exists, there is nothing that "brings it all together"
> for developers. An email/document that allows for *reduction* into
> new document versions would allow developers to a) explore the
> design space, b) record design decisions, c) save alternatives, and
> d) create a uniform "design picture" out of rambling discussions.
> To date, open source efforts have been limited to extending and bug
> fixing. This system could make it possible to initiate an open
> source design in an open source way.
part of our objective should be self documentation, but we also need a
test set and a series of tests that we need our system to pass.
> When a large body of code is released all at once (like Netscape's
> mozilla), the opposite problem exists -- no one can "wrap their
> head around it". You look at code and ask "Why is that there?" and
> there is no one around to answer the question. Linked explanations
> provide the possibility of answering "why", which means makes the
> code that much more accessible to new people. (Interestingly, open
> source code has much *more* documentation than is typical for the
> industry as a whole. This system provides better mechanisms for
> capturing the information.)
Could someone provide a sketch on the modules/units we'd need and how they
inter-relate? Then we could start to divide those units down further and
start implementing units one at a time. These could function as a set of
seeds. Instead of producing one large project may be we should design a
set of projects that are interlinked, yet can be developed (almost?) stand
alone in the traditional open source style. Then a "bake-off" or
inter-operbility test could be carried out.
So what so we need?
* a protocol (based on xml?)
* a storage format ( a database?, a number of files?)
* a user interface (web browser with intermediary at start?)
* a means to enter new material
* a means to retrieve old material
* a means to find the material that we're interested in
Any suggestions for a small test set? I know someone suggested the linux
documentation, but I think we need something simpler and smaller to begin
with. How about two small books that are part of a series? The idea is to
have something that has interconnections, is rich in data, yet small
enough so that everyone involved can remember most of it and consentrate
on how the system behaves and not on what part of the document someone is
talking about when discussing a problem.
--------------------------- ONElist Sponsor ----------------------------
Shop for your Valentine at eGroups.
<a href=" http://clickme.onelist.com/ad/SparksValentine6 ">Click Here</a>
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT