Add blog post draft

Author: bitfl0wer

docs/blog/posts/2025-02-12-governing-polyproto.md

@@ -0,0 +1,28 @@
+---
+date: 2025-02-12
+draft: true
+categories:
+  - polyproto
+authors:
+  - bitfl0wer
+title: Governing polyproto
+---
+
+There's precedence which suggests that governing federated software as a one-man-band is a bad idea. This begs the question: How would polyproto be governed?
+
+<!-- more -->
+
+## I am in a somewhat interesting situation.
+
+Polyphony and polyproto are, at the moment, "just hobbies" for me. However, I *do* still really want this all to succeed long-term. These wishes do involve a lot of planning ahead, including thinking about passing on the torch, so that this fire does not die with me. A pretty uncommon thing to say about a hobby, I think.
+
+It is pretty clear to me that I do not want to be the sole ruler of all things polyproto. I simply don't have the time, energy and skills to manage everything myself, should polyproto really become something that is used by a larger audience. polyproto must be an open standard, and in my opinion, to make a standard truly open is to eventually let go and involve other people in decision making processes. This is what I have been thinking about a lot lately, and I wanted to use this article as a space to share my thoughts and wishes for the future.
+
+## Democracy!
+
+To make a long story short, I believe that establishing a non-profit foundation or association that concerns itself with governing and developing polyproto is *the* way to go. The tasks of such an association would be:
+
+- **Coordinating and overseeing work on the protocol:** As the polyproto sees increased usage, changes and additions to the core protocol will most definitely need to be made to align the protocol with real-world needs and wants voiced by users and developers alike. The polyproto association would have the final say over what changes will be included in the next version of polyproto by reviewing, commenting on and accepting/rejecting change proposals submitted by people/groups.
+- **Foster a collaborative environment:** I believe it would really *suck* if there were 12 (exaggeration) different p2-extensions defining what a Discord-like chat application should look like. The polyproto association should make efforts to foster, unify and certify "official" extensions and standards that all developers should use. I am not 100% sure about what this would look like; Imagine, someone develops a p2-extension defining what a Google Photos-like should look like. This person now comes to the polyproto association with a wish to get a "seal of approval" via getting their extension certified. The association members notice, that this extension is pretty awesome. What happens now? Should this extension be "absorbed" into the association somehow? Should only this exact version of the extension receive certification, requiring the developer to contact the association again if an update to the extension is made, to get the updated version certified as well? And if this is the case, say there happens to be a disagreement between the association and the developer on the contents of the extension update – what then? Does the association eventually "hard fork" the extension? This seems very complex, and I think that cases like these should be considered, given that sadly not every human being gets along with each other. In any case, the polyproto association should make the process of getting your extension proposal reviewed and seen by other people easier, so that extensions are not created in a vacuum, but through *collaboration*.
+- **Act as a giant documentation resource:** The association should be a great source of information for interested developers. Documentation and explanations of concepts should be available in various levels of complexity and should always be up-to-date.
+