Werd I/O

Much of the last decade or two of the tech industry has been dominated by the idea of the cloud: the simple, powerful idea that all of your applications and data can be accessed from any device with an internet connection. Enterprise businesses around the world have decommissioned server rooms in favor of subscribing to services maintained by other people, reducing overheads of all kinds. Even companies that once built and operated vast datacenters now rely on cloud providers. At the same time, cloud services have helped individuals save money upfront (even if subscriptions often cost more in the long run) and have taken the need for installation and troubleshooting out of the picture. Overall, cloud services have saved lots of people huge amounts of time and money.

But this convenience comes with trade-offs, some of which have become more apparent over time.

• You only ever rent: There’s no real ownership, and vendors can modify, discontinue, or increase prices at will.
• Privacy concerns: Because your data and activity pass through the provider’s infrastructure, they can be easily monitored, tracked, or even resold.
• Jurisdictional constraints: Your data often resides in the provider’s chosen region, subjecting it to local laws, which may not align with your needs.
• Downtime and dependence: If your cloud provider goes down, so does your access — sometimes across multiple services.
• Vendor lock-in: Moving away from a cloud provider can be complex and expensive, discouraging competition and user control.

These trade-offs become even riskier when your work involves sensitive information. When software and infrastructure are controlled by the same entity, it not only enables easy monitoring and resale of your data but also makes it a prime target for subpoenas. Courts can compel a cloud service provider to produce your data, often without your involvement.

If your work involves sensitive personal information, for example of patients or sources, that could put their privacy and safety at risk. That might be particularly problematic in a situation where, for example, you work on reproductive health issues, and your software is hosted in a jurisdiction that has abortion bans. This risk extends across professions: journalists protecting sources, lawyers safeguarding client data, and healthcare providers managing patient records all face heightened exposure when their software, data, and infrastructure are all controlled by the same party.

At the same time, moving away from the convenience of the cloud is not really an option for most organizations. To date, most have opted to pay for more expensive enterprise contracts, which promise greater data protections alongside features like stronger audit logs and SSO. These provide some legal protections, but still amount to little more than an enforced promise: the vendor physically can inspect your data in most cases, you’re just paying them extra so that they’ll promise not to. These contracts also don’t address jurisdictional issues: if the vendor is based in Texas, your use of their platform is still subject to Texan law. The power dynamics at play remain unaddressed.

This is also problematic when you consider the increasing popularity of LLMs. If you’re dealing with sensitive or proprietary information, you probably don’t want an AI model to be trained on your data. You can pay vendors like OpenAI to promise that they won’t look at your data or train their models on it — but, again, you need to take their word for it.

If we want to retain the benefits of cloud software without its fundamental risks, we need a different model: one that restores control to users and organizations rather than vendors.

• Retain the ease of deployment, access, and collaboration that makes cloud software so appealing.
• De-couple software and infrastructure so that the company making the software is not the company that hosts the software.
• Allow customers to pick an infrastructure host in the jurisdiction of their choice.
• Ensure that data is encrypted at rest and in transit, so that even the hosting provider cannot access it.

Self-hosted cloud software is, of course, absolutely a thing that already exists. Some of it is even end-to-end encrypted. But it’s also largely free and open source, and requires a fair amount of configuration and maintenance from an organization’s IT department. There’s nothing wrong with open source software (I ran two open source startups!), but the complexity of configuration and lack of clear business model can introduce problems for both the customer and the vendor. Vendors like Cloudron are making this easier for open source software — and they should serve as a model for what could come next.

Some cloud infrastructure providers, like AWS, already host marketplaces of software you can install. The trick is, you usually have to decide which kinds of virtual servers to use — are you going to go for an m3.medium or a t2.xlarge? — and then consider how your private cloud will be configured. AWS also offers self-hosting for LLM models through Amazon Bedrock, but the same problems present themselves. There’s a lot of technical overhead which many organizations can’t easily address — and in stark contrast to a cloud offering like Google Workspace, which is completely turn-key.

But this doesn’t have to be the case. What if we could combine the ease of cloud-based software with the control and flexibility of locally managed applications?

Consider an iPhone: here, your software runs on your device, wherever it might be, but is seamlessly downloaded from an App Store on demand. Some of that software is free; some of it is paid-for, either as a one-off or on a subscription basis. The underlying operating system is a variant of the FreeBSD UNIX system with significant proprietary additions, including some sophisticated sandboxing, but you wouldn’t know it, and you certainly don’t need to configure anything: you request an app, and zip!, there it is on your phone.

Consider this user journey:

• The customer signs up to a certified provider in the jurisdiction of their choice. There are providers tailored for different levels of customer and different industries.
• They add their payment information.
• They choose the software they want to provide to their organization from an App Store accessed through the provider. As soon as they install it, it is near-instantly available to them.
• They can make it available to every user in their organization or a subset of users.
• For every user for whom it is available, the app shows up on a web-based dashboard. It can also be configured to automatically show up in providers like Okta.
• They never have to care about the speed or capacity of the underlying hardware: they just pay for a recurring license to the software.
• They never have to care about configuring or upgrading the software: as soon as they select it, it’s available. Customers can opt for updates to be pushed out automatically, or they can hold back non-security updates for more testing.

The App Store distributes revenue to the vendor and the hosting provider, and takes a cut for itself. Apps are charged for on a predictable, monthly, per-seat basis, with each app able to set its own prices. As is the case with a phone App Store, the store itself does some vetting of each application, certifying it for security and a set of core rules that each app must abide by. Unlike a phone App Store, it also does vetting and certification of the hosting provider itself, reducing the customer’s need to undertake security auditing.

Because every hosting provider associated with an App Store would necessarily need to adhere to the same open standards, the customer could move providers easily. They’d just sign up to another hosting provider associated with the App Store and migrate their apps. The App Store itself would handle the rest, dealing with migrating block storage, databases, and so on behind the scenes.

This model isn’t just about redistributing power from giant cloud vendors to customers. It’s about enabling organizations that deal with sensitive data to more easily use the cloud to begin with. It makes it easier to know that there is an enforced separation between an LLM and its training infrastructure. And it creates new opportunities for vendors that might not be in a position to offer their own cloud infrastructure, too. It lowers the barrier to both privacy and innovation for everyone involved.

Existing cloud providers aren’t incentivized to build this. It’ll take a new entrant or someone willing to make a big bet. The technology to do this already exists. The only question is: who will build it first?

If it’s you, I’d love to hear from you.

I’ve seen a lot of this sentiment lately, and can relate:

I miss being excited by technology. I wish I could see a way out of the endless hype cycles that continue to elicit little more than cynicism from me. The version of technology that we’re mostly being sold today has almost nothing to do with improving lives, but instead stuffing the pockets of those who already need for nothing. It’s not making us smarter. It’s not helping heal a damaged planet. It’s not making us happier or more generous towards each other. And it’s entrenched in everything — meaning a momentous challenge to re-wire or meticulously disconnect.

Many of us got excited about technology because of the web, and are discovering, latterly, that it was always the web itself — rather than technology as a whole — that we were excited about. The web is a movement: more than a set of protocols, languages, and software, it was always about bringing about a social and cultural shift that removed traditional gatekeepers to publishing and being heard.

It’s perhaps hard to remember now, but in the early nineties, finding an audience really meant being discovered and highlighted by a small number of very rich publishing companies (or record labels, etc) who were most often not representative of their audiences. The web was a revolution: anyone could publish their words, their music, or their art, without asking anyone for permission, and they could find their communities equally permissionlessly.

The web, of course, didn’t turn out to be quite as utopian as the promise. The truth is, the people who could afford to publish on the early web were also from a narrow, relatively wealthy demographic. To make publishing accessible to most people (who didn’t, quite reasonably, want to learn HTML or pay for or configure a domain name and hosting), we needed a set of easy-to-use publishing platforms, which in turn became centralized single points of failure and took the place of the old gatekeepers. Replacing publishers with Facebook wasn’t the original intention, but that’s what happened. And in the process, the power dynamics completely shifted.

The original web was inherently about redistribution of power from a small number of gatekeepers to a large number of individuals, even if it never quite lived up to that promise. But the next iteration of the web was about concentrating power in a small set of gatekeepers whose near-unlimited growth potential tended towards monopoly. There were always movements that bucked this trend — blogging and the indie web never really went away — but they were no longer the mainstream force on the internet. And over time, the centralized platforms disempowered their users by monopolizing more and more slices of everyday life that used to be free. The open, unlimited nature of the web that was originally used to distribute equity was now being used to suck it up and concentrate it in a handful of increasingly-wealthy people.

For the people who were attracted to the near-unlimited wealth hoarding and rent-seeking potential, this new web was incredibly exciting. Conversely, for those of us who were attracted by the power redistribution more than the technology itself, it was incredibly disheartening. The reason we got involved in the first place had all but evaporated.

For a while, decentralization did become a hot topic. Unfortunately, this was more about avoiding the trappings of traditional banking — crucially, including avoiding regulatory controls — than it was about distributing power. The actual equity redistribution was mostly an illusion; although there certainly were people with their hearts in the right place in the movement, the people who truly gained from blockchain and cryptocurrencies were libertarian grifters who saw potential in moving money away from the prying eyes of regulatory oversight and saw banking regulations designed to protect people as being unnecessarily restrictive. Blockchain wore the clothes of power redistribution, but rather than empowering a large number of people, it enriched very few, often at other people’s expense.

I do think the brief popularity of blockchain helped bring attention to decentralization, which was useful. I don’t know that as much attention would have been paid to the new crop of decentralized social networks like Mastodon and BlueSky, for example, had Web3 not previously seeded some of the core ideas in a more mainstream consciousness. The web3 community was also the most successful at, for example, embedding identity in the browser. It wasn’t valueless as a movement, but it fell far short of the hype.

Which brings us to AI, the current hotness. Like any software technology, it’s being sold to us as an empowering tool. But the broad perception is that it’s anything but: models are trained, unpaid, on the work of artists, writers, and researchers, who are already relatively low-paid, in order to build value for a small handful of vendors who are making deals worth tens or hundreds of billions of dollars. Or as one commenter put it:

The underlying purpose of AI is to allow wealth to access skill while removing from skill the ability to access wealth.

If you think this is hyperbole, consider Marc Benioff’s comments about not hiring any more software engineers in 2025:

“We’re not adding any more software engineers next year because we have increased the productivity this year with Agentforce and with other AI technology that we’re using for engineering teams by more than 30% – to the point where our engineering velocity is incredible. I can’t believe what we’re achieving in engineering.”

Whether you care about software engineering jobs or not, the same dynamics are underway for writers, artists, and any other creative job. Even the productivity gains that are being realized through use of AI tools are benefiting a small number of wealthy companies rather than individuals. This is the exact opposite of the power redistribution that led to so many people seeing such promise in the web.

It’s very hard to get excited about technology that redistributes wealth and power in favor of people who already have it.

The trajectory of the web — starting as a tool for redistributing power and becoming one that entrenches it — was not inevitable. It was the result of specific choices: business models that prioritized monopolization, technologies designed for centralization, and a relentless focus on extracting value rather than creating it. If we want a different future, we have to make different choices.

What does an alternative look like? It starts with software designed for people rather than for capital. The web once thrived on protocols instead of platforms — email, RSS, blogs, personal websites — before closed networks turned users into data sources. We are now seeing efforts to return to that ethos. The Fediverse, open-source publishing tools, community-run platforms, and decentralized identity projects all point to a path where individuals have more control over their online lives. They aren’t perfect, but they represent a fundamental shift in intention: building systems that work for people instead of on them.

The first wave of the web was decentralized by default but only accessible to a small number of people. The second wave was more accessible but centralized by profit motives. If there is to be a third wave, it will have to be intentional: built with equity and accessibility as core values, not an afterthought. That’s a hard road, because open and ethical technology doesn’t attract billion-dollar investments the way extractive models do. But if history has shown anything, it’s that the web’s greatest strength is in the people who believe it can be better. The real question is not whether more equitable software is possible: it’s whether enough of us are willing to build it.

For many of us, the social movement, rather than the underlying technology, was always the point. We need that movement more than ever before. Hopefully building it is something that more of us can get excited about.

Photo: Tim Berners-Lee's tweet "This is for everyone" at the 2012 Summer Olympics opening ceremony, released under a Creative Commons Attribution 2.0 Generic license.

Ask a CTO is an irregular column where I answer anonymous questions from a technical leadership perspective. You can ask questions using this form.

I have two answers to two questions this time around:

Security vs. productivity

Where do you draw the line between security and productivity? What are the drawbacks of totally locking down user workstations and onerous password, 2FA, convoluted permissions and never-ending zero trust implementations?

Security and productivity don’t have to be at odds: they should reinforce each other. They’re not at different ends of a continuum.

The purpose of IT is to support everyone’s work by empowering them to use technology efficiently and safely. Therefore, any good IT strategy is rooted in service design.

Anyone who builds a product needs to consider the user journey of the person they want to use it: their individual steps from discovering the product through to becoming a dedicated user. IT service delivery is a product, too, and the people who provide it need to consider the work journey of its recipients just as carefully. Consider their jobs to be done: the stuff they need to do, the workarounds they’ve created for themselves, the things they’re studiously avoiding doing. And understand that everyone’s role has different requirements: only a few people need access to payroll, for example, and engineers really need access to install their own libraries and developer tools.

There’s also got to be a “why” for everything that’s implemented: the worst IT policies are created by people who do something because they think they should, perhaps because they perceive that other people are doing them. Do you really need to rotate your passwords every 90 days? (I’ll spare you a search: the answer is no.)

And you need to be open to the idea that you’ve got it wrong. Nobody knows their work better than the people who are doing it. Security policies exist for a reason: unchecked software installs or poor password practices can put the whole organization at risk. But the way those policies are designed and enforced makes all the difference. IT departments lock down workstations in part so that people don’t install random software that might turn out to be harmful; they’d better also have a friendly process for helping people to install software that isn’t part of their core supported offerings but turns out to be needed for someone to do their job.

All these elements need to be in place: well-considered user journeys for every role, a considered reason for everything you’ve implemented, great training and bedside manner, and an openness to change, in partnership with a strong understanding of the risks and the products and approaches that might address them. Once these things are there, a good IT strategy should actually improve productivity rather than get in its way, even as it implements security procedures like managed devices, MFA, least privilege security, zero trust, SSO, and so on.

A good password manager makes passwords and MFA easier than manually typing credentials. Good SSO just requires a touch to seamlessly log in. Good IT support is a ubiquitous, friendly presence with good bedside manner. Good device management means that you don’t have to worry about keeping your machine up to date. Those things are all necessary for good security, but they also take out steps to common workflows and, once they become a habit, are easier for most users than life without them.

Conversely, if you don’t implement these things from a human-centered perspective, people are going to resent the changes, and you run the risk of getting in the way of people’s work. When that happens, they’ll try to work around you, and your entire organization is less secure. Security really depends on everyone being aligned, which in turn depends on an IT department being laser-focused on being of service.

Keeping up with the Joneses

How do you decide which trends are worth adopting?

There are three things you need to know, in order of importance:

• What is your organization’s mission, vision, and strategy? In other words, what are your goals? What are your problems to solve?
• What are the jobs to be done of the individual people in your organization? Where are the points of friction in their workdays?
• What are the emerging trends? What are the pros, cons, ethical considerations, and potential risks of a new technology or approach?

I’ll start with the last first. It’s good to be informed, but that means cutting through marketing and sales excitement to understand the underlying nuances. Many new technologies — and certainly the ones high-profile enough to become “trends” — have an attendant hype cycle. The first step to parsing coverage is understanding that the hype cycle exists; the second is to find voices you trust and listen to their commentary.

My feed reader is loaded with thousands of subscriptions not just because I like blogging and RSS (although I do!), but because these voices keep me informed. Many of them will disagree with each other, and some of them come from perspectives that are very different to my own; these different angles allow me to construct my own informed opinion. I don’t rely on TechCrunch or similar sites for trend analysis because they tend to amplify hype rather than provide nuanced perspectives. Instead, I filter through relevant connections whose opinions I trust.

But it all comes down to those organizational goals and the problems you need to solve. Implementing any technology for technology’s sake is a fool’s game: it all has to be in service of your organizational strategy or improving the working lives of the people who implement it. Does it address your strategic problems? Does it reduce friction for your colleagues? How?

That can be more complex than it sounds. For example, if your goas include hiring top-tier engineers, that isn’t just about salary: it’s also about the tools and environment you provide. A company that invests in high-end hardware, flexible work policies, or a strong internal developer experience may attract better talent than one that skimps on these details. A company that has an open mind about AI may be more attractive to investors than one that takes a more dogmatic approach. And so on.

Finally, ethical risk is organizational risk. It’s important to understand the ethical considerations and impacts of a new technology as a core part of its pros and cons. Overlooking the dubious ethics of a team or a technology’s environmental footprint is likely to lead to problems down the road, even if the technology may seem like it’s super-popular today. These things have a tendency to manifest as real speed bumps down the road.

Stay focused on your goals, cut through the hype by listening to diverse experts, understand the risks, stay human-centered, and always think for yourself.

Ask a CTO

Do you have questions that you’d like a technical leader to answer? You can ask questions using this form. I’ll try to answer in a future post.

#askacto