A program? and Project 'Government'

[Matthew Tuck]

Otieno Ododa wrote:

> I think we're going to find that the most common language among us is
> C or C++, so that's probably what we should write the original
> implementation in. As far as a development environment, I think the
> nature of the code we'll be writing will make it able compile on just
> about any compiler. I have Borland C++ 4.52, a Linux box (currently
> dead, but revivable) with some version of gcc, and djgpp. I know C++
> and some basic x86 assembly

OK, well the C++ meets the criteria of being freely available to
everyone, object-oriented and known.  For a prototype these are the main
criteria I think we should follow.  I believe our compiler should be
able to be fairly OS-independent at first so cross platform issues
should be restricted to integer sizes and such.

I have Borland C++ 3.1 I think, so I guess I'll mosey on over and get
GNU C++.  Is the STL standard yet?  If so we should support it, since
GNU C++ should be freely available to all of us.  I assume it won't be
too hard to learn.

> An 'oversight' group, which delegates tasks based on the project's
> general aims and goals. This group would have to serve as the specs
> group, and would have a closed membership, where its members would
> select new members, if required. This group would not really do any
> coding, but instead coordinate the efforts of the other groups, as
> well as have the tasks of deciding what goes in 'official' releases,
> laying out the specs (which is what we're all doing, right now, I
> guess) of the project, and determining what new features to support.
> Of course, you could be a member of this group and of other groups at
> the same time.

A famous open source paper suggests that the only model of open source
that usually succeeds is that of a 'benevolent dictator' who controls
the standard distribution and delegates to subsystem owners when
necessary.  Linux is done this way, but Apache and Perl are notable
exceptions, Apache using a group and Perl using a rotating dictator. 
It's similar to the oversight group but there's also a leader of the
oversight group.

I'll put some more links up on the web page shortly.

> Several groups or committees which handle sub tasks, such as a tools
> and utilities group, a compiler group, etc. These groups would have to
> be subdivided, because the scopes of their tasks are very large.
> However, I think that the need for intercommunication between these
> potentially separate groups is such that they need to be combined,
> whereas the intercommunication needed between, say, the
> tools/utilities group and the compiler group can be handled by the
> oversight group.

There can sometimes be problems with design by committee where you end
up supporting everyone's features.  I don't see a problem with this in
libraries given adequate feature integration and orthogonality, but it's
a real problem in the language proper.  Part of the appeal of the
dictator is "the final word".  I do remember being told by someone that
has taught me a lot "democracy doesn't work in software".  To a large
degree, unfortunately, I think it's true.
 
> As far as voting on issues goes, after adequate discussion of issues,
> I think any contributing member of the project should have a vote in
> any issue touching on a task their group would be doing ...
> Contributing right now means ideas, and later would mean code. I know
> that definition will be pretty vague, later, if someone contributes
> code and doesn't do anything else ever again, or something similar, so 
> that would need to be clarified.

Given that you can make your own version of the software, if we have an
oversight group or person, then poll might be the better word for it. 
And voting with code is a powerful idea too.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/