← All updates
A lot of people have been wondering if Venue is just another website system like WordPress or Squarespace. It does share some similarities — i.e. you can use it to make a website — but our goals and methods are very different.
We’ve been active for many years as artists, organizers, and producers. We are actively involved in the arts community where mutual aid is at the forefront. We’ve seen a ton of things that could be better orchestrated, especially in situations where budgets are slim and different volunteers flow through regularly. We built Venue, first and foremost, because we needed it.
There are various solutions to these problems but each attacks one specific issue (and each comes with an individual price tag ballooning up costs for services). Many of these solutions fail to see the forest for the trees and that arts orgs are missing quality digital infrastructure for the data and systems they need to do their work.
Venue is this base infrastructure — a system for storing data, leveraging that data, and crucially, creating a commons of data, so information can be shared between organizations and artists. Event organisers are inputting the same event data into ticketing company websites, their own website, Instagram, internal docs, and many other places. On top of that, artists are sending through data (bios, photos, music) that then require individual input and editing with haphazard results. Keeping things up-to-date and the quality high takes a ton of extra time and labor on the part of everyone involved.
We want to push towards a better way of handling this.
The VenueCMS is a place to enter data once and then easily leverage it in multiple ways: your website, on Instagram, email broadcasts, in accounting, in your internal planning docs, in your ticketing system and across the fediverse.
Because we structure this data according to open standards, we also enable artists and organizations to access and contribute to a commons of event, location and artist information. Instead of endless emails about bio updates, tweaks, which photo to use, etc., an event organiser could simply pull that from the public commons and if the artist needs to tweak it they can. The organiser simply needs to pull the latest info or allow edits to come through automatically.
Let’s take archiving as an example. So much effort goes into trying to gather the information needed after an event has occurred. We need to make sure we know when something happened, who was involved, where it happened and what related media exists. Someone needs to go in and put all this info into a separate archiving system where it can, again, be out of sync with any updated information that might come through.
The rub is that this process already happened. Someone already entered all this information before the event occurred and when they did it, they were extra careful to be sure that all the details were correct because if they weren’t people would show up at the wrong place, or the wrong time, or expecting the wrong artists, etc. The moment of setting up the event and getting people to come to an event is the single most motivated moment where organizers and artists come together to be sure that all the data for the event is correct. Because of this, that point of data entry is the most valuable for the archive, for marketing, and for reporting. This is where our CMS shines. We’ve designed this data entry for purpose and minimum friction.
Getting that data in accurately and in a well-defined format means we can now use it directly in the archive. We’re working on providing ways to attach archival information — such as recordings and other media — directly to an event so you can build on a single data point instead of entry into multiple systems. We can then create possibilities for processing and storing that data into the archive, sharing it across event calendars and displaying it on the website generally or to select user groups. The data can also be shared more widely through open protocols to help others reduce their workload, too.
In some ways it centralizes the data store for your own data, but allows a decentralized world of data sharing (much like how Mastodon works). In this way, building the CMS is a first crucial step towards a much more collaborative system of data input for the performing arts world. We think that the benefits for artists and administrators will be immediate but also increase over time.
So you can use it to create a website now, knowing that the info you put there today is ready to be used for another purpose tomorrow.