Decentralisation isn't a collection of technology. Rather, it's a set of principles or tenets. It's above all the by-product of the choices one makes.
Sure, you can install a gazillion packages, use serverless, static site generators, SaaS platforms, install CMS x, y or z.
But then again, you can still use a simple FTP program, copy HTML files over TCP/IP to a remote server with a process running in the background that listens for incoming HTTP requests. Your browser will still be able to from the HTML it receives via a HTTP response. In fact, you don't need a browser. Curl or Telnet will yield a string of text characters any human can read.
Those basic protocols still exist after 30 years and underpin the Web. Nothing changed fundamentally, when you dig deep.
As such, you could lease a shared hosting somewhere and put up your own set of HTML pages and slap a DNS domain to the IP of the server. Boom. Congratulations. You own a website now.
Decentralisation - at it's core - is about ownership. If you put content and data on a host, who owns that? You or the owner of the host? This is where the entire discussion becomes a legal debate.
The big shift of the past decade is that social media offer easy access to centralised hosts they own. This has caused a massive influx of users to publish stuff on hosts that are owned by others.
Meanwhile, there's this perception that you need a gazillion tools to build a website. That you need deep knowledge of languages and such to publish HTML formatted content on a host you own.
This couldn't be further from the truth. Unless you are a business, or an organisation and you need to manage tons HTML formatted content, you can do away with a text editor, basic HTML and shared hosting you pay a tuppence for.
The only reason why things got complex because of business reasons.
I suppose the entire point of open sourcing software is to take a step back from generating revenue through IP.
That doesn't exclude charging for the hours one put in solving specific issues or requests raised by third parties.
Open source only provides a legal framework that defines the terms by which one distributes code. It was never intended to be a business model in the first place. Not does the entire concept claim to be a business model.
As such, all software projects being equal, choosing a permissive or proprietary license is just a fork in the road.
The bigger picture here is the intent and motivation of developers that drives them to build software and share it with the world. Sadly, the hard truth is that there's no such thing as a free lunch. If you provide the output and the labour for free, discussing that such efforts are unsustainable is a bit of a cognitive dissonance on the part of the maintainers.
It's totally valid to write code, release it for free and then charge users for the maintenance of the tool. That is, put a figure to issues and only solve them as a maintainer when enough users care to chip in the hard currency to cover the time.
Sure, many FOSS maintainers don't do it for the money. They simply want to have a positive impact on the world. Share something cool with the world. Assert their identity as the author of their own creative vision. But if history teaches anything, great artists have always walked this tight rope between covering living costs through patronage and finding freedom and artistic license to actualise their own vision.
Hypothesis: most users on social media wouldn't publish or share content, let alone leverage RSS, if those platforms didn't exist.
Social media emerged alongside existing technologies. And they attracted a whole new audience. Of course, there's been a migration from former self hosted users towards those social media.
An apt comparison is IRC. It existed for decades now, but the concept of an office group chat never quite got successfully poured into a business model until Slack came around. Organisations using Slack didn't necessarily shift away from IRC or other options. They simply didn't use chat until they jumped on the Slack bandwagon.
I do recall criticisms when GR was unveiled: why use a centralised online service in order to consume a distributed network of content? At that point, GR did overtake the market of RSS clients.
Axing GR was the exact turning point for RSS as that happened exactly during the meteoric rise of social media, leaving many with little alternative to turn towards social media. Remember that at that point, Big Tech was perceived as the "Good Guys" and many touted that this was just the natural state of affairs.
I used to be a heavy RSS user, but when GR got axed, that pretty much fell away overnight. I never quite got back to using RSS via an alternative.
Alexander of Macedonia conquered a vast empire right up to the Indus River.
Then there's the Silk Road who connected the Eurasian continent economic, cultural and political influence for centuries.
So, the spread of ideas across cultures is pretty much established.
The problem is that the survival of specific historic records across centuries or millennia is tenuous at best. First hand accounts are extremely rare and most of what we know about those times was handed down by copying what was deemed relevant throughout time.
Lesson number one each historian learns is to ask critical questions about the source material. Who wrote this? What do we know about the contemporary context? Does other material corroborate with what we are reading now? How about our own hindsight bias when reading records today? What about other biases that played out at the time?
Oftentimes, it's not possible to ascertain a theory or a hypothesis, how things actually went down, simply because we lack the source material. And just as often we may get caught unaware by our own assumptions that were handed down to us by teachers, authors, movies, art,...
As such, most historians will tell you that while it's plausible that the origins of some technologies root back further in time, there's little point in looking for evidence as there is simply no historic or archaeological record available. That's where you'll find that a falsifiable theory turns into mere speculation.
A historical researcher therefore only builds on top of verified sources. Much like a criminal investigator trying to establish the raw facts that support a given narrative.
That's what we are debating here: is this claim that use of UML is always markedly better when modelling any problem domain is true as observed through a sufficient number of data points?
I'm poking holes in that hypothesis because there's always n + 1 conceivable use case where the opposite is true. And I'm basing myself on set theory and computational algebra.
The crux is 'sufficient' because all use cases that could be moddeled with UML being equal, prove to me that there is a finite amount of use cases. Hard answer: you can't.
Moreover, there is no way you can prove to me that each and any use case is solvable with UML in an efficient way without actually solving said use case.
I think the answer to your question would be: it depends on external constraints. How much time do you have? What is the scope of the project? Size of your team? Number of stakeholders? Budget? Etc.
In my mind, the crux of the entire exercise is trying to translate a complex murky real world problem domain into a mental model that can be expressed via a shared language describing properties, aspects, processes, concepts, etc.
The challenge is getting that translation done in a timely, secure, efficient, performant, maintainable manner.
Quantifying that translation into a comparable measure? That's where you'll find your in the same boat with many other project managers who make guestimates and hope that everything pans out in the end.
Trying to see it as a purely computational problem will confront you with that other evergreen: the P equals NP problem.
My point is that trying to find a hard model that answers your particular question pertaining to UML is very hard since there is no neat general foundational model here that allows you to compute hard, quantifiable predictions about the usefulness of a given tool.
I suppose it's like with so many trades. It depends on the experience of the expert to assess what strategy is best. It's okay to question that experience in hopes of avoiding all too human biases that cloud our view from what we are actually trying to solve. Even so, questioning any and all statements because you can't boil it down to hard data equally might threaten to narrows one's view.
If your experience tells you that UML works for you as a tool, then, by all means, stick to UML. Even when there is more then one approach to a solution. If you use pen and paper to quickly draw stuff, well, that's equally valid if that works for you. I just wouldn't dismiss an approach because its usefulness can't be measured up front. Reality is far too complex and sometimes there's simply no point in dwelling too much upon all of this in the first place.
Sure, you can install a gazillion packages, use serverless, static site generators, SaaS platforms, install CMS x, y or z.
But then again, you can still use a simple FTP program, copy HTML files over TCP/IP to a remote server with a process running in the background that listens for incoming HTTP requests. Your browser will still be able to from the HTML it receives via a HTTP response. In fact, you don't need a browser. Curl or Telnet will yield a string of text characters any human can read.
Those basic protocols still exist after 30 years and underpin the Web. Nothing changed fundamentally, when you dig deep.
As such, you could lease a shared hosting somewhere and put up your own set of HTML pages and slap a DNS domain to the IP of the server. Boom. Congratulations. You own a website now.
Decentralisation - at it's core - is about ownership. If you put content and data on a host, who owns that? You or the owner of the host? This is where the entire discussion becomes a legal debate.
The big shift of the past decade is that social media offer easy access to centralised hosts they own. This has caused a massive influx of users to publish stuff on hosts that are owned by others.
Meanwhile, there's this perception that you need a gazillion tools to build a website. That you need deep knowledge of languages and such to publish HTML formatted content on a host you own.
This couldn't be further from the truth. Unless you are a business, or an organisation and you need to manage tons HTML formatted content, you can do away with a text editor, basic HTML and shared hosting you pay a tuppence for.
The only reason why things got complex because of business reasons.