MeatballWiki

FairSoftware

Summary

FairSoftware = FairProcess + FreeSoftware (/OpenSource). This will take a long time to express, but I'll do it in spurts and starts -- SunirShah

My goal with this is to imagine a world where

I'm actively trying to create such a world. However, I also feel that the current work practices do not match this world view very well, and there are major problems with all of the above that may make the world a more difficult place to live than a better one. I want to learn how to do things properly so when my career meets the wave, I will be set to be on top of the wave, surfing. -- SunirShah

Introduction

Background

What's wrong with computer science?

Software projects often fail.

As a result, software development demands too much (heroism, anti-heroism) from developers' lives.

Software development needs to do more than understand social context. It must be integrated into the very fabric of social activity.

Hughes, J., T. Rodden, V. King, and H. Andersen. (1994). Moving out from the control room: ethnography in system design. In CSCW'94. Greensborough, North Carolina. Available from http://citeseer.ist.psu.edu/hughes94moving.html

Not all software developers are going to fit in:

So ignore them. It's a big Internet, we can EnlargeSpace, and everyone has the RightToLeave, etc.

FreeSoftware and OpenSource are not magic solutions

Since the FreeSoftware and OpenSource movements are populated by the people in computer science, it is unsurprising that both continue to suffer from the same problems. OpenSource is the most vulnerable to this. At least the FreeSoftware movement has always been based in values, principles, and philosophies first. The OpenSource movement however arises from the classic ContentOverCommunity fallacy (vs. CommunityOverContent). It focuses too heavily on the object, the artifact, the output of the process (the source code), rather than the "invisible" social element that powers the process. Still, even the FreeSoftware movement fails to see the full social picture, and thus it still has room to improve.

  • OpenSource is not a panacea. There is more to the process than the output. The people who write and use the source code matter too, because without them there would be no source code (cf. CommunityOverContent). There are many ways to release source code, with different power arrangements that result in different kinds of outcomes. You can release code without ever accepting changes, for instance. Thus, while the released source code may be the most visible and striking part of the entire solution, it isn't a sufficient condition for success. (And it may not even be necessary.)
  • FreeSoftware is not very free. FreeSoftware is free if your notion of free is limited to "free as a bird." Certainly, once the code is released, it is free to have its own LifeInText divorced from TheAuthor, but that is not all the freedom one can have. There is real power locked up in the people on the project. The most important power in a software development project rests with the developers, and amongst them the person who controls the source control has the most power. If as a user I cannot impact the development of the software, then my only freedom will be to convince or hire other developers to fork the project, and then pay for the ongoing maintenance of my fork until I no longer need that software. That is a significant burden for users.

The people matter more than the code. Only from collaboration does any of this matter. There are many GhostTown projects on SourceForge that have died from programmers keeping too much social power for themselves. The most successful projects have had either a supergenius with the ability to hyperfocus down some technological alley for several years--not something we all can or wish to do ourselves--or a strong collaborating community that includes the end-users in some direct, tangible way.

Free software and open source are means, not ends in themselves. The ends one seeks are freedom from dictatorial control (the RightToFork being a means of supporting that), and reduced bugs (LinusLaw being a means of achieving that).

Methodology

Many FreeSoftware/OpenSource projects are amazing successes, but most are dead ends, or at best personal hobby projects with limited appeal. We should look at some of the best projects to see how they are socially organized, administrated, and what values they have. We can then extract patterns of best practices and build a PatternLanguage of what to do. There is no one solution, but there are better solutions and worse solutions.

Because, let's face it, after over three decades, we have figured out a few things.

Roles

In a typical OpenSource project, we expect to find BenevolentDictators who know how to lead the whole project. However, the dependence on an enlightened programmer is in the long term unstable, and in the short term highly unlikely. While individual programmers are always encouraged to write and release as much code as they want, a project with the LongView should recognize that putting too much power in the hands of one person creates conflicts of interest.

In particular, we can identify three roles that need to be split based on the fundamental power structure of an OpenSource project.

  • Lead developer (product). The person in charge of the code base, its qualities, and its internal design. This is the traditional role of the enlightened programmer, and for what it's worth, is probably the preferred role for the programmer.
  • Community leader (workers). The person with political power in the project. As the FirstServant, this person facilitates the internal social network that creates the OpenSource project.
  • Community marketer (users--and money). The person who tries to relate the project to the external world. This person seeks ties to the outside universe, in particular fiscal, social, and other resources critical for its continuing survival.

Collapsing these roles together results in aberrations in the development of the project, and may ultimately stunt its growth. A developer who is also the community leader will be a GodKing. A community leader who is the community marketer may seek to build a CareerCommunity and neglect the internal social needs of those who have already committed to the community. A marketer and a programmer will create brochureware with low usability.

The ideal community has these positions in some negotiated tension, since they are all necessary for the survival of the community, but neither one of them alone or no two can support the community in the long term.

The major problems in OpenSource remaining in 2004 (the date this was written) was that most OpenSource projects have poor usability and poor financing, intense feature creep, and sometimes fundamental problems or bugs that nobody seems to be willing to address (see Mozilla for example). If you map those outcomes against the reality that OpenSource projects until 2004 have been primarily led by one self-interested programmer, you will see why (at least) three roles are needed.

In particular, my now defunct resignation was a reaction against the conflict of interest where all three roles had somehow collapsed within one spatial-temporal-spiritual location. My new plan is to try to grow new positions to fill the three and then act as something akin to a CEO. -- SunirShah

Related

  • http://opencapital.net describes the same roles for Limited License Partnerships in the UK: a triangle of service providers/service users/commonsholder (in trust).

Development

Tools

The dominant model for OpenSource development today is best reflected by SourceForge, the largest and most popular public repository for open source projects. Roughly speaking, an open source project today

In general, we claim that despite the power of the Internet to reduce the distance between authors and readers, coders and users, the standard tools for open source reflect and preserve and teach the common computer science values of maintaining a strong distance between the developer and the end user. Further, the notion of "many eyes" gets thwarted by the meritocratic social organization (the cathedral) that acts as a bottleneck to individual contributions, as the oligarchy running the project must vett and approve changes to the mainstream codebase. Very rarely do we have a true bazaar, a project of lively exchange (cf. LittleEconomy) between contributors growing an organic mesh of code on top of the commonly maintained StableBase.

Unsuprisingly, we instead see the industrial era values and practices that govern contemporary Western computer science. Open source projects remain hierarchical, distant, system-oriented, and controlling.

For people that do not share these values, the software that grew from these values becomes an albatross to be hacked around, rather than a tool to help. The code as law does limit and direct contributors along an opposite social path. Thus, it is necessary to build new software to facilitate the kind of collaboration that we want to have.

Wikis, since wikis reflect the basic properties of the DigitalNetwork, have long since shown that hierarchical social systems are not necessary on the Internet, and often an incumbrance. Further, they have shown that social distance is a problem, not a solution. Could we not reform the open source tools around the wiki model?

We also need to rethink how software is designed. Let's stop building monoliths. Let's start building HyperCode. The Internet works because there is a NetworkStandard we commonly build, upon which we all can build what we want. Keep software simple, and build it in layers. Allow software to talk to one another through protocols, not through tight binding. Why have only one codebase when we know that software is more powerful when it is an ecosystem of interacting parts?

Perhaps:

  • A wiki as the meeting place for the community of developers, users, testers, funders, and whomever else is interested in collaboration.

Future Tools

We may want to develop tools which more capable. So that in the future (now?) software development is:

  • Centre around a wiki;
  • A socially hyperlinked SourceControlRepository (somewhat unlike the hierarchical CVS or [Subversion], but close) integrate in to the wiki.
  • A socially hyperlinked task-management application (like Bugzilla, but not Bugzilla) integrated in to the wiki.;
  • A better configuration management system then GNU Make or Ant;
  • The CopyLeft GeneralPublicLicense or a BSD-style copyright license that allows the RightToFork. (CreativeCommons?)

Maybe compare http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?ProgrammingWithAndInWiki

To Be Integrated

Jamie Zawinski describes open source development as the CADT (Cascade of Attention-Deficit Teenagers) model:

It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. [...] But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again. http://www.jwz.org/doc/cadt.html

= Discussion =

...Let's start building HyperCode. The Internet works because there is a NetworkStandard we commonly build, upon which we all can build what we want. Keep software simple, and build it in layers. Allow software to talk to one another through protocols, not through tight binding. Why have only one codebase when we know that software is more powerful when it is an ecosystem of interacting parts?

When you get around to defining HyperCode, please mention the CommunityWiki:OneBigSoup project. ( [OneBigSoup blog] [OneBigSoup wiki] )

From the [OneBigSoup:MissionStatement :] "We are integrating existing communication systems, including Wiki, IRC, Instant Messaging, e-mail, and even static web sites. We connect communication systems with protocols, services, clients, anything. We focus on Integration and Pragmatism."

We've been working on precicely what is called here the "HyperCode" model- lots of communication software pieces working with lots of other communication software pieces. We've been working on it consciously and directly. We've just called it "OneBigSoup" rather than "HyperCode."

We have several efforts to interconnect communications systems.

So far, we have built (and are refining:)

  1. an XML-RPC based event server named [DingDing]
  2. [LocalNames]- extending wiki-like linking to just about everything
  3. [UniversalLineInterface,] which makes it easy to connect IRC to servers, or web queries to servers (which could be done from wiki as well), or do IRC-botish things from the command line just like from in IRC
  4. [plog,] which before it was "project log," meant "personal log-" a way of logging your events from around the Internet's forums

...and we have zillions more ideas in the pipe- [see IntComm:IntegrationOpportunities.]

Note that: We claim ZERO credit for these ideas. These ideas are ancient and obvious. They've been around since at least the 60's. Many people have been saying these ideas for a long time now. So, we are not claiming credit for these ideas.

We are just looking for people to help make them a reality. -- LionKimbro

It would be better if you related OneBigSoup to the page once it's written since I can't claim to understand the project as well as you. I'll remind you then. -- SunirShah

Other related points of interest

Years ago I did a lot of work (a number of projects) with long-term goals in mind. Well, not 200 years, but 50 years (solve the problem and never think about it again). One problem in that were the different programming languages. Algol, Fortran, Basic, Pascal, C, C++, Java, C#, Perl, D ... they came and went and I felt a need to think and work independently from languages, to have a higher level of abstraction but still within the implementation. So I arrived at a "(natural) language oriented programming" that uses a OO paradigma that can be implemented on procedural languages too. I called it LOP (language oriented programming) or THELOP (THE language of programmers). So in short: I have created an English-like private language + syntax, so I do write things like FileAppendLine("this.log","process started") or EmailSendToSubjectText("office@xy.com","BUG","description...") in any of these programming languages. It looks simple but it isn't. It means to give final names to the really reusable elements of programming. It means to go from OO programming to OO thinking, a world where objects and methods are just created at will to a world where they are highly constrained by consistency and meaning. It works very well for me and I wrote about it in Wiki:CategoryThelop. But it is not a product, it can't be hyped, you can't earn money with it (except by writing excellent software) and I'm no missionary. So I left it at that. -- HelmutLeitner

"OpenSource" (at least to the users) is a nearly necessary but not sufficient condition. -- SunirShah

Discussion

Sunir, I wonder what the fundamental difference between a software project and an online community (wiki) project really is. Maybe it would just make as much sense to depict FairCommunity. Why should roles be a necessity in FairSoftware, but a problem in a wiki community. Things don't seem to fit together. -- HelmutLeitner

Answer 1. The difference is at the level of abstraction. Everything is a community (or at least should be). The difference is the output. The city engineers that design and build the sewer system are a community with a specific output: the sewer system. A software project just results in software, and even if socially they might organize in some very archetypical ways. And just like city engineers need T-squares, drafting tables, and laser-sighted surveying equipment, the software developers need specific tools to make that happen. WikiAsSourceControlRepository is my favourite example, but it also goes down to Wiki:CrcCards and Alexander's Patterns. These are all mechanisms, forms, ideas, structures that operationalize one particular set of values in a particular domain for a particular outcome.

That is, to distinguish between various social organizations that organize in socially similar ways, I figure you can simply identify them by their particular "Values in a domain operationalized towards an outcome."

Also, many communities are even communities of communities. For instance, the city is several interlocking communities playing various roles, including the sewer engineers, the politicians, the artists, the public transit workers, the businessmen, the medical community, and so on. Everything may seem to blend together (a city engineer might also be an artist), yet I think there is still meaning in focusing on one specific output.

Finally, my goal is not to build better social organizations, since I think there is an ocean of wisdom in that and I am still learning. My goal is to build better software--or more broadly, to accept the inherent unity of technology and society and then embrace that in a responsible way. I know the world is far from accomplishing that. -- SunirShah

Answer 2. Roles aren't bad in a wiki community; roles are bad in a community of SelfishVolunteers with no feedback loop to measure outcomes against (PowerLoop). A directionless community cannot justify having roles. After all, when someone makes a decision to go one way, there is nothing to measure their decision against to see if it was the right decision. Rather, for something like Meatball, which is more of an ongoing conversation, it makes a lot more sense to try to be "as large as possible while still remaining coherent." Not quite RadicalInclusiveness (at least as I understand it), but still inclusive and (mostly) unroled. I like conversations where participants feel free to speak when they want to, rather than wait for someone to approve them. Or maybe my point is that every role belongs to every person. Everyone needs to TakeResponsibility. -- SunirShah

Answer 3. Wikis are like empty rooms (WikiAsRoom); there are no social rules embedded in the walls. The social organization on a wiki depends on the social practices of the people inhabiting the wiki. So, the question is not should a wiki have roles, but rather does this or that organization require roles, of what type, and in embedded in what social structure. A FairSoftware project requires roles because it has various stakes that are conflicts of interest. A project like Meatball also has conflicts of interest, and it was best served when administration and editorialship was split between Cliff and I. Now there is a monetary side to Meatball (or at least my life), so having all three executive roles located in me was a major conflict of interest. The idea of CommunityMembership is another thing altogether; the question is always what would members have over random visitors, why this is a good thing, and how to LimitTemptation of AntiAuthoritarians (i.e. how to do the right thing). -- SunirShah

Meta-answer. This discussion of roles might find a better home. There are obvious contradictions in what I'm saying because I'm mostly just having an allergic reaction to the idea of a formal role system for Meatball rather than offering a strong alternative other than the status quo, but either way, it's off-topic for FairSoftware and I believe on-topic on some other page that has at the moment escaped my mind. I do believe that Meatball needs roles; I don't believe in creating a gigantic formal system to set a solitary direction, since Meatball is not an industry (it has no objective output). I think the MeatballMission needs to be rewritten to be clearer. That concept of Meatball as an inclusive yet coherent conversation is something I just thought of off the cuff, and it makes a certain sense to me. -- SunirShah

http://joi.ito.com/archives/2004/06/19/describing_the_sharing_economy.html Joi Ito's doing research on the SharingEconomy - the economic role of the commons in software and other forms of culture.

I'm pretty sure the best way to implement ethical software is for the company that produces it to be a cooperative with open membership. That's the only feasible way for ordinary people to be able to submit user stories and have them taken seriously. I also think that sticking with interaction design and publishing the user personas is the only way to provide a minimal warning to users. Sortof "yes, this is for you, welcome" versus "no, this software isn't for you, so sorry, please form your own developer coop with all your friends".

The (preceding) reference to a DeveloperCoOp resonates with several of other interests that are tangentially referenced here at Meatball. If anyone cares to collaborate on this facet a bit, just create the page and I will be delighted to join in. -- HansWobbe.

EthicalSoftwareFoundation?

moved to NobodyGivesFeedback

Edit this page | History