Dreams has been used by The Borderland and other burns since 2016. It has enabled the participants to co-create the events by allowing any participant to create an idea (a dream) of something they want to do, set a budget, and then letting all participants decide what to fund collectively with tokens representing a part of their membership fee.
Dreams is a prime example of technology coming out of the participatory culture and something that has good potential for wider adoption and usage. But adopting this platform and process for your own event requires a lot of specific technical know-how, as a single deploy can only handle a single event, meaning that you need to set up and deploy your own version of Dreams to use it for your own event.
Rewriting Dreams to allow multiple organisations and events to use the same instance would lower the barrier for it to be used by not only more and smaller burns that do not have the resources to set up and run its own deploy, but also opening up the possibility to use it for other types of events and gatherings and in other networks.
Building a Minimum Viable Product (MVP) of a multi-tenant Dreams
I’ve talked with @hugi about leading the development of an MVP funded by Participio, using a similar tech stack as Realities, another Participio project (with the biggest difference being using a more traditional database here):
- UI: React, Next.js, Apollo Client
- API: GraphQL server using Node.js, Express and Apollo, with a Postgres database
Goals of MVP
- allow multiple organisations and events on the same instance
- make it possible for a smaller event to adopt the Dreams process without needing any technical know-how (admin of event might need to do some non-technical manual work, like giving out tokens to the correct members)
MVP user stories
- to be determined
Future development possibilities but outside of MVP scope
- integrate with OpenCollective to use it as the financial backend, to handle the money part and expense reimbursements, reducing a lot of manual and tedious work that takes place today
- build support for custom integrations per organization, like Keycloak (used by Borderland for single sign on), Loomio, ticketing, etc
Why a rewrite?
Tech debt and developer happiness. The current platform is built in Ruby on Rails, and has developed some tech debt over the years. I was part of the Participio Dreams hack in March, and the general feeling I sensed among the developers was that it was a pretty cumbersome to work with. Small changes taking a long time to implement. While an experienced Rails developer would have no trouble being very productive in Rails I think it becomes increasingly hard to find people wanting to work on this tech stack, myself included…
Another factor is the benefit of using a similar tech stack as Realities (which is also, arguably, a more modern and popular tech stack) and making it easy for developers to switch seamlessly between them. Using GraphQL there are some neat things you can do in stitching two schemas together, reducing the data barriers between the platforms.
- Name. Is this a Dreams 2.0 or something else?
- What other use cases beyond burns can you see for the Dreams process?