[FM Discuss] more open than open source

[adam hyde]

hi,

the current conversation is very interesting...i have been asked to
write an article about fm, so i thought i would pick the issues we have
been discussing in the last days as a theme...i just wrote something
quickly and will build it out more (its not due for some weeks)...if
anyone has time to comment on how the last (and most important) section
can be built out then please let me know...I have put a * next to points
that need to be fleshed out...

adam

==================
More Open than 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, 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 *produced in two days* - but that is another story.

Each of these manuals has been produced with 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 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. To have a 'commit
bit' is to have the permission to contribute code directly to the shared
source code. The culture of each project determines how quickly or not a
commit bit is handed out. 

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.

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)
* role of the maintainer
* vandalism prevention vs cure
* authority of knowledge vs collaborative knowledge production

**the politics of tools and communities**
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 at flossmanuals.net
irc: irc.freenode.net #flossmanuals

"Free manuals for free software"
http://www.flossmanuals.net/about