Free software is very often developed using the tools and infrastructure of open source methodology. Programmers collaborate across space and time using web hosted services for sharing and archiving software source code, for recording programmer notes, collecting documentation, for direct communication between programers, and to publish software.
Collaboration on software source code has been successful and productive. Can we help to create similar collaboration infrastructure for other kinds of creative project? Should we? And if so how?
I propose that we build a free software, collaborative infrastructure for video, audio, images, drawings, spreadsheets, word processor documents, fonts, MIDI scores, and more. Such a project will be an interesting collaborative challenge itself, since it require cooperation and coordination across the boundaries of many existing free software projects.
Sections:
What's the best "bar joke" told in all of the juke joints and funky dives across the US? What are best 10? Who tells these? What do they mean in people's lives? How far do they spread?
As a thought experiment, I propose that those questions could be addressed by one or more 60 minute video documentaries comprised of short segments (average length, 5 minutes), filmed on location at bars around the country, collecting joke telling and discussion from staff and patrons. 10 jokes per 60 minute segment.
If joking is not your thing, a similar style of documentary film can be helpful for some kinds of journalism. For example, what's the state of city parks in America's small cities? How do they compare?
The subsections here speculate on what technical forms of collaboration might be helpful to such a project. Or, you can skip to the next section .
These videos need no extraordinary travel budget. When Penn and Teller made a similar film, "The Aristocrats", they of course had to travel with crew, to many locations around the country. For an "open source" film there is less need: different crews can film in New York, Pittsburgh, Dallas, and so forth. The raw footage can be gathered on-line from anyone who would like to produce some and make it available under a suitable copyright license.
Of course, that will create some serious technical challenges and editorial challenges. Different crews mean different equipment and different styles. For example, the audio and lighting levels are likely to be "all over the map". There will be considerable paperwork (such as release forms and perhaps profit-sharing contracts) to manage. The task of selecting and editing content is substantial. Parts of the film may want a musical score.
If interested project contributors can be found - anywhere "on the net" - then that production work, too, can be made an "open source collaboration".
One can't predict whether an open source project lives or dies or whether its work-product will be good or bad. Yet, let's suppose that we are lucky and at least one excellent short film emerges from this project, suitably licensed for collaboration but also for commercial exploitation by the group who contributed to its creation.
Further collaborative projects then arise: budgets, marketing plans, on-line and print ads, perhaps posters, and perhaps a 3-fold glossy to hand out at film festivals. Tools for Internet-intermediated Collaboration across a wide range of media types is called for: documents, spreadsheets, drawings and images, ad copy, and perhaps even custom fonts ("BarNapkinScrawl AllCaps").
We're talking here about an exploration of freedom. When we imagine a project like the "Bar Joke Movie" we're in some sense talking about the possibilities that unfold when people are free to communicate across the net and free to share multi-media content and free to develop and improve that content and share the results.
There is a technical entanglement, though. To work with digital multi-media content, contributors must use a diverse array of software programs such as word processors and video editors and must use remote servers on the net (such as to store intermediate work where co-collaborators can find it).
(Please be sure to read this section but for you convenience, here is a link to skip to the next section .)
There are two possibilities:
People can share the programs with anyone who wants to collaborate. They can study them and modify them to add desired features or remove objectionable features. They can have servers that aren't "spied upon" by a large firm interested in collecting advertising data or other forms of surveillance.
In this situation, it is easy for third parties - namely the authors of the software and operators of the servers - to demand exhorbitant rent, to collect private information about users, and to otherwise interfere with the freedom to collaborate.
That choice is a no brainer. As a community, if we want to encourage this kind of collaborative project we must make sure that the necessary software programs are free software programs and that the provisioning of servers is inexpensive, decentralized, and reasonably private.
If someone wants to start a collaboration project for something like the Bar Joke Movie there are free-software tools to get started already. It's just that there are drawback to these tools. This section mentions a few (as examples, not endorsements) and some of the key drawbacks to the current landscape. Or, you can skip to the next section .
Some examples of existing editting and production tools:
Some of the design tools already have features for collaborating over the net. For example, Open Office is able to read and write files to WebDAV servers (WebDAV servers provide a form of remote, sharable, file system). InkScape has a feature that allows multiple users to collaborate, in real time, via instant messaging services, on a single "virtual whiteboard".
The examples of Open Office's WebDAV support and InkScape's use of instant messaging teach an important lesson: a few very generic server-side features (a WebDAV server and an instant messaging hub) an enable a great deal of multi-media collaboration, at least crudely.
A relatively private and inexpensive collaborative environment
can be provisioned by the collaborators themselves by leasing a
generic server running software such as the Apache Foundation's
mod_dav (for WebDAV support) and
a Jabber hub (for instant messaging).
"Version control systems" (which help with keeping track of who makes what changes to media file, and why, and with being able to retrieve older versions and combine seperately worked on versions) are another helpful element in collaboration on digital media. Again, free software server components (such as git-related servers or Subversion) exist and are able to at least minimally handle a variety of media file types.
While all these tools already exist, I see three main drawbacks to the currently available free software tools. Of these three classes of problem, two are are of concern but one is already under control:
Some will say that Open Office isn't as high quality a word processor, judged by UI and features, as some others. They'll make similar claims about GIMP, about Audacity, about Inkscape, etc. In many cases, the authors of the free software programs would even agree, wholeheartedly. They would say "That's true. We're not as rich in features and excellent in UI yet. We'll get there but it takes time." Or words to that effect.
That's a drawback but a minor one. The best of these programs tend to be at least "pretty darn good" for many uses and they are indeed getting better all the time. There are already other people working, well, on the "quality" problem so there is no need to worry about it too much for the project of creating a collaboration infrastructure - just so long as these programs are good enough to do many possible projects.
An example will illustrate: Using Inkscape locally, not over the net, I can export a drawing as a pixmap - an image file - and my (local) collaborator can import it into a word processor document. That's great. And, Open Office can also import a pixmap over net, using WebDAV. Fantastic, we're half-way there.
But there's a problem: Inkscape can't export that image file over WebDAV. If my collaborator and I are separated by the Internet, and we're using just Inkscape and Open Office, the drawing I'm working on "can't get theah from heah": I can't export from one program such that my partner can import to the other program.
There are workarounds. A user could export the file locally and then use a third free software program to copy the file over WebDAV to a location where Open Office can find it.
This is a serious drawback, though. It requires fairly uncommon expertise for a user to understand why he can't simply "Export" and paste in the right URL. It requires a fairly expert and persistent user to puzzle out exactly which third program he should use for the work-around, and exactly how.
This is a higher priority drawback because nobody is working on it yet it's certain to be a real obstacle for most users.
Sure, it's "cheap and easy" for a group of 10 typical free
software / open source methods developers
to assemble server-side components of the sort needed.
One might have some spare server bandwidth already. Another
might be quite familiar with configuring Apache to
have mod_dav loaded and suitably running.
Another will volunteer to set up a list-serv. They'll
coordinate all of this in a few emails or on a chat channel
and it could be done, literally, in a few hours at
most if people wanted to go that fast.
The problem is that for anyone other than "10 typical free software / open source hackers" such a project would not be cheap or easy.
This is another higher priority drawback of the existing software because, again noboody is (much) working on it yet it's certain to be a real obstacle for most users.
In the above I made a pretty strong case, through a "use-case" thought experiment for the high social value of free software tools and non-rival services to support a collaborative design tool set . I pointed out that much of the needed software exists but that software has some serious drawbacks .
The drawbacks I described point to a systemic problem: the need for deeper coordination and cooperation between existing free software / open source methodology projects.
For example, I spoke of the problem that Open Office can
read WebDAV but Inkscape can't write it.
And I spoke of the problem that the collaborative features
of Open Office and Inkscape call for a server which is
both a WebDAV server and a Jabber server, yet such a server is
cheap and easy to create
only for hackers
.
I am calling upon granting organizations with an interest in the social advancements described here to help "us" (me and some people I'm working with) create a hub project whose mission is to help realize the kind of free software inter-project coordination and cooperation needed to begin to build out this truly collaborative workspace for digital, multi-media content. The hub project can: