Home | Open Content License v1.0 | Open Publication License v1.0
Open Source Content Development
Programmers have long known that they could work together in physical and temporal separation from each other. The phenomenon has grown to the extent that it has its own academic/professional literature and acronym: CSCW (Computer Supported Collaborative Work). While sites like http://sourceforge.org/ are burgeoning with collaborative, open source software projects, little seems to be happening in the way of collaborative content development.
The principles Eric Raymond outlines in his essay "The Cathedral and the Bazaar," while aimed squarely at programmers, are perfectly valid for use in the development of content. The model relies on and succeeds because of the interest and effort of talented authors and the truth of "Linus' Law," which states that "given enough eyeballs, all bugs are shallow." While we have seen huge quantities of content go open source since the inception of the OpenContent project, the vast majority seem to be single author works licensed for use and reuse. Why are people not collaborating on content creation as they are on code creation?
Perhaps it has to do with a fundamental difference between code and content, let us say prose, for example. While there are almost an infinity of ways to code a program so that it fulfills a specific purpose, whether or not it fulfills its express purpose is a rather objective matter. Even the subjective part of coding, decisions about specific implementation issues, can to some degree compared objectively in terms of reductions in file size, memory footprint, or execution time. In other words, the improvement of a program is, pardon the term, a relatively objective matter.
The betterment of a piece of prose is a different matter entirely. How do you compare one piece of prose with another? While there are some comparatively objective sides to prose, such as mechanics or accuracy of factual information, prose is a much more subjective matter. If a well-meaning programmer introduces some bad code into a program, it should be readily evident when the code fails to compile, execute, or perform its stated function. When someone inserts "not" into a sentence, however, there is often no quick, objective way for us to tell that the content of the prose has been tainted. This is certainly an issue for open source content creation.
I believe that Eric has, in his relation of the "maintainer" and his/her role, afforded us the solution to this dilemma. The open source content project coordinator has the same responsibilities as the open source software project maintainer. While there is certainly a distinction to be made between the factual and hermeneutic sides of an open source history project, a responsible maintainer must be accountable at least for factual accuracy. For example, while one open source Civil War project might interpret the causes of the "recent unpleasantness" to be issues of states' sovereignty and another might explain it in terms of human rights, we would expect both projects to be as factually accurate as possible, and hold the project maintainer accountable to see that it is.
This and the other roles which make for successful open source content development will develop over time as part of the culture of open source content development. I mention them here only to raise awareness of some of the issues of OSCD and help the community begin a dialogue on the challenges of succeeding in such an undertaking.
Have I left out some critical piece of the puzzle? Click here to contribute to this article in the manner described above.