From: jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr})
Newsgroups: comp.programming
Subject: Re: collective program design
Date: 18 Dec 92 21:49:39 GMT
Organization: Ultra Network Technologies

As always, this is one man's opinion, based on my experiences.


>> Frank Kaiser <fkaiser@Physik.TU-Muenchen.DE>


>>The best public domain programs known were created by many programmers
>>working together. Everyone of these did a little share of work. 
>>But the begin and development of such a workgroup was a result of randomness. 

	Hmm, most of the freely-redistributable and public-domain programs
I've seen began with a few people solving a problem.  Others laid additional
code atop it, tweaked designs, and expanded the operating model along the
same lines as the original operating model.  "Random" is very much the wrong 
word to use here;  I think "informal" better captures the flavor.

	("Random" implies that there is no intelligence or purpose behind
an action;  "informal" implies that it wasn't necessarily done so that it
could be done again.)


>>One could think of rules for finding the need for a new program, for 
>>example a newsgroup with suggestions for new programs, together with 
>>a sort of democratic decision to start a new project. 
>>For the development of such a project, one could thing of a bbs, where
>>everyone willing to take a part of the burden can find a task to solve.

	We already have these. :-)  Someone complains about something,
and he or someone else figures out a quick way to solve the problem.  Word
(and software) leaks out, and pretty soon others are playing with it,
making it more portable, more robust, and more usable.  Some of those changes
make it back to the original author, and POOF the ball is rolling.


>>This procedure should have to be higly formalized in a top-down-manner.
>>I don't believe this is a new idea. Please comment it.

	Not sure what you mean by "top-down" in this context.  And no, it's
not a new idea at all:  it's ad-hoc group software development.  However, you
need motivated people to work on these projects, and continuity in the form
of documentation and (often) regular social contact.




>  Michael  Ayers <mayers@yak.syr.EDU>

>	The democratic process thing sounds like the weakest link - "Okay,
> we've all agreed on what to do, now who's going to do it?" [silence]

	Wrong question, Michael.  "Okay, we've all agreed on what to do, now
who's most interested in making sure the design stays intact?  Who's keeping
track of what's happening?  And what do each of you want to start with?"

	A usual title for the person answering the first question is
"principal architect" or "principal designer":  he is the final word on
this group as a whole believes should be the content of the software.
He also is the one to divide up the work, with the help of everyone else.

	A usual title for the second person is "project manager":  he is
the final word on getting the resources and organization necessary for the
project to progress.  He also is the one to track that the work continues,
and takes care of the process.

	Depending on the group, the principal architect or the technical
manager makes any assignments.  With smaller, ad-hoc groups where everyone
works as peers and could do any task nearly as well as anyone else, the tasks
go to those most interested in doing them.



>	I do agree that a newsgroup or mailing list for thinktanking
> prospective projects would be a good idea, I just think that a relatively
> anarchic framework is mandatory - project control must remain entirely
> within the group which does the work.

	And someone within the group needs to handle the process, at least to
the extent that everyone can build with everyone else's pieces.



>	I can see myself working on my own baby, and then giving it away. I
> can picture myself working on someone else's project, so long as they were
> nice to me, so they could give it away.  Working for a committee?  Sorry,
> I just can't picture myself doing that for free.

	Ah, but working for (and with) a peer group is something else entirely.
I infer that "committee" means a group which emphasizes process over content.
Other climates for working within a group exist.  I for one think that this
would be a neat and logical extension of GNU and other freely-redistributable
work.


		Joseph Beckenbach
		toolsmith and releaser
-- 
----
Joseph Beckenbach	jerbil@ultra.com	408-922-0600 x246
	(speaking from, but not for, Ultra Network Technologies)
Newsgroups: comp.programming