Day One Support; Who Needs It?
MartinPacker 11000094DH Visits (406)
It’s the Time Of The Season1 for thinking about Day One support. Not for z/OS, or DB2, or CICS, or anything mainframe-related. But for iOS, MacOS and their kin.
Before you switch off - if you’re an Android user2 - you can consider the Apple bit an analogue. This post will be light on technical detail, and heavier on developers' approaches. It might even stimulate some discussion about z/OS.
So, it’s a month or so since Apple announced new iOS, MacOS, etc releases at their Worldwide Developer Conference (WWDC) and developers (and foolish / brave non-developers) have run betas. Several betas, in fact.
Part of the point is to prepare their products for General Availability3. And developers' approaches to that is what this post is about.
So, you can see this might have some relevance to z/OS and its vendor ecosystem.
Approaches To Day One
As I look around at the many iOS, WatchOS, and MacOS apps I have I see a number of approaches from the various developers. Here are a few examples:
Through these various approaches and stances runs a theme: I’ve emphasized the words “sole” and “Group” for a reason.
In Enterprise we might well appreciate the “more planned” approach Omni Group are taking. In the consumer space not quite so much.
But, back in 2014, I wrote in And Just Complain:
So, assumptions of tolerance of errors and issues is in limited supply everywhere.
What Do You Need?
There’s obviously a lot of Marketing value to being able to claim “Day One” support - for some markets. So, from a developer’s point of view, something close to Day One support is important. In “real world” terms there’s another point for developers: They really don’t want to field “iOS 124 broke your app” issues.
For the vendor - Apple or IBM - it’s great to have customers able to adopt their new release on Day One. In reality, though, many customers will want to skip early life and the “pioneer cost” issues5 that brings.
A few days ago (as I write this) was World Emoji Day. The relevance of World Emoji Day is surprisingly high: Each year on this day the Emoji standards body releases the new emoji for the year6. Apple traditionally supports these on the first point release after a new version of iOS or MacOS. That’s also where the first batch of “settling in” fixes are delivered for an iOS version. It might seem superficial but getting people to install this point release is a lot easier if there are new emoji to play with.7
And what about us, hapless punters that we are? Some of us are insanely keen to install the new operating system level on the day of release. I’m not consistently one of those. But pretty close.
When I review the myriad material coming out of WWDC, I take note of the new things8. But I consider what the operating system vendor ships as being “one shoe dropping”. I’m really looking forward to the other shoe dropping: What the app vendors ship.
But, of course, z/OS is different, or rather its customers are. Very few will install a new z/OS release at GA, for example. But they would like to know that all their products - whether vendor or IBM - work well before they need them to.
Exploitation might well be a different thing; My suspicion is most customers are less worried about exploitation. Though, if you ask them, quite a few customers will reply “I’m really looking forward to x”.
There is a whole interesting side conversation to be had about what drives customers to upgrade, quite apart from exploitation. Maybe another time. But, even if you’re just upgrading because you have to, it’s still important to know stuff continues to work. If you are a “Last Day Upgrader” (to coin a phrase) the chances are that vendor and IBM products will have introduced toleration.
But I still get excited at reading announcement material and learning about new functions.