Talk on FLOSS+Art at a workshop on Open Source Urban Planning and Architecture, at Plan09, Cologne.

I’ve been invited to give a talk at a workshop on Open Source Urban Planning and Architecture. I was very intrigued by the notion of applying the term “open source” to these two domains, that seem to have nothing to do with software development. I know very little about urban planning and architecture, and have been asked to talk about my own philosophies regarding FLOSS and art. I’ve prepared a presentation of hello process! and puredyne as examples of how FLOSS is used in an art context (software art and creative tool development), and prepared some questions for a discussion with the participants of the workshop. The text below is the result (work in progress!).

My background

I am a (software) artist (and occasional author, editor, developer and curator), part of international digital arts collective GOTO10. I am editor of FLOSS+Art, a collection of articles on the relation between FLOSS and art/design practice, and the digital artists handbook, a series of articles introducing FLOSS tools and related methods and concepts to artists. I am interested in computers as a stage or theatre, life-like processes on networks (viral), distributed and collaborative processes in both software art development as software art itself, the influence of the use of FLOSS on artistic practice, and last but not least, copyleft and FLOSS as the only serious alternative to boredom and archaic (economic) models in the art world.

hello process! Black versus white box paradox

hello process! (in collaboration with Aymeric Mansoux) is an installation consisting of a computer, a printer and a wall covered in prints. It shows a machine doing what it does best; deleting, copying and moving blocks of data. All code written for the project is licensed GPL (and can be found here). A black versus white box paradox: the computer is a black box with its processes hidden to the outside, GPL licensed code shows it all. Hello process! gives very minimalistic output via the prints, showing the evolution of a world consisting of 128 blocks that can be filled with small programs. Each program has a strategy to conquer other blocks and have names that match their behavior (boobytrap, anti-eraser, swap-master to name a few). It presents the spectator with a puzzle trying to decode what is happening inside the machine, and with maps of past evolutions. Hello process! is a reply to the ‘hello world!’ program that most people write when learning a new programming language.

hello process! is designed in a bottom-up fashion: a simple system based on its underlying rules not on end results. It is part of “continuous design” art project metabiosis, and is an example of how FLOSS gives artists increased control over their tools and greater freedom in their creation process. We needed access to all levels of the operating system, and build this custom environment using multiple compatible open source tools (GNU/Linux operating system, shell script, Gforth, C). hello process! is collaboratively developed using SVN to manage the code. Making the code public is an intricate part of the project, it is part of the concept and puts it in a wider cultural context of opening source code as another layer of interpretation of software art.

Cowboy coding is good :) puredyne

Puredyne is cowboy coding in action. The community of developers is small and unmanaged. Cowboy coding is a derogatory term but in my opinion for all the wrong reasons. In small scale projects a completely autonomous and unmanaged developer team can move mountains. All puredyne developers are also users and users can (and sometimes do) develop. That is why it works. If something is broken, it will be fixed because the developers themselves need the tool to work. Puredyne started from a real need, not a supposed one. This is typical of open source projects, if you cannot get the developers motivated, then there is no project. Motivation is a big factor in the success or failure of FLOSS projects. Motivation out of personal interest is also the reason why the best open source projects are tools that are needed by the developers themselves (server tools for instance).

Open source outside of the software domain

I want to mention www.openorg.nl as an example of how the term open source is sometimes also successfully applied outside of the domain of software development. Openorg is a wiki where WORM, a Rotterdam based cultural organisation, made available all the paperwork they needed to set up a cultural organisation in the Netherlands. You can simply copy/paste your own organisation. They also invite other organisations to contribute their paperwork. “The wheel is already invented”, “download now! A professional organisation in a split second”, “this paper mountain is there specially for you”, … On a more light note, there is also the free beer project, where you can brew the same beer, branch or fork it. Here the term open source can be used quite literally because both projects replaced code to instruct a computer what to do with scripts of what a human is supposed to do, and made this code publicly available.

Free/Libre Open Source what?

So here starts the question part of my contribution to the workshop.

Q: Can you take the term ‘open source’ out of its software development context and apply it to other fields?

It can be an inspiring concept, but definitions need to be clear if we want to avoid typical transdisciplinary confusion of using the same vocabulary but different definitions.

On paper FLOSS is software with its source code available, that grants the Freedom to:

1. run the program for any purpose.
2. study how the program works, and change it to make it do what you wish.
3. redistribute copies so you can help your neighbour.
4. improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

In practice FLOSS is not a uniform phenomenon. Open source software development is a complex process (from code management to project management) and a very diverse one. It can range from a 1 person art project to the +- 1000 contributors to the Linux kernel, with management varying from truly non-hierarchical bottom-up collaborative and collective authorship to the “benevolent dictatorship” of Linus Torvalds.

Using the term outside of software development often refers to:

• decentralized development
• user generated content and technology
• concurrent input of different agendas, approaches and priorities
• constant feedback and peer review

These are all aspects of open source software development, but the main characteristic is making the source code of a project available, and strange enough, this is something that most projects using the term “open source” are missing. When looking into the topic of this workshop I ran into a project called “open source house”, that had a repository of files related to the design of the house available. All that was there were pdf files of plans of the house, and even those were subject to terms of use that blocked the use of the plans for any other purpose than to build that very project on that very location. An open source house should at least publish their files and plans in their original (and of course open) format, and preferably licensed copyleft. The term “open source” is becoming a fashionable add-on to projects or even professions, with its original meaning lost, just like the word “open” has been part of many new project names that are often very closed in nature.

Skill

According to Erick Villagomez from re:place magazine, urban planning is losing relevance in today’s rapidly changing society. He marks open source planning as the solution to overcome the slow processes of top-down and centralized planning. According to him a radical transformation of the profession is needed (The future of urban planning is open source, April 2009). How to bypass bureaucracy and fulfil real local needs…

The idea of “prosumers”, as in consumers that produce, is seen as antidote to top-down design. Users will generate content and shape their (software) environment. In FLOSS projects the border between expert/developer and user only occasionally blurs. In most cases the border simply is less thick, users can make requests more easily and developers get more direct feedback from their users. Developers usually listen carefully to the community of users, because without them the project dies. Users are more proactive in their involvement with software user communities because help desks (and often help files) are not available and people can only rely on others in forums or mailinglists to get support when facing problems. Users are able to hack, change and redistribute, but only very few can. It requires skill that is not yet common, and would take too much time investment for the general audience of today to learn (the children are the future).

Q: How does open source urban planning and architecture deal with this skill difference between expert and layperson?

Decentralisation

That depends on what open source planning actually is (I haven’t found a single clear definition yet). Based on what Villagomez writes, it seems to be involving emergence (for more on emergence in cities: Steven Johnson – Emergence: The Connected Lives of Ants, Brains, Cities, and Software). The Open Source Planning blog mentions collective intelligence, but also open data and a common tool set for urban planners, in order to rapidly respond to climate change. I think open data and a common (FLOSS) toolset are the basis, but what about “using” emergence in urban planning…

Q: How does planning enter decentralised and self-organised processes?

You cannot “organise” self-organisation, so is open source urban planning about increasing or decreasing control? Or simply about applying the control at another (lower) level, trying to initiate or spark self-organisation?

Above is a picture of Mitchel Resnick’s book “Turtles, Termites, and Traffic Jams: Explorations in massively parallel microworlds”. In the book he describes all kinds of systems that are organised in a decentralised way (without organisers, planners or coordinators), like bird flocks, termite colonies and traffic jams. Resnick stresses we are all conditioned to think in centralised ways, but shows how valuable investigating the opposite approach is through numerous examples. This book is dated, but still points out some interesting concepts that can also be applied in urban planning and architecture. Be it through looking at ways to start decentralised processes (writing manuals…) but also researching existing processes with this mindset.

Giving up control

Open Source Software development is not without centralised control. Bigger FLOSS projects have management and strict planning procedures for every part of the project. For instance, at the most basic level, most projects have a roadmap. And many tools exist to aid the development process (see picture with logos of some popular open source software development tools for project management, bug-tracking and source code management). Even if a project is totally open, as in: here is a discussion forum, an empty code repository, feel free to initiate something, the project will most likely follow self-organisation rules until it grows to the point where some form of management is needed.

In a FLOSS project decentralisation happens only up to a certain level. For instance patches can be submitted by the community, but it’s up to the patch reviewer or project leader, or maintainer to test it and decide to apply it “as is”, partly, or not at all. There are unpredictable parts, but they never
enter the project without going through some form of decision making process. A fork and the decision of a community of users to either stay with the original or move to the fork is the most drastic and uncontrollable possible event in a projects history.

If Open Source Urban Planning is about self organisation and emergence, it will inevitably be about giving up a certain amount of control. Although similar strategies can be used as in FLOSS development, naturally a copy of this process is not possible when working with people and places instead of code. You can’t fork an existing neighbourhood or park (you could fork the design though).

Q: Bottom-up design of complex processes involves giving up control, is this possible an urban planning context?

Responsibility

FLOSS projects take NO warranty, the user is responsible. There is a growing debate (fed by lawsuits and lawyers) on the notion of liability in the open source community.

GPL waranty:

“THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”

Q: When projects are developed by a large number of people, without legal binding factor like a company, where does responsibility lie? How would open source urban planning handle liability?

Intellectual property in architecture and urban planning

In architecture, there are “open houses” that use the term “open source” for the way they have been designed. But they are not necessarily copyleft (I haven’t found any), as in free for others to use, modify and redistribute. It is not hard to imagine how copyleft architectural designs could function, generating designs that can be copied, improved or modified by others, generating designs that solve certain global problems like energy efficiency, adjust them to specific climates or with local building materials, etc.

In an art and software development context copyright and patent law are usually not a problem as long as you’re not competing with big companies, and choose a strong copyleft license from the start of the project. There are FLOSS projects that have been shut down by lawyers over copyright and patent disputes. Submarine patent (patent issued but not published) are the biggest problem. In the Theora project for instance, which is blocked from inclusion in for instance Nokia systems because Nokia is afraid there are submarine patents present in the Theora codec). Copyright and patent work against progress by blocking developers in their freedom to experiment and forcing many to “reinvent the wheel”.

Q: Is copyleft a current practice in urban planning and architecture? Is there a need for a special architectural or urban planning copyleft license?