Slow Software for a Burning World by bonfire
-
🐌 Slow Software for a Burning World 🔥
In a world of “move fast and break things,” we’ve chosen a different tempo — one rooted in care, deep listening, and collective stewardship. Slow software means building for long-term resilience and meaningful participation, rather than chasing novelty, speed, or scale.
(bonfirenetworks.org)
This feels like it rhymes with a lot here.
-
🐌 Slow Software for a Burning World 🔥
In a world of “move fast and break things,” we’ve chosen a different tempo — one rooted in care, deep listening, and collective stewardship. Slow software means building for long-term resilience and meaningful participation, rather than chasing novelty, speed, or scale.
(bonfirenetworks.org)
This feels like it rhymes with a lot here.
Bonfire are doing some amazing work. They forked the Elixir codebase developed by Pleroma/ Akkoma, to make an efficient, general-purpose ActivityPub server, that they can building a range of fediverse apps on top of it, customised for different social experiences; Bonfire Social, Open Science, Bonfire Community, Federated Archives, Bonfire Coordination, Bonfire Coordination.
Not sure if any of those would be suitable for building a music site on top of. Maybe that could be its own Bonfire app flavour?
-
Bonfire are doing some amazing work. They forked the Elixir codebase developed by Pleroma/ Akkoma, to make an efficient, general-purpose ActivityPub server, that they can building a range of fediverse apps on top of it, customised for different social experiences; Bonfire Social, Open Science, Bonfire Community, Federated Archives, Bonfire Coordination, Bonfire Coordination.
Not sure if any of those would be suitable for building a music site on top of. Maybe that could be its own Bonfire app flavour?
Yeah, it’s very interesting. We were talking to them for RFF community a while ago. But it transpired that they needed us to sort funding for it first! They have limited resources to do these pilot programmes. So it ended up being stalled.
-
Yeah, it’s very interesting. We were talking to them for RFF community a while ago. But it transpired that they needed us to sort funding for it first! They have limited resources to do these pilot programmes. So it ended up being stalled.
This isn't uncommon for tech projects in the solidarity economy. They don't have access to the VC pipeline, and the potential for future returns through IPO or acquisition by a larger competitor. So money needed for R&D, beyond the time and skills that enthusiasts volunteer, generally comes through grants, funded by governments or well-heeled not-for-profits.
One thing I've noticed by watching this space for a while; there isn't a huge overlap between people who are good at developing new kinds of software, and people who are good at writing grant applications. Even in that overlap, writing multiple applications (to increase the chances of getting one) takes time away from software work, which is kind of counterproductive.
So it's often better for people who need software adapted to their use case to write the grant applications. But they often don't get the grants either, because they struggle to prove that a working solution can be delivered for the money granted (why is another story). Meanwhile, another thing that makes it really hard for developers to get grants is the inability to prove demand for what they want funding to build.
What I'm ambling towards here is that if a group could be coordinated here to put in a grant application for building a Bonfire Music flavour, with thorough technical input from the Bonfire team, there's a good chance you'd get funded. I'd suggest making a number of small grant applications to both tech-based funders (eg NGI0 and NlNet), and music-based ones.
Random idea that may or may not work; include the full list of funders you intend to apply to in the grant applications. Encouraging them to backchannel and co-fund a grant big enough to cover the work needed.
