# Open brainstorming: Money, small communities and inter-community trading and communication **URL:** \ **Category:** Outreach square đź«‚\ **Created:** [November 1, 2022, 1:46pm UTC](https://discuss.coding.social/t/open-brainstorming-money-small-communities-and-inter-community-trading-and-communication/174 "2022-11-01T13:46:32Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![IgnisIncendio](https://discuss.coding.social/letter_avatar_proxy/v4/letter/i/85f322/32.png) [@IgnisIncendio](https://discuss.coding.social/u/IgnisIncendio)\ **Post date:** [November 2, 2022, 7:34am UTC](https://discuss.coding.social/t/open-brainstorming-money-small-communities-and-inter-community-trading-and-communication/174/2 "2022-11-02T07:34:06Z")
# The universe is big Let’s say we have small communities maintaining their own software. How do these software communicate? An open protocol like AP? It might be very hard for consensus to be reached – indeed there is already a divide between the Mastodon developers and the developers of other Fediverse projects such as Misskey and Pleroma. Do we really need consensus? Much like how the Fediverse does not have consensus on social norms (e.g. CW rules), and likely will never have consensus, but instead forms a sort of organic graph, where some servers are “more compatible” than each other. Should that be the case for open standards too? Where different implementations implement different de-facto standards and have differing levels of compatibility rather than waiting for a consensus? That I think is already happening with AP. But it also happened with XMPP, did it not? And the fragmentation was a big UX issue. So maybe it’s not such a good idea. What about Matrix? They have a much more centralised way of creating the open protocol, which allows for higher velocity and de-fragmentation, but re-creates the issues of very big projects. > **[Reflections: The ecosystem is moving](https://signal.org/blog/the-ecosystem-is-moving/)** > > At Open Whisper Systems, we’ve been developing open source “consumer-facing” software for the past four years. We want to share some of the things we’ve learned while doing it. As a software developer, I envy writers, musicians, and filmmakers.... In essence: **The universe is big. The bigness has to be _somewhere_** ; we cannot only talk about smallness(?). Where, and how do we manage it? Related quote with possible solutions, once again from the same post: > [@Free Software Movement: Stepping out of Failure modes](https://discuss.coding.social/t/free-software-movement-stepping-out-of-failure-modes/166/1): > > The idea expressed by @jbauer aligns with [Strategic Ecosystem Alliances](https://discuss.coding.social/t/ecosystem-alliance-strategic-collaboration-to-evolve-faster/89) and the formation of [Software Guilds](https://discuss.coding.social/t/unionize-free-software-found-software-guilds/59). @jbauer will write another blog post to which I look forwared to, that explains more about this concept. # The Do-Ocracy [https://communitywiki.org/wiki/DoOcracy](https://communitywiki.org/wiki/DoOcracy) The Do-Ocracy feels very much like an informal computer-science-degree (which I’m pursuing) project. Whoever does the thing is in charge of it. Want to clean up the code base? You can just do it, etc. For that a few things need to happen: 1. Anyone should be able to _just_ make changes to the software. This includes non-programmers. Abstraction is needed; perhaps visual programming. Note, visual programming is not just “coding but with blocks”! Excel is a good example of visual programming. Unity Shadergraph too. 2. The contributors must be able to _just_ contribute instead of going through a whole consensus process, and for that to work, the team must be small. And for that to work, the software must be build-able by a small team. Requires abstraction, then, modular building blocks (see npm/cargo/github/OOP?) likely from other communities. For both 1 and 2, the small community building the software relies on other communities; inter-community trading or communication is needed. Personal opinion: do-ocracy is good, it gets things done. But it must stay small… then where shall the big-ness go? # Wikipedia and Fediverse instances: Collaboration and Division I am talking to myself… hello me! Hello, me. I like this way of brainstorming. - I am happy about how Fediverse instances are divided. My thought process: there is no way a single community (e.g. Twitter) is able to make everybody happy. Therefore, the ability to break up into instances with all sorts of rules (I am including single-user instances here), _and_ the ability for different instances of similar rules to find each other organically is important. Essentially, division is important for _everyone_ to keep their local culture. - The ability for anyone to _just_ make their own changes, for example, to the rules and the banlist is important. Obviously this won’t work with large instances; everyone will just try and ban one another. Thus, the ability to _just_ make their own instances is important, and to protect this ability, there must be so many servers that anyone that tries to make an allowlist or somehow maliciously restrict federation will not be able to access the majority of the Fediverse (which is valid, but just to avoid a gmail-like scenario). - So… when do we collaborate? When do we divide? - I GOT IT! I think. Wikipedia is very simple to edit, and if you’re editing something simple, it’s hard to get wrong (and others can help). Imagine a piece of software as simple to edit as Wikipedia, without technical knowledge needed. The same collaboration will emerge, wouldn’t it? It is because today’s software is so hard to modify, that people find it easier to just bother the maintainers. --- _[View the full topic](https://discuss.coding.social/t/open-brainstorming-money-small-communities-and-inter-community-trading-and-communication/174)._