It could be said that economies run the world, whether we’re looking at the natural world of living ecosystems, natural, non-living cycles like the weather, or ourselves as human beings. Either way, the same general principles apply: supply, demand, and the movement of exchanges.
When it comes to the software economy, we tend to think in terms of money and time, but there’s a critical piece that often gets overlooked. That component is attention. But how does attention play its role in the software economy? More importantly, how does this role shape the software ecosystem and the relationships that maintain it?
A recent newsmaker that brings these questions to mind is the GNOME Calendar and Linux Mint debacle, which has become one of the many viral topics circulating throughout the open-source community.
The dispute centers around Linux Mint’s decision to distribute a quite outdated version of GNOME Calendar that its upstream developers no longer support. The GNOME Calendar developers asked Mint to remove upstream support links and change the application’s branding, arguing that users were bringing them problems related to old or modified builds. Linux Mint rejected the request, viewing it as an attempt by upstream to exert control over how freely licensed software is redistributed.
There are legal and philosophical questions mixed into that debate, but the social question is more immediately relevant here: when a downstream project chooses to distribute software differently, who’s indebted with paying attention to the consequences?
Should upstream developers be expected to investigate problems caused by versions they no longer support? Should downstream packagers take responsibility for a burden they may not be equipped to adequately support? What does one project owe another when both are already operating with limited resources? These questions matter because attention is a limited resource, and while there’s technically a “right” and “wrong” in matters like this, those lines can become blurred when the demand for attention shifts from the developer and the distributor to the end user who’s just looking for answers.
Software Insight: Attention is more than time
Attention is distinct from time, but the two are closely related. We often say that time is money. Attention takes time, and so it would also be fair to say that attention is money, even when the correlation isn’t immediately obvious.
Two tasks may take the same amount of time while demanding vastly different amounts of attention. Ten minutes spent waiting for a download isn’t equivalent to ten minutes spent deciphering an unclear error, remembering an obscure workaround, or rebuilding the context of a task after an interruption.
Whether or not we immediately recognise it, attention influences how we spend our time, our energy, and ultimately our money, or at least the things that could stand in the place of it.
Attention is a resource of value, and anything of value is precious and should be treated as such.
We owe it to each other to value attention
We all pay attention somewhere:
- Developers pay attention to code: its logic, methods, means, and outcomes.
- Designers pay attention to the details others take for granted.
- Testers pay attention to the corners that get overlooked.
- Users pay attention by learning, configuring, troubleshooting, remembering, and adapting.
In every area, some of this attention is deliberately invested, some is merely consumed, and some is, frankly, wasted.
Learning a powerful application can be a worthwhile investment. A little attention spent today may lead to years of improved capability. By contrast, fighting an unclear interface, repeatedly encountering the same avoidable bug, or searching for information that should’ve been communicated clearly may provide little lasting value.
Developers face a similar distinction. Their attention may be dumped into creating something new, refining the experience, understanding users, or improving their craft. It may also be consumed by vague reports, repeated questions, preventable packaging problems, or the need to constantly shift gears around unfinished, scope-creeping work.
Underlying all of this is a need shared by every party: we want the demand for our attention to be rewarded with something of substance. No one wants to feel like they’re labouring in vain, whether that labour comes from the producer or the consumer. Users want software to help them accomplish something. Developers want their work to be used, understood, appreciated, and improved.
This is why developers often crave feedback.
It isn’t that they’re dying to hear, “Your app sucks!” They’re looking for confirmation that the attention they invested produced something meaningful. Constructive feedback gives them users’ attention in return, along with information that may help them improve their craft.
Even developers who work without direct monetary compensation tend to care deeply about how their work is received, because human beings require exchange.
Every software decision shifts attention somewhere
No software eliminates the need for attention; it distributes it. A developer might spend several hours refining a workflow, writing clearer documentation, or selecting sensible defaults. That work may then save thousands of users a few minutes each. Good design allows one person’s concentrated attention to spare many others from repeated (wasted) efforts.
Poor designs (and by designs, I don’t just mean visuals, but experiences) do the opposite. A problem that could’ve been solved once is instead encountered by every user individually. Each must recognise, investigate, find a workaround, remember the workaround, and perhaps explain it to someone else.
The original problem may appear small when viewed from the developer’s side, but its cost multiplies across the user base. Convenience, therefore, doesn’t mean no one paid attention. It usually means someone paid the cost further up the chain. Inconvenient experiences often mean someone punted decisions down the line until the traffic of unmet attention demands crashed in a pileup.
This is why it pays to give a damn
All of this brings me back to the subject of the recent viral debate over whether Mint or GNOME has the “right” position, and to be fair, while both have some valid points, I have to lean heavily in the direction of the GNOME Calendar developer on this one.
Distribution is a choice to invest attention so users won’t have to. Choosing, purposefully, to go with software that’s become outdated is a valid pathway, but, and this is key, it’s also a choice to take on responsibility for the experience that choice provides.
Putting off that attention debt on someone else isn’t just unfair. It should frankly be disqualifying, at least if the intention is to provide a user experience that spares the end user from paying the debt that distributions are meant to soften.
What good software gives back
The Mint and GNOME Calendar dispute shows what happens when that exchange of attention breaks down. More broadly, it also shows why good software stewardship matters just as much as good software itself.
Good software doesn’t eliminate the need for attention. It makes the user’s effort worthwhile by giving them greater capability, confidence, or control. It also makes the developer’s effort rewarding by turning their work into something useful, appreciated, and worth maintaining.
Ultimately, good software makes sure that attention is spent responsibly and gives something meaningful back.
Practical Tip: Pay some attention forward
This week, let’s commit to do one small thing that saves someone else some attention debt:
- Document a workaround.
- Improve an error message.
- Answer a question clearly.
- File a useful bug report.
- Add the missing context someone else will need later.
Attention debt grows whenever unresolved work is passed down the line. Paying some of it off is one of the simplest ways to make software, and the communities around it, better.
If you want to stay in this lane
I’ve written some related articles in this series that you might find interesting if you liked this one:
- Why form equals function
A people-first look at software design, usability, friction, and why the experience of using a tool is part of its functionality. - The Myth of the Learning Curve
Why software shouldn’t be judged only by the attention it initially demands, but by what that investment eventually gives back. - What happens when open-source takes itself seriously?
A look at how stronger usability, packaging, governance, and professional stewardship are helping open-source serve users better. - Open-Source Owes Us Nothing, And That's Good
A deeper look at obligation, exchange, and what open-source developers, projects, and users actually owe one another.
Working with us
At RolandiXor Media Inc., we blend design and open-source thinking for our clients.
Elsewhere
- Mastodon: mastodon.social/@rolandixor
- Threads: @rolandixor
- X: @rolandixor
Support this work
If this writing has been useful and you’d like to help sustain it:
→ https://ko-fi.com/rolandixor
Catch you in the next Roll Out!
Comments