Observations and projections II (5/5)

1

Previous article: Observations and projections from half a year of using Osuny : "Co-construire un commun numérique" pour "Devenir un commun" (4/5).
First article: Ergonomy of development experience and common reproducibility questions around maintaining degrowth.net.

9. The Osuny CI is tested to run on FLOSS platforms and allows for customizations

Right now the Osuny CI is implemented as a GitHub Actions workflow file, which is pushed by the @osuny-bot to main in the website repositories. More on that in the next point.

It is tightly coupled with the proprietary, but free GitHub Actions workflow runners and they are a sufficient runtime dependency. Without them, no Osuny is possible. While it is hard to imagine that Microsoft GitHub goes down for a longer period of time, we like to know that we have the choice to switch to a tested FLOSS alternative.

This could include starting from the existing Osuny · GitLab organisation to experimenting with the new GitLab CI/CD steps syntax.

Another experiment that offers itself could be to play with Gitea Actions using the GitHub Actions runner nektos/act. It means the existing workflow could be reused as is. This is also availailable on Codeberg as Forgejo Actions. They are a nice German association providing this instance as environment for its growing community. If noesya are already a paid GitHub customer, it would be very nice to redirect those funds into an autonomous alternative from Microsoft instead.

It remains to explore how the hard-coded file name and content of the deuxfleurs.yml could be decoupled from @osuny-bot and allow for more degrees of freedom, e.g. in concert with custom forks or extended pipelines.

We’ve successfully added a link checker workflow with lychee to the next deployment on dev, because its decoupled pipeline and deployment target allowed us to experiment a little. The workflow file of the main workflow deuxfleurs.yml just kept on being replaced by @osuny-bot.

Once such an extension is possible, it appears useful to extend the application of the website workflows to an integration test with hurl (Salut @Orange-OpenSource!). We will test this first on next and report back.

Also it would be nice to opt out of the Slack notifications, if we don’t want them. Or to opt in to our own notifications.

Which requires another way of testing and establishing consistency of the primary CI workflow file to build and deploy an Osuny website from. Can we opt out of overwriting the workflow file with each commit from @osuny-bot? Or can we maybe modularise the pipline and allow to optionally workflow_call other pipelines, if a definition is present?

Or maybe we can generate dynamic pipelines, e.g. by leveraging CUE? (cue-by-example/001_github_actions_importing_workflows/README.md at main · cue-labs/cue-by-example)

Questions to all of which I don’t have any answers on my own, why I am addresing you dear reader here the Osuny community.

There’s one more thing …

10. The Osuny website git repository only holds references to its modules and doesn’t contain them

It’s a place which repeatingly asks for resolution of diverging interest. It is the single source of truth, from which Osuny pages are built and deployed. Multiple forces push into the repository, which is alleviated by using Pull Request based workflows.

Unfortunately the repository in its current state limits the degrees of freedom, with which the chosen levels of indirection allow us to interact. The repository is partially tightly coupled with the state in @osuny-bot, which it reconciles with every change event in its source system. It also defines the live deployment and procures them.

This is a question of sovereignty for the repository.

Asking who is the sovereign of the repository also means asking in which relation we interact, and which workflows we are able to give to ourselves.

  • If the Osuny websites are a gift from noesya to the IDN through its participation via its membership, then it is eventually the IDN OC Tech Circle, who will allow to resolve disputes.
  • If the Osuny websites are maintained by participation of the IDN in the Osuny Common, then it would be nice to learn who that is and how to address them. Right now it is not perfectly clear who is what under which circumstances, esp. when emailing someone at @noesya.coop.

If the second is the case, we could convene as a community and debate our internals some place more private.

In an ideal world, it could be nice, if the bot pushed to feature branches and created and merged labelled PRs automatically, after a test build (without deployment) succeeded.

This way main can be locked and restricted to PR merges.

Eventually this also opens up an editorial feature, which behaves like the DecapCMS editorial workflow: Using feature branches for collecting multiple change intents into change sets, and then pushing them all at once when reviewed.
Such a setup also allows to consider use cases, in which multiple changes occur within in a short time interval. These incur a heavy load on CI, due to running builds in parallel for each incoming change that is pushed. This takes longer serially discards outputs, which consume resources. Maybe some kind of back off timer can help to pool changes semi-automatically, depending on how fast they happen after one another.

The website code repository also uses a git submodule for the theme, which is a crufty technique to work with and complicated to keep in sync. (The best pattern for them is to use the submodule read-only and to only contribute to it from a separate clone.) It also creates some kind of intermediate metadata, which is neither state nor metadata. Submodules are easy to break while keeping them in sync, as we have seen in the commit history.

The submodule also tightly couples the theme to the repository. Replacing it by some mechanism that uses versioned packages increases one degree of freedom.

To end today’s journey, let’s allow ourselves some intellectual freedom and imagineconsider the holy grain in decoupled content management: decoupling content and code.

The content-API-driven publishing workflow to static pages meets contemporary demand and expectations to the way how commodity websites are built. While there are plentiful of static site generators, who build their web pages from files, also known as file-based CMS, there are few who expect to build pages from data.

The way how Osuny approaches the area is, that it found a way to serialise large and complex data structures into the frontmatter of an article, which will be treated accordingly by the theme. When Hugo themes were generic and often impartial, by converging on a set of Standard frontmatter variables supported in many themes, Osuny couples the theme to its data structure, which is impossible to manage without its editor in the admin instances.

With some recent changes to Hugo in the last few weeks, it even becomes possible to draw an outline of « Osuny as a Standard »: a data-first and model-driven content API to interact well with Standard-compliant Hugo and then potentially also other generator’s themes.

Hugo now knows how to build pages from remote data:

This feature is just perfect in combination with a content API, such as Osuny:

The proposal is to allow @osuny-bot, or whichever decoupled pull mechanism, to integrate updated content into website build pipelines from inside the degrowth/idn-website repository, to complete our emancipation from template and to call the repository « our » home.

In the mid-term allowing to build from other repositories than in the osunyorg GitHub organisation could also mean to break the fork connection and to become a hard fork. In the long-term it could be nice to allow people to link to their repositories on any GitHub, GitLab, Gitea or Forgejo instance via a simple OIDC login from their admin instance.

I don’t know enough about the internals of the application, to make an informed suggestion, but hey, we are dreaming now, are we? A versioned pull-based approach with a read-only API token also removes the need for involving git on the transport layer. The page can just be rebuilt by sending a Webhook to the pipeline trigger endpoint and the pipeline takes care of the rest. No data, but metadata is transferred on the control channels.

Maybe there are other Osuny customers and Commoners, who would like to use similar facilities.

I will try to use some of these suggestions myself and see, how our own computational Common and our projects check against them. It’s hard to look at those aspects, when you’re just running around and trying to keep the head afloat, while being totally immersed by the process. This written reflection of my expectations towards Osuny also allows me to reflect them back at our own Commons.

Thanks for this surprising outcome of me finding a space to write to the community here!

Reflections from our own experiences with building a static website from a content API that has a nice interface for actual people to use

With starting to build a new Website for eco:bytes, be have also embarked on the journey to implement contemporary decoupled ways of developing dynamic websites. Ask your machine assistant to translate this for you, or skim it for its diagrams and keywords.

Inclined by its presence in the ThoughtWorks Radar, we opted for building a static Astro site from a Directus API and can very much relate to the complexity involved in managing loosely-coupled systems. I’ve once made a Mermaid diagram which mentions most parts of the project. Just look how quickly it got out of bounds, by simply following « contemporary professional website development techniques ».

ecobytes/web: stack and dependencies ($427) · Snippets · ecobytes / web · GitLab

In other projects we have successfully leveraged the GitHub and GitLab APIs for managing content and associated CIs for producing builds. Using decoupled client-only CMSes, which work on custom frontmatter schemata expressed in a domain-specific language (DSL), works for small sites which don’t change often. Their editors are not the most appealing to look at.

GitHub/-Lab API backend admin panels

While they build on a similar strategy to decouple content editing from the artifacts, and they shine in using contemporary PKCE authentication, they often don’t feel like real applications. Their editors are comparatively mediocre, and do not allow for a nice editing experience.

What I’m getting at with that is this: it’s a horribly complicated maneuvre to operate a fleet of configurations and running systems, which need to be instrumentable, traceable and auditable.

The cloud-native design patterns, which ultimately emerged from the Immutable Infrastructure and 12 Factors movements, contain good examples of running distributed, API-driven compute workloads at scale. IndieHosters and Assemblée Virtuelle both have experience with Kubernetes (No offense, DeuxFleurs, we hear you with Nomad.*) and would be my first address to tend to, when considering the move to containerised compute of signed immutable artifacts with the help of a CHATONS.

While the Platform as a Service (PaaS) development and deployment model allowed us to get started with the DevOps paradigm quickly, it is also limiting us now in terms of API surface, rollout, update cycles and handling application state. To ensure longevity of the Osuny Common, I am proposing to invest in increasing the resilience of the application, by gracefully upgrading its design and maintenance patterns to cloud-native Standards.

Using cloud-native design patterns will ensure replicability and help developers to get started quickly, when wanting to instantiate a complete production-like development environment from FLOSS components.

Our first step is to build the page in a development container to allow for development in GitHub Codespaces and alike. Who would be able to tell what comes after that!

Remarks

To find out what Osuny is, we voyaged through many interferencing layers. The path was crossed by surprises and concerns. I still don’t know what or where the Osuny Common is and how it distinguishes from the cooperative economy around it. But what I do know is this:

Osuny

  • is a decoupled CMS to conveniently build up a static, eco-friendly web site
  • is a large community of Commoners
  • has a cooperatively-owned host organisation that runs development projects and managed hosting with the Common
  • has institutional support and funding
  • provides a good looking and easily adaptable standard theme
  • provides a content management interface for editorial workflows

The remarkably well presentation and exceptionally transparent progress of Noesya with Osuny allowed me to trace a path from through their innerst workings out to the tiniest bits of configuration. It allowed me to learn from and iterate on my own patterns, as well as to find understanding for the things how they are.

When I wasn’t sure about something, I could always ask @arnaudlevy. At some point, many questions opened themselves, following one on the other. Because I couldn’t answer my questions myself, I had asked the documentation. Which only brought me even more questions.

Attempting to even pose them required to develop this narrative, which in places tries to cross reference back and forth to guide the reader. Be not alarmed about the length. There are people out there in different temporal regimes, which allow for different kinds of interventions. It’s a quality, not a threat. Please read the amount of consideration as a sign of diligent care for the case, not to judge when rather support would give aid.

Because, who knows, where we live with the Commons in 500 years from now?

Answering the new, improved hypothesis

The previous discoveries and argumentative considerations offer the possibility to adjust our initial hypothesis a little, in order to receive a more deliberate answer.

From: Is it possible for a computational commoning collective or Librehoster to run a replica of the Osuny application for the International Degrowth Network and possibly other communities?

To: Is it possible for a commoning collective to replicate the Osuny Common and to reproduce the Osuny application?

This change reifies the shift from looking at the mere artifacts as the Common, to also include the social forces and managerial chores, which make up a replica of Osuny. Because we are here to take care of the whole household, and not just the shiny parts we like.

Then:

What is Osuny? What is a Software Common?

Many different fields touch the provisioning of a live broadcasting Osuny instance. These involve economic affordances to cater for computational resources and the application development team. When looking from the perspective of the Common per se, these are outsourced into a cooperative, which voluntarily feeds back into the Common. Because we are talking about two systems which are non-identical (noesya & Osuny), we must introduce this interface to couple the two together.

In the Common rests a set of artifacts, which can be used to reproduce parts of the Osuny website build workflow. Only small parts of the running live infrastructure are dedicated to Commoning projects. Many of the instances are paid gigs with potentially an initial design contract and a subsequent service provisioning contract.

The digital Common is an idea that is used to communicate about Osuny and to generate attention for it. In return Osuny is used a lot to communicate the message of Computational Commoning to very diverse audiences. The service contracts of the cooperative sustain the continued development, which feeds back to the Common. There is a reciprocity involved in how these two relate. Can we find concrete examples, where no reciprocity is involved?

  • Can we highlight the informal Osuny pages without contract, which are provided as gifts by the Osuny SaaS operations team with consent by noesya?

Due to surprisingly missing technical documentation, noone ever tried to run another Osuny instance. This accidentally puts noesya into the place of being the sole vendor of Osuny, for which they have the monopoly. This centralisation of decisive force in a single location makes the line between the two blur.

Many companies, who run commercial operations and development for FLOSS, separate the management of the Common (property) into a foundation, which is independent from the company. This way other actors in the field can more easily contribute, because they are not directly working with a competitor, so to say. This level of indirection together with the usage of libre licensing has led to the cambrian explosion of contributions and cross-pollination between projects.

Let’s also use the idea for Osuny and have it work for the case. Are there ways in which the separation between noesya’s Osuny SaaS and the Osuny Common can be made more distinctive? How can I contribute to the Common and how can I participate in the collective decision making process?

There needs to be a little membrane around the body, else it dissolves.

Then we can use this diagram¹ to give names to its parts:

4000×2856 1.18 MB

¹ via Model dels 5 pilars del Procomú – femProcomuns

Associated patterns are:

To be able to answer the question if we can replicate or reproduce Osuny in some of its forms, we need to be specific about which form we mean. As there are many interwoven layers of maintenance and management involved in keeping Osuny running, it is good to consider them independently.

What is Osuny? Is it what it claims to be?
Run by a cooperative with ethical aims Enthusiastic yes!
A Common Vague maybe. Yes, but restricted to specific parts of the whole operation. Requires an arena and community for collective decision making.
Open Source Enthusiastic yes!
Free Software Careful partly?

Based on my personal interpretation of the license text

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

their come no warranties or liabilities attached with the Osuny code base. It is there, and that is just it. What we do or can do with it is written on another sheet of paper. But is Free Software really free, if it cannot be run without proprietary mandatory dependencies of a live running instance of the software?

We have to ask us this question, because as Commoners we must live up to higher Standards. Take the AGPL, for example. It wouldn’t anyone allow to run a paid service based on modifications of the source code, without them having to publish their changes. As Commoners, this is a preferable license option for web applications.

Incidentally, our writing about the new website also contained a section that goes more deeply into this subject:

I am not proposing to change the license. I am proposing to consider the whole stack of the application as part of the application. The outsourced platform services are APIs within the responsibility of your data path as any code line you write for yourselves or that you inherit by vendoring them. The platform condition thus also challenges our understanding of what is Free Software, due to the many API integrations that can be used to speed up delivery.

The whole Software Delivery Pipeline is part of the application.

 

:balance_scale: Let’s add to the idea of Freely-licensed and Open Source Software for use in Public Interest Tech an extension about similarly Free execution environments, based on the very principles and the very implementations.

 

A clear positioning on these matters would also have helped me to reduce my confusion when finding out about the conditions around the Software in question. Citing from an email conversation that sparked these posts:

When reading the Noesya and Osuny websites, I'm getting the impression, that supporting the Commons by using Free and Open Source Software is one of the core aims of the cooperative. Yet I'm finding many commercial components in the stack, starting with the dependency on GitHub, some Slack webhook, an eventual Netlify integration, Google Mail, keycdn and probably more, which could all be replaced by FLOSS components. This gives me the impression that the alignment with Commons and FLOSS principles only exists as a brand surface to gain customers, but not to engage with the FLOSS and Commons ecosystem and its values at a fundamental, say radical level. Would you like to help me out in my confusion with a few words, why this is the case?

I’m still sharing the sentiment, yet now more nuanced, after taking the time to look into the theoretical underpinnings of noesya’s work and the practical artifacts there are to work with. I still want to run this application on my own, but am now more convinced than before, that it is not possible at the current point in time.

But who can speak for a future that is yet to come?

« What do you think? Please let me know in the comments below. »

Osuny has many meanings in different contexts

Reasonably speaking, Osuny has many meanings that differ by usage context:

Name Used to call … Context
Osuny
 
  « above the line » What people will see.
+ the Community A lot of people that are involved in making and using Osuny websites
+ the Common Website, marketing story, the visible parts of the application (think: « Above the line, Below the line »)
 
+ the Product Design and development service
+ the Product Developer noesya
+ the Source Code repositories On the platforms and on the developer machines
+ the Source Code artifacts Freely downloadable, self-contained packages of the applications and their parts
+ the Documentation Application and SaaS user manual
 
+ the Service Managed hosting SaaS osuny.org
+ the Service Provider noesya
 
+ the Web Sites The content returned when requesting an Osuny web site from Deux Fleurs.
 
  « below the line » What developers and maintainers work with.
+ the instances Running code and infrastructure code that describes Osuny deployments: locally, on the server, in a container and in CI
+ the integrations Connections with services from third-party vendors
+ the infrastructure Infrastructure code that runs the SaaS application platform, PaaS-driven
 
+ the CLI Lucky us, it’s also called osuny
+ the theme Called theme, an accessibility, typography, image handling and screen size optimised Hugo theme
+ the template Called template, from which the Hugo web site repositories are generated
+ the admin back office Called admin, the interface, the API and its database model
+ the bot Runs on the Git repositories to push content changes and the workflow file, implementation unknown
 
+ the web site repositories The source codes accompanying each Osuny web site
 
+ the Garage repositories state
+ the Assets repositories state
+ the CDN repositories state
 
=
 
Osuny the decoupled website management system

Osuny, a public interest digital common
Osuny, a public interest digital common1010×345 10.8 KB

Previous article: Observations and projections from half a year of using Osuny : "Co-construire un commun numérique" pour "Devenir un commun" (4/5).
First article: Ergonomy of development experience and common reproducibility questions around maintaining degrowth.net.

2

Hey @yala that’s amazing!
I gave you the maximum confidence + moderator rights.
Thanks a lot, this means a lot and will be really helpful!

1 « J'aime »
3

@yala in fact, https://plateaux-numeriques.fr (which is a great project) tried to take care of a second instance of Osuny. And they failed. The reason is quite simple: it’s a lot of work!

This raises very interesting technopolitical questions about centralized/decentralized approaches. Decentralized is very interesting, but takes a lot of care (security, quality of service, migrations, support…). We are trying to apply a quality first vision: decentralized for website hosting, centralized for headless CMS. And we don’t care at all about people trying to replicate the whole Osuny architecture, because we feel it’s a waste of time (most of it being pro bono).

4

Take it as you will, but make no mistake: Osuny the Ruby backend is a distributed web application, but behind a centralising load balancer. It is a system that comprises of sub-systems, whether they are self-hosted or not and independent of how they are run or implemented. This is why all the products from the SaaS vendors that power Osuny are part of your code path. The care you mention we apply in any case Security, Quality of Service, Migrations, Support and the likes are also necessary for centralised application stacks.

If you can help me, which part of Osuny is finally the Common? I am not sure if you are addressing me directly with « we don’t care at all about people trying to replicate the whole Osuny architecture », or if this is a reference to something else, like the case presented above. I am asking, because I am not sure if you meant « we don’t care that you want to replicate Osuny »; or why the generalisation?

Quality-first can also mean that the application stack is reproducible, in so more people can have a voluntary look and eventually work with the code and openly contribute their diverse skills. Wasn’t that the dream behind the Commons and Free Software?

5

Hey Jon!

which part of Osuny is finally the Common?
I think the whole is a Common, made of smaller commons (the theme, the admin, the documentations, the infrastructure, even the websites themselves in a way…). That’s why we do monthly public assemblies (next one on the 4th of July Assemblée Osuny #8 | Osuny), scientific committees. We’re trying to build rituals for the community to manage the different aspects of the Common.

I am not sure if you are addressing me directly
Sorry, not at all, did not mean any harm. What I’m trying to say is that we are focused on onboarding people in the community to design, code, and contribute to websites. We did try to make it easier for the Plateaux to maintain another instance of the Osuny admin, though we were very doubtful. We learned in the process, for example we started using a proper semantic versioning and release notes. But it failed, as we expected, because taking care of an instance takes something like a full time job for one person. So we don’t give any energy to make it easier, as no-one seem concerned except us.

Quality-first can also mean that the application stack is reproducible
Fully agree! I guess we are mostly talking about the Ruby on Rails app here. We try to make everything open and documented here Contribuer à l'admin – Osuny. There are, for example, quite detailed steps about connections and references here Connexions et dépendances – Osuny. But to the moment, it’s almost only the noesya team Contributors to osunyorg/admin · GitHub.

The whole project is not only technical, but also a political and economical perspective on how we do websites. It would make perfect sense to have another Osuny in south-america, for example. We’re just not there yet, and we need to improve our processes further.

Thanks again for all this!

1 « J'aime »
6

Bonjour Arnaud.

This is developing into an interesting direction.

While I agree with the latter, I must politely disagree with the first.

My let’s say investigation led me to discovering very blurred boundaries between noesya and Osuny as its product, and Osuny the Common (of noesya and its user base) which together manages the overall direction of the project.

That is, as proposed, I would suggest to introduce interfaces (in both directions) between the two entities, to be able to draw a clearer barrier.

noesya coop + Osuny SaaS product > develops modifications to the shared code base derived from a large user base + voluntarily publishes > Osuny Common artifacts
Osuny Common community requirements > collect, refine + build up knowledge common > additional empirical experimentation for noesya to work with

As Commoners, we create these little membranes around us, to filter out the world of business interest and hegonomic logic from our praxis. From the presentation on the many websites, it is just really hard to see where the coupling points are. Maybe I am a radical Commonist, in so far, that to me cooperative money-relations are happening outside of the Common and that for a good reason.

As a suggestion to look at it: while it is noesya who receive public funding for a very specific project, it is the presence of the independently maintained Common which accommodates its outcomes and ensures its long-term sustainability. What I am getting at is: which are the practices in the Osuny community Common, which do not engage in reciprocal exchange?

I’m really interested in learning, how many non-SaaS clients of Osuny there are, how many non-paying instances that serve the General Interest?

A good reminder.

I see you are a friend of selfdogfooding already. It’s interesting to witness how the presence of an admin interface that invites for easy contributions, you can use your static website environment as a semi-dynamic web application and have it very up to date.

Often with static websites it’s just fire and forget.

Yes, the modern Software Delivery Lifecycles encourages append-only working styles with regular dated releases.

Doesn’t have to be. Depending on the automations you provide and guarantees you can give about your system, e.g. by using the other suitable abstractions, you receive other leverage points to instrument and maintain your decoupled system.

Caring for DX in terms of platform engineering and Infrastructure as Code, like the whole GitOps train, has changed the way we build software. In a good way! Deterministic builds and declarative interfaces with clear separation of the twelve factors allows to implement for more resilient application engineering patterns.

Take Scalingo, for example. Their Heroku-like git push deployment model is not as proprietary, as it may seem. With Dokku, it costs close to zero effort to replicate an Osuny instance, if good instruction is given. They probably also just build a container for you, like Dokku and the many other PaaSs, so why not do it yourselves already? Then it’s there and you can reason about it. Before that, all discussed here is a little theoretical.

I also don’t see, why nobody else would be concerned. The world is so large and there are so many groups and people struggling with the exact use case Osuny provides. Why is there sutty.coop.ar/ for Jekyll? Why are people trying to use DecapCMS or Sveltia CMS, despite their horrible UX? Because there is a global demand for such nice editors for static websites.

We are engaging in quite some intercultural dialogue here. My brain is not yet wired for connecting my technical French reading with my technical knowledge in the other two languages. Now that I take a second look at it, I am seeing some command examples.

I think the website - and Osuny in its backend - could make it easier to distinguish article drafts, those in a collaborative review process and those published. Here it’s a very deep hierarchy (four levels) with many empty pages and only little visual distinction, content spread over many pages. Many parts of pages only contain bullet points. It’s hard for me to follow a narrative under these conditions.

What I’m really asking for is just a little Docker Compose with a simple up command that gets you started right after cloning the repository, maybe even without modifying an .env example.

There is also a lot clarity to gain from this OpenAPI schema or that Rails ERD.

I’d like to understand more, how you combine these three aspects. But this may not be the space.

I’m here for the websites and the Commoning, which also involves the three kinds of perspectives, but maybe in another light? I’m looking at this without the cooperative glasses, implying my earlier conjecture about concrete interfaces inbetween noesya and Osuny. As long as they are not established, Osuny is a product.

From what I understand, noesya, or its people in their spare time, I don’t know, contributes a lot more to Osuny than Software artifacts. There is already writing documentation, engaging the community, reaching out to and involving with other partners and communities (IDN), running pro bono, in a reciprocal view unpaid, websites and probably a lot more.

Could be nice to see how others could be involved, too. For example, I’m really interested in having an English reference documentation of Osuny in my hands. I’m just clicking around in the French one and keep on getting lost in the many items and levels in the navigation tree. Is this worth a series of coordinated PRs and content changes in the admin of https://developers.osuny.org/? Which editorial workflows are recommended for Osuny?

While I could theoretically fork the repository and recreate the data structure locally, it seems limited by how many separate writing environments there are for the development. website, and how content changes progress between them. Would you happen to have a means to reimport content changes and new content from pull requests at your disposal? Does Osuny have a feature that allows me to check out « a branch » of the database for an individual website, edit ahead and then reintegrate that?

Let’s make it happen! I’m already looking forward to rip Osuny admin apart and to put it back together.

This should eventually be a prepared, documented and funded endeavour. But nobody stops us from requirements collection and seeking cooperation partners, for the Common and out in the open.

There is also a conversation to be had about publishing ActivityPub. You already have a long-running process (daemon) that can handle medium amounts of changes per time interval (limited by CI velocity & concurrency).

À la prochaîne

Edit:

PS: slsa.dev/ presents us with Supply-chain Levels for Software Artifacts (SLSA), which can be attested and verified.

PPS: This is a nice example of a similar system, too. Website Factory: NGO — Commit Global « The only Website Builder designed specifically for NGOs. » :wink:

PPPS: The Codespaces example for using a development container to build a web page is now here:

7

Update:

This article has a nice compilation of arguments for (1) using the AGPL and (2) decoupling the whole stack of an application from Commerce and open sourcing it into the Commons.