I sent a ShowerThought on fedi about AGPL-like licensing for protocol extensions, which was not a good idea, but in the thread @LibreSolutionsNetwork mentioned using reference implementations instead [of FEP / AP protocol extension docs] to demonstrate new capabilities. And these can be AGPL-licensed to encourage they remain open and maintained as further changes are made.
Quoting Libre Solutions Network:
- Create reference implementations of specific features in major languages
- License those implementations as GPL
- Encourage app developers to contribute their extensions as reference implementations.
If steps 2 & 3 can start rolling forward it could be very powerful.
Musing a bit further about this idea, below some thoughts…
Allow federated app developers to demonstrate ActivityPub extensions in code in their familiar language, instead of asking them to write formal documentation (a process that in practice doesn’t happen or stalls).
The code serves as reference implementation of particular capabilities / features that are added to the protocol.
Other developers may hone and improve the snippets, or provide additional alternatives written in their language of choice.
There are many ways to offer this. Here’s some ideas:
- A webapp that allows submission of reference impls with a basic UI.
- A minimum amount of metadata is required to present submissions to other devs.
- Service that allows simulation of message exchange patterns that’d trigger the capability in the reference impl.
- A Codepen-like online editing environment might be available to, either:
- Write glue code that invokes the proper behavior in the federated app itself.
- Or just contains test code that generates the expected responses directly.
- A Gallery-like UI might present the submissions of reference impls in neat fashion.
- Gallery is like a pattern library that can be easily navigated to find specific capabilities.
- If later on formal FEP’s or AP extension docs are created they can be tied in with the impls.
- Code is stored in a git repository with copyleft license, and PR’s can be made to it directly.
Documentation is a chore. There’s a barrier to do it and do it well. Devs generally prefer coding to writing docs. They are proud of what they built and are incentivised to showcase that. If their extensions are more broadly adopted their project would benefit.
Other devs who want to adopt an extension can quickly see the inputs and expected outputs. They can follow the message exchange easily. While adopting they can first testdrive compatibility by writing code in their own language in the same environment, using it as a test harnass. Once done at the same time they have added an alternative reference impl to Gallery / pattern library.
Further incentives are provided by a clear attribution to the authors of the reference impls. Also having things come together in a single Gallery they are no longer dispersed across the web and very hard to find. Each dev can add references to their own codebase and other resources that are relevant when other want to adopt similar capabilities.