I am going through my things tagged “to blog” and this one seems timely. In June of 2008 the CRUMB list was dedicated to a discussion of collaboration. I wrote a long post in response to a post by Steve Lambert, in which he argued that there were multiple forms of collaboration: Master and Apprentice; Collaboration with leadership roles; Totally balanced collaboration (which he admits probably doesn’t ever really exist. He also points out that
The thing is, I don’t think there has to be openness to the outside world. Collaboration ≠ openness. There’s probably people working collaboratively on some weapon at Lockheed Martin or Lawrence Livermore right now that is classified and worked on in secret. The spouses of the engineers have no idea what they do at work. But there are probably great collaborations happening behind closed doors protected by armed checkpoints.
As I get ready for the FLOSSify 1: Digital Foundations event at Eyebeam next weekend, I’m thinking a lot about collaboration, structuring participation, authorship and credit, and team building. So I think it is relevant to revisit some of the things I wrote in my CRUMB post
So here it is, in its entirety, balanced hierarchy for better and faster work:
I am going to talk about a couple of things. One of which is a response to Steve’s post about modes of collaboration. But ultimately the question I think I am answering is “Why Openness?” and also “Why Collaborate?” And my answer is “Faster and Better.”
I am working on a number of projects, almost all of involve working with other people. I work with other people because i have found it is the best way to get the most things done. The best projects happen the fastest when you work with other people. That sounds kind of puerile, but I am quite serious.
The way I work with other people ranges accross the spectrum of working styles Steve has described. I want to point out that the Master and Apprentice, Collaboration with Leadership Roles, and Totally Balanced Collaboration are part of a continuum of collaboration ranging across differing levels of *hierarchy*.
I’m going to go out on a limb here, and say that Hierarchy & Leadership *is* ultimately necessary when people are working together in a significant scale (more than two or three). Even the Park Slope Food Coop, which is my personal paradigm of a successful communal and collaborative organization, has four levels of hierarchy (shift worker, squad leader, coordinator, general coordinator). I see a number of large scale open source projects run out of the OpenLab, and ultimately it comes down to one or two project leaders, who have the vision, the mad skillz, and the enormous time commitment to *organize* the other collaborators. These roles *can* shift over time. This is true for software work and RL work.
I want to describe one of the group-work models I use: I work with two to four student-assistants who are definitely apprenticing under me; they know exactly why they are working with me: they learn TONS and get to contribute to real projects in significant ways. Role-wise I am the creative/technical director who works out ideas with them, and then they are given wide latitude to execute. They return to me with drafts, we discuss, they make revisions. It is often the first time they have been given responsibility for such a large creative project, and they rise to the occasion. Put another way: they have the passwords to all of my FTP accounts. Trust is an important part of collaboration. To suggest that this is a non-hierarchical collaboration would be false, but to suggest that this is not a collaboration would also be false. We are constantly creating things through working together that neither one of us would come up with alone. So Steve, I am going going call it collaboration, and not just b/c I want to feel better about myself esteem (*kisses*)(LOL)
I have also many times attempted to do the perfect-collaboration-where-everyone-has-the-same-responsibility-and-does-the-same-work-and-gets-the-same-credit. _it_doesn’t_work_. someone always flakes out. someone one’s skills are always more labor intensive, or more needed in each project. someone is always too bossy or controlling. nothing is perfect. utopia is the land that does not exist. that is just the way it goes.
One of my favorite instances of a utopian attempt to do this was made by a feminist art collective I knew (and loved) in grad school: when they edited video all three to four of them would sit in the edit lab and edit the video together. sometimes someone on the keyboard, and a different person on the mouse. beautifully poetic utopian attempt to create perfect collaborative balance. two problems: at the time one of them was much better at the software than the others, and ended up doing most of the work (despite the others’ presence at the computer). AND it was phenomenally inefficient: to my knowledge most of their incredible video is still unedited.
Which brings me to my most successful collaboration to date, and also brings me back around to this idea of “openness” and why I work with others to do better work faster. xtine burrough (http://www.missconceptions.net) and I are writing a design textbook called “Digital Foundations: An Intro to Media Design”. It will be published by AIGA Design Press late this Fall, and already up online here (yikes!):http://www.pearsonhighered.com/bookseller/academic/product/0,3110,0321555988,00.html The book integrates the visual principles of the Bauhaus Basic Course into Adobe design software training. In my life as a professor of media art I do a lot of hands on lab based teaching, where I have to teach students how to use the tools so that they can express their ideas. There are no good textbooks to do this with — they are all corporate training manuals without any visual principles or historical perspective, but with a mind-numbing amount of bad design examples (drop shadows and outer-glow anyone?).
So xtine and I decided to write the one *we* and our peers wanted to use.
Here is where openness and the principles of creative commons come to make it happen better and faster. Many of these things are conventional for a open source project, but not for a book or design project:
1. We are using only public domain and creative commons licensed images in our examples. We did a fair amount of research, and realized that our image costs would be larger than the entire budget for our book (http://www.blog.digital-foundations.net/?p=4). So we turned to the public domain and creative commons for our examples: http://flickr.com/photos/digitalfoundations
2. We have secured the first Creative Commons license from Peachpit/Pearson. (CC+, BY-NC-SA) We don’t actually have the contract signed yet (LOL) but we do have the go-ahead. This is huge. Not just as a symbolic marker of the acceptance of ‘openness’ in the proprietary media world, but b/c of what it allows us to do. Remember: Better and Faster
(nb: we did get it in writing, and it is on the “copyright page” of the book)
3. What we can do with CC // Better and Faster: Though the book is only half written(!) we are already planning with Adam Hyde of FLOSS Manuals (http://en.flossmanuals.net/) to translate the book into Open Source. “Translate into Open Source?” you ask…? Yes, translate the core exercises from Photoshop to GIMP, from Illustrator to InkScape, etc. And then, we’ll translate those translations into the growing set of languages that FLOSS Manuals are working in. Imagine: Josef Alber’s color exercises as a means of explaining how to use the color picker in InkScape… in Farsi. This is openness because it is Better and Faster.
4. In fact we have an entire chapter (#2) which talks about Creative Commons, Fair Use, and openness. Find another intro textbook that does that! http://wiki.digital-foundations.net/index.php?title=Chapter_2_Sandbox
5. We have been blogging the writing of the book (http://www.blog.digital-foundations.net/) to share our research and process. Comments become a key component of judging feedback. Expect a post on “How to get a CC license from your publisher” We share our findings, and others have provided immediate feedback.
6. We are writing the book on a WIki (http://wiki.digital-foundations.net/index.php?title=Main_Page) so that we can write collaboratively and incorporate feedback directly. This has already had direct positive results.
So, to recap, for me it is about Better and Faster. Openness is a faster route to better work. There are lots of ways of doing it, but I do think that as much as they pretend pure openness, successful OS projects all have hierarchy.
Faster and Better,
michael
