This mirroring might be very useful. It is nice to have stable backups on systems under one’s own control and all based on FOSS.
Two concepts to define further. Healthy relationship and neighborhood. They are both related to the FSDL. When it comes to dependencies various categorizations can be made. Like a separation of:
- Tools & software used (LibreOffice, Inkscape, Forgejo, …)
- Toolchains (e.g. front-end NodeJS stack, back-end Rust stack)
- First-order direct dependencies (package.json, cargo.toml)
- Second-order indirect dependencies
Then there’s something of a prioritization wrt sustainability e.g. …
- Creator. The own initiatives’ sustainability needs must always come first.
- Clients. Customers and other stakeholders the software is created for. Includes downstreams.
- Ecosystem. All the direct and indirect relations that make the own initiatives stronger.
With these just in the back of the head, I would start with a process of mapping from “product management” to “ecosystem management” (by lack of better terminology). In other words going from what you want to achieve with your deliverables (the product or service), the strategy by which you want to achieve that, and with objectives and needs clearly pictured.
Ad 1) Creator. Here a carefully curated list of dependency relationships should be maintained, identifying the crucial enabling tools / technologies / open standards / software that the initiative directly dependent on to not only serve the current needs, but align to (product) mission & vision and known current/future requirements and innovation trajectory.
Ad 2) Clients. The creator part above serves to a robust foundation upon which solutions can be built and delivered. Client needs and stakeholder feedback are key drivers that determine a whole range of additional dependencies to take on (or avoid). But also a list of candidates to adopt possibly in the future and keep track of (actively, i.e. giving feedback in hopes of these projects make beneficial choices). I find for point 1) and 2) using Technology Radars are a good way to keep track of this. These tech radars can be quite project-specific e.g. documenting the reason for adopting a Markdown editor because of user-friendliness (an elaboration of the decision-making would end up in ADR’s).
Ad 3) Ecosystem. Here there are direct dependencies that must be mapped, but also relationships to adjacent initiatives e.g. projects that depend on the same technology base and open standards. Here are win-wins of doing things together, and the collaborative aspect of the commons-based ecosystem should be emphasized. There might be a healthy spirit of coopetition if a software is in the same field, whereas competition is best avoided. There may be relationships to non commons-based initiatives as well. Wrt transitional dependencies, I feel the priority of considering them falls off quickly, and depends on how important they are in light of 1) and 2) sustainability criteria. That super easy-to-use Markdown editor may get most its features from one particular parser project. It might be a likelier target for upstream contribution than to some basic packaged NodeJS utility function that is used in millions of projects.
In finding a kind of methodology to this relationship management we might go from a particular showcase, and do the exercise.
