A who, what, where, when, why and how guide to choosing technology based on needs rather than ecosystems
We have become accustomed to buying software the way we buy a buffet.
Need a word processor? Here is an entire productivity suite.
Need email? Here is cloud storage, a calendar, video meetings, collaboration tools, identity management and an AI assistant.
Need to edit a PDF? Here is a complete document ecosystem.
Need a spreadsheet? Here is a subscription that also gives you dozens of applications you may never use.
There is nothing inherently wrong with this model. Bundling can be convenient, and integrated products can genuinely save time. The problem begins when we stop asking whether we actually need the entire buffet.
That is where the idea of digital sovereignty becomes useful.
Digital sovereignty does not have to mean abandoning Microsoft, Google, Adobe, Apple, Amazon, Zoho or every other proprietary technology company. Nor does it mean replacing every proprietary application with an open-source equivalent regardless of whether the alternative is suitable.
A more practical definition is this:
Digital sovereignty means understanding what you need, choosing technology deliberately, controlling your important data and processes, and retaining the ability to change your tools when circumstances change.
In other words: build the process first, choose the tools second.
Who Needs Digital Sovereignty?
The first mistake in discussions about digital sovereignty is assuming that it is primarily a government or national-security issue.
It is certainly relevant to governments. A country that cannot operate essential digital infrastructure without foreign vendors has a strategic dependency. But sovereignty exists at many levels.
- An individual can become dependent on one cloud provider.
- A family can put its photographs, documents and communications entirely inside one company's ecosystem.
- A small business can build its entire workflow around one SaaS provider.
- A large company can become dependent on proprietary databases, APIs, identity systems and cloud services.
- A government can become dependent on a particular vendor for citizen-facing infrastructure.
- An entire country can become dependent on foreign technology for computing, communications, software and hardware.
The scale changes, but the underlying question is similar:
What happens if we need to change?
If the answer is “we can export our data and move to another tool,” the dependency may be manageable.
If the answer is “we would have to rebuild our entire organisation,” we have created something much more serious.
What Is Digital Sovereignty?
Digital sovereignty is sometimes reduced to a slogan:
“Use open-source software.”
Open source is extremely valuable, but that definition is too narrow.
Consider a professional video editor who needs a particular 4K60 HDR workflow. A proprietary application may provide better support for a particular codec, GPU acceleration, camera format, colour-management pipeline or delivery requirement. If the open alternatives cannot reliably produce the required result, insisting on open source at any cost is not sovereignty. It is simply refusing to use an appropriate tool.
Likewise, a government service might use open-source technologies extensively on its backend while requiring citizens to interact through a particular browser, signing mechanism, proprietary driver or other closed component.
Open infrastructure, open standards, open source and an open user experience are related ideas, but they are not identical.
The objective therefore should not be:
“Everything must be open.”
It should be:
“Every dependency should be intentional.”
That is a much more achievable goal.
Who, What, Where, When, Why and How?
The simplest way to make digital sovereignty practical is to treat it as a 5W1H exercise.
Who?
Who will use the technology?
A single home user, a family of six, a ten-person business and a government department have completely different requirements.
A family might need nothing more than document editing, photo storage, backups and a shared calendar.
A small company might need accounting, email, office documents, customer records and collaboration.
A large organisation might need central identity management, auditing, compliance, disaster recovery, data retention and thousands of simultaneous users.
The mistake is buying technology designed for the largest possible organisation when your actual requirement is much smaller.
Start with the users, not the product catalogue.
What?
What exactly needs to be accomplished?
This is probably the hardest question in the entire software-selection process.
People often describe requirements using product names:
- “I need Microsoft Office.”
- “I need Adobe.”
- “I need a cloud.”
- “I need an ERP.”
- “I need an AI platform.”
But these are solutions, not requirements.
The actual requirement might be:
- Write ten documents per month.
- Maintain one financial spreadsheet.
- Edit PDFs and add signatures.
- Synchronise files between three computers.
- Maintain a searchable internal knowledge base.
- Share a calendar between ten people.
- Produce professional 4K video.
Once the underlying task is identified, the list of possible solutions becomes much larger.
Where?
Where does the software need to operate?
On a Windows PC?
On Linux?
On Android?
Offline?
On a home server?
In a company's own datacentre?
In the cloud?
On a browser?
On specialised hardware?
This question can eliminate otherwise attractive software very quickly.
A superb cloud application isn't necessarily suitable for someone who needs reliable offline operation. Conversely, maintaining a self-hosted server may be unnecessary complexity for a small organisation that simply needs dependable email.
When?
When is the capability actually required?
This sounds obvious, but it is one of the easiest ways to overspend.
Technology is constantly sold on the basis of what it might become useful for.
But buying tomorrow's requirements today can be almost as wasteful as ignoring tomorrow completely.
The better question is:
What do I need today, and what is reasonably likely to change?
This is where wiggle room becomes important.
Good technology choices should leave room for expansion without requiring you to purchase an entire enterprise architecture on day one.
Why?
Why do you need the capability?
This question can expose surprisingly weak assumptions.
“Everyone uses it” isn't a requirement.
“Our IT consultant recommends it” isn't a requirement.
“It has 500 features” isn't a requirement.
“It has AI” isn't a requirement.
The requirement might simply be:
“We need five employees to create and exchange ordinary business documents.”
That could potentially be satisfied by several products with radically different prices and architectures.
How?
Finally:
How should the requirement be fulfilled?
Only now should we start choosing software.
This is the point where we compare open-source, proprietary, free, paid, perpetual, subscription, local, cloud and self-hosted options.
The Most Important Question: What Is the Minimum That Works?
Modern software marketing has trained us to ask:
“Which product has the most features?”
A better question is:
“What is the least complicated tool that can perform the job properly?”
If LibreOffice handles the job, why buy a subscription?
If a lightweight PDF editor handles the required PDF operations, why buy an enormous document-management platform?
If a local file server solves a family's storage problem, why automatically place everything in a cloud subscription?
And conversely, if Microsoft Office saves a business substantial amounts of time because its Excel, Outlook or collaboration capabilities genuinely matter, then paying for Microsoft Office can be the correct decision.
The objective isn't to minimise spending at all costs.
The objective is to minimise unnecessary dependency.
The Office Suite Is a Perfect Example
Take something as ordinary as an office suite.
Microsoft Office remains an extremely capable product. For some users, it is unquestionably the right choice.
But it is not the only choice.
There are mature alternatives including LibreOffice, ONLYOFFICE, SoftMaker Office, Ashampoo Office, WordPerfect Office, Ability Office, Calligra and others.
ONLYOFFICE Desktop Editors, for example, are open source under the AGPL v3, can operate without a constant Internet connection and support DOCX, XLSX and PPTX. Its desktop applications also integrate with platforms such as Nextcloud and ownCloud for collaborative workflows.
LibreOffice provides another major open-source option, with a mature desktop productivity suite rather than a cloud subscription.
The point isn't that one of these products is universally “better” than Microsoft Office.
The point is that Microsoft Office is not automatically the answer simply because the requirement is “office work.”
The actual requirements should decide.
The Microsoft Tax — But Without Making It the Whole Argument
There is also an interesting economic dimension.
Microsoft's Indian store currently lists Office Home 2024 at ₹10,999 for one PC or Mac, for non-commercial use. Office Home & Business 2024 is ₹27,999 and adds Outlook while permitting use at home or work.
That does not mean the entire difference is simply a charge for Word, Excel and PowerPoint. Commercial licensing is itself a legitimate distinction, and Outlook has value.
Nevertheless, it illustrates an important principle: the same underlying productivity tasks can have very different economics depending on licensing model and customer category.
The subscription model makes the comparison even more interesting. Microsoft's current Indian business pricing includes separate offerings for desktop applications and broader packages that add cloud storage, business email, identity management, collaboration and other services.
For a large enterprise, that bundle may be extremely valuable.
For a small office that simply needs word processing, spreadsheets and presentations, it is worth asking whether the organisation actually needs the entire bundle.
That is the real question:
Do we actually need these capabilities badly enough to justify the subscription, ecosystem dependency and migration costs?
And the same question should be asked of Google, Adobe, Zoho and every other major software vendor.
Stop Comparing Ecosystems. Compare Tasks.
This is perhaps the biggest mental shift.
Suppose someone says:
“I need a Microsoft 365 alternative.”
That may be the wrong question.
What does Microsoft 365 actually provide to this particular user?
- Word?
- Excel?
- PowerPoint?
- Email?
- Calendar?
- File synchronisation?
- Video meetings?
- Team chat?
- Shared documents?
- Intranet?
- Identity management?
- AI assistance?
Once the bundle is separated into requirements, entirely different solutions become possible.
Instead of finding one “Microsoft 365 killer,” an organisation might assemble a stack from several independent components.
The Open Productivity Stack
This is where projects such as Nextcloud, Tiki, EGroupware and XWiki become relevant.
They should not all be described as Office alternatives. They solve different problems.
Nextcloud is better understood as a self-hosted collaboration and cloud platform around files, synchronization and a growing ecosystem of applications.
EGroupware occupies the groupware side of the equation, bringing together capabilities such as email, calendars, contacts, project and collaboration functions.
Tiki is much closer to a wiki, CMS and groupware platform. Its documentation describes it as a broad collaborative environment, with wiki pages, history, permissions, categorisation, attachments and other tools.
XWiki is particularly interesting for organisations that need structured knowledge management and enterprise wiki capabilities.
These systems therefore don't replace Word or Excel directly. They replace pieces of the ecosystem surrounding Word and Excel.
The distinction matters.
A possible open/self-controlled stack could look like:
- LibreOffice or ONLYOFFICE — documents, spreadsheets and presentations
- Nextcloud — files, synchronisation and collaboration
- XWiki or Tiki — organisational knowledge
- EGroupware — groupware and organisational workflows
- Joplin — personal notes
- Immich — personal photo management
- Paperless-ngx — document archive
- Kiwix — offline knowledge
It doesn't have to be deployed all at once.
That is another important part of sovereignty: you can migrate progressively.
The 4G–5G Lesson
There is a useful analogy in telecommunications.
5G is not simply “better 4G.” It introduces different capabilities and can provide major advantages in the right circumstances.
But the existence of 5G does not make 4G useless.
India's experience illustrates the point. 5G deployment has expanded enormously, but the proportion of mobile data actually carried over 5G has not simply followed the percentage of population covered. Analysts have pointed to factors including limited use cases and questions around return on investment.
The broader lesson is more important than the precise telecommunications numbers:
A technically superior technology is not automatically the correct technology for every use case.
If 4G provides everything a user needs, the user does not have to feel technologically backward for remaining on 4G.
If 5G's additional capability matters, use 5G.
The same principle applies to software.
LibreOffice may be sufficient.
ONLYOFFICE may be more compatible with a particular workflow.
Microsoft Excel may be indispensable for a particular organisation.
A proprietary video editor may be worth its price.
A proprietary GPU driver may be necessary for a particular hardware configuration.
There is no contradiction.
When Proprietary Software Is the Right Choice
This is where a sensible digital-sovereignty philosophy must avoid becoming ideological.
There will always be situations where proprietary software is the best practical option.
Professional video production can require specific codecs, hardware acceleration and production workflows.
Engineering may depend on specialist CAD or simulation software.
Scientific research may depend on specialised applications.
Government systems may require particular client software, authentication systems or signing mechanisms.
Businesses may depend on industry-specific applications for which no mature open-source replacement exists.
None of this means that sovereignty has failed.
The relevant question is:
Is this dependency necessary, or did we simply accept it without evaluating alternatives?
If Adobe is the best solution for a particular PDF workflow, use Adobe.
If Microsoft Office is the best solution for a particular spreadsheet workflow, use Microsoft Office.
If a proprietary video tool is the only realistic way to deliver a required production format, use it.
There is no shame in buying the right tool.
The mistake is assuming that the vendor's entire ecosystem must accompany it.
Don't Be the Sheep: Evaluate the Category, Not the Brand
Consider PDF editing.
The requirement is:
“I need to edit PDFs.”
That sentence should not automatically produce:
“Therefore I need Adobe Acrobat.”
Instead ask:
- Do I need to edit existing text?
- Do I only need annotations?
- Do I need signatures?
- Do I need OCR?
- Do I need form creation?
- Do I need batch processing?
- Do I need redaction?
- Do I need to edit hundreds of PDFs?
- Do I need enterprise document management?
Perhaps Adobe is the answer.
Perhaps another commercial application is better.
Perhaps an open-source tool is sufficient.
Perhaps the task can be accomplished with several smaller tools.
The important thing is that the requirement came before the brand.
The same principle applies to office suites, photo editors, video editors, password managers, cloud storage, databases, browsers, operating systems and almost every other software category.
Requirements Are Harder Than Software
Ironically, the hardest part of software selection is often not evaluating software at all.
It is discovering what the requirement actually is.
Software products are concrete. Requirements are abstract.
It is easy to say:
“Let's buy an ERP.”
It is much harder to describe exactly how the organisation currently handles purchasing, inventory, invoicing, approvals, accounting and reporting.
It is easy to say:
“Let's build an app.”
It is much harder to answer:
- Who will use it?
- What problem does it solve?
- What happens today without it?
- What is the minimum useful result?
- What information does it need?
- What happens when the number of users grows?
- What happens when the original developer leaves?
- What happens if the service disappears?
This is why requirements engineering is often more important than technology selection.
Technology should be the implementation of a requirement, not the substitute for one.
The Questions Every User Should Ask
Before adopting a significant piece of software, a surprisingly short checklist can reveal a great deal.
About the task
- What exactly am I trying to accomplish?
- What does success look like?
- What is the minimum functionality I require?
- Which features will I actually use?
About growth
- Could the number of users grow?
- Could the amount of data grow substantially?
- Will collaboration become important?
- Will offline access become important?
- Will security or compliance requirements change?
About dependencies
- Does this require a particular cloud?
- Does it require an account?
- Does it require a particular operating system?
- Does it require a particular vendor's hardware?
- Does it lock data into a proprietary format?
About exit
- Can I export my data?
- Can another application open it?
- Can I download everything in bulk?
- Can I operate locally if the cloud disappears?
- Can I migrate without the vendor's cooperation?
- How much would switching cost?
About reality
- Can I actually administer this?
- Can I afford the maintenance?
- Do I have the skills to self-host it?
- Would paying for a managed service actually reduce unnecessary complexity?
The last question is particularly important.
Self-hosting isn't automatically more sovereign if the organisation cannot maintain the server properly.
A badly maintained self-hosted system can be less secure than a professionally managed commercial service.
Sovereignty includes realistic operational capability.
The Exit Test
Perhaps the most powerful question in technology purchasing is one that is almost never asked:
“If I decide this was the wrong choice two years from now, how difficult will it be to leave?”
There is a world of difference between:
“Export the files, install another application and continue.”
and:
“We have five years of proprietary data, 200 workflows, 500 employees, dozens of integrations and our identity system tied to this vendor.”
The first is a tool.
The second is an ecosystem dependency.
This is why open formats, standard protocols, documented APIs, local copies and good export facilities matter so much.
They preserve optionality.
Open Formats May Matter More Than Open Software
It is tempting to think:
“Open-source software equals sovereignty.”
But consider two applications.
Application A is open source but stores everything in a difficult-to-migrate format.
Application B is proprietary but allows complete export into well-documented, widely supported formats.
Application B may actually be easier to leave.
This is why open standards deserve as much attention as open source.
For documents, widely supported formats can make it possible to move between Microsoft Office, LibreOffice, ONLYOFFICE, SoftMaker and other applications.
For data, standard export formats and APIs can prevent an application from becoming a permanent repository.
For infrastructure, standard protocols can make it possible to change providers.
The ability to leave is itself a form of sovereignty.
The Three Layers of Choice
A useful way to think about digital independence is to separate three ideas.
Process sovereignty
Do we understand our own workflow?
Can we describe what we actually need without naming a vendor?
Tool sovereignty
Can we choose among multiple tools?
Are we evaluating competing solutions rather than automatically selecting the market leader?
Exit sovereignty
Can we change our mind later?
Can our data, knowledge and processes survive a vendor change?
These three layers are more useful than simply asking whether a particular application is open source.
The Buffet Problem
Perhaps the biggest change in software over the last decade has been the move from individual applications toward ecosystems.
A traditional software purchase looked something like:
Buy Word → write documents.
The modern cloud ecosystem can look more like:
Buy Microsoft 365 → receive Word, Excel, PowerPoint, Outlook, OneDrive, Teams, SharePoint, identity services, collaboration features, AI and more.
Google and Zoho have similar ecosystem strategies.
Again, the bundle isn't necessarily bad.
It can be exceptionally convenient.
But convenience has a hidden cost:
The more parts of your organisation depend on the same ecosystem, the harder the ecosystem becomes to leave.
That is the buffet problem.
You didn't necessarily need everything on the table.
But once you have built your workflow around it, you may find it difficult to stop paying for the entire meal.
À La Carte Sovereignty
A more sovereign approach is to choose components based on actual needs.
For example:
Documents: LibreOffice or ONLYOFFICE.
Files: Nextcloud or another suitable storage system.
Knowledge: XWiki or Tiki.
Groupware: EGroupware or another appropriate solution.
Photos: Immich.
Notes: Joplin.
Offline knowledge: Kiwix.
And if a proprietary application is genuinely superior for one particular task, add it.
There is no requirement that the entire stack be provided by one company.
This modularity can also make the system more resilient.
If one component becomes unsuitable, replace that component rather than replacing the entire digital environment.
Don't Over-Engineer Sovereignty
There is another trap waiting on the opposite side.
Once people discover self-hosting and open-source software, it is tempting to build an enormous stack simply because it is possible.
A home user who needs shared family photographs may not need a Kubernetes cluster.
A five-person company may not need to operate its own mail server.
A freelancer may not need a complete enterprise groupware platform.
A person who edits two PDFs a month probably does not need to construct an elaborate document-management system.
The same process-first philosophy applies to open technology itself.
Don't build an unnecessarily complicated sovereign system.
Build a system that is sufficiently independent for the risks and requirements you actually have.
Digital Sovereignty Is Not Technological Purity
There is no perfectly open computer.
Modern computing contains layers of firmware, drivers, hardware interfaces, codecs, standards, patented technologies and proprietary components.
Even a Linux workstation may rely on closed firmware or proprietary hardware support.
Likewise, an open-source software stack may need to communicate with proprietary systems outside its control.
Trying to eliminate every proprietary component can therefore become an impossible or counterproductive objective.
A better goal is open dominance with controlled exceptions.
Use open technology where it is mature and appropriate.
Use proprietary technology where it provides a meaningful advantage.
Document the dependency.
Understand its cost.
Know the alternatives.
Keep an exit route wherever practical.
What This Means for Businesses
Businesses should perhaps be the biggest beneficiaries of this way of thinking.
Before purchasing a major platform, management should be able to answer:
- What problem are we solving?
- What processes will change?
- Which features are genuinely required?
- Which features are merely attractive?
- What data will enter the system?
- Where will that data live?
- What happens if prices rise?
- What happens if the vendor changes its product?
- What happens if the vendor is acquired?
- What happens if the service disappears?
- What would migration cost?
These questions shouldn't necessarily prevent purchasing the product.
They simply ensure that the purchase is a conscious decision.
Sometimes the conclusion will be:
“Microsoft 365 is clearly the best choice for us.”
Good.
Sometimes it will be:
“We only need office applications, so a perpetual commercial suite is sufficient.”
Good.
Sometimes:
“LibreOffice and Nextcloud cover almost everything we need.”
Also good.
The important part is that the organisation understood the choice.
What This Means for Individuals
The same principle works at home.
Ask:
Where are my photographs?
Where are my documents?
Where is my email?
Where are my contacts?
Where is my calendar?
Where are my passwords?
Where are my backups?
Can I retrieve everything?
Could I switch providers without losing years of information?
You don't have to self-host everything.
You don't even have to stop using Google, Microsoft or Apple.
You simply need to know where your dependencies are.
A person who knows that all their photographs are in Google Photos and has a current independent backup may be in a much stronger position than someone who has moved everything to an ostensibly “open” system but has no backup or recovery plan.
And This Is Also How Software Should Be Built
The process-first philosophy doesn't stop at choosing software.
It applies to creating software as well.
Developers can make exactly the same mistake as consumers.
“Let's build an app using the latest framework, AI model, cloud platform and twelve managed services.”
But what problem are we solving?
A better sequence is:
- Define the problem.
- Identify the users.
- Define the desired outcome.
- Identify the minimum viable process.
- Define functional requirements.
- Define non-functional requirements.
- Identify constraints.
- Consider likely future changes.
- Design for reasonable expansion.
- Choose the architecture.
- Choose the technologies.
- Build.
- Measure.
- Change when the requirements change.
Notice how technology comes surprisingly late.
That is intentional.
Technology should serve the process.
Digital Sovereignty as Optionality
Perhaps the simplest way to express the entire idea is through one word:
Optionality.
Open software gives you an option.
Open formats give you an option.
Local copies give you an option.
Self-hosting gives you an option.
Interoperable standards give you an option.
Multiple vendors give you an option.
Good export tools give you an option.
Even a proprietary application can fit into a sovereign strategy if it is a deliberate choice rather than an unavoidable dependency.
Suppose Adobe is genuinely the best tool for a professional PDF workflow.
Use Adobe.
Suppose Microsoft Excel is genuinely the best solution for a complex financial model.
Use Excel.
Suppose a proprietary video-production application is necessary for a particular 4K60 workflow.
Use it.
There is no virtue in making professional work harder simply to satisfy an ideological definition of openness.
The important question is whether we chose the dependency.
The Final Test
Before buying the next software product, perhaps we should stop asking:
“What is the best software?”
There is rarely a universal answer.
Instead ask:
What am I trying to accomplish?
Then:
- Who needs it?
- What exactly must it do?
- Where must it work?
- When will it be needed?
- Why is the capability necessary?
- How much growth should we anticipate?
- What alternatives exist?
- What will each option cost?
- What dependencies will each option create?
- How difficult will it be to leave?
Only then should we choose.
Don't Buy the Buffet
Digital sovereignty doesn't require us to reject every proprietary product.
It doesn't require everyone to become a Linux administrator.
It doesn't require every family to run a home server.
It doesn't require every business to replace Microsoft 365.
It doesn't even require every piece of software we use to be open source.
What it requires is a change in mindset.
Instead of beginning with the vendor and asking what we can do with its ecosystem, begin with the problem and ask what tools can solve it.
Instead of buying everything because it comes in a bundle, buy what you actually need.
Instead of choosing one vendor by default, compare several.
Instead of asking whether software is open or proprietary as a binary question, ask what dependency it creates.
Instead of designing only for today's requirements, leave enough room for tomorrow.
Instead of assuming that every new technology is necessary, ask whether its additional capability provides a real benefit.
And instead of asking only how easy something is to adopt, ask how difficult it will be to leave.
That is perhaps the most practical definition of digital sovereignty:
Build your processes first. Choose your tools second. Use open technology where it makes sense. Use proprietary technology where it genuinely adds value. And keep enough control that you can change your mind.
We don't need to stop eating at the buffet.
We simply need to stop assuming that we have to eat everything on the table.
Order à la carte.
That is not technological isolation.
It is technological choice.
And choice is where sovereignty begins.
