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.
Open questions
Name. Is this a Dreams 2.0 or something else?
What other use cases beyond burns can you see for the Dreams process?
Yes! I’m excited about this. Dreams is indeed quite cumbersome and frustrating to work with these days. Remember also that the original Dreams architecture was never built for multi tenancy or even for the social functions we built into it in 2019. It seems like it might be time to take what we have learned and rebuild it with all of our lessons learned. I’m very happy that you’re picking this up!
Financially, I will use the rest of the money in the Participio fund for this development. It will be managed in an OpenCollective organization which will also be possible to donate to through crowd-funding to extend those resources. I will be the owner of that org, but @gustav will call the shots on who gets paid for what, as the do-ocratic leader of the new Dreams.
@jakobskote has some ideas about how it might be used in cities, and I’ve also had ideas along those lines. @nadia and I have also spoken about idea for using Dreams for the Edgeryders “festival” and event format.
Such things are always sad to read for developers and maintainers. I’d love to continue working with Ruby and/or Ruby on Rails and wish you that the chosen stack will lead to a more maintainable solution. At least PostgreSQL will not be a moving target
I mentioned the project today in a chat of people from https://makers4humanity.de/ which is a conference/festival/gathering - probably close to the current use case.
Thank you for pointing this out! I’m very much spouting out my personal technology preference as some sort of truth, sorry about that. I don’t know if I have to point it out but the original Dreams platform is awesome, no matter my very biased tech stack preferences, and the people that built it deserves a lot of credit. There will be a lot of shameless copying and stealing of ideas, as we are essentially building a multi-tenant clone.
I hope this project can be seen as some kind spiritual offshoot of the original Dreams platform, with the goal of taking its magic to more places than before, without necessarily trying to be a successor or replacement. If you would like to use the Dreams process and know some Ruby/Rails, the original platform should be the way to go still.
As for PostgreSQL, it actually might be the most moving target here , as the idea has been to stick close to the stack of Realities, except for its graph database which seemed overkill for the use case here.
Very cool! I think these types of gatherings/conferences would be great to have in the indented audience for this
The proposed tech stack is put in place (with the slight tweak of using MongoDB instead of Postgres, more info in the tech stack issue) with a GraphQL schema currently encompassing users, memberships, events, dreams.
It would be good if the schema is consistent with Realities when possible and relevant, for example having the same nomenclature for a Person, user etc. Just a minor thing, but makes it easier once we want to link them together.
Authentication with magic link is done and a basic UI is starting to take place (login, create event, create dream, edit dream, listing of dreams). You can see it, log in and try to create some dreams here: https://microburn2020.dreams.wtf/
I think the next focus will be event/membership management (to invite people and approve members, make them guides or admins).
Good call! Added a GNU General Public License v3.0 (same as Realities). If someone is deep on open source licensing and would like to suggest another license to re-release under I’m all ears
That’s me! GPLv3 is a very “good” choice. However,
Its good practive to mention it in the README, too:
Copyright 2019 Gustav Larsson, released under the GPLv3+ which is included in the file [LICENSE](LICENSE) in the git repository
I advocate to specify the license as GPLv3+ (with the plus added), which means people can relicense your code as GPLv4 if that should ever be necessary (there is lengthy discussions about it, here a quick summary without all the historic story that you can read up somewhere else gpl 3 - GPLv3 - Explicit version number / "or any later version" - Implications? - Open Source Stack Exchange ). This of course means that you trust GNU to not mess up in the future and has the benefit that you stay compatible with future GPL versions - that are incompatible with former versions; this actually happened with GPLv2 ↔ v3.
The Affero GPL (AGPLv3+) would (roughly speaking) require people who privately fork your project and offer it as a service (via the web - this is a difference to “distributing” the software) would also have to give you access to their changes if you ask them. Afaiu this is not a requirement for the pure GPL, where you could pimp multi-dreams and sell your service offering the improved version without showing how the improvements were implemented. Thus “hardliners” (like me) would probably choose the AGPLv3+ for web-applications.
There is a FAIF podcast that gives some general information regarding open source licensing:
Its tricky. Afaiu giving away the Copyright of ones own works has to be done rather explicit in most legislativesn and situation, i.e. you would need some kind of contract or written proof that the contributor consciously “donates” the otherwise exclusive copy-rights to you. In the case of a single author, stating the copyright in the README or the published file should be enough though.
I’ve seen this being handled in multiple fashions and I am not an expert in this, so take it with a grain of salt; and as stated I think the situations would be judged quite different in the courts of different countries.
Anyway, multiple copyright holders should only become an issue if the code is to be relicensed - e.g. suddenly a client wants to have some changes that shouldnt be made public for whatever reason or suddenly a different license makes more sense. Traditionally as sole copyright owner you would hand the client a copy under a proprietary license. In the case of multiple copyright-holders you would have to get permission by each copyright owner to copy his/her contributed code under different license terms (as long as you respect the original license terms you are of course okay).
For (not only business-)practical reasons it can be desirable to choose a single copyright holder (e.g. you, or edgeryders). Actually there are also foundations, NGOs and Charities founded just to hold copyright and/or act as fiscal host for software projects.
I’ve signed digital Contributor Agreements of companies owning GPL’ed code, other (most) projects seem to assume that a license change might not be necessary or that contributors agree to transfer the copyright of their changes to the entity which is mentioned e.g. in the README.
I think if I were a company like edgeryders, I would ask the copyright to be transferred to me (the company), find out and care about what happens if the company should ever cease to exist and require a single file in the git repository where every contributor is asked to put his/her name with the intention to transfer the copyright (although this might not be 100% legally binding in every legislation I think that it would make a good enough argument, especially when linked to a discussion / company manual regarding the implications). Btw I think if you are paid to deliver code usually the client owns the copyright afterwards.
@hugi@matthias Some more formal process and guidelines (e.g. when contracting IT work, explicitely mention Copyright and propose a preferred License) could go into the Tech Strategy or Company Document.
In this particular case, Edgeryders is paying for the work through a budget I control. As long as the code is written with a strong copyleft license like AGPLv3+, it’s up to Gustav to either write himself as the copyright holder or to write Edgeryders as the copyright holder. Doesn’t matter much to me, do whatever feels best for you.
Very exciting to see the progress on this project. I have been in touch with some organizations who might be interested to trial the platform for more mainstream use-cases but were not ready to take it on due to the wider work needed (tech + backend processes). Amazing this is in the works!
Quick update on the project. Work has been mostly standing still over the holidays, but expecting the pace to pick up now. Before Christmas I implemented basic membership/event management: ability to invite members, delete members, make/remove admins, approve/reject requests to join, set registration policy (open, invite only, request to join).
I’m thinking the next large chunk of work will be focused on the funding/granting mechanisms, as it is a critical piece of the software…
Status update. A first iteration of granting is now implemented:
Admins can set the following granting settings:
currency
grants per member
total budget
grant value (with the help of a calculator to set a reasonable value)
dream creation close date
granting open date
granting close date
Admins can prefund dreams manually.
Members can give grants to dreams that are approved for granting (by admins) when the granting is open.
Admins can also reclaim grants from dreams that did not reach their minimum target, and reallocate those manually. I think adding the option of letting an algorithm do this redistribution would be a good feature also.
Update on time budget, I’ve logged slightly less than 120 hours so far.
I’ll be completely offline the next 10 days for a meditation retreat, back online march 1st!
?
I’m very much spouting out my personal technology preference as some sort of truth, sorry about that. I don’t know if I have to point it out but the original Dreams platform is awesome, no matter my very biased tech stack preferences, and the people that built it deserves a lot of credit. There will be a lot of shameless copying and stealing of ideas, as we are essentially building a multi-tenant clone.
, as the idea has been to stick close to the stack of Realities, except for its graph database which seemed overkill for the use case here.
(there’s no license file yet).