It's not enough to have better ideals.

Last week I was privileged to contribute to the PublicSpaces conference in Amsterdam, which discussed the impact of technology on democracy. I was there all-too-briefly, but I was reminded how wonderful Amsterdam really is as a city: both culturally rich and a reminder of how a city’s infrastructure can work if it receives the investment and thoughtful attention it deserves. PublicSpaces itself is a marvel: a conference that dives into the underlying power dynamics behind tech and aims to create space to discuss alternatives. Robin Berjon’s _‌_ We Build On Hope and Erin Kissane’s _‌_ Holdfast were both standout talks that were both excellent in themselves and representative of the tone of the entire event. On Friday, I participated in a panel that asked whether journalism can use the Open Social Web to strengthen democracy. I shared the stage with Catherine Tait, expert in residence at New_ Public and former president of the Canadian Broadcasting Corporation; Robert Amlung, the Senior Innovation Advisor at ZDF; and Björn Staschen, the founder of the European non-profit Save Social. The conversation was spirited, taking in the rise of authoritarianism, what we are hopeful about, and generational shifts in how people seek out news and information. We did plan for one more question that we sadly didn’t get to. It’s a point that I think is important to make, so I thought I’d go into it here. > As an early-stage investor in media startups at Matter, and Founder of Elgg and now in your role as Senior Director of Technology at ProPublica you probably have had to balance ideals vs business. What would you advise us when we talk about ‘Technology for democracy’: what kind of strategies should we use / explore to combine our lofty ideals while still being able to earn a living? If we have lofty ideals — and we should! — we probably want these three things: * To build tools and networks with pro-social values * To have lots of people use them * To be able to keep doing it The message I’d send to anyone who wants to build a pro-social tool or network is: we are not absolved from doing the complex product work of building something people need in a way that has the potential to be self-sustaining. But the good news is, doing that work is also how we reach more people and get to keep building. In product, we sometimes talk about vitamins vs painkillers. Vitamins are always optional, but if you’re actively experiencing pain, you’re highly motivated to find something that will solve it. Painkillers are the products that truly drive value. Although pro-social values are important, it’s never enough to build something that is _ideologically_ better. We need to build tools that are _practically_ better for people today, based on people’s actual needs. “Twitter but decentralized” is not a particularly useful idea. You need to figure out who you’re going to help first, get to know them, understand what is _painful_ for them, and solve that pain. Extractive networks have literally brought down democracies and enabled genocides, so we know we need software that encodes better ideals — but to most _individuals_ , those ideals alone are vitamins at best. If your project has better ideals but the experience of using your software compared to the incumbents is the same or worse, you’ll only attract the most dedicated idealists. To attract more, you need to _both_ provide better ideals _and_ solve a real need better than the alternatives. And you have to offer it sustainably. Sustainability isn’t a thing you think about after you’ve designed a product. Your product’s business model is _an integral part of it_ : whether your solution is valuable or not to a user depends in large part on the business model you use to provide it. Its cost, and the friction of using it, are a key part of the equation a user will use to determine whether your solution is worth using. If you’re doing something good, you need to be able to _keep doing it_ , so figuring this out very early is really important. You can’t hand-wave it away. A lot of pro-social developers yearn to be paid for building something with great values and distributing it for free in the commons. I like that idea too! It sounds like a great gig. But in reality, that’s almost never how the value exchange actually works. Not to belabor the point, but people will pay you because doing so is an easier way to solve their pain than anything they might be able to do themselves. _What about government grants?_ you might ask — but this harsh reality _includes_ grant funding. For example, the EU is highly motivated to build an alternative tech stack this year because it’s begun to see US tech as a security risk. But it’s only going to pay you if it sees your work as a plausible way to accelerate its path towards getting there in measurable ways. National security risk is certainly pain, but you have to be able to prove you can reduce it. So you always need to understand who your customers will be; you need to know who your users will be (if they’re different); then you need to figure out what their needs are; and you need to serve them better than anyone else. Nobody gets to hunker down and just scratch their own itch or build something they believe in. Not in a vacuum. Most idealists are not that excited to think about money. Me included! And we make all kinds of excuses to avoid having to think about it. Here are two fallacies I’ve seen over and over again: 1. Startups don’t need to consider sustainability from the beginning 2. Open source contributors do it for the love of it First, the startups. Years ago, Twitter famously decided to grow as fast as possible and worry about a model for sustainability later. It spent years just building product without even so much as a word dedicated to how it would make money. That set the tone for a lot of idealistic founders — I’ve met many who want to do the same thing. What they missed is that Twitter had Ev Williams, who had previously sold Blogger to Google. That gave him both the capital and the investor goodwill to experiment — he used his Blogger proceeds to buy Odeo, the startup that became Twitter, back from its investors. Even then, the lack of attention to business model meant that when Twitter eventually _did_ get serious, it pulled back on the open APIs and libraries that had built its ecosystem. So while many founders and builders find it distressing to think about money, I don’t think avoiding the topic is wise. Meanwhile, we often look to the open source ecosystem as a beautiful ecology of people building things and releasing them for free. The entire internet is based on open source libraries, tools, and radical collaborations. Couldn’t we have a nice life doing the same? It’s kind of an illusion. Over half of contributors are paid to write open source code directly, usually for larger corporations. In these cases, open source software solves infrastructure pain for these employers: the code is required for them to realize their strategies but isn’t a core part of their competitive advantage. Collaborating in the open lowers their costs and allows them to build better infrastructure more efficiently. At the same time, Tidelift found that 60% of open source project maintainers aren’t paid at all. We’ve all heard stories of open source contributors building load-bearing infrastructure without any real compensation. Between the corporate backed contributors and open source’s deep bench of starving artists, there are very, very few people actually managing to find sustainability building open source code projects independently. Despite these dynamics, if you release a project on an open source basis, you’ll find that lots of people celebrate your work. They’re very happy that you’ve done this, because they share your values and are excited to see more people build with them. Sometimes they’ll help spread the word in ways that help more people discover your product, and they’ll often have useful technical ideas. But they’re almost never going to be your customers themselves. Some of them may even get angry if you choose to sell a service in order to achieve sustainability. “The community” is helpful in terms of figuring out shared values and connecting to other projects, but in terms of solving concrete needs and providing value, they’re rarely who you should optimize for. Pro-social developers often worry that they shouldn’t add a feature because “the community won’t like it”, without asking the wider group of people who have a real problem the software could solve whether they need it. Allies are not the same as customers. To be clear: pro-social values matter. Open source matters. It’s just, if we want to build something with pro-social values that will reach a lot of people, and do it in such a way that it can continue to exist for as long as it needs to, they’re not the _only_ things that matter. Doing great product and business work is how you achieve those things. And make no mistake: those things _are fully achievable_. I have so much hope. When we build something that solves a real problem better than anyone else and we do it with pro-social values, we further those values in a meaningful way. The values themselves give us a meaningful lift: nobody _wants_ to be locked in or to otherwise be at the mercy of big tech companies. They subject themselves to those things when they have a problem that can’t be solved any other way. They’re _actively looking for great solutions that aren’t in opposition to their values_. And we can meet them where they’re at. We should all have hope. We also need to have discipline. The discipline is how the hope becomes reality. Making a valuable product isn’t in opposition to having lofty ideals. It’s how we bring those ideals to the world.

werd.io

Original post on john.onolan.org

john.onolan.org

Original post on john.onolan.org

john.onolan.org

Original post on john.onolan.org

john.onolan.org

I built a CLI for Ghost

Recently, I've found my preferred way to interact with lots of products is getting Claude to use a CLI tool, and then just talking to it out loud about what I want to happen. So I made a CLI tool for Ghost, to see what it would be like in our own product - it's called `ghst` and it essentially makes everything in the UI available by CLI (and MCP). Mostly this was an exercise in doing it just to see if I could - but it turned out to be a lot more interesting than I expected. We've spent 10+ years focusing on having a clean, well designed interface for Ghost. It's something we care a lot about, and spend a lot of time on. But within about ~1hr of using Ghost via Claude/CLI, it was hard to imagine going back to caveman-clicking around a browser to get something done. Particularly for complex or compound tasks that might require visiting several different areas of the app. The experience is so different when you're just describing what you want to happen, out loud: * "I saw this theme called [whatever], can you install that for me?" * "give a complimentary subscription to [member name]" * "how much traffic did my post get last week?" Which is both obvious, and at the same time kind of jarring. I know Ghost's UI extremely well, and know exactly where to go and what to click to do the thing I want – and even for me, using Claude is significantly faster/easier than clicking myself. So how big would the delta be for a regular user who _doesn't_ already know the UI inside out? My initial thought was "huh, I wonder if UI even matters anymore?" - maybe everything just becomes a CLI / voice interface for a database, as various people have been suggesting about CRM tools. But I don't think that's quite right. I notice when I interact with the product via Claude - I usually still keep the UI open, but my relationship to it is different. I use UI to see what happened, verify things look "right", and get an overview of what's going on. Which is kind of familiar, because "agent does the actions for me / I review the results" has obvious parallels to AI coding workflows. Before I'd be in VS Code all day doing the thing myself, but now I use Codex Desktop which is a _UI_ designed entirely around optimising for: agent does the actions for me... I review the results. Anyway, I don't know what my conclusion is here other than to say that AI+CLI is a really cool pattern, and I think it's likely to meaningfully influence what "UI" means over the next few years. There are still tons of rough edges and reasons for why this is not yet a fully-formed paradigm (regular humans do not, and should not, ever need to know what "CLI" or "MCP" even means), but I like where it's going. If you'd like to try out `ghst` - the beta announcement is here: Developer Beta: ghst cliHi everyone, Wanted to share a new ghst CLI tool we’ve been working on - as a developer beta - which allows you to interact with Ghost publications from the command line. In short, this allows you (or an LLM like Claude, or Codex) to automate tasks within Ghost using a set of pre-built tools. Pretty much everything you can do in Ghost Admin, you can do using this CLI. For example: Create/edit posts and publish them Import or export members Download/upload/activate themes Find out which post…Ghost ForumJohn

john.onolan.org

Ghost

We're hiring! Ghost is a proud non-profit organisation building open source technology for fiercely independent, professional publishers.

careers.ghost.org

Original post on john.onolan.org

john.onolan.org

Open Source in the age of AI

Early 2026 is a very weird time to be an open source maintainer. On the one hand, the burden of codebase maintenance has dropped dramatically. Small teams with long todo lists now have the ability to accomplish more than ever before. On the other hand, the dynamics of the software industry are rapidly changing, and some of the foundations open source projects built upon are looking increasingly shaky. Any open source project that achieves a degree of success will at some point face the reality of a competing company taking your open source code and using it to compete with you. Substack has – at various points – wholesale copied and pasted significant chunks of Ghost's source code into its own product. Open source maintainers have been fighting this sort of thing for a while with increasingly restrictive licenses, or keeping certain parts of the development stack private, like the test suite. "If you want to use our code, you have to follow our rules." But the dictating of the rules has largely been built upon a premise that code is intrinsically valuable because it's a scarce resource. Difficult to maintain. Expensive to write. AI is now rapidly overturning that premise, as evidenced by Cloudflare this week, who took a competitor's open source codebase and cloned it in the space of a few days into an entirely new product: How we rebuilt Next.js with AI in one weekOne engineer used AI to rebuild Next.js on Vite in a week. vinext builds up to 4x faster, produces 57% smaller bundles, and deploys to Cloudflare Workers with a single command.The Cloudflare BlogSteve Faulkner If anyone can point Claude at an open source codebase and have it rewritten from scratch, without actually using any of the original code, what does that mean for software licenses? More specifically: Do software licenses mean anything? Some will debate whether this is even a thing – with a lot of hand waving about "vibecoding slop" – but the trajectory is clear to see. In December, Simon Willison wrote about porting an HTML parsing library from Python to JavaScript, raising these legal/ethical concerns as a thought exercise. Two months later, we have a publicly traded company shamelessly cloning the entire product of a competitor purely for the sake of strategically undermining them. In some ways this feels like the start of software's Studio Ghibli moment. But it would be a mistake, I think, to imagine that only open source software will be susceptible to being cloned. I don't imagine it will be long before any sufficiently successful proprietary product with a public-facing interface can be reverse-engineered and rebuilt by a motivated competitor with access to frontier models. What took Cloudflare a week with an open source codebase will likely soon take a week to do with a closed one. LLMs, it turns out, are already pretty good at reverse engineering. the z80 technique reveals the source code for Atlassian’s ‘rovo’ AI assistantEver wondered what happens if you take the technique at “Can a LLM convert C, to ASM to specs and then to a working Z/80 Speccy tape? Yes.” and run it against the Atasslian Command Line (ACLI) interface? Strap yourself in, as the Z80 is amongst one of theGeoffrey HuntleyGeoffrey Huntley Which is an interesting wrinkle. What happens when we get to a point where closed products can just as easily be cloned and released as open source? When Stallman launched the free software movement in 1983, it was a reaction to a world where software was closed, proprietary, and wielded as an instrument of control. Open source was built upon the idea that anyone should be able to study, modify, replicate and share software. Free from the grasp of corporations and copyrights to prevent it. In a strange way, I'm beginning to wonder if AI might end up fulfilling that vision more completely than open source ever did.

john.onolan.org