3 notes

Why I won’t depend on your pre-release software

I’m sure your pre-release software is more fun than heroin, but experience has taught me to consider it off-limits.

It’s for your own good.

Trust me, you don’t want me to depend on your unfinished work. Do you know what will happen if I do that? I can tell you, because I’ve seen it many times before.

Excitement about an upcoming release is contagious. It spreads through user communities, with little correlation to the actual release schedule. For example, at a conference there is naturally great interest in what’s coming next. Out with the old, in with the not-quite-here-yet! Attendees are often left with the impression that the good things are just a few months away, whatever the schedule says or doesn’t say.

So if I’m working on a related project, why not build for the next big thing that seems to be around the corner instead of wasting time on “throwaway code” built for last year’s big thing? My educated guess could be that the next release is about 3 months away. If I start now I could have my release ready to go in tandem with yours.

But skip ahead to 6 months later. My guess was wrong and your software is still not released. In the mean time I may have helped you find some bugs or identify unworkable interfaces. But for the most part, my interests have been to pressure you in two conflicting ways: prioritize the bugs and feature gaps that matter to me, and release this damn thing already. In other words, I have been a bad influence.

However many people you have lured onto your pre-release crazytrain, they’ll have their own special demands. You may try to please all of them, but this will only delay your release further. In the end, all crazytrain passengers are unhappy. And crazy.

There’s just no better way to convert your biggest fans into loudmouthed grumpy-pants than inviting them to upgrade to your “snapshot”.

It’s for my own good.

Programming is uncertain enough without importing the uncertainties of your unreleased software into mine.

I spend some time contributing to open source software, and I would like to spend it as efficiently as possible. The more time I spend diagnosing build problems, broken interfaces, and buggy libraries, the less I want to spend at all. If I’m not careful this cycle will reach an equilibrium state of me contributing nothing.

It’s also bad for my projects. In the hypothetical scenario where I expected your release three months ago, I’ve split my efforts between a maintenance branch and a cool-new-features-branch to be released on a schedule that is outside my control. As a result nobody can benefit from my work and I can’t even tell them when they can.

So instead of doing that, consistently and for a number of years now I just haven’t built anything with pre-release software. I’ll use a beta on occasion if I have reason to believe the interface is stable and if the beta shares distribution channels and build characteristics with releases. In other words, I won’t work with anything that that would impede me releasing my own work today.

As a result I can appreciate your final software releases without suffering the battle scars, the bitter arguments, and inevitable disappointments it took to get there. Not that I’m lazy: I walk that same road in my personal projects. I release my software, and people start to use it Yours is developed over a longer time and released whenever, without holding up mine or those that depend on mine. It’s pretty cool.

You see, non-blocking behavior is useful at this scale, too.

Release early and often.

Far be it from me to tell you how to manage your project, but the easiest way to slip into a pre-release coma is to corrupt naturally arising release cycles—the heartbeat of your software—with marketing. This is not 1995 and you are not Microsoft.

All I need is a versioned release that does what it says and doesn’t take my build process into a new circle of hell. When you have that, you can “ship” it.

See you at the next release!



21 notes

Foxes (or asses) guarding the hen house

Six months ago when the iPhone location logging story broke, this Android fan refrained from gloating. Why? Because you can trust the corporate intelligence of handset manufacturers and wireless service providers about as much as #occupywallstreet protesters can trust the NYPD to lead them merrily across the Brooklyn Bridge.

It was just a matter of time before a severe data breach occurred with the variants of Android that carriers and manufacturers cobble together. We’ve already seen a pretty amazing data destruction bug from Samsung. Everybody’s system customizations are closed source, so nobody else knows what kind of foolishness is going on in there. For a while.

I am quite speechless right now. Justin Case and I have spent all day together with Trevor Eckhart (you may remember him as TrevE of DamageControl and Virus ROMs) looking into Trev’s findings deep inside HTC’s latest software installed on such phones as EVO 3D, EVO 4G, Thunderbolt, and others.

Android Police

Did they find this scary thing before the “bad guys”? Who knows. The bad guys stand to make a lot of money by finding such vulnerabilities quickly, and keeping them secret.

In recent updates to some of its devices, HTC introduces a suite of logging tools that collected information. Lots of information. LOTS. Whatever the reason was, whether for better understanding problems on users’ devices, easier remote analysis, corporate evilness - it doesn’t matter.

Android Police gets that point right away. It doesn’t matter what the explanation is for this breach, or that breach. This one is worse than Apple’s because the data (including but not limited to location) is accessible to third-party apps. Neither came from building features that users actually want.

The reason these privacy breaches keep happening, in general and across different mobile platforms, is that mobile commercial interests are largely at odds with those of device owners and users. And since there’s little consequence to sellers for using/abusing their power over buyers, it’s only natural for them to do so.

The iPhone location logging incident convinced me that, for devices we take everywhere and use for everything, an open-source operating system is even more necessary than it is on old-fashioned desktops and laptops. It’s the only way to have any confidence that your phone is not, actually, a fancy piece of spy equipment with you as its subject.

But it takes some time and effort to root and flash a phone, and when I got a new (used) HTC Incredible I did really appreciate the famously hawt HTC weather app. (It actually flashes your screen in a thunderstorm!) I allowed myself to slip again into a misplaced trust in the manufacturer to code a better “user experience” for their device than anyone else. That trance could have lasted many more months, but it finally broke when I broke my Incredible’s touchscreen.

Incredible reassembly

I decided to try to replace the glass with my own fumbling fingers. At one low point it seemed like the hardware was borked anyway (it wasn’t), so I went ahead and flashed CyanogenMod on it for fun.

It was love at first sight.

Definition of Open

Touchscreen phones are pretty awesome toys in the first place, but having system software that is actually written for its user is a whole new game. The differences come out in unexpected places, like finally being able to set the screen brightness for particular levels of ambient light. Why can’t you do that on any stock phone? Because the people who make them are stupid, or they think you are. Either way.

And screenshots. I’m now allowed to take screenshots, you guys! So crazy.

A clean install of Android 2.3 is pretty great in general. I had been stuck on 2.2 because HTC isn’t updating the original Incredible these days—why would they? But with CyanogenMod this old battle axe is as sharp as any new phone, which is a funny thing considering you can get a used Incredible for a little over a hundred dollars on eBay. It’s almost as if you don’t need to sign a multi-year, multi-thousand-dollar service contract to be able to “afford” a good wireless touchscreen computer.

But most of the improved value is in the knowledge that all of the code in the OS is open to the public. There is no completely daft insecure logging going on, the way there is right now on stock HTC phones, because nobody would commit such garbage under their own public name. Want to double-check CyanogenMod’s optional, anonymous statistics collection? It’s on github.

If you have a stock HTC phone that can be flashed to an unencumbered operating system, you’d better do it right now to be safe. Or, if you have some other device with mystery meat software running the show, don’t get too comfortable in that hen house.

Whether it’s foxes or asses guarding the door, chickens are somebody’s dinner.

“It turns out that the International Intellectual Property Alliance, an umbrella group for organisations including the MPAA and RIAA, has requested with the US Trade Representative to consider countries like Indonesia, Brazil and India for its ‘Special 301 watchlist’ because they use open source software.”

Free software challenges “intellectual property” construct

}