In an Outreach Workgroup conversation on Feb 2, 2023, the conversation turned to strategy for community growth, and I advocated - not for the first time - a more grassroots model. Historically Magma was built around business to business relationships driven like business development in a company, I said, and that flowed from the project's origin's as a Facebook corporate initiative. I advocated for a more grassroots model, looking for organic growth.
Other workgroup members debated whether such a model makes sense for a technology like Magma. It has high barriers to entry no matter what. A hobbyist is unlikely to be able to surmount those barriers. Moreover, the value proposition is mostly relevant only to businesses. (If I mistate this position, I welcome improvements!)
In this document I'll make the case that these positions are only opposed in ways that are superficial.
The researcher Nadia Eghbal has suggested a method of classifying open source projects along two axes: contributor growth and user growth. A contributor-focused model is on the supply side. A user-focused model is on the demand side. Projects fall into buckets depending on whether they are driven by demand or supply, or both, or neither.
Importantly, none of these classifications rejects grassroots community growth. They are held together in the informal style of classic open source communities.
(To learn more about Eghbal's writing, look up Working in Public. There is also a YouTube).
Magma is plainly a project in the style Eghbal calls a club. The number of people who are likely to write code ("contributor growth") or deploy ("user growth") is always going to be relatively small. But this isn't unique. It's true that Magma has high barriers to entry and is mostly relevant only to businesses, except for handset users who aren't aware of back end software.
A comparable project in the "club" bucket is Autoware, which does open-source software for autonomous driving. The number of authors of such software is always going to be low, and the number of deployers is also limited for the moment.
Being a club-style project is not a reason why organic growth won't work. A club is still open source. It is still shaped by the forces that affect all open source. The Autoware Foundation, for example, only accepts organizations as members, but it encourages contributions from individuals.
We currently accept organizations only for the membership. However, we are delighted to have your contributions to Autoware such as creating/amending programs by signing up our platform etc. If you are interested in contributing, a good place to start is to look at the repositories on GitHub and see if there is anything on the issue tracker you can tackle. https://github.com/autowarefoundation/autoware
You might also want to take a look at the list of active working groups where you can join to contribute. https://github.com/autowarefoundation/autoware-projects/wiki#working-groups
Additionally, we encourage you to visit Github Discussions for discussions/collaborations with other Autoware contributors. https://github.com/autowarefoundation/autoware/discussions
A student or hobbyist would poke at the code but probably be defeated. It costs too much for equipment and servers. The cheapest eNodeB I have seen was around $2500. The monthly AWS bill is around $1000. These people may not be stopped by complexity, but they are definitely stopped by money.
As it happens, a lot of the developers who check out Magma for the first time are on the border between hobbyists and companies. They have the technical skills to write code and the background knowledge of telecom protocols to understand systems, but they lack money.
They are usually tire kickers affiliated with some organization.
What's open-source about these people is that they don't ask permission or wait for support. They just start. They are self-service.