What we in the open world are messing up in trying to compete with big tech

Our societies and governments now largely run on American proprietary big-tech platforms. Many of us want to decrease this dependency, or even end it altogether.

This article is part of a series of posts on (European) cloud challenges.

Everyone in the open tech scene is full of good intentions and we all want to improve things, but mostly we are not succeeding. By our nature, we would like to build fun, open, federated, and standards-based things. But that’s not enough — that’s not what the world is waiting for (right now).

This is a living document — additions and experiences are very welcome at bert@hubertnet.nl!

What follows may come across as rather painful and preachy. But the open tech scene really needs a wake-up call. We’re not building these things just for our own enjoyment — we need to help progress the world to different, less dominant, platforms.

Ok, sometimes we do this just for fun. Which is also fine, but we should be clear what we are trying to do. Having fun developing software for our own sake, or (also) trying to improve the world through reduced dependence on big tech. We should not only do the parts we like, and then be unhappy that the world isn’t flocking to our solutions.

Here is a provocative list of principles. There’s quite a bit of overlap between these points — see them as inspiration on different fronts. And again, I know this may come across as painful. Criticism and improvements are, as mentioned, very welcome at bert@hubertnet.nl.

Also, know that even the established players didn’t get all the things below right in one go. But every point you tackle already makes a difference!

Whatever you’re building, you have NO margin to get away with being uglier/harder/more difficult than big tech

Just as women and minorities, tragically, have to be three times as good to be taken seriously, the same goes for alternatives to overly dominant platforms. We get no leeway.

At the first “your stuff is weird, why is it like this,” you’ve lost almost everyone. You get no credit just because your solution is European or Open Source or both. Quite the opposite. Your stuff has to be more beautiful and easier to use than what Microsoft and Google offer.

So please obsess over the details of how people can quickly get started with your solution. Remove every hurdle you can.

There’s no point in arguing or making excuses about this. If you don’t have people who deeply care about user-experience in your team, you’re doomed. If you think folks will “see past your slightly clunky user interface,” that’s just not how it works. Unfortunately.

A practical example – only 70% of users of the Cloud Kootwijk Mailing List Software managed to complete the sign-up process on the first try. For the comparable OpenTK software, that was 98%. After contacting users who failed to sign up, it turned out the wording on the site and in the emails was just not clear enough. After some tweaking, now over 90% of sign-ups succeed right away. This is the kind of thing you need to do. Unfortunately, in the open source world, we too often still blame the user for not paying enough attention.

Hardly anyone self-hosts software anymore, so you must PROMINENTLY offer things as-a-service

Techies love to build software. Sometimes, even doing releases of that software (with changelogs, documentation, installers, etc.) is already a stretch for us. But it gets worse. Big tech now delivers everything “as a service.” There’s no point in offering free software to a (local) government or large organization — most places can’t do anything with it anymore. They don’t use software anymore, they use services.

Everything you make must also, perhaps by someone else, be PROMINENTLY delivered “as a service,” ready to use. As-a-service is not a side show, it IS the show. And of course, it’s great if your software is also available standalone so that (large) organizations can run it themselves if they want.

But you shouldn’t give the impression that the service version is just a fallback for the poor souls who aren’t smart enough to self-host. Service first!

And not only must the service be available online, there also have to be people who help with onboarding, training, migrations, possible customization, coaching.

This doesn’t mean programmers need to do all this — but SOMEONE needs to.

Of course, this doesn’t apply if you’re working on things like compilers or embedded databases. But if you expect “regular people” to use your software, you unfortunately can no longer expect them to arrange for a system administrator. That person usually isn’t there anymore. In general, this page is geared towards development of “people facing”-technologies. Your post-quantum crypto library does not need to be available as a service or have an attractive UI. Documentation, tutorials and tests would be great to have though!

Don’t build an “America-light” solution

The American style of software and services is well known. Cookies all over the place, shady privacy policies, popups across your screen, ads everywhere, trackers following your every move. Pointless stalking with “how did you like your order.” And AI in places you don’t want it. Don’t be like that.

Americans welcome you with a cookie banner listing 801 partners who all claim to care deeply about your privacy.

Strangely enough, when you visit a European initiative, you’re often immediately bombarded with those same cookies and trackers. Don’t Do It. You really don’t have to. Also, don’t start your open source project on Microsoft Azure. Want to do something with open and private communication? Don’t start with Gmail. From day one, you’re sending the wrong signal: “Even we couldn’t find anything better (locally).”

Similarly, if you want to run a mailing list, or host a poll, or have people fill out a form, or organize an event: take a stand and choose solutions without tracking. Choose local as well — companies you can work with to build better things together.

American-style solutions might offer you privacy — if you tick all the right boxes. But we now know that this is an unsustainable battle, and that the privacy isn’t even real.

So build things based on tech that doesn’t require checkboxes to all be set just right. Be crystal clear about that. And if you want to know what users thought of your service? Try sending some actual human emails. Not yet another dumb “give us 5 stars” survey.

You really need experience with the situation your software is for

Be humble in your claims and assumptions. It’s great that your solution is based on post-quantum crypto and the most brilliant algorithms. But are you actually solving the problems people have? Do you have concrete experience in that (work) environment?

The communications/public relations department of an organization isn’t using Mastodon — and it’s not because they don’t have their own Mastodon server. It’s because they already have to manage seven communication channels, and you’re coming in with an eighth that isn’t integrated into their social media workflow. And if they don’t already have such a workflow, they’re certainly not looking forward to 14% more manual work just to support your Mastodon hobby.

So the “pro move” is not to offer a Mastodon server, but (if needed) a Mastodon & BlueSky crossposter. And yes, that hurts ideologically. But we’re here to get people MORE open and LESS big-tech. Not to celebrate our ideals.

Know the existing software very well before claiming you’re better

The well-known big tech solutions have thousands and thousands of features — including ones we nerds don’t know about or personally need. There are departments that finally got their mail merge working properly with MS Office to send out physical mail. Don’t come in suggesting Etherpad — it can’t do any of that.

And it especially doesn’t help to recommend (say) Nextcloud as software that can replace MS 365. Because 1) it can’t, and 2) we “on the outside” don’t really understand what people actually do with Office, so we can’t judge it properly. (You can do a lot with Nextcloud, but be truly realistic.)

The fastest way to lose credibility is to come up with suggestions that turn out to be major disappointments. Don’t do it. Underpromise and overdeliver.

Specifically, never use the word “just” as in “just switch to Proton.” If it were just that simple, we wouldn’t be dealing with these problems in the first place.

Your datacenter is not a hyperscaler cloud

What is a cloud, actually? I wrote a separate piece about that because it’s not a single, clear-cut thing.

When people talk about “alternatives to the cloud,” they mean alternatives to AWS, Google, Microsoft Azure, and Oracle.

It’s perfectly fine to point out that Europe is the best place to rent servers, storage, and bandwidth. Because that really is excellent here.

But let’s be honest: no one here credibly offers even basic global S3, let alone solid (customer) IAM, Spanner, Aurora, Amplify, or Firebase. And if you don’t know what those are, then I’m sure you’re not an AWS alternative.

So absolutely highlight the things we do well here — many of which are also much cheaper than what hyperscalers offer. But make it clear that you’re in the compute/storage/networking business.

And in the meantime, work on plugging the gaps in our service offerings. But it won’t be easy. There is a strategy to get there though

It would already be fantastic if we got the basic cloud services right here.

Yes, also the boring bits

It’s not sexy, but your software must also be easy to back up, support communication archiving, and comply with odd and possibly pointless standards/certifications. Sometimes those standards aren’t so pointless after all — like the ones for accessibility. But somehow, open source projects often don’t get around to this kind of important work that we personally don’t need.

This is a truly difficult gap to bridge. Open source programmers love solving problems that are seen as important within their own circles. You don’t have to motivate anyone for that.

But some dull module needed for a certification we don’t personally care about just keeps fermenting at the bottom of the to-do list.

Another important thing: make your services and software available in languages other than English. Unlike our techie world, many customers truly prefer to be served in their own language.

Also, we love reading, but many users actually prefer video explanations. This really goes against our instincts — but we’re doing it for the users, not for ourselves! Many people really hate reading with a passion (sadly).

It has to be extremely solid and reliable

It hurts tremendously to say this, but wow — big tech is sometimes incredibly good at what they do. If you have a problem with AWS S3, chances are, you are the issue.

Entire teams are monitoring that S3 service 24/7, and they have alerts for everything that could possibly go wrong. And if you want to put a billion records in the database, it just works. You’ll get a massive bill, but it will work.

In short, there must be monitoring for everything. Either a 24/7 SLA, or if that’s not needed, at least 8/5. Not 7.5/4.5 (“7.5 hours, except on Friday afternoon and during the weekend”), like is the default in some trial projects.

Again, the fact that our solution is beautifully open source helps absolutely nothing if the quality is lacking.

Another example: if you’re offering spam filtering, it must be extremely good. Not outsourced to someone else where if it disappoints you end up saying “well, that’s just how it is.” Sadly I’ve had this experience with multiple open/open source email providers.

Security

Many techies use safer or at least more obscure software. That makes us less of a target for exploits and criminals.

Big tech writes terribly insecure software, but they push out hundreds of patches per month to improve it. They also respond quite quickly to active exploits in the wild.

It’s really not fun to admit again, but in the open source world we are sometimes SHOCKINGLY lax about this. There’s a belief that our software is inherently better (because it’s open source), and so we don’t need a serious security team.

But really, software is software — and our lovely open source tools are also full of holes. You can get away with that when you have 300 users. But if we really want to break through, this has to get much better.

This can go two ways — minimal software with as few dependencies and risks as possible is one option. Or, if you’re shipping 12 million lines like big tech, you need a massive security program.

So in short, if you don’t have a full-time security team — or you’re not writing ultra-compact code — you’re taking a huge risk.

Coding in Rust is a great idea, but it doesn’t prevent logic errors. And that’s how the bad guys still get in.

Protecting users

Google simply won’t allow you to log in from a different country on a new device just like that. “Impossible travel detection” protects you against account takeovers.

Meanwhile, lovely open source initiatives still allow you to log in with single-factor authentication from anywhere in the world or permit millions of login attempts.

If you’re offering a platform for confidential communication or file sharing, make sure your login protection matches the level of the major providers. It’s kind of embarrassing if even Facebook does a better job than we do.

Certifications, training

Many people in open source are self-taught and never needed certifications to be taken seriously. That’s great, but the Microsofts, Oracles, and Ciscos of the world became big by training people to use their tools — and handing out shiny diplomas.

We often make fun of this, but these kinds of certificates can be genuinely useful. Not everyone learns the same way we do (“learning by doing”), and there are many tech professionals who work to live, not live to work.

If you want to succeed with large numbers of administrators, at some point you’ll really need to offer certified training with diplomas and all. My previous company, PowerDNS, did this (a bit), and for some clients, it worked really well.

ISO 27001, etc.

While we’re on the topic of certifications, be aware that Amazon & friends have them all. If you look closely, you’ll see those certifications don’t always mean what people think. But they sure do check a lot of boxes, especially if no one is looking too hard.

It’s awful, but sometimes you’ll need to play along. Telling clients that Azure’s certifications are meaningless and that everyone knows it — that’s not a winning move. And maybe it’s not even true.

The accepted solution is to get your own certifications so you can participate. The scope of your certificates might be limited, but at least you’ll have something. Just know that everyone blindly trusts Microsoft’s ISO 27001 — but will scrutinize yours letter by letter.

Hey, and how’s your privacy really doing?

No offense, but be brutally honest with yourself. If your software “phones home” for version updates, how long do you log the details of that? Are you unnecessarily sending identifiers that allow you to track users?

And if there is phoning home, do your users know? Have you properly informed them? Or have you accidentally created a dark pattern?

And if your servers keep log files, are you deleting them in a timely fashion? Are you logging things you don’t actually need to log?

“The shoemaker’s children go barefoot” — it’s all too easy to get this wrong for yourself!

Be vigilant you aren’t out-big-teching big-tech here. Don’t log what you don’t need. I presented about this problem some time ago.

Don’t skimp on servers, storage, networking, and DoS protection

If your project becomes truly popular, you’re going to need compute power. If you’re hosting content, understand that you are not a content distribution network (CDN). Unless, of course, you are starting one (which would be a great idea). If money needs to be spent on hosting and networking — spend it. Or build a dedicated team for it.

The same goes for denial-of-service (DoS) protection. If your thing becomes even remotely important, you will get DoS attacks. And once again, either you buy protection, or you become a DoS-protection provider yourself. Both are fine, but pick one.

Also: don’t be stingy with storage capacity. As computer nerds, we often feel it’s a bit of a cop-out to throw hardware at problems. But sometimes, that really is the only practical solution. Buy generously, so you don’t end up having to email users saying “sorry the server filled up” — which unfortunately happens far too often in the alt-software scene.

Sales

Sales? Yes. A good product does not sell itself. Even a free product needs to be actively promoted. If you leave it all to word of mouth, progress will be slow. Every initiative needs a “sales” department — even if money isn’t involved.

But it is about getting your new thing on the agenda. Because if no one knows it exists, if people aren’t aware of its benefits or how it solves existing problems… nothing’s going to happen.

Sales efforts also teach you a lot about what customers actually need — because they often don’t know well enough themselves to explain it clearly. The same, by the way, applies to us when we are the customer.

See also this piece I wrote earlier about marketing and sales.

Bring the demo, not the memo

Go to Facebook.com and within hours, a business department can click together a whole community. They’re almost ready to go — all they have to do is give up their users’ privacy.

Now compare this with the European/open experience. You can’t do anything until you’ve phoned someone. And they’re going to schedule a time for an intake call. Which might easily take 90 days.

Whatever you’re building, go as far as you can to make sure users can get started instantly — even if that means spinning up a demo environment. Even a video isn’t enough. It must be click and go. The Americans have that, and because we don’t, we come across as less serious right from the start.

If you do this right, you turn any office worker into an enthusiastic ambassador for your product!

We love open standards, but it also has to work

When you actually start offering services, you inevitably run into weird stuff. For example, iPhones insert “smart quotes” into forms at the strangest times—quotes that your search engine can’t interpret, and no documents get found. We can get mad at Apple, but it’s pointless. Just convert those smart quotes back into dumb quotes.

Microsoft sabotages your sign-up workflow with their security scanners, which is horrible and shouldn’t be allowed, but they do it anyway, and you have to work around it.

We don’t have the clout to veto the technologies people actually use.

Be a solid outfit

If you want to get anywhere, know that procurement departments and decision-makers will have someone look at your company/organization. How many people work there? What’s the revenue? How are the reserves? Does your org file taxes and returns properly everywhere? Who owns the place? Are there three different companies listed on your website, two of which no longer exist? Who owns the intellectual property? Is there a phone number on your website?

For some things, the bar is even higher. It’s annoying, but “boring customers” prefer doing business with solid companies that have existed for 10 years. Sometimes, this is even explicitly required in procurement conditions.

If you can’t appear solid and respectable on your own, you really need a bigger partner company—and those don’t grow on trees, and they’re not just waiting around for you. So start thinking about this kind of thing early. And in the meantime, “look bigger”.

“Look the part”

I’m not a huge fan of marketing and branding either. But that’s how it works. If your site looks too student-like or too “for nerds,” you’re already way behind in many places. Especially decision-makers often (unfortunately) make decisions based on vibes and feelings. That’s dumb, but you can at least make sure those vibes and feelings don’t work against you.

It’s incredibly hard to reach “Apple”-level branding (see here), but with a reasonable amount of effort, you can reach a ‘functional’ level of design/marketing.

Don’t wait too long with this—every day your site looks off, you’re building a bigger and bigger gap and missing chances to be taken seriously, while cultivating a pool of people who don’t take you seriously. “Did you see that font”.

Pro tip: don’t try to make one site do everything for everyone. A company like The Good Cloud (as of May 2025) made a clear positioning choice (‘somewhat cheerful’), which works well for their main customer base (NGOs). But if you want to target (say) ministries of defense, then you’ll need different content and a different look.

Don’t hesitate to launch multiple sites or even brands (for the same technology). Because building a single site that feels right for everyone is not doable.

Collaborate, also beyond the tech

Open Source projects can collaborate really well—that’s why we still exist. But in other areas, we don’t. For example: Microsoft and Google regularly discard our emails because they think it’s spam (and because they get away with it). There’s really nothing you can do about this, and it’s a big reason why “email outside of Microsoft and Google” is gaining a bad reputation: your email doesn’t get through.

But what if we set up one IP address used only by carefully selected organizations to send email? And when Microsoft or Google once again throw away all our mail, we take them to court together.

That takes some technical prep and then solid planning to actually win the case, but it could make email without big tech a lot more viable again.

Business

If you come up with something, be clear on how it’s going to be paid for. Yes, open source developers can contribute in their spare time for free.

But no, that’s not enough to build alternatives to big tech.

You need programmers, testers, and other staff to be seriously paid—enough that it’s not just a hobby. €60k a year, €100k a year—then things become possible (these amounts will differ from country to country). Know that big tech (in the U.S.) pays a LOT more than that.

Open source is open, but the people working on it still need to get paid.

That’s why every initiative needs a plan for how it’s going to sustain itself over time. Crucial to that is thinking carefully about your pricing. I strongly recommend this piece—I think I reread it at least once a year as a reminder.

Who owns your operation?

Suppose your company becomes successful — will you quickly get acquired by Microsoft and it’s game over again? Is it even clear who actually owns the solution, the service, and the software?

Many open source projects struggle with this. Mastodon is a recent example, though they now seem to be on the right track.

These kinds of ownership issues are often easy to sort out early on. Once the project is successful, it becomes much harder.

Priorities, purity, and nitpicking

In the tech world, we sometimes have our own set of priorities. Do something useful online and a swarm of techies will show up to tell you that your HSTS preloading isn’t configured right, your nameservers don’t support IPv6, your TLS algorithm order isn’t optimal, your mail server doesn’t use DNSSEC, your site uses unnecessary JavaScript, your CSP could be tighter, not everything has an RSS feed, and according to internet.nl you only score an 8.

“Well, thanks.”

Now, these are all valid things to look at. But you can only spend your hours once. This kind of purism is a major distraction. If we demand maximum technical perfection from each-other in these areas, there’s no time left for things like documentation, training materials, an online demo of the software, correct installation instructions, or improving the user interface.

If you feel the urge to bombard an open source project with minor (technical) critiques (“why are you still on GitHub?”), first check if there are bigger things you could help with. And once those are done, there’s time to polish the DMARC policy.

And no, we shouldn’t forget our own values either

You might forget it after the somewhat commercial tone above, but let’s not lose sight of why we started. Open software that everyone can collaborate with. Technology that doesn’t exclude people, and gives us back control over our own IT and data.

So if you’re building something ‘as a service’, make sure people can download their data in a standard format and take it with them to another solution.

Also make good use of existing open source software. Unlike our proprietary competitors, we actually can build things together well.

As mentioned earlier, we’re not going to win this by carefully cloning closed software. They’re better at that themselves. We need to bring software based on our values—and use that to convince people!

Comments and tips very welcome at bert@hubertnet.nl