Frequently Asked Questions
What is the purpose of Magic Stone in practical terms?
Setting aside the big hairy mission, Magic Stone exists to solve two problems. One is not enough contributors (docs, code, testing) on fediverse projects and the other is high-friction, slow development processes. Slow processes turn off contributors so I want to take merge time for patches from what can be weeks or months down to hours and days.
The C4 RFC defines a process where the merge speed depends on describing and valuing problems rather than reviewing and approving code. With this faster process, the hope is the community will grow and overall speed and quality will increase.
How did this start?
The story started early in 2021 when I (@weex) started thinking more seriously about social media and what a better future for it might be. We came to the conclusion that since nobody really knows, experimentation was key. This led to a survey of open source social networking projects that might be good platforms for experimentation. Mastodon came out as top candidates.
At that point, I realized it’s not only a problem of not knowing what better social media looks like, but also how to run a successful open source software project. That’s when I found Pieter Hintjens and the Collective Code Construction Contract (C4) that he developed with the ZeroMQ community. The core idea is that community is primary, not technology. Only a strong community can develop and maintain software for the long-term that will meet the needs of the market.
It’s at that point that Mastodon was forked and Magic Stone was formed. C4 hadn’t to my knowledge been applied to social media so part of the opportunity for this community is to test whether it can work. In order to prove anything from a scientific standpoint, we need reproducible results so I forked diaspora* as well. Since then we’ve been solving problems found through using the software.
What is C4?
It’s short for Collective Code Construction Contract. A contract, a protocol, a set of rules to a game we’re playing, C4 is for making accurate software on the internet. You can read the contract here.
Who defines accurate? The market. We’re all part of different markets, the supermarket where we get food, employment market when we have to find a job, the housing market. A market brings a diversity of wants and skills and creates a place where success means satisfying some segment of the population. The bigger the group you can satisfy the more successful the project.
More important than a protocol or the software, is a community. Many are using C4 but it’s not possible to count since they’re distributed across many projects. Certainly in dozens of projects around ZeroMQ but more research is needed to know more. It doesn’t help that there is no development protocol as commonplace as Git
C4 is community-centric software development. We focus discussion almost entirely on problems and accept solutions freely. Automation and free collaborative platforms make it easy for anyone to help but ultimately it’s about laying out some rules then letting everyone do what they do best, alone or in groups of their choosing.
Do you plan to federate diaspora* and Mastodon or implement feature X? Where is your roadmap?
Under C4 we don’t have a roadmap, or assigned tasks, or releases. Our issue trackers are populated with interesting problems. Developers excited by any one of them are invited to submit pull requests. We find this a liberating way to work, never having a deadline, free to work alone or in groups and appreciating progress as it comes.
Have we federated those two? See here
Merging code is great and all but what about quality?
It is our belief that quality comes only from diverse community involvement. Typical open source project maintenance places a heavy burden on maintainers who must manage code reviews and make judgements about patches. Under C4, code is merged based on trust. The trust is there either way. Open source projects have been subtly backdoored in the past. It’s true that our process makes it easy for anyone to add code to our projects and some might see this as a vulnerability but we see no solution but to foster a healthy community who cares about what they’re doing.
How are Ecko and Acropolis different from what upstream/other projects are doing?
The projects we’ve forked have done amazing work and created systems that are in use by many, many people. Since forking, we’ve focused on issues raised by our particular users and admins. The software will diverge over time but since these all use AGPL, it’s easy for solutions to cross-pollinate and for forks to benefit from the cooperation.
Is C4 just for developer-centric projects?
Most of the history of C4 is in ZeroMQ and that is a very developer-centric community, but we don’t see any reason why it can’t work just as well for other projects. People are the common ingredient in all human endeavor. We are excited to be testing C4 in the social networking space.
The usual pattern for an open source project places developers in privileged positions of writing code, judging others code and which bugs get fixed and features resolved. A handful of very large projects broaden the opportunity to have a voice through design and UX teams.
In our projects we realize that diversity is a key strength of community so we invite everyone to raise and discuss any problems they want. So far most of our discussions have been in issue trackers on GitHub but discussion can happen anywhere. It’s important for everyone to be able to see the reasoning so we do ask that discussion take place where it will be publicly available long-term.
How can I try C4 with my project?
It’s a tough sell to switch development processes which is part of the reason we decided to fork these projects and operate independently. If you’re ready to try C4 we recommend forking an existing repo and then recruiting one or two volunteers to try the new way. If after a few months it seems not to be working you can PR any interesting developments back upstream and leave the new repo alone. You may find C4-tools to be helpful for processing any stuck pull requests.