inessential by Brent Simmons

January 2019

On Public Bug Trackers

For open source projects it makes sense to have a public bug tracker. It would be hard to do the work without it.

But for commercial software? It’s not a good idea at all.

(I bring this up because I saw someone suggest this idea recently, and it stuck in my head.)

Decisions about what to work on — and when, and by whom — are complicated. From the outside it might look like it’s as simple as picking the next feature request with the most votes, but it’s not that simple.

A company might prioritize a crashing bug over that bug.

Or that feature might need x, y, z and done first, all of which require major work — maybe it needs some surprising amount of design or under-the-hood work, or both, that the requestors understandably don’t know about. Or it needs a bunch of localizations. Or lots of extra testing because the implementation is complex or wide-ranging — or it’s in an area where it could cause regressions.

Or the person who best knows that area of the code is temporarily on another team to help with another company priority. Or that person is going on vacation.

Or there are features nobody has asked for specifically, but that the company thinks would be awesome, and those get priority.

Or there are a half-dozen features that are low-hanging fruit, and for various reasons it’s a good idea to do a bunch of easy things for a while.

Or the feature doesn’t even really fit with the app: companies make that call all the time. (I never added Usenet support to NetNewsWire, despite getting requests for it.)

Or the feature is actually impossible. Or impossible without spending two years and a few million dollars on research and development first.

Or there’s a new OS feature that should be supported. Or an incompatibility with a new OS to fix.

And so on — the list goes on.

But if you have a public bug tracker, you’d likely find that you’re having to explain your decisions all the time. You’d be constantly defending your plans to people who remind you that Feature X has all these votes, so why hasn’t it shipped yet?

I’d argue that most companies aren’t open and accessible enough. Many companies don’t listen to their users very well. Many don’t even write honest and respectful release notes.

But opening up the bug tracker to the public is just a way to get bogged down: it’s a way to make worse decisions, and make them more slowly.

NetNewsWire Privacy Policy

I’ve been working on the NetNewsWire privacy policy, which I realized I needed as I was working on crash log collecting.

If you have questions, feedback, or suggestions, please let me know.

The gist is pretty simple: I really, really, really do not want anybody’s information. It’s not interesting or useful to me, and managing it is a burden I don’t want. Most importantly: I believe strongly in not just a decentralized web but a web where privacy is respected.

That said, I do have webserver logs (which, frankly, I complete ignore — I don’t even look at the stats, though that could change), and I collect crash logs when the user opts in, because making sure that the app doesn’t crash is job one.

* * *

My favorite line of the privacy policy:

Neither ranchero.com nor inessential.com use any cookies or JavaScript, and they do not display any ads.

I wish there were a clever marketing name for no-cookies/no-JavaScript sites. It should be a trend.

While the industry is focused on SSL everywhere, we’re not looking at the other half of surveillance tech.

I’ll actually be attending the Xcoders meeting tomorrow — not just the after-hours thing. I’m making an effort. It’s a new year. Why not?

What’s cool is a talk from Sean McNeil on ReactiveSwift. I’ve been personally skeptical about React-style frameworks on Mac and iOS, because experience, and the wisdom of others with experience, tells me that the further you get from Apple’s frameworks the less your app will feel like a native app.

The best advice has always been “Don’t fight the frameworks!”

But still — this is something I should learn about rather than just dismiss it. So I will.

* * *

Despite my skepticism about React for Mac and iOS apps, I have pretty strong feelings about things I think React folks would agree with: minimize state, for instance. Use immutable objects and structs. Don’t share memory across threads (queues). (NetNewsWire’s coding guidelines goes into more detail.)

The web will, eventually, make everyone a crime victim.