At 11:13 AM -0700 on 8/3/99, Alain Farmer wrote:
>>Alain: There are many ways to arrive at a consensus,
>>particularly if everyone participating in the
>>consensus-building process are reasonable and are thus
>>prepared to make some compromises in order to achieve
>>the goals of the group.
>
>Anthony: If I am right and you believe the opposite of what I believe,
>why should I compromise with you? Or if you are right and I believe the
>opposite of you, why should you compromise?
>
>Alain: You are correct that compromise is impossible when the parties
>involved have diametrically opposed views, particularly if what is at
>issue is value-ladden. Forking is the only reasonable alternative at
>this point but, in so doing, each separate fork will end up doing the
>similar work (redundant)
Not necissarily. Nothing makes it so that forks can not share code. If
someone patches a bug in the offical OpenCard which exists in the forked
OpenCard, the fork's maintainer would probably apply the same patch. And
vice versa.
>instead of collaborating. So, to avoid this
>loss of potential due to redundancy, it is advisable to somehow come to
>a workable consensus instead of forking.
True. But eventually, enough compromise = everyone's unhappy.
>
>Anthony: Of course, there are things where there is no "right" and no
>"wrong." Those can be compromised on. There are some things that are
>not important, and can be compromised on (the color of an icon, for
>example).
>
>Alain: All the tactical stuff - the programming, the interface, and so
>on - can be compromised on easily enough. We will eventually come to a
>workable consensus on the licencing issue as well. As for the Politics,
>we happily do not have to agree on these issues.
Yes, we will have to agree on licencing. And, IMO, we should just make it
liberal enough that everyone except the groups which would rather nuke the
Earth than let M$ make a cent off of it can agree.
>
>Anthony: But when two groups of people, with radically different,
>mutually exclusive ideas or approaches, with neither being able to
>convince the other, exist, no compromise should be attempted: It'll
>wind up as making both sides unhappy. I'd argue it is time for a fork.
>
>Alain: You are right. I am forking left.
LOL.
>take our clash between
>altruism vs. egoism: Will we ever reach a consensus, other than that we
>do not agree?
>
>Alain: Nope!
I think maybe our grandchildren will one day... When Atlas Shruggs :)
But I'd much prefer a fork in that case too: We can leave each other alone.
Neat political idea. Let us egoists have our state, and the altrusists
another. Open boarders between the two. I bet one will decay into perpetual
poverty and the other ascend to new hights... we'll be back on OCPD arguing
which is which, though, soon ;-)
>
>>Alain:Consensus has nothing to do with the use of
>>force.Force is used when some party has more power than
>>another, and wishes to exercise its power instead of
>>negotiating with the weaker party. Consensus, on the
>>other hand, is about negotiation among equals such that
>>everyone say is taken into account in the final
>>decision. Consensus is not equivalent to Unanimity, as
>>many falsely believe.
>
>Anthony: In other words, consensus, by your definition, is the ultimate
>compromise?
>
>Alain: ...People make these
>compromises, willingly, because they know that they will gain more by
>participating (collaborating) than going it alone (forking).
Alain! That's not very altruistic of you. Maybe I've rubbed off a little on
you? (Of course, your perfect rebuttal would be that one must know the
audience one is talking to.)
OK. That sounds fine. So long as any person or group of people is at
liberty at any time, for any reason, to fork. And so long as we make that
clear.
>
>Anthony: I want no part.
>
>Alain: So I gather that you are arguing for voting, and forking when
>there is dissent.
I'm arguing that we should have an official version with official policies
and an official maintainer, and if anyone dissents from the majority to an
extent that it justifies to him a fork, he should fork.
>
>Anthony: Can you have a consensus with dissent?
>
>Alain: Yes, of course.
I'm going to have to find my dictionary.... I was not aware of that. I was
under the impression consensus meant everyone consented, i.e., no dissent.
>
>>Alain: So you make all of the decisions concerning your
>>interpreter, Uli makes all of the decisions concerning
>>OC file system, I make all of the decisions concerning
>>the collaboration infrastructure, etc !!!
>
>Anthony: Yes.
>
>Alain: Alright! So I get to make all of the decisions as to how we will
>work together, how our shared information and resources will be
>organized and presented, what licence gets adopted, etc... because all
>of these are Collaboration issues.
Correct. And if anyone does not like it, we could by a majority vote say
bye-bye to Alain's leadership. Or if less than that disagreed, they could
fork (or if it were minor, ignore it).
>
>>Alain: Who makes the decisions for the aspects that
>>affect the whole group?
>
>Anthony: Someone who should be given the ownership of that aspect.
>
>Alain: Ownership of the aspects that affect the whole group???
The maintainer should have de-facto legal ownership of the derived work
known as OpenCard. (BTW: Whatever we name OpenCard when we have a name for
it, it should be a trademark to protect the name)
Actual legal ownership would I guess belong to some person who signs an
exclusive licence of that work to the maintainer who is to be decided under
the rules which are put forth in the organizational proposal. It would seem
that forming a legal organization to produce OpenCard would work well here.
Or maybe one of the existing OpenSource companies would do that for us. Or
an individual could, but it'd probably be messier.
>
>>Alain: Who makes the decisions for elements of OC that
>>will be accomplished by many people at once?
>
>Anthony: Someone.
>
>Alain: You are dodging the question, Anthony.
That would be up to the group that works on it. If it is something major, I
immagine they'd probably just copy our organization and appoint a
maintainer.
In any case, so long as the work is distributed under LICENCE, it
(possibly) becomes part of OpenCard, and what is in OpenCard is decided by
MAINTAINER.
>
>>Alain: How much does one have to contribute to a
>>particular product of OC to be able to make decisions
>>concerning it?
>
>Anthony: The person who starts the product -- and no doubt does most of
>the work getting it delivered, at least in the first version.
>
I should probably just state that this is really outside of the scope of
OpenCard's organization, but:
>Alain: What about products that many start together?
Should be decided by the people who start the project, as we are doing now.
>What about all of
>the latter versions and contributors?
Would be spelled out in the decision above, hopefully. But I'd suggest that
for projects of a large scale, they do something like my proposal and for a
smaller scale, they just say one person is in charge. In both cases, allow
forking.
>Do they have or acquire some form
>of decision-making rights? How? When?
Yes, the fork, and whenever they want, respectivly.
>How would you deal with someone
>that starts MANY products without ever following through? Despite the
>fact that this person contributed, say, the first half-day�s work to a
>product, this person would then and forever after make all decisions
>concerning the product???
No anyone who wants can fork.
And remember, that anything added to OpenCard is under the control of
MAINTAINER. He can patch it however he feels prudent. I'd say that OpenCard
is virtually a fork off of all the products it includes. I'd of course
submit new versions of Interpreter to this list -- but ultimately, it will
be up to MAINTAINER to include them or reject them.
>
>>Alain: Does everyone create their own individual
>>product(s)?
>
>Anthony: Yes. But since they are under a licence allowing it, they can
>easily be integrated into OpenCard -- which would be controlled by one
>person.
>
>Alain: So OpenCard will be more like an empty shell, with hooks that
>will allow autonomously developed modules to operate seamlessly with
>the OC shell and with other modules. None of the parts in the shell,
>nor in the autonomous modules, are developed by more than one
>individual, and consequently one unambiguous author for each part. Who
>knows!
Not quite, but, let's give an example. Say we have Interpreter, XBF, a
stack engine, and a GUI frontend, and some other stuff.
User launches OpenCard. Init code gains control. Calls various init
routines. Calls GUI code to put up GUI & tell it how to handle events.
Init code then calls the stack engine to load the home stack & to tell it
how to handle GUI & scripts. Stack engine calls XBF to open the stack file.
Stack engine calls XBF to read stack info. Stack engine calls GUI code to
create stack window. Stack engine calls XBF to read first to be executed
script. Stack engine inits Intepreter, telling it how to "go to card x" and
other such things. Stack engine calls Interpreter telling it to execute the
handler startup. Interpreter finds no start up handler in the card script,
and calls stack engine to get the next script. Interpreter still finds no
startup, so it asks stack engine for the stack script. It finds it, and
executes it.
The script does some stuff, and causes Interpreter to make some calls back
to the stack engine and to change cards and userlevel. Also calls stack
engine to tell it to update some fields, which in turn calls the GUI code
to draw the changes and the XBF code to write them to disk.
Interpreter returns, and stack engine goes on sending openCard,
openBackground, and openStack messages. The last one, however, contains a
scripting error, so when Intepreter sees it, it calls the stack engine to
tell it that an error occured. The stack engine calls the GUI code which
puts up a dialog and due to the user's responce, invokes the script editor.
The script editor then calls the stack engine to get the script. It returns
to the stack engine, which then returns to Interpreter, which then returns
to the stack engine.
The user then edits the script, and the script editor eventually calls the
stack engine to save the script, and the GUI code to close the window.
The user then quits. The GUI code calls the proper event handler, which
then calls the stack engine, which sends closeCard, closeBackground,
closeStack, and quit. It calls XBF to close the file... etc.
The layout looks something like the attached PICT file. (Sorry about the
attachment -- it's small)
>Anthony: That person who is in charge of OpenCard.
>
>Alain: The elected person that we wrote about above, right?
Correct. Please see the proposal draft.
>Anthony: I'm arguing for a structure in which litigation would
>hopefully be unnecessary.
>
>Alain: We agree on the goal of reducing or eliminating litigation,
>that�s clear enough. Do we also agree that we should structure our
>collaboration carefully in order to achieve this mutual goal of ours?
I think that's answered, at least on my part, in the quoted paragraph right
above yours.
>Anthony: ...trying to do a piecemail work in multiple emails is silly.
>
>Alain: What is silly about multiple emails? Your complete proposal
>will be analyzed, debated, etc ... in a similar piecemeal fashion. A
>web-based review process would be nice though. I am working on it.
What's silly about it is there is no one place people can look and say
"This is Anthony DeRobertis's proposal." And since there is no one place to
look and say "this is it", it is near impossible to debate it.
If there is one, official version of something, I can say "on line 17, you
said.... I believe that will lead to.... I think that "..." will be
better." You can't do that when we've just been discussing things with
email. Sure, you can go look through the couple of megabytes of email
archives -- hundreds of messages -- and say "Well, on so and so you
said..." but then you may miss a different post on the subject. It's also
easier to mistakenly take something out of context.
Also, anyone who comes later will need it. We now have a four-page mail
archive, which no doubt contains over 1,000 messages. It'd be silly to ask
them to read all of that.
%code_design.pict
code_design.pict
