RE: [-empyre-] Re: [backup.lounge|lab.02]welcome to february'sdiscussion on open source-open art

> Some artists are very secretive of their techniques for fear of being
> copied or criticized.  This is akin to proprietary software where you
> can see the result but you cannot look under the hood to see how it was
> made and how it works.  Pride and economics are the main motivations I
> see for this sort of proprietary attitude.  This also reinforces the
> romantic notions of the artist as a heroic mysterious genius.

Great post, Brendan, but I'm not sure that "pride and economics" explains why artists rarely
divulge the source code.

I would think that in most cases where the source could possibly be of interest and even use (as
opposed to the large majority of works of software and other art where the 'code ideas' or
techniques are not of general interest or general use) the artist just has not thought the idea
of source-as-part-of-the-public-project through with any interest, clarity, or purpose.

The more generally useful the code or technique is, the more likely the artist will consider the
issue. There is usually little point beyond 'window dressing' to make the source available to
projects that are not of general use. It would just be artists tarting up their projects with
buzzwords. O yeah it's open source ooo ahhh.

When I developed some code that is of use in an art project called Nio, I wondered what to do
with the source code. Publish it or keep it to myself? I decided that the only reason to keep it
to myself would be to sell the source code. There was no buyer, however, and I've never thought
seriously about finding one, so I published the source. And documented it well, both internally
and in an essay about the code that macromedia later published on their site.

I also published the code because i would like to see the art of interactive audio for the web
develop, would like to see new forms of music arise on the web. and this is a matter both of
software development and artistic, conceptual evolution. i published an essay about that, too.

it would be great to see Mark Napier's source code. Java art looks like a pretty rare and
endangered bird at this point. Napier's useful, extensible code ideas (or techniques) involve
client-server communication. There still isn't much interesting client-server art. Very dry and
conceptual, for the most part, but his often isn't. If you can help others make interesting art
influenced by your techniques, not only do you further the art in a way you don't do by just
displaying the executable; you also help give the art a future. If the art doesn't have a
future, you probably don't either.

i have no worry about bad artists producing bad likenesses of the Nio project from the available
source code. that is simply sloppy homage. the *art* of the project runs mainly on mojo, and
that is hard to appropriate. the code is only really useful by understanding its general use.
and this requires enough brains and dedication that i'm not worried about what such people will
do with it.

I published this project a couple of years ago. So how has it panned out?

Well, most people don't give a damn about the code or the essay about the code, they just visit
Nio and enjoy it as art. And that's great. But I have had some feedback concerning the code and
the essay about the code. i get a few hits from macromedia having published the essay and it's
really the only longish essay on audio programming with Director, so far. and i have had e from
Music students doing their Masters degree or Doctorate and they have written about the code. But
you know I've only had one email from anyone who really sounded like they understood the code
and its general use. And this person is developing his own interactive audio work and said the
code and essay saved him a lot of time and helped him in his own thinking about it. I told him
it seems like I wrote the essay and published the code just for him.

He noted that the art of interactive audio for the Web is still not as developed as one might
have thought it would be at this point, a couple of years ago. I agree. It looks like it will be
a slower development than one might have thought. The tools are out there, but combining the
software dev with musical and graphical creativity is a leftbrainrightbrain challenge suited to
only a few people.

The more innovative, challenging, and extensible the technique, the more need there is to
publish the source, and the less cause there is to worry about it being misappropriated.


This archive was generated by a fusion of Pipermail 0.09 (Mailman edition) and MHonArc 2.6.8.