Forges and the positioning of Github and Gitlab
In chatroom discussion @dachary posted:
But … every developer knows what a forge is. Even though they all have different ideas, they more or less relate to “a set of tools they use to work on software”.
I first learned the term when I bumped into ForgeFed. Never heard or used it before then. I’d want to say, be careful, as there are biases creeping in because of our exposure to terms and technology. Same maybe with name recognition of Gitea, where likely the vast unkempt hordes using Github don’t know about it. Github has a large wikipedia page. Do you know how many times the word “forge” is used? 6 times… as part of the ‘brand’ name “SourceForge”.
This relates to why I am an advocate of modeling consistent sub-domains that map directly to the software development lifecycle, i.e. to categorized activities that IT technologists (multiple stakeholder types, the domain experts) perform. If we look at Github’s introduction text on Wikipedia:
GitHub, Inc. is a provider of Internet hosting for software development and version control using Git. It offers the distributed version control and source code management (SCM) functionality of Git, plus its own features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, continuous integration, and wikis for every project.
I think this is not the best split from a domain analysis perspective, yet as a fresh start to this analysis I’d note down:
- “Internet hosting for software development” → top-level domain
- Distributed version control, source code management, bug tracking, feature requests, task management, continuous integration → sub-domains
- Access control, wikis → supporting domains
Another example. The Gitlab Wikipedia page. 1 occurance of “SourceForge” in the footnotes listing “Bug Tracking Systems”
Here in the introductory text Gitlab is described as:
a DevOps software package that combines the ability to develop, secure, and operate software in a single application.
→ top-level domain
It would be interesting to study the websites of both companies and distill their mission / vision / product portfolio positioning from there.
Going to the Github About page it becomes immediately clear what their “completeness of vision” entails…
Github: Where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub—the largest and most advanced development platform in the world.
Key words: Build software. Build, ship, maintain. Most advanced development platform.
There’s no direct mission/vision statement, but just on the About page some more indicators on how they view their own products and their scope:
We’re focused on fighting for developer rights by shaping the policies that promote their interests and the future of software.
Let’s do the same for Gitlab from their About page…
Gitlab: The One DevOps Platform
From planning to production, bring teams together in one application. Ship secure code faster, deploy to any cloud, and drive business results.
For every stage of the DevOps Lifecycle
Eliminate point solution tool sprawl with our comprehensive platform.
They actually have a lifecycle diagram on their page:
Plan → Create → Verify → Package → Secure → Release → Configure → Monitor → Protect → Manage
Their about page provides a wealth of information on doing productization well.
Now, it becomes interesting to see how Gitea contrasts to that. From the landing page there are only 2 direct top-level domain / product-related statements:
- A painless self-hosted Git service.
- Lightweight code hosting solution
The rest of the page, while relevant, highlights that it is FOSS, that it is maintained by a community, that it is easy to install + host. In terms of productization it is by far not the worst I’ve seen in FOSS circles, but there’s a lot to improve. I recently on the Open Strategy megathread contrasted Lemmy and Mastodon landing pages as a good example (where Lemmy represents a typical FOSS website).
Also discussed in chat by me in reaction to Ryuno Ki on future plans of MS/Github:
I have mentioned my thoughts on where I think Github is headed in earlier chat (scroll some miles upwards
)
TL;DR going to a situation where your browser is a dumb UI terminal, and on any project complete executing environments run in the background / in the cloud (Azure mostly), and you just edit the code. Even git and your code files may be abstracted away.
If I were them and went for max. lock-in I’d abstract away code files altogether. Have you navigate a language and architecture dependent logical data model instead. Then if you work offline you sync a execution environment package that has the abstract syntax tree of that. Bye bye git, the future has arrived.
There might be a git repo export to comply to regulation (like GDPR, Digital Markets and Services Acts of the EU).
Let’s thwart that future with federated FSDL
There is the general concern / risk that the use of words as “forge” lead to a dogmatic approach and not seeing the broader landscape. Because there’s a certain notion of what a forge is and is not.
I have argued before: A forge is really a type of application, it does not demarkate a generic ‘business domain’. There’s no would-be developer that says “give me a forge, I want to be a developer”. Instead they master skill after skill, explore domain after domain and become domain experts in fields of software development.
Re: The word “Forge” it is interesting to analyse the Wikipedia page that mentions it. It is undoubtedly written by a FOSS developer. Now if you would ‘productize’ such page in the same way Github / Gitlab did for their platforms… there’d be a big improvement.