Collaborative work on malleable software

Forging Software versus Software Forges

There’s something very interesting here, and it touches on the notion of App Free Computing too. There is the ForgeFed specification that provides guidance how software forges can integrate, and allow working on any repository regardless of its location. First of all I’d like to mention that an implementer is free to implement their own process using this specification. One that is more in line of what’s needed for malleable software collab.

Going from there, more interesting to consider is: What is a software forge?

Well, it is an App, and it provides UI’s and abstractions that expose you to an application domain. This application domain in turn serves to help you be more productive in a particular business domain. This (top-level) business domain is nothing less than Software Development itself.

Now a problem statement:

:warning: In code forges typically the application domain has become more dominant than the business domain.

All forge softwares are more or less similar in what they offer. A representation of the file hierarchy of the codebase, a list of issues, a list of patches to review, wiki pages, etc. Now consider this:

  • Where is the software development process in this software abstraction?
  • How can I track stakeholder Needs being delivered as concrete features, and keep monitoring them?
  • In this Developer-oriented tool, how can I involve other stakeholders in a multi-disciplinary fashion?

If we go back to the potential that the Fediverse might unleash, we shouldn’t talk about “forge federation” (application domain), but “federated software development” (business domain). Together with App Free Computing this might unlock a vast ecosystem where many people contribute the building blocks in which malleable software can be delivered.

@jryans passed me this link to Situated Software written by Clay Shirkey. It contrasts, what it calls Web School software (basically the entire Web 2.0 high-scale generic platforms), with Situated Software that is tailored for small groups (“Software for your Mom”). With App Free Computing in mind, situated software would be composed from small building blocks that can be universal and reusable. Component-oriented programming. A choreography of small components. Joyful creation of social experiences.

This fits the family tree and layers idea of @akkartik, as well as the notion of Freewheeling apps. If I look at the layers post, I consider the larger blocks to be similar to the Bounded Contexts of Strategic Design in DDD.

Now, back to forges. It is clear to see that they are typical Web School applications. A lot of flexibility and possibillities to accurately support real-world development processes are lost this way. They provide a straitjacket set of features to conform to. And instead of fully supporting the existing development lifecycle, it must be adjusted to adopt work processes to the capabilities of the software forge.

If we go back to considering the business domain of software development, and how it might be supported in a component-oriented manner, we can ditch the restrictions this app places on our imagination.

Why, for instance, do I need to think about the file hierachy of my codebase? The namespaces (modules, clases, whatever they are called) and logic branches in the code itself are the real structure after all, and they are a graph. There are best-practices for chunking code into files, both in language-specific and project-specific conventions. This could be done by the tool.

And how would my codebase be best represented in terms of UX/UI if it allowed me to at any time drill down from stakeholder Needs into functionality and features delivered?


Update: I must remark here that when it comes to software forges, the big platform providers and innovative startup vendors, are in a shift towards a new paradigm where they offer Web School type one-stop-shop experiences on their platforms that facilitate a broader part of the software development lifecycle and more stakeholder types. This trend is Not Good™ for open ecosystems and software freedoms in general. It cements the already overly dominant position of Big Tech platforms. Github is of course a prime example, and you can check out Github Next for a taste of what’s coming.

2 Likes