Community and Artifact Define One Another (Was: SqF purpose: supporting the Squeak community?)
That is, we are both looking inwards to discussing purposes and projects to support "Squeak the artifact" as opposed to looking outwards to purposes and projects to support "Squeak the community". The two are naturally related, but the choice of perspective might have a profound influence on how we all think about the Squeak Foundation, as well as how the Squeak Foundation carries out its operations and sets its priorities.
I would most certianly agree. I think it is always better, perhaps infinitely better, to support the community rather than "just" the artifact that the community formed around. The latter will come from the former.
Excuse me, gentlemen, this is mere sophistry. A seasoned advocate can trivially make the contrary argument with equally compelling rhetorical force. But I'll spare you the demonstration, because to do so would be mere demagoguery -- indeed, mere pabulum.
The question is not "whether the artifact drives the community or the community drives the artifact?" Even to attempt an answer (using an exclusive or) is losing, for this is a fundamental principle of open source communities and, to use your terms, their "artifacts:"
COMMUNITY AND ARTIFACT DEFINE ONE ANOTHER.
Put another way, the community and artifact are not only "naturally related," but are inherently intertwined. At least for a viable community.
In an open source world, the artifact joins and defines the community. Just as surely, the community defines the artifact. This is because of what we are -- of what is an open source community: a community comprising those who are concerned with a program they program. It is because the word "program" is both NOUN and VERB.
Projects and communities that enjoyed these synergies prospered. Those projects and communities who have not became irrelevant. It is as grievous an error to rationalize a dangerously conservative posture regarding the artifact on the theory that the artifact --as is-- defines the community as it is to rationalize an unconcionably unnecessary fork on the theory that the artifact is irrelevant if it is not changed to serve some special interest identified for particular purposes as "the community."
If we try to define the community with words approximating a functional specification at any level, we have already lost. As such, it leads to hopeless and divisive advocacy -- and eats at the core of a community. I am not saying you are right or wrong. I am saying that THIS argument is pointless, possibly harmful, and disserves community and artifact equally.
Let us define our community by our dynamic and limitless good works. It is time to write much less political prose and write much more code and documentation. All of us. Let our works (meaning both the efforts and the products), not our words, define us.
Andrew-
Karl Popper said science advances by unjustified, exaggerated guesses followed by unstinting criticism. http://www.eeng.dcu.ie/~tkpw/ So thank you for your comments. :-)
"Andrew C. Greenberg" wrote:
Excuse me, gentlemen, this is mere sophistry. A seasoned advocate can trivially make the contrary argument with equally compelling rhetorical force. But I'll spare you the demonstration, because to do so would be mere demagoguery -- indeed, mere pabulum.
Well, I'd like to see it. I don't think it would be as easy to construct or as convincing as you suppose. I'm not saying you couldn't present something coherent -- any lawyer should be able to defend a guilty client to the best of their ability. But winning the case is another story.
Still, the reason I don't think the contrary argument would be convincing is that the artifacts cannot stand alone. Without a community to talk about them, understand them, maintain them, and ultimately use them, they are useless. One rests upon the other. They are not equal participants in the relationship. Quite often one has communities before artifacts, as was the case with SqC before they made Squeak. They shared a "vision" and a "purpose". There is something deeply human here about the way people interact around a common purpose, irrespective of the objects they use at the moment to do so.
The question is not "whether the artifact drives the community or the community drives the artifact?" Even to attempt an answer (using an exclusive or) is losing, for this is a fundamental principle of open source communities and, to use your terms, their "artifacts:"
COMMUNITY AND ARTIFACT DEFINE ONE ANOTHER.Put another way, the community and artifact are not only "naturally related," but are inherently intertwined. At least for a viable community.
The flaw in this is that it is more true that:
COMMUNITY AND PURPOSE DEFINE ONE ANOTHER.
You are right that the community and specific artifacts are intertwined at any one point. Doug Engelbart talks about the need for the Human System and the Tool System (and the Knowledge System) to "coevolve". http://www.ddj.com/articles/2000/0009/0009a/0009a.htm http://www.bootstrap.org/institute/bibliography.html
However, an artifact can drive nothing (unless it is perhaps sentient or in some way designed to do that). It is always the community that makes the choices, perhaps for reasons they do not understand or even like (such as if they are locked in an arms race), but ideally to strive towards some shared purpose, ranging from survival to transcendence.
Community and artifact are not equal. The community can subsume the artifact, but the artifact can not subsume the community (at least, not yet). If we were to "burn the disk packs" today, within a few months we would have a Squeak again -- and probably a better one. It quite possibly woudl be one that looked and functioned nothing like the current one, but still captured some essence of it. It surely would be one with a more standard license and a clearer title to all contributions. This is because Alan Kay and by extension the Squeak community have a shared purpose -- a hard to define one, granted, but some sort of shared vision about how computers should be with roots back in the Dynabook project which in turn borrowed from Engelbart's NLS system. (See "The Early History of Smalltalk" section 11.2.1 in _History of Programming Languages_ by Bergin and Gibson). I might add that this is a vision many other development communities (e.g C++, Java) lack.
For an example of the difference between the two, consider this. After W.W.II, Europe could rebuild with Marshall plan aid because most of the skilled people were still there, used to a notion of formal order, with just the physical infrastructure destroyed. Yet, developing nations have been developing for 100+ years despite (not enough) money being poured into them -- because the human side of the development problem (education, social institutions, corruption, civil war, imperial occupation legacies) has not been easily resolvable or often even recognized as an issue (as for example when big dam projects were built). [This is not to say that many developing nations did not have workable social orders before colonial imperialism destroyed their subsistence economies with plantations and so on.]
In an open source world, the artifact joins and defines the community. Just as surely, the community defines the artifact. This is because of what we are -- of what is an open source community: a community comprising those who are concerned with a program they program. It is because the word "program" is both NOUN and VERB. Projects and communities that enjoyed these synergies prospered. Those projects and communities who have not became irrelevant.
First off, there isn't just one Squeak artifact. There are many. This is not quite so much the case with a project like Apache (at least, not a few years ago). Essentially every screen shot on this page refers to a different Squeak artifact, many of them wildly different: http://www.create.ucsb.edu/~stp/CD-ROM/Screen%20Shots/
In some ways, much of the Squeak community is more like the total community of all Apache web users, talking about the details of the content on their web sites or special scripts or new modules, as well as bugs with Apache and proposals for improvements to that base. Just because an artifact may "join" some people together at a point in time does not mean the artifact "defines" their community. Even the Apache Foundation is now branching out to support other projects (some completely unrelated to anything except being collaborations). http://www.apache.org/foundation/contributing.html Yet, the Apache Foundation still retains coherence around the vision of fostering collaboration and improving communication.
It is hard to act and think in many ways at once. If people have limited attention in the context of running a foundation, and that's what we are talking about, which should they think more about, making the Squeak community better, or making Squeak artifacts better? There already are a lot of people on this list thinking about how to make Squeak artifacts better. Yes the two are related, but it is a matter of dynamics and psychology. It is quite likely we would never get people in a foundation with a decent level of involvement by Squeak users to agree on one way to make a Squeak release, since there are a dozen or more different types of Squeak user subgroups from embedded through mainframe. Yet, we may get them to agree on some processes to make all releases better, and we may also get them to agree to take steps to improve community interactions overall.
Doug Engelbart talks about something like this when he refers to A, B, and C levels in an organization. http://www.bootstrap.org/#note_7 The A level is the organization's mission (here, making better Squeak artifacts). The B level is the part of the organization that helps do the A task better (in the proposal, I argue for a "Squeak Community Foundation" to help the community do what it does better). The C level is about helping the B level improve on how it helps improve the A level (here I would argue the Chaordic Alliance, or Doug Engelbart's MetaNIC Bootstrap Alliance could serve this function). http://bootstrap.org/colloquium/session_01/session_01.html
It is as grievous an error to rationalize a dangerously conservative posture regarding the artifact on the theory that the artifact --as is-- defines the community as it is to rationalize an unconcionably unnecessary fork on the theory that the artifact is irrelevant if it is not changed to serve some special interest identified for particular purposes as "the community."
Java has been quite successful and there are endless versions of it by multiple vendors ranging from MicroEdition to EnterpriseEdition. In fact, some people point to this as a sign of Java's success (not that there aren't also weaknesses evident in how it happened).
Forks happen with Squeak every time a person starts an image and saves it. I guess I don't follow you here.
If we try to define the community with words approximating a functional specification at any level, we have already lost. As such, it leads to hopeless and divisive advocacy -- and eats at the core of a community.
Well, I can definitely see your point about community and specifications. It is true that a hacker's approach to community building is usually to try to define it in functional terms like an API or a clockwork. Hopefully, those, as Smalltalk programmers we think a little more in terms of interacting agents. But still, I am probably guilty as charged.
However, the fact remains that a non-profit like the Squeak Community Foundation needs a charter. And a charter includes a basic functional specification of what the non-profit's mission is supposed to be. This has very direct implications for fund raising and how funds can be spent.
According to the concepts behind the chaordic process, http://www.chaordic.org/what_des.html the purpose is the single most important thing that binds the community together. It is true some people in an existing community may not agree with any new purpose. But we are after all talking about the purpose for a new organization (the Squeak Foundation) so if there is divisiveness among the participants (who have not yet all been identified), the purpose should be updated to encompass it if possible. Obviously, you can't please evryone 100% of the time, though you can try as much as is reasonably possible.
I am not saying you are right or wrong. I am saying that THIS argument is pointless, possibly harmful, and disserves community and artifact equally.
So then it is wrong in the sense of being bad for the community?
A foundation with a mission statement of making an artifact better will have to stretch further to justify helping the community get better. A focus on making Squeak as an artifact better might not easily admit to, say, figuring out ways to help people on the Squeak list communicate better with each other, much less get people thinking in that direction. Yet, clearly the Squeak artifacts might benefit from better community communications infrastructure.
This gets back to something I heard Alan Kay say recently. Some people are "religious" about Squeak the artifact. SqC (According to Alan) tries to not be "religious" about Squeak the artifact. Alan sees Squeak as just a stepping stone to even greater things, realizing a deeper vision of personal computing. He's stepped on so many stones along the way from Simula to FLEX and ST-72 through ST-80 that such stepping must come naturally by now. I would suggest a focus on the artifact rather than the community in the Foundation purpose is more likely to reinforce this "religion". My reconceptualization was an attempt to shift our thinking from being about a "goal" or "artifact" to being about a "process".
In evolutionary terms, individuals and artifacts cannot "evolve". Only populations can evolve, as individuals (or artifacts) are varied and selected. So, a focus on Squeak as artifact makes understanding how evolutionary processes work around such artifact very difficult. And avoiding "religion" about Squeak the artifact means supporting its evolution, and that means having religion about "Squeak the community" as a driver of "Squeak transcendent". (This is not to say that in other contexts a belief in religion or spirituality and a belief in evolution aren't compatible, or not, as the case may be.)
Let us define our community by our dynamic and limitless good works.
Sounds good. But I don't think it would work as a non-profit charter.
Frankly, that is one of my concerns about forming a non-profit, having a separate mailing list, raising funds, and so on. When we stay informal, then our definition can remain closer to what you outline. If you want to argue the Squeak community does not need a Squeak Foundation and would be harmed by it, then make the case. I'll listen.
It is time to write much less political prose and write much more code and documentation. All of us. Let our works (meaning both the efforts and the products), not our words, define us.
The Declaration of Independence. Common Sense. The US Constitution. All important documents. Maybe someday the SqF charter will be up there with them. ;-) Well, probably not, but it wouldn't surprise me if Dee Hock's Chaordic Alliance charter was.
Both words and deeds define us. At the moment, I program full-time for a living. It's nice to use another part of my brain for a while, in a way I hope is still of use for some. Surely you must understand -- when you were crafting words all day as a full-time lawyer, wasn't it nice to come home and program?
-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
On Monday, May 28, 2001, at 01:09 AM, Paul Fernhout wrote:
*snip* in paraphrase summary: 1. a suggestion that no strong argument can be made that the program defines an open source community for that program; 2. a suggestion that a statement of purpose is more important than the program for an open source community; 3. a written statement of purpose is essential for an open source community.
I dissent. I don't believe Paul could be more wrong, in part for the reasons previously stated. I think he misses the point. Squeak *IS* the fulcrum of this community, it defines us in the most meaningful sense: our members are those interested in squeak, and those disinterested in squeak are unlikely to be members. Another community might be interested in other, related issues. But that isn't this community, so far as I understand it.
On the other hand, the community defines what is squeak, it does so in the most meaningful sense: the community programs the program.
The community defines the program and the program defines the community. There isn't any unanimity on what is the purpose of the community -- indeed, the community comprises many constituencies, many of which are at odds. But we are united around the same thing: the program. We add to, take away from, and define it, just as it defines us.
As can be seen by empirical evidence -- these statements of purpose discussions, these forking or not to form discussions and generally EVERY POLITICAL DISCUSSION WHATSOEVER IN AN OPEN SOURCE PROJECT has been divisive. It has slowed us don. It has hurt us. It continues to hurt us.
[I'm pretty sure I could whomp all comers on the "program defines the community" side of the debate -- as an exercise to the advocate, it is merely a variant of the "forks are bad to open source projects" debate. It is a view widely shared by the open source community and its leaders, and there is massive evidence that forks have killed good projects and neutralized great projects to uselessness. But as I noted, taking an advocacy position --just making the argument--, isn't worth the exercise. It is divisive, and it is also not the truth as I understand it. We have already argued it ad nauseum here, and I will not do it again.]
The problem with taking the view that one of the positions is more important misses the truth of this thing. In the most successful open source projects, the synergies of the program drawing a community, replacing those we lose via attrition, with the vital community advancing the program, leading to more members of the community, and so forth, works in its favor. In the notable failures, forks and splits and politics preclude anyone from having energy or interest in doing much more than arguing. The schisms in the community discourage people from committing to working, fearing they will be shot down or their changes ignored by their particular antis -- and concerned that the community's inevitable split will leave their work without a constituency. We leave our code in a fit of genetic altruism, and in hopes that others will grant to us. If that won't happen, most will just go find another project.
In short, forks ARE bad, but failure to evolve is likewise bad. Splits and schisms in the community ARE bad, but the failure to embrace new blood and new ideas is likewise bad.
If the Squeak Foundation is just going to be a debating society for pissing contests on these trivial questions -- be sure to count me out. Who knows, maybe I'm just not a member of the community after all -- I'm just this old geek who merely contributes to and enjoys Squeak. I didn't realize that I needed other credentials as well.
Paul argues that a statement of purposes are important, by analogy to the declaration of independence and the constitution. I find the analogy amusing, but fail to see where he connects the dots. There is amble practical evidence that an organic instrument is not a necessary precondition: most great OSS projects don't have one.
Paul argues that the Chaordic principles require a charter. This seems to me more an indictment of the applicability of these principles to an OSS project than a compelling reason to have one.
I am not against drawing up a simple charter with precatory statements as to what we are here to do. A foundation could sever our community well in a number of various ways -- none of them being a forum for political wrangling.
I am simply saying that any principle beyond the most fundamental:
THE COMMUNITY DEFINES THE PROGRAM AND THE PROGRAM DEFINES THE COMMUNITY (We program the program AND the program is our program)
misses the point and disserves the community. Such other policy disserves us because it is wholly unrealistic for open source projects. While there may be better ways to start political movements, those ways are probably hopeless for starting great open source projects.
Don't get me wrong. I have drafted many organic instruments. I know and can slam-dunk most parliamentarians on the fundamentals of Robert's Rules and lawyering issues through these arguments. That's great fun for me. I can see why these things can be useful and are, indeed, critical AND NECESSARY for any deliberative body.
And this brings me to my final point.
An open source community such as ours is NOT a deliberative body.
We "vote" with our fingers, or our feet.
True, this view makes an open source project more of a meritocracy than a democracy. I'm not sure this is a bad thing.
Andrew Greenberg wrote:
We "vote" with our fingers, or our feet.
Absolutely.
I disagree about forking being necessarily bad (I think it depends on the nature of the fork in question, and the willingness of forkers to cross pollinate with other forkers)...but I'll leave that argument alone for now (but remember: evolution needs variation and selection...any attempt to dominate and control evolution only ensures that you'll find the wrong path).
The fact of the matter is that SqF, SqC, and StSq are all attempts to organize and collect resources, either to pursue a specific agenda, or in anticipation of pursuing an agenda.
If SqF is going to accept money as part of it's organization, then those with money to contribute will no doubt expect to have some influence over its agenda. Once SqF is established as a credible and viable organization in the community, it becomes a convenient marketing vehicle for those that wish the community to pursue a certain goal...they only need to convince SqF that the goal is worthy.
Is this any different than SqC?
Everyone participating in the Squeak community is pursuing their own agenda...as they should. Make Squeak do what you want it to do...and, if you have the means to collect and organize resources in order to pursue a specific goal...great.
- Stephen
Hi Gang, IMNSHO, an egalitarian meritocracy is a very *GOOD* thing that has been the driving force behind the Internet itself and most, if not all, of the successful open source projects: those that produce results, get to make the rules; those who just want to talk, get left in the dust. Members o the Squeak community(s) would do well to consider this carefully. Moreover, I don't know how some of us find the time and energy for these debates. I'm peddling as fast as I can and can barely keep up with: (1) learning Squeak and (2) tracking this list. Cheers, Roger.....
"Andrew C. Greenberg" wrote:
On Monday, May 28, 2001, at 01:09 AM, Paul Fernhout wrote:
[snip]
And this brings me to my final point.
An open source community such as ours is NOT a deliberative body. We "vote" with our fingers, or our feet.True, this view makes an open source project more of a meritocracy than a democracy. I'm not sure this is a bad thing.
Hi Gang, Exactly and well stated. Fork the artifact and you fork the community. Fork the community and you fork the artifact. So, we now have three artifacts and three communities: SqC, SqF, and StSq. This should be interesting to watch. :-) Cheers, Roger.....
"Andrew C. Greenberg" wrote:
That is, we are both looking inwards to discussing purposes and projects to support "Squeak the artifact" as opposed to looking outwards to purposes and projects to support "Squeak the community". The two are naturally related, but the choice of perspective might have a profound influence on how we all think about the Squeak Foundation, as well as how the Squeak Foundation carries out its operations and sets its priorities.
I would most certianly agree. I think it is always better, perhaps infinitely better, to support the community rather than "just" the artifact that the community formed around. The latter will come from the former.
Excuse me, gentlemen, this is mere sophistry. A seasoned advocate can trivially make the contrary argument with equally compelling rhetorical force. But I'll spare you the demonstration, because to do so would be mere demagoguery -- indeed, mere pabulum.
The question is not "whether the artifact drives the community or the community drives the artifact?" Even to attempt an answer (using an exclusive or) is losing, for this is a fundamental principle of open source communities and, to use your terms, their "artifacts:"
COMMUNITY AND ARTIFACT DEFINE ONE ANOTHER.Put another way, the community and artifact are not only "naturally related," but are inherently intertwined. At least for a viable community.
[snip]
I think people seem to forget that for a long time now, we've had a fork that has quite successfully co-existed with the rest of the Squeak community. I think it has also been mutually beneficial. It's called ComSwiki and can be downloaded at:
http://minnow.cc.gatech.edu/swiki
- Stephen
-----Original Message----- From: Roger Vossler [mailto:rvossler@qwest.net] Sent: Thursday, May 31, 2001 1:48 PM To: squeak@cs.uiuc.edu Subject: Re: Community and Artifact Define One Another
Hi Gang, Exactly and well stated. Fork the artifact and you fork the community. Fork the community and you fork the artifact. So, we now have three artifacts and three communities: SqC, SqF, and StSq. This should be interesting to watch. :-) Cheers, Roger.....
"Andrew C. Greenberg" wrote:
That is, we are both looking inwards to discussing purposes and projects to support "Squeak the artifact" as opposed to looking outwards to purposes and projects to support "Squeak the community". The two are naturally related, but the choice of perspective might have
a profound
influence on how we all think about the Squeak Foundation, as well as how the Squeak Foundation carries out its operations and sets its priorities.
I would most certianly agree. I think it is always better, perhaps infinitely better, to support the community rather than "just" the artifact that the community formed around. The latter will come from the former.
Excuse me, gentlemen, this is mere sophistry. A seasoned advocate can trivially make the contrary argument with equally compelling rhetorical force. But I'll spare you the demonstration, because to do so would be mere demagoguery -- indeed, mere pabulum.
The question is not "whether the artifact drives the community or the community drives the artifact?" Even to attempt an answer (using an exclusive or) is losing, for this is a fundamental principle of open source communities and, to use your terms, their "artifacts:"
COMMUNITY AND ARTIFACT DEFINE ONE ANOTHER.Put another way, the community and artifact are not only "naturally related," but are inherently intertwined. At least for a viable community.
[snip]
squeak-dev@lists.squeakfoundation.org
-
Andrew C. Greenberg -
Paul Fernhout -
Roger Vossler -
Stephen Pair