How to run an open-source design project?

Disclaimer: no links in this article are NSFW, but they aren't SFW exactly. Please read further

Introduction

I'm working with the BDSMtest team to open-source and modernize it. This work is a personal endeavor — doing something many peers have talked about but never actually started.

A quick introduction: BDSMtest.org is a website where you can test how kinky you are and what kinds of kinks you are mainly into. It's not precisely NSFW — there are no images or explicit wording — but as the theme is sexuality and kink, your work might not approve of you clicking the link during your shift. I'd recommend taking the test, even if you are vanilla.

Don't know what vanilla is? Then, well, take the test.

The website has been up since 2014. Every kinky friend — quite a lot — and even non-kinky people have been using it as an essential source of information on their kinky preferences.

I am a front-end developer looking forward to redesigning the website and modernizing its codebase. After doing that, the idea is to revisit the test structure, questions, and results with the help of data scientists (not my area, but that's what open-source is for, right?)

The question

The first part of any modernization project is to think about architecture: how is the current website organized, and what's the goal of the modernization. In this project, one of my goals is to make it look better. It's not exactly ugly; it's just... old. So, it would need a new design.

I, as a front-end developer, have some knowledge of how open-source coding happens:

1. you find a GitHub repository;
2. fork it;
3. work;
4. open a PR respecting the CONTRIBUTING guidelines;
5. Answer comments;
6. Make requested changes;
7. (Hopefully) get it approved;
8. ...
9. (Not) profit!

But, as a designer... how could that work?

Tools

First, design does not have straightforward collaboration tools like GitHub, with granular versioning. There's Figma, of course, but having multiple collaborators in it costs money, and someone can just come and erase everything, right?

It would be necessary to have a clear conduct guideline on how to work on that shared project and also be sure no one is breaking those rules — which would be a manual task, as there are no automated tests or way to compare the current work with the former.

There are also no PRs: any work done happens in the same space. If someone deletes something or changes a component, we'd only be able to notice it after they already done it.

In Figma, all the commits are in main.

So, how to collaborate knowing the source will be preserved while making it possible for new people to add work?

Behavior

If you are a professional programmer, you may know how to group code. The whole GitHub — or GitLab, or whatever tool you prefer — ecosystem is natural to us, as we've been using it forever.

There are straightforward tools inside GitHub, for instance, to prevent commits on main, block PRs if the workflows fail, require specific approvals when merging, etc. There's nothing like that in Figma, for instance.

A quick thought: I'm using Figma as an example because there are no other collaborative design tools in my mind right now. After Figma's acquisition by Adobe, XD isn't even on the table anymore.

How to guide the behavior of new collaborators in an open-source design project? How to avoid destructive workflows? How to maintain project structure while allowing collaboration?

Blocked

This situation blocks my progress with this task. I will start my design process by myself, but I would love for it to be public and collaborative — I don't know where to begin to make this happen.

Do you know the answer? Could you share this with designer friends or start this discussion with your colleagues? Will Figma ever get their hands on this and make it free for open-source software?

I can only kneel and pray — oops, new kink unlocked.