Discussion List
This Month
search
About CRUMB
Discussion List
List
Edited Files
Subscribe
CRUMB Interviews
CRUMB Seminars
Practical Resources
CRUMB Outputs
Links & Bibliographies
Advanced Search
Latest | Archive | Search Discussion


Date: Tue, 17 Jun 2008 17:14:53 -0700
Reply-To: Michael Mandiberg
Sender: "Curating digital art - www.crumbweb.org"

From: Michael Mandiberg

Subject: Re: June Theme: Open Source, Residencies and the Lab Model
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes


Hi All,

Michael Mandiberg here. I'm a Fellow at Eyebeam's OpenLab, on leave
from my position as an Assistant Professor at the College of Staten
Island/City University of New York.

FYI Some Current Work:
http://therealcosts.com/
http://eyebeam.org/project/bright-idea-shade
http://digital-foundations.net/
http://mandiberg.com/

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 below. 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 (http://foodcoop.com/ -- 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 a 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: most of their 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 budget 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

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

--
Michael Mandiberg
R&D Fellow // Eyebeam
Asst Prof // CSI/CUNY
http://Mandiberg.com
michael at mandiberg dot com
--





On Jun 14, 2008, at 8:11 AM, Steve Lambert wrote:

> Hey,
>
> My name is Steve Lambert and I am one of the Senior Fellows at the
> OpenLab.
>
> Sorry for the delay in answering these questions. I'm just going to
> answer this one because I think it kind of answers the others at the
> same time.
>
>> * Can collaboration exist without openness?
>
> Yes. Bad collaborations can certainly exist without openness.
>
> In my mind, there are a few kinds of collaborations. I have never
> written this down before so hopefully it makes sense.
>
> Master and Apprentice - this isn't really collaboration, but some
> people call it collaboration to makes themselves feel better. The
> Master calls it collaboration so that they don't have to feel guilty
> about taking advantage of the apprentice. The Apprentice calls it a
> collaboration so they don't have face that they're being taking
> advantage of. The pitfall here is pretending it's something it's
> not. If the rolls are properly defined (actually calling it master
> and apprentice, mentor and mentee, or artist and assistant, etc.)
> and treated appropriately, it can actually be healthy and good.
>
> Collaboration with leadership roles - With this kind there's someone
> who takes the lead at various stages. The roles may shift and
> another person may lead at another stage. This changes can happen
> frequently or infrequently. But someone steps to the front and
> others step back - often because the person in the leader position
> at that stage has some special skill or expertise. I'm thinking of
> jazz when a soloist will step forward for a few bars, then they step
> back and someone else steps forward.
>
> Totally balanced collaboration - The last is a totally even
> collaboration where all parties have an equal hand in everything at
> every stage. This may not exist in the real world as much as it
> exists as a goal to strive for.
>
> So getting back to the openness - there has to be openness among the
> collaborators for the collaboration to work. (and a bad
> collaboration could exist where the collaborators don't communicate,
> which sounds awful doesn't it?) In all of the above models, they
> collaborators need to communicate with each other. They need to
> formally or informally convey to eachother what their doing, why,
> documenting the process so the other can understand, etc.
>
> 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.
>
>
> Another thing I want to mention, which I have said around here
> before, is what we're calling "openness" is not new. It's ancient.
> The term is new and the concept has had a resurgence in the past
> couple decades, but sharing intellectual property is as old as
> civilization. Most of the knowledge our culture has was passed on
> by others for free. If I wanted to make a basket weaved like yours
> I just asked you to show me. You would have no financial, or any
> other reason, not to show me. Civilization progresses because of
> the proliferation of shared knowledge.
>
> And this is how all knowledge has been passed on since the
> beginning. From language to skills and ideas. Until IP became
> commodified. I see what we're doing as going back to the ways that
> are closer to human nature, before knowledge was perverted by the
> market.
>
> In this way, open source is an innate part of being human. Treating
> it as foreign or new just helps reinforce the way IP currently
> functions within the market as being normal.
>
> Steve
>
> --
> Steve Lambert
> http://visitsteve.com
> Eyebeam Senior Fellow
> http://eyebeam.org
>
>
>
>
> On Jun 2, 2008, at 2:57 PM, Sarah Cook wrote:
>
>> * Can collaboration exist without openness?
>> * Is collaboration 'hardcoded' into the lab model, and what are the
>> implications when the lab's philosophy embodies open source-ness or
>> releasing work into the public domain? (as is the case with the
>> Eyebeam R&D OpenLab)
>> * Is it necessary or helpful to have a creative commons mentality
>> when engaged in collaborative projects?
>> * What can be learned from the model of artist-curator residencies
>> within labs, where participants are expected to collaborate?
>

Keywords:

  media art
  design
  time
  open source
  software
  video
  wiki
  collaboration
  press
  technical

People:

  Sarah Cook
  Michael Mandiberg