SPACA
· 17 min read

There Isn't Enough Small Team Art in the World, So I Open Sourced a Legal Agreement

  1. Ian Carroll's Headshot
    Ian Carroll

    Chief Technical Director

  2. Steve Hogan's Headshot
    Steve Hogan

    Photographer

A person demonstrates working software, and how its put together [photo credit: Ray Hightower]
A person demonstrates working software, and how its put together [photo credit: Ray Hightower]

Maybe you’re not seeing the connection.
Three years ago, I wouldn’t have either.
I promise to explain myself, but in order to do that I’m going to have to share my story.

My name is Ian Carroll and I take a lot of risks others might not.
In my 20’s, this habit got me in a number of sticky situations.
Now that I’m older, I’ve learned to be more careful…
so that I can take even bigger risks.

Let me say right at the top here, that I am not a lawyer. I’m proud to have taught myself software engineering and have been successfully working as an engineer for half a decade, but I am never trying that with Law. The risks are too high. It’s probably not even legal – I don’t know – I’m not a lawyer!! As such, everything I say here is philosophical food for thought. It is not Legal Advice.

Done with my yapping? Tap here to go to the agreement's gitlab repo.

Now that that’s out of the way, I have a new problem. There are going to be people with very different backgrounds reading this article. Artists, Engineers, maybe even a Lawyer or two, who knows. These fields have extremely different worldviews, assumptions, and jargon. Which means I am going to need to explain all of that jargon so that everyone is on the same page. Expect basics to be explained. It’s not to patronize you, it’s for a different professional who doesn’t know your shorthand.

Ok, now I can actually begin to explain what I mean when I say "There Isn't Enough Small Team Art in the World, So I Open Sourced a Legal Agreement":

It all started in 2019. Back then, I was part of a thriving theatrical genre-based narrative improv community. I was also working as a software engineer and consultant mentoring apprentices and coaching teams on Agile and Extreme Programming practices using open source software.

Theatrical Genre-Based Narrative Improv:

Raishel Wasserman delivers a made-up soliloquy as part of a cast of six improvisers in <em>Shakespeare Improvised</em>, Directed by Brian Lohmann in Impro Studio&rsquo;s black box theatre, early 2020
Raishel Wasserman delivers a made-up soliloquy as part of a cast of six improvisers in Shakespeare Improvised, Directed by Brian Lohmann in Impro Studio’s black box theatre, early 2020

So, if you know “Whose Line is it Anyway”, it’s not that. Maybe it started like that, but this kind of improv takes a team, “ensemble” as we call them, of usually around 8 people, rarely less than 4, never more than 12 and have them get up on stage and perform an entire play without a script. That much is called “Narrative Improv”. We’d take it further by relying upon acting, directing, and writing techniques as we improvise. That much can be called “Theatrical Narrative Improv”. Then we’d add in a genre, author or playwright, Like Horror, Jane Austen, or Tenessee Williams and we’d do serious research and dramaturgy to get into that particular genre’s tropes, aesthetics, themes, and worldview. We’d adapt all that into our improvised show (still with no script and no pre-arranged agreements beyond understanding the genre) to create a “Theatrical Genre-Based Narrative Improv” that looks and feels like the play William Shakespeare never wrote, made up on the spot in realtime by 8 separate minds. It was magic, and it still is.

Technical Improvisers: We’d even have other improvisers operating the lights and sound for improvised lighting effects, underscoring, gunshots, you name it. Those artists are called “Technical Improvisers”.

All of that is art. And it’s not made by one person. It’s made by a small team of equals. So improv like this is an example of “Small Team Art”, and there isn’t enough of it in the world.

Agile Software and Extreme Programming:

A 3D-printed chess set sits in the foreground while a software developer&rsquo;s station with two monitors, a coffee mug, and an office chair loom behind it.<br>
[photo credit: Ian Carroll]
A 3D-printed chess set sits in the foreground while a software developer’s station with two monitors, a coffee mug, and an office chair loom behind it.
[photo credit: Ian Carroll]

[ Dramatization of history: ] Sometime in the late nineties, some software developers working in a standard corporate development process looked up past the project on their monitors. After two years of effort, it was failing and they knew it would fail within 3 weeks of starting. Many projects like it had failed too. “This sucks,” they said, “This is the wrong way to write software!” So they made some principles.

  1. Interacting with people is better than following a process
  2. Showing working examples is better than reams of documentation
  3. Collaborating is better than negotiating contracts
  4. Responding to change is better than following a plan

This boils down even further to allowing for a team to organize itself rather than be managed from outside. And it includes the idea of continuous improvement. That team should be empowered and expected to improve itself and its effectiveness. Extreme Programming takes it further with the use of pair programming (two engineers working on a single problem on a single computer) and other ways of breaking down “knowledge silos”.

About knowledge silos: There’s a tendency in software to focus on your own tasks so hard that you have no idea how the rest of the software works, and the rest of the team has no idea what goes on with your piece of the puzzle either. Maybe this isn’t an immediate problem, but what if you want to take a vacation? or life happens? maybe a pandemic? You don’t want knowledge silos, then.

Extreme Programming includes practices designed to share expertise and opportunities for the team to reflect and improve upon their work together. So they can learn quicker, and even take a vacation every once in a while.

This kind of development practice requires strong trusting relationships, because it doesn’t rely on a management-heavy chain of command to be effective. Far from it. Command-and-control is very much less effective for writing software than allowing a team who already has their hands on the work to self-organize, self-correct and self-optimize. Some argue that with a strong enough whip-hand, all this Agile stuff doesn’t matter, but I’m interested in having fun when I create art, be it software or improv.

Open Source Software: It was about this same time that Open Source Software became a thing. Before Open Source, any software written was treated as writing, and was subject to copyright law. That measn if someone wrote the code for “the button” that a browser uses, that button would be copyright the the software developer’s property (or more likely the-company-the-developer-worked-for’s property). If we stuck with only that, software would be prohibitively expensive and difficult to pay for. Any given app today uses hundreds of dependencies, software written by other developers or companies, in order to function. Open Source simply says, “I own the copyright and that gives me the authority to grant anyone at all completely free use of it. Use it, change it, sell it, I don’t care, just don’t sue me. I don’t guarantee it even works.” This is basically what an MIT License says. Bill Gates at Microsoft famously hated it. He said it was eroding his labors. Poor developers like him should be paid for their work. Richard Stallman had another take. He said free software was not immoral. It was “free, as in free speech; not free, as in free beer”. I side with Stallman on this one.

Meanwhile, back in 2019…

An old skateboarder shows his longboarding techniques at Venice Beach<br>
[photo credit: Steve Hogan]
An old skateboarder shows his longboarding techniques at Venice Beach
[photo credit: Steve Hogan]

Impro Theatre decided to run an experiment. Could we take our stage show, “Twilight Zone Unscripted”, and stream it on Twitch as a three-camera improvised TV Show? Geek & Sundry was successfully streaming on Twitch, and several community members were involved there, too. They were inspired, and had been pitching the concept of live streaming improv for some time. In 2019 it happened.

We got together a team of improvisers (not camera operators) to crew the cameras. I was on that crew because of my problem-solving skills, willingness to volunteer, and a lot of organizational ability from agile software development. every improviser on that team had been a technical improviser too. The crew would capture the performance from the actors, who were all experienced improvisers from the main company or the lab ensemble.

The studio needed to be ready for traditional classes and free of camera gear when we weren’t using it, so the crew set up and tore down all the equipment every show.

We created 60 stories over half a year. And our most-watched show had about 60 live viewers. If the theatre got any money from it, Twitch got the lion’s share. And us, we were all just enthusiastic volunteers excited to be a part of something groundbreaking. Many of those shows were amazing. They were funny, dramatic, and creative. They were art, in essence. I no longer have access to the recordings, I’m not sure if they survived.

A Remote Satellite Dome in the Arctic  [photo credit: Steve Hogan]
A Remote Satellite Dome in the Arctic [photo credit: Steve Hogan]

As great as it felt to be a part of that, it also felt terrible. We were looking for models to follow in organizing our TV studio, and so we followed the default Hollywood movie and tv industry standards. The trouble is those standards directly conflict with the spirit of improv. Studio models are about establishing artistic control, all the way down to who you may talk to and who you may not. It is not a free and open collaboration. It is one person, or a small team (not my kind of small team), who has a vision, paying everyone else to execute that vision. Top-down. Command-and-control. It is designed to optimize accepting direction at the cost of restricting improvisation. It is also exactly the opposite of an Agile approach to teamwork.

Having another group of improvisers who were the only ones allowed on screen, who also didn’t help with setup or teardown, made me feel lesser. Even with all the fun I was having knowing the technical details of the equipment, and problem-solving to ensure it all worked reliably, the separation between myself and the talent made me feel like my expertise was a mark against me. I was still very happy to be involved, and no improviser there ever personally made me feel lesser. I know and like all of them and they know and like me. It was the organizational structure of the typical Hollywood studio that was wrong for us.

I was thinking about a better approach to all of that when the pandemic hit and the theatre was forced to close. I was faced with a choice. I could drop all of my artistic pursuits “for now” and hope that maybe they’d still be there later, or I could take a huge risk. I could go all-in and apply my entire being to supporting the theatre and the people I had come to call friends. I’ve mentioned my default behavior is to take risks.

I applied myself to solving the technical problems of streaming with Zoom and OBS, shared those solutions, created a facebook group to allow others to share, and started Squirrelington Studios so that when we came back, we were ready.

As we all moved to Zoom, unease ramped up. I was doing everything from my room; Zoom for work, Zoom for improv classes, Zoom to watch shows, Zoom to talk to friends and family. My life was one continuous locked-down up-tilted wide-angle medium shot. Nevertheless, I continued to pour effort into helping the theatre, and this long-shot of a Studio when we got back. My work life suffered because of my focus on the Studio. Also my life suffered, but that was just the pandemic. I don’t do well without other people around me.

Many very talented friends left. Some formed their own troupes, some started new projects and ventures, others simply burnt out. The stress from the pandemic made every negative aspect of the theatre more apparent and extreme.

But amidst all that gross junk, I started reflecting on the principles I believed in. Open Source. Self-Organizing Teams. Agile Teamwork. Improv where there is no one calling the shots; where we share our stories together to make something no one can predict. I thought about what had stopped shows both before and during the pandemic.

Why are shows made by small theatres, businesses and teams of impassioned artists so hard to come by? The world seems filled instead with major studio products, or solo acts on social media. What would allow more shows to get made and shared? What would provide money for the artists who make those shows so they could make even more shows?

A photographer lowers himself to take a pictures of a very stoney model (because that model is a literal statue on a pedestal made of rock) [photo credit: Steve Hogan]
A photographer lowers himself to take a pictures of a very stoney model (because that model is a literal statue on a pedestal made of rock) [photo credit: Steve Hogan]

One major obstacle is the way we organize. The way a major studio organizes itself can’t be used by small teams. It’s designed to achieve opposite conditions to create art, ones that will destroy a small group of improvisers.

We can’t just wing it and have no organization scheme, either – well, we can, but we run the serious risk of going the way of so many failed garage bands. Life happens. Or someone gets upset and ruins an otherwise good thing. Without some kind of working agreement, there just isn’t the right structure and safeties in place to keep everyone together happily making art.

And social media is designed for the individual, not the team. Social media profiles are self-centered by their very nature. And social media posts are just broadcasts limited to the scope of people who subscribe to you. That’s not collaboration, let alone friendship. Without any supplement in-person contact, social media becomes isolation masquerading as community.

So if we want more community, more small team art in the world, we’ll have to combat the influences of major studios, and social media. Winging it won’t do for long, either. All those approaches will undermine us even as they appear to support us. We need our own self-organized way of working together.

Even the concept of intellectual property is a stumbling block. I have archives filled with shows that can’t be shared because there was a song that had a copyright. Or some aspect of intellectual property was violated. In many cases, that intellectual property was so influential to entire generations of people that failing to reference it would have marred the art.

The intellectual property of large media companies is so ubiquitous that they have become integral to our lived experiences. That means those companies own substantial chunks of our own memories. Under intellectual property law, they can silence us when our lived experiences intersect with their intellectual property. Intellectual property rights are too-often used to suppress the free expression of small arts.

Creative Commons licensing tries to Open Source the arts, but there are issues. Creative Commons applied without careful thought will give gifts to the rich (the major Studios) from the poor (the artists). Those artists still need money in order to continue creating art.

Unfortunately, Creative Commons is not doing for the arts what Open Source did for software because companies pay software developers. They don’t pay artists. Otherwise we should be seeing an artistic renaissance. Where’s that renaissance? There’s only a couple streaming media giants. If Creative Commons was supposed to change that, it has failed, so far.

What we need is a new way to think about collaboration. We need an a Creative Commons localized to friends only … or localcollaborators.

All Collaborators would have the rights to the group’s intellectual property so they could share and even sell freely. "Think free speech, not free beer." No one would be allowed to stop other collaborators from sharing the art for petty reasons, but there would be stops allowed for quality, so that a collaborator couldn’t just churn out crap with everyone else’s name on it.

Provisions would be made for equal sharing of any revenue generated, regardless of the collaborators that happen to be selling. Every collaborator comes at their own risk and receives a share of the revenue. Their share is determined by a list of 17 different contribution types they could be credited for. This encourages collaborators to take on more than one role, and learn to be independent.

And even if something went wrong, every piece of work would be under its own isolated agreement. If someone fools you once, that one art piece may be ruined. But you don’t have to invite them to sign the next one.

That encourages teamwork and helps everyone feel equally respected, regardless of their financial, marketing, or merchandising prowess. If collaborators feel respected, they’ll stick together instead of breaking up. That means more teams would join up, and less would break up. It was at this point that I thought I might have a proposal for having more small team art in the world. I needed to write all this down.

A Union Master Sergeant on horseback with a saber rides forth reenacting the battle of Gettysburg<br>
[photo credit: Steve Hogan]
A Union Master Sergeant on horseback with a saber rides forth reenacting the battle of Gettysburg
[photo credit: Steve Hogan]

So I made this Collaboration Agreement that defined all of the rights and responsibilities of a small self-organizing agile improv team of artist-technicians, collaborators. I considered all of the theatres I had been a part of and built in ways that they could be included, too. I considered how it could support new playwrights and writers. I considered how it could support a Cinematographer with an idea, or any mix of planned and improvising artists at all. I rewrote it to remove myself from the equation so that anyone, anywhere could use it.

I wanted to make sure that there was a firm, but flexible working agreement in place that accounted for individual responsibilities, emergency preparedness, physical and psychological safety. The working agreement is highly structured in certain ways so that it can be completely unstructured where it counts. The collaborators need to be free to experiment. It employs the latest innovations in theatrical ensemble safety - agreements that before were assumed but too-often disregarded. It employs the very best practices from Agile Teamwork, using models of open collaboration and self-organization. I know of no other agreement that includes a retrospective and an andon cord in the body of the agreement. This one does.

It also builds on what I’ve learned from my earlier experiences. For instance, everyone should help with setup and teardown. Otherwise we’re not in this together. If you don’t know how to set up or teardown, learn. The agreement even requires you to learn. Someone knows, and will help. The agreement is designed to encourage trying new fields and playing multiple roles. There should be no division between art and tech. Art uses technology, even if that technology is a paintbrush. Paint brushes are not naturally occuring. Neither are cameras. They are an artist’s tool. And every collaborator is an artist, regardless of their isolated expertise. The agreement includes provisions for mentoring and coaching for the purpose of increasing each collaborator’s artistry and independence.

It also defines how we will support each other as artists and how we will engage with audiences to create a self-fueling fire of positivity and empathy.

But is all that really needed for a collaboration agreement? Would anyone actually sign it? I don’t know. My entertainment lawyer told me it’s not how he would have worded it. But it is still, in fact, a contract.

It is not a perfect agreement. It can use more eyes and more thought on it. But it’s a solid foundation for the kind of collaboration a major studio would never do. And one that will help make sure there’s plenty of small team art in the world.

Since I’m coming from the world of open source software, and I wanted the community’s input, I decided to open source this legal agreement, which does way more (and way less) than what most legal agreements would do. The legal agreement comes with an open source license.

You can suggest changes to improve it. I highly encourage that!!
You can copy and modify the clauses, just for your use. I encourage that, too!
You can springboard off of this agreement and offer a new public version,
You can even sell it and keep the money for yourself… if you manage it.

The point is, I wanted to start a discussion around what art should be.
And how small teams coming together to create art should treat each other.
I hope this spurs some thoughts.

Tap here to look at the agreement's gitlab repo, yourself.

Who knows, maybe some team will really use it!
but I hope that team talks to their lawyers first… Did I mention I’m not a lawyer?

Two people (who are probably not lawyers) row a canoe together on a blue-green lake in an an expansive Canadian wilderness<br>
[photo credit: Steve Hogan]
Two people (who are probably not lawyers) row a canoe together on a blue-green lake in an an expansive Canadian wilderness
[photo credit: Steve Hogan]