A metaphor that's relevant to your argument: Programmers talk about optimistic versus pessimistic behavior. For instance, optimistic locking or caching allows a program to alter its version of a data before checking whether there's a lock, and then wait if there is a lock. Pessimistic locking or caching checks for the lock right away and then says, "Sorry, you can't do that." Of course, non-programmers won't find this metaphor illuminating. ================== More Open than Open Source FIRST SENTENCE DOESN'T MAKE SENSE, AND I DON'T REALLY LIKE THE WHOLE FIRST PARAGRAPH. I THINK YOU DIDN'T COME TO GRIEF ANYWHERE, BUT YOU DID EXPERIENCE CULTURE SHOCK WHEN YOU TOOK YOUR CONCEPT OF OPENNESS TO PROGRAMMERS WHO YOU EXPECTED TO APPRECIATE IT BECAUSE OF THEIR SUPPORT FOR OPEN SOURCE. Recently I came to grief by running my assumptions into themselves. My understanding of open source as a process where 'openness' was fostered crashed head long into my assumption that I was applying open source principles to books. It was a messy encounter. I stood by the accident scene screaming at bystanders who were as confused as I was. THE STORY ISN'T FINISHED AT ALL, SO THE NEXT SENTENCE IS ALSO DISTRACTING. The story, as with most accidents, has a rather long beginning and a rather short finish. It begins somewhere in a small community of around 1500 people, called FLOSS Manuals. A community, or collection of variously connected individuals, gathered around the idea of producing free manuals for free software. We have produced around 50 manuals or so, and many of which are translated or currently in the process of being translated into about 20 languages. All free, and open for improvement. Many of the manuals are very high quality. For example, Benjamin Mako Hill, board member for the FSF, has described the Introduction to the Command Line manual like so : "I have written basic introductions to the command line in three different technical books on GNU/Linux and read dozens of others. FLOSS Manual's "Introduction to the Command Line" is at least as clear, complete, and accurate as any I've read or written. But while there are countless correct reference works on the subject, FLOSS's book speaks to an audience of absolute beginners more effectively, and is ultimately more useful, than any other I have seen." What is surprising to many is that this very high praise is for a manual written by a community. Quite remarkable. Even more remarkable is that this book was MOSTLY WRITTEN IN TWO DAYS, AFTER LESS THAN TWO WEEKS OF PLANNING - but that is another story. Each of these manuals has been produced UNDER an entirely open policy. Anyone can create an account and change the content. Also of interest is that all credits occur on a very egalitarian basis. Everyone WHO TOUCHES ONE OF THE FILES is credited without exception (it is automated) and all credits are the same - your name in the back of the book under the title of the chapter. So far, over 2 years, I have seen very few bad edits and nothing malicious. What I have also seen is content improving over time. Sometimes this happens in small steps and other times in large bounds. An interesting model, but in many ways I felt we were doing very little different than applying principles of open source development to the development of books. That is until I ran head first into my own poor assessment of the situation. It has been with thanks to the FM community, and especially to Andy Oram, that I was reminded of the Commit Bit. To forget the Commit Bit was my undoing. In open source projects there is often a process of validation before you can directly contribute to the main code base. THOSE WHO HAVE WORKED INTENSIVELY ON THE PROJECT FOR A LONG TIME ARE GRANTED THE PRIVILEGE TO BYPASS THIS VALIDATION AND ALTER THE SHARED SOURCE CODE IMMEDIATELY, A PRIVILEGE THAT PROGRAMMERS HAVE JOCULALY LABELED THE 'COMMIT BIT' IN REFERENCE TO THE BINARY DIGITS THROUGH WHICH OPERATING SYSTEMS RECORD PRIVILEGES. The culture of each project determines how quickly or not a commit bit is handed out. THE FOLLOWING PARAGRAPH RAMBLES AND CONCEALS YOUR MAIN POINT, WHICH SEEMS TO BE THAT A FREE SOFTWARE PROJECT CAN HAVE A TOTALLY CLOSED COMMIT POLICY (FOR INSTANCE, ONLY JANE SMITH CAN COMMIT ANYTHING) BUT STILL BE OPEN SOURCE BECAUSE OTHER PEOPLE CAN MAKE CLONES. YOUR LAST SENTENCE IS HINTING AT THE POLICY THAT NO MATTER HOW MUCH SOMEONE MAY LIKE HER ORIGINAL PROJECT, SHE CAN'T STOP SOMEONE FROM MAKING CHANGES THROUGH THE SIMPLE EXPEDIENT OF CLONING A COPY. I think you could argue that 'open' in 'open source' effectively translates to 'potentially open' - which might actually seem closer to 'closed' depending on your mood. Open source however has an 'out' clause which is actually the right place to understand 'open' in free software as it applies to the 'code' and not commit access to the projects shared source code (these are easily confused) - if you don't like the policy of the project then the license allows you to fork the code (split the code base) and do what you like around it - build a new culture of developers, make your changes to it, give away commit bits to whoever you want. Of course this is not always appreciated by the founders or maintainers of the original project since forks also can represent a fork on energy committed to the project but that is also another story. WELL, WHAT ABOUT THE "READ" VERSION, WHICH WE'VE TALKED ABOUT SO MUCH AS PUTTING UP A BARRIER TO UNWANTED CHANGES--AND EVEN TO CHANGES THAT ARE WANTED BUT ARE COMING TOO FAST AND HAVE TO BE EXAMINED FIRST? FLOSS Manuals does not have a commit bit and the difference - commit bit or no commit bit is, in the eyes of many open source developers, radical. This is the clash of openness that surprised me when discussing with a group of open source developers how content gets improved in FLOSS Manuals. The developers wanted a higher threshold for contribution than the culture of FM currently endorses - essentially, they wanted to manage commit bits. We are still in the process of working this out but it brings me to question what is there to choose between the two models? If the only question is quality then its an easy answer. I am sure both methods work - they just require slightly different mechanics. Although I haven't seen the open source commit bit model literally applied to books, I am sure it can produce good content. I also have experienced first hand that the no-Commit Bit model also produces excellent content. So, if the measure is not quality then what is there to choose from? In other words why does FLOSS Manuals choose to be more open than open source? --> points to elaborate... * hard to get people to contribute (retarded with higher thresholds) WE LIVE IN A SOCIETY OF IMMEDIATE FEEDBACK, IF NOT IMMEDIATE GRATIFICATION. I DON'T THINK PEOPLE NEED IMMEDIATE GRATIFICATION TO ENJOY MAKING CHANGES. BUT THEY DO NEED TO KNOW WHETHER THEY'RE BEING HEARD AND SOMEBODY IS DOING SOMETHING CONSTRUCTIVE WITH THOSE CHANGES. IF THEY THROW IN AN IDEA AND HEAR OR SEE NOTHING FOR THREE WEEKS, THEY'LL LOG IN TO SOME OTHER PROJECT AND START CONTRIBUTING THERE. IMMEDIATE COMMIT IS THE EASIEST WAY TO PROVIDE IMMEDIATE FEEDBACK. * role of the maintainer HAVE YOU READ THE "ART OF COMMUNITY" BOOK FROM O'REILLY? IT HAS A LOT ABOUT CREATING A CULTURE AND AN ATMOSPHERE, WHICH IS MORE IMPORTANT THAN RULING WHAT'S IN OR OUT OR ISSUING A LOT OF "THOU SHALT'S." * vandalism prevention vs cure THIS IS WHERE MY OPTIMISTIC VS. PESSIMISTIC METAPHOR MIGHT HELP. * authority of knowledge vs collaborative knowledge production WE'VE HAD A LOT OF TALK ABOUT THIS; VERY GOOD POINT TO MAKE **the politics of tools and communities** I LOOK FORWARD TO WHAT YOU SAY ABOUT THIS. KARL FOGEL'S "PRODUCING OPEN SOURCE SOFTWARE," AND TO SOME EXTENT ALSO "THE ART OF COMMUNITY", TALK ABOUT THIS. Joshua Facemayer, one of the longest standing FM community members, nicely put it "the tools for 'ownership' should not be distinct from the tools for 'participation'". This is the principle for openness as I see it as it reflects the more egalitarian approach active at FM. It might be idealistic, but so far it works. -- Adam Hyde Founder FLOSS Manuals German mobile : + 49 177 4935122 Email : adam@flossmanuals.net irc: irc.freenode.net #flossmanuals "Free manuals for free software" http://www.flossmanuals.net/about _______________________________________________ Discuss mailing list Discuss@lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net -- ---------------------------------------------------------------------- Andy Oram O'Reilly Media email: andyo@oreilly.com Editor 10 Fawcett Street, Fourth Floor voice: 617-499-7479 Cambridge, MA 02138-1175, USA fax: 617-661-1116