Service
Introducing open-source systems and maintaining them for the long run.
For many jobs in a business there are mature open-source solutions. I check whether one of them fits the way you work, set it up and stay responsible for the updates afterwards. And if something is already running at your place that nobody has touched in years: those updates are what I take on too: planned, tested, and the previous state stays available.
Setting one up
File storage, inventory management, ticketing, sign-in: for most of these jobs there have been proven open-source solutions for years. I look at whether one of them fits the way you work, set it up, and migrate the data out of whatever you are using today.
Honestly though: open source is not automatically cheaper. What you save in licence fees goes into running and looking after it. The difference lies elsewhere: you are not tied to a vendor who can change prices and terms, and your data stays where you want it. If a commercial product is the better choice for your case, I will say so.
Typical systems
Mostly it is the systems running in a lot of businesses: websites and online shops on WordPress, WooCommerce, Magento, PrestaShop or Shopware, file storage and collaboration with Nextcloud, plus the Linux servers and databases (PostgreSQL, MySQL/MariaDB) all of it runs on.
Your system not on the list? Ask anyway, much is related, and honest "no"s exist too.
How an update project runs
- 01
Assessment
Versions, dependencies, risks. What is actually running, and how far is it from the current state?
- 02
Backup & test environment
A complete copy on a test environment. No update touches production before it ran cleanly on the copy.
- 03
Update roadmap in stages
Bigger jumps get split up: each stage is signed off on its own and the previous state stays available.
- 04
Switchover with a safety net
The production update happens in an agreed window. If something goes wrong, the previous state is restored.
- 05
Ongoing update support
So the backlog doesn't build up again: regular updates, security patches, status report, as a monthly flat rate.
Why this is more urgent than it feels
Security holes in open-source software are documented publicly: the patch comes with instructions on how to exploit the hole. Systems two or three major versions behind are an easy target for automated attacks.
As the operator you are responsible for the state of your systems, also under data protection law. Continuing to run a known-insecure system is not a neutral state under the GDPR, it is an omission. No reason to panic, but a good reason not to postpone the update another quarter.
How far behind are your systems really?
The assessment gives a clear answer: versions, risks, effort. Then we decide together whether and when to update.