Add-Art: Sharing, Freedom, and Beer (essay from NetWorks)

The following essay appears as Chapter 16 in the book NetWorks: Case Studies in Web Art and Design edited by xtine burrough and published by Routledge. It tells the story of Add-Art and a post-mortem reflection about the project after we got it off the ground.

Note: This essay is in the Public Domain and has no copyright, and no rights reserved.

Add-Art: Sharing, Freedom, and Beer

by Steve Lambert, 2010

Before discussing Add-Art or “free and open source,” we should think about the concept of sharing. As a culture, we have been sharing since the beginning of civilization. Sharing code, especially “open-source” code, is only a recent form of cultural sharing.

We’re familiar with the image of scientists working in labs, researching, generating and testing hypotheses, then publishing their work in journals or otherwise presenting their work to the scientific community. As an artist, what I do is not so different from this image. I collect research constantly, I work in a studio, I experiment and develop concepts, and then publish my work in galleries, museums, and other media outlets. As an analogy, this method of researching and publishing extends to writers, performers, musicians, software developers, and anyone else who creates media.

Extending this analogy, repeating the research someone else has done is redundant. The goal is to make progress. Publishing research outcomes enables the work to be documented and thus built upon. Theories and techniques are built upon. Knowledge is built upon. Through this process scientific theories are established, art movements emerge and retreat, musical styles develop and are folded into new styles, software becomes more sophisticated, knowledge is collected, developed, and progress is made over generations. As creative people, we want to be a part of the creation of history and progression of culture. We want to be relevant.

This is why we share our research. “No one creates in a vacuum” is a fitting adage for researchers. We are products of the cultures we are exposed to, where ideas and themes merge and mix.

Mock-up demonstrating Add-Art on the New York Times website.

The cultures before us shared and the resulting developments traveled around the world. Take a moment to consider what has been gained by sharing: this is how all language developed, the written word, boats, gunpowder, weapons, poems, recipes, designs, and on and on. Everything we have has endured through sharing. For example, if I lived in North America in the year 800 CE and wanted to make a basket, someone in my village showed me how. If I, when making that basket, came up with a way to add an interesting pattern or a way for that basket to hold water, then I would share that in turn. In the year 900, that method would probably remain and be taught to the following generations in my village. In this way all the knowledge we have comes from sharing. The foundations of our society and culture are built on sharing.

As our culture has developed, so has technology and economic markets. In the past money changed hands when goods and services changed hands. But relatively recently in our history, our markets have become much more sophisticated and efficient as capital is more likely to move over virtual networks than in a physical marketplace. We live in a society of information, and so markets, especially in the United States, have attempted to capitalize on the transfer of information as well as goods and services.

Information is commodified through intellectual property and restrictive licenses like copyrights and patents, privatized education, proprietary software, and by reselling old information in new formats (LPs to CDs to MP3s, paper books resold as digital books, VHS to DVDs to BluRay discs, and so on) just to name a few ways.

Of course capital has not changed everything. Most of what we would call culture and society exist alongside but out of the reach of markets. Artists, musicians, writers, and educators still generally do not enter the field expecting to make an outrageous fortune. When it comes to friends and neighbors we continue to share with each other far more than we trade capital. Family, friends, favors, polite exchanges, and gifts are, thankfully, separate transactions from the market system. Additionally, a resistance to the capitalizing of shared information has emerged with new licenses that permit and encourage its transfer rather than lock-down and wall-off innovation.

Free Software

The Free Software Movement emerged in the early 1980s in response to (arguably misguided) efforts to withhold software program source code to increase profit, such as non-disclosure agreements and the patenting of software concepts so that they cannot be reverse engineered. Prior to this period software was shared fairly openly among researchers and early hackers. Money was made, but software was shared.

The founder of the Free Software Foundation, Richard Stallman, has an informal slogan to help clarify what free software means, “Free as in free speech, not free as in free beer.” He also created the Four Freedoms to further explain the guidelines of free software:

Freedom 0: You are free to run the program, for any purpose.
Freedom 1: You are free to study how the program works, and adapt it to your needs.
Freedom 2: You are free to redistribute copies so you can help your neighbor.
Freedom 3: You are free to improve the program, and release your improvements to the public so that the whole community benefits.

When we have these four freedoms with software, it becomes “Free Software.” Sounds pretty reasonable right?

Together the four software freedoms sit well. This structure has allowed for rapid innovation of popular free and open source programs like the GNU/Linux operating system, the Apache Web Server, the Firefox web browser, and mainstream web publishing software like WordPress. Note that the four freedoms do not mention money, sales, or profits. Free software can be sold. Many businesses offer training, support, and the customization of free software. We could even sell copies of the software, though anyone would be able to do the same. The four freedoms work in concert with business, innovation, and sharing, and they have worked, as a paradigm, for several decades.

By comparison, let us check software commonly used by artists, Adobe Photoshop, against these four freedoms:

Are we free to use Photoshop for any purpose? Sure, we can use Photoshop to make everything from a corporate presentation to pornography.
Are we free to study the program and adapt it to our needs? In one way, yes, we can get an Adobe Photoshop manual and learn how the program works, and we can customize the workspace and write Photoshop Actions to script the program and adapt it to our needs. But, these are relatively insignificant changes. The source code is not publicly available and we cannot adapt the software by changing the source code, so thereby Photoshop fails to meet this freedom.
Can we redistribute copies of Photoshop to help our neighbors? While that may be how some people obtain copies of the program, technically this is a violation of the user license, and therefore illegal. The third freedom is violated.
Can I make improvements to Photoshop and release, or even sell, the Photoshop “Steve Lambert Edition” for the benefit of Photoshop users? No, absolutely not. The fourth freedom is also violated.

Adobe’s model is profitable, but in a different way than free software. Adobe’s profit model is not based on support and customization, but on selling licenses of their software. Each license, that is, each copy of the software, costs several hundred dollars. This sales model interferes with the four software freedoms. Adobe’s model works for business. For innovation, one could argue it works as well – Adobe is a large company that creates quality products. They are certainly an industry leader. But we are not free to improve their work, we are not free to examine it, and we are not free to distribute it.

And what happens if Adobe dismantles, or, perhaps slightly more likely, if they stop supporting or releasing one of the programs they distribute? Their code remains inaccessible. Their work cannot be improved upon even after they are no longer interested in supporting it. In fact, this is how the current most popular blogging software started, by volunteer coders picking up on a nearly abandoned project called b2cafelog and turning it into WordPress. Had b2cafelog been licensed with a proprietary license, WordPress would likely not exist.

In the context of the importance of sharing, and how this applies to software, let’s turn our focus to Add-Art.

Add-Art

Add-Art is a Firefox add-on that replaces advertising on the Internet with art. When you visit a web page with Add-Art enabled, instead of seeing ads, you will see a selection of curated art images that change bi-weekly.

Add-Art is free software as in both “freedom” and “beer.” It also builds on earlier free works, primarily the Mozilla project, the Firefox web browser, XML, and the various ad-blocking add-ons that preceded it.

Because Mozilla Firefox is free and open source software, others are free to build on it by contributing core code or through extensions and add-ons (and creating Firefox software offshoots like CELTX). Add-ons are smaller, sub-programs that extend Firefox’s functionality beyond what it is capable of doing “out of the box.” An extension might display a small weather forecast in the bottom corner of the browser, or enable you to save your bookmarks to an online social bookmarking service. There are thousands of add-ons available, and the most popular by far is AdBlock Plus.

Add-Art’s lineage stems directly from AdBlock Plus, an add-on that eliminates advertising from the Internet. It is, at the time of this writing, the most downloaded extension for Firefox and has been nearly since the time it was introduced. When users discover they have a choice of whether or not to look at ads on the Internet, many choose not to. As a result Adblock Plus was downloaded over 87 millions times between January 2006 and July 2010 and in July 2010 had over 10 million active daily users.

I am one of those users. When I saw that Adblock Plus simply took ads off the page and replaced it with blank space I was…delighted. And it did not take long before I thought,

“Why blank space? Why not replace the ads with something more interesting?”

Not knowing how to code such a thing, I sent an email to friends and asked “Would it be possible to replace the blank space created by Adblock Plus with art images? And if so, would you help me”And by help, I meant, do it for me. They all responded fairly quickly, “yes, technically it’s possible and no, I will not help you.”

The plan was put on hold.

Around 2 years later I was a new fellow in the OpenLab at the Eyebeam Art and Technology Center in New York City. Eyebeam has a strong open source and collaborative tradition and after a few weeks I remembered my idea to replace ads with art using Adblock Plus. I sent an email to the other fellows and resident artists, “Would it be possible to replace the blank space created by Adblock Plus with art images? And if so, would you help me”A few minutes later I got a reply from Evan Harper, “Can you give me a week?”

Evan Harper created the first prototype of Add-Art. Our prototype was cobbled together and it replaced ads with images of bald eagles and American flags, suggesting, in a funny way, my excitement for this particular type of freedom.

We used this proof of concept to apply for a Rhizome Commission, which involved creating a web page so Rhizome members could vote on submissions.7 Naively, I did not foresee that Rhizome members would blog about the project and cause a stir before we were even off the ground. This resulted in an article in the New York Times about the project.

This would have been a great opportunity to recruit interested programmers and volunteers, but I was so caught off-guard that I did not think about using this attention to better the project.

The proposal was popular among the Rhizome Community and the jurors, which resulted in the project winning the 5,000 dollar commission. The attention online and in the press interested a supporter, co-founder of WoosterCollective.com, Marc Schiller. The combined effect was a small budget to get us started with the project.

My next step was to communicate with Wladimir Palant, creator of Adblock Plus. Palant had also built on (then rewrote) the work of those who came before him; programmers Henrik Aasted Sorensen, a person known only as “rue,” and Michael McDonald. The slowly growing Add-Art team was beginning to build on this work. Because Adblock Plus code is licensed under Mozilla Public License we could freely modify, adapt, and release a modified version rather than write a new ad blocker from scratch.

Knowing the Adblock Plus code well, Wladimir Palant was kind enough to write the first version of Add-Art for us. Though he did not ask for it (and I am not sure he wanted it), we sent him some of our grant money to compensate him and thank him for his work. Without being able to build on Palant’s work, and without his decision to use an open license, Add-Art would have been much more difficult to create.

With a solid foundation of work generated by those who came before Add-Art, I started inviting new people to work on the project.

At first, my plan was to make the project perfect (in terms of its utility) from the beginning. I was striving to create an automated system that needed as little human intervention as possible – as I wanted to create the project, but not administer the project long term. I researched content management systems (CMS) which would enable curators to select images that could be automatically loaded into Add-Art without writing additional code. I worked with programmer Michelle Kempner on writing a custom content management system that would do a majority of the management and administrative work of organizing the bi-weekly shows. After some time, we abandoned the custom CMS route, researched more, and started using existing code. This went on for a few months and, after much planning and researching, and several false starts, I realized I hadn’t accomplished much at all.

Shows promoted on the Add-Art website

I had to change my strategy. While at first counter-intuitive, setting the standard at the level of perfection meant it was difficult to make progress on the code. I had forgotten one of the philosophies of free and open source coding, “release early and often.” This means, publish something that works to the world, let people use it, discover failures, then release frequent improvements based on user feedback. And if you’re lucky, those users will submit improvements, as well.

My new strategy was to use the grant money to pay for pizza and beer. I contacted programmer friends with different skill sets and invited them to weekly meet ups at Eyebeam to figure out the Add-Art code together and create a new release. The pizza and beer helped make the work and the meet up more attractive.

Unfortunately, no one in the world had the experience of creating a Firefox extension that replaces ads on the Internet with art whom we could ask questions. Sitting around a table with our pizza, beer, and laptops, we were venturing into uncharted territory, but the surrounding area was mapped. We slowly parsed through documentation on creating extensions on the Mozilla.org site, we entered IRC (Internet Relay Chats) with other developers, we sent emails, and we hacked away at our code creating failure after failure to figure out what worked.

Working in a group allowed us to share ideas and collectively solve problems that were new to all of us. Eventually we had something that was “good enough” and we published our first version: 0.4.2. It was missing features: it required a little too much work on behalf of the user, it did not have an interface, it did not replace every ad that had been blocked with art. But it worked. It replaced most ads with art. And nothing crashed.

The “release early and often” strategy worked. By cutting features and lowering our ambitions from “ideal” to “working” we made the task more manageable and surely enough, finally made significant progress toward our goal. The software was by no means perfect, but we were making much more progress toward something that could live up to the standards I originally held. Over the coming weeks and months our pizza and beer group built on the codebase adding features and simplifying the user experience.

Add-Art’s shows change every two weeks and, in the beginning, changing the content was a tedious task involving the command line, encryption keys, things I had never heard of before like “md5 and sha1 security hashes,” and about four hours of repetitive and frustrating work – because it never worked the first time. This hassle was a motivating factor to improve our code. At each step we examined problems and evaluated as a group what was the most urgent one or two issues to tackle together. Our code was published very early on and we used an online wiki to document our progress as well as a web based “ticket system” to keep track of the bugs or issues that needed to be fixed. This enabled those wanting to join our efforts to learn our process quickly and choose a ticket to fix.

art replaces ads on the salon.com website

In January 2008 we began to make steady progress on Add-Art and in May I gave a public presentation of the project at The New Museum in New York City. I remember finishing some final touches the day of the presentation and I had my head so buried in the logistics and technicalities of the project for so long, I had not thought about the conceptual and cultural aspect for months. At the first public presentation of the project, not surprisingly, no one cared much about the technical accomplishment. They all had questions about “what it means for the web” and clarifications on the legal issues (there are none – you are free to manipulate data on your own computer). In this way, our release early and often approach worked again. No one cared that Add-Art wasn’t technically perfect (besides us). The project worked, the technical guts were more or less invisible to most, and the cultural and conceptual aspects took the limelight.

At the time of this writing Add-Art has replaced ads with art for an average of 15 to 20 thousand users every day for the past two years. Over sixty different shows have been curated of all kinds of work from photography, to drawing, to digital art, animation, and performance documentation. It is an ongoing process and there are still things that could be improved, but it works, and it is free, and you can get it at http://add-art.org.

Conclusions

If there are two major lessons here, I would sum them up like this:

1. The importance of open licenses and sharing

No one person created this project. And no one person should create a project of this magnitude. We were able to, as Sir Isaac Newton, and later Linus Torvalds of the GNU/Linux kernel, put it “hoist ourselves up on the shoulders of giants.” Open licenses used by those who came before us enabled us to focus on the work we needed to do instead of inefficiently rebuilding software that already existed.

And it does not end with Add-Art. Since Add-Art is licensed with a GPLv3 license, anyone is able to build on our work and fix issues (there are some remaining from our earliest iterations), or create something new in the future that we could never imagine today.

2. Working iteratively or “releasing early and often”

If you wait to release a free and open source project until it is “just right,” you risk getting lost in your own process and are missing out on user contributions. Working in iterations and releasing beta versions makes the project more effective and conducive to more obtainable production goals. It also enables real world feedback and contributions from users.

Outcomes: It’s Not All Great

There is always more that can be done. Other valuable lessons include ongoing challenges I face in supporting and maintaining this project.

One constant issue with free and open source software is documentation. For instance, how can you communicate clearly to new developers the reasons for making the decisions you made in the past or how those resolutions were executed? Where does a new developer start working on the ongoing project? What does that sloppy code you wrote mean? It is important to realize there is an audience for your work outside your brain, so what might make sense to you probably makes no sense to a person viewing the project for the first time. Document your process, annotate your code, and be ready to answer questions.

Having done much of that, there is still a high barrier to involvement in Add-Art. Every combination of technology Add-Art uses (like javascript, XML, GIT, and so on) narrows the field of people who will be experienced with this particular combination of technologies. How can you help newcomers with code that is so particular to your project?

While working on our project, we found that the documentation of the Mozilla project and other code was often too dense to understand. As grateful as we were to those who came before for us, sometimes those who are brilliant at coding did not create the best documentation. I tried to make sure we did not make the same mistake for the next creative person who wants to use our code for a future project.

Another issue that plagues Add-Art is the lack of understanding of free and open source software. The art is selected by various curators. Curators give some assurance of intention and quality of the images displayed. Curators are selected by past curators. This is done so no one person has control over what is shown on Add-Art. Nonetheless, not everyone likes the art. In fact for nearly every show we have ever produced, someone does not like the art. They will often make a comment in our forums, which is why we built the forums. I never expected every viewer would like every exhibit all of the time. But when I do not like a museum show, I do not complain to the director and demand a change. Like most museum-goers, I realize that the show is not for me. Ocassionally I change my mind over time – a piece might grow on me. Learning that I do not like some art works helps me to understand why I favor others. I consider a “bad show” (in my opinion) to be a learning experience that I was open to having when I walked into the museum.

The problem is people mistake the project for a product. A product is usually accompanied by customer service. Behaving as if one does not like a product, if someone does not like the art on Add-Art, they may complain, expecting “customer service” to fix it. However, it does not work according to the “customer service” paradigm. The developers of free software projects do not respond in the same way to complaints. They are more likely to say, “Yeah, I know that is a problem, why not get down here and help us fix it?”

This extends to requesting (or sometimes demanding) top down fixes (i.e. “make an Add-Art for Safari/Chrome/fill-in-the-blank!”) instead of submitting code, hiring someone if they do not have the skills, or otherwise taking ownership and initiating the new project or modification themselves.

Worse, people who perceive free and open source projects as products are used to insisting on satisfaction. I can relate. When I pay for something and I am disappointed in how it worked, I complain and sometimes demand a satisfactory outcome or threaten to take my business elsewhere. With a free software project, these threats are rather meaningless.

But can we really blame anyone for this confusion of product for project? Commercial software and the capitalist paradigm have a decades long head start in shaping the way people think about consuming versus participating in and creating the software they use.

Free software is not a product, it is a gift. There is no customer service because there are no customers. Anyone can take charge and build on the code to fix a problem. In fact, the people making the software already have. And you can, too.