Zotero Took Five Years to Build, Not Five Minutes
The Slow Formation of Durable Software
On Zotero's 20th anniversary, Dan Cohen reflects on its slow, collaborative development at George Mason University's Center for History and New Media. Unlike today's instant AI-generated code, Zotero's vision emerged from years of conversation and iteration, producing durable software used by over 20 million people. Cohen argues that this measured pace holds a vital lesson as programming becomes a 'caffeinated bender with magical bots.'
If AI had existed in the early aughts, we could not have accelerated Zotero’s conception, because we did not know exactly what we wanted, and so could not have written coherent prompts for an LLM.
- nickledave
For folks who are wondering:
This post is about Zotero.
If you are not an academic, you might not know Zotero.
It is such a pleasure to use. Every app should be like this.
I read everything in it, including books I'm going through right now from https://teachyourselfcs.com/
It also does an amazing job of taking snapshots of posts. I use it all the time to grab posts from HackerNews so I can mark them up.
And it automagically syncs everywhere across devices and lets me store way too many files on the web like the ADD packrat I am, without breaking a sweat.
In short, this software just works, and it works well.
So when somebody behind Zotero talks about how to develop software, I listen.
And it's a fun post with some history. You should save this post to Zotero, and then read it.
- adamddev1
> But that slow formation led to software that was durable rather than ephemeral, with a strong foundation that could be built upon.
People say that agentic development is great because you can churn out so much so fast. But that doesn't mean that any of it will be truly good and reliable.
The things that are truly insightful and solid end up being used exponentially more, which makes the linear cost of extra development time (asymptotically) insignificant in the cost/benefit equation.
- _fw
As somebody responsible for the acquisition of users and growth of a company in terms of customer and revenue, this is a VERY salient point:
> “… we could not have accelerated Zotero’s conception, because we did not know exactly what we wanted, and so could not have written coherent prompts for an LLM.”
A surprising proportion of software products, maybe even businesses today, are solutions in search of a problem.
Sometimes that’s okay, but only sometimes. And being a solution in search of a problem requires you to get everything /else/ pretty much perfect if you want to succeed.
The fact Zotero paid attention to what people wanted, and gave it to them, and were market oriented, is demonstrably a big part of their success.
It is MUCH easier to make something people want, than to make them want something you made.
- sdevonoes
> Today, software can be created more or less instantly with AI, for a large user base or for yourself, for any purpose or for no serious purpose at all.
I don’t think this is true. I’m working on medium to large features in companies that have around 1K engineers. These features typically involve 50% of work within your domain plus 50% of work in dependant domains. You cannot get anything doing without previous alignment with such domains. There are discussions, tradeoffs, design docs, approval committees, etc. AI can (and does) help in every step, but it’s not a magic wand that can solve the whole thing with a well crafted prompt.
Ithe hands of inexperienced people, AI slows down things (e.g., ai-generated robotic and lengthy slack messages that go nowhere, PRs that implement what a jira ticket says… but jira tickets without alignment are worthless, etc)
- ORDINAND_PIZZA
good things take time because they grow from something like seed. as that seed grows, it figures out its local and global context. a curious and patient caretaker of this seed will spend a lot of time looking at it, understanding it, trying to figure out the right way to give the small plant a steady foundation. with care and attention, it could grow into a tree and attract all sorts of other insects, animals, and all sorts of life.
speed kills quality. it’s literally impossible to make anything good fast.
we know this, and it still applies to software. while we may be able to make things faster, they will never become good (or great) without an incredible amount of care, patience, and joy from its maker.
there are no shortcuts to quality. it will always take a lot of time to make anything good.
- kstenerud
> If AI had existed in the early aughts, we could not have accelerated Zotero’s conception, because we did not know exactly what we wanted, and so could not have written coherent prompts for an LLM. Instead, it took a great deal of time and collaboration to develop a clear vision for what Zotero should be.
AI doesn't preclude this. In fact, it can help accelerate parts of it.
He's describing the typical big project lifecycle:
- Examine the landscape
- User research (how they use existing software, what their frustrations are, etc)
- Brainstorming
- Early ideas and prototypes
- Refinement, user feedback
- Solidify the vision and high level process design
- Choose technologies
- Design & architecture
- Plan out phases
- Build phases, then test them with users
LLMs are great at research, and great at prototypes. Once you have your design, they're good at coding as well. They're also good at distilling user feedback.
- peterbell_nyc
I love great software and agree that great software is evolved - not built. The whole point of building v0.1 is to figure out what's wrong and should be fixed in v0.2
At the same time, there are broadly three motions in the loop:
- thinking/discussing (what should it do)
- building (Make it do that)
- using (Seeing whether that is actually what it SHOULD do)
And then of course you repeat until you run out of time, money, patience, volition, etc. For some software there is a terminal state - it truly does exactly what it should. For most you're always reaching for it.
LLMs definitely accelerate 2 and potentially can help accelerate 1 and 3. As such cycle time can be reduced. It still may take 100 turns to get what you want, but I'd be surprised if the clock time for the 100 turns would be unchanged using AI.
- olafmol
In the Netherlands we have this saying: “Without friction, no shine”