Jon Alper's probably insufficiently humble opinion

I need to spend more time with it but here are my preliminary reactions to the Mac App Store in no particular order:

• The standard license is actually nicely liberal in terms of what you’re allowed to use where. (Any Mac you own or control if you’re not a commercial user.)
• The pricing model, for now anyway, is hardly settled. It appears Apple will discount and unbundle some of their products for sale on the App Store as compared to their retail price. (Aperture as an example of discounting and iWork and iLife apps as examples of unbundling.) Some third party Products are priced oddly. Full versions of RapidWeaver and upgrades of RapidWeaver are the same price.
• The installation process is, to me, creepily opaque. It is exactly like iPhone/iPad. Download, a little icon proxy flies from the App Store application to the dock and an iOS-like progress bar appears on the app icon in the dock while it downloads and installs.  No idea what goes where, no way to inspect a package prior to install to see what you can about what might go where.
• The installation process leaves you nothing ‘portable’. While you may own a license, it appears you must pull down each copy of your App Store purchased software from Apple on each machine you use it on.
• Because what you download doesn’t seem to be kept in any kind of package or, better yet, a .dmg, you loose control of configuration management. If you are in the midst of a project on one machine and need, for example, to move it to your laptop, you have to install whatever version is currently available on the App Store. That version may not be bug for bug compatible with the version you’ve started your project with. It’s an essential truth, once in the full throws of production you avoid changing your tool chain if at all possible. If you rely on the App Store, you have lost this control.
• Apple seems to be able to tell a lot more about my Mac than I want them to by simple dint of my launching the App Store. They know what third party software I have installed. This is, arguably, good for the the user so they don’t re-purchase something they bought via another channel but the App Store application should ask me if I want it to check. What third party software I’ve bought via other channels is, frankly, is none of Apple’s business. It’s unclear whether Apple gets a complete list of all apps or only query my machine for those apps that are made available in the app store. The former is surely more troubling but even the latter doesn’t give me a warm fuzzy. Now, before you call me paranoid, The law allows me to, under some circumstances, decrypt CSS encoded DVD’s. Getting into the question with Apple, or anyone else, whether or not my possession of the tools to do so is in keeping with fast changing law isn’t something I would pro-actively choose to share with Apple.
• I actively use no less (and often more) than 3 Macs (and sometimes WinTel and Linux machines) at a time in the course of doing both my personal and professional work, all of the above poses administrative challenges for me but, for clients where I manage sometimes hundreds of Macs, it could get very messy very fast.
• Creation and maintenance of install (deployment) images could be nightmarish given the issues above. If you maintain 100 Macs, you build a standard install disk image(s) and you clone to your machines as you deploy new hardware. The use of receipts as authentication for legitimate licenses and the lack of stand-alone installers will make this as unfun as online activation. There’s a reason corporate volume licensing usually includes an installer that doesn’t rely on online activation. (Adobe and Microsoft for example)

Here are my predictions as of day one, the App Store is going to be a mixed bag:

• The iOS app store is essentially an uncurated disaster area. Discovering quality applications is next to impossible for the novice user and the frivolous applications crowd out those of genuine utility and refinement. Even at day one, the Mac App Store is littered with faux-free apps that are useless without the purchase of a commercial iOS app. Cluttered with apps that fall well below any kind of reasonable design quality standard (language NSFW) and chock-a-block with casual games. This will make it VERY hard for some publishers and there will be good products killed.
• The presumption of a broadband connected computer is not the same as the presumption of a network connected mobile device. This could undermine Apple’s currently improving place in non-consumer environments. The valid usecases where desktop computers are not connected to the public internet (or shouldn’t be) include:
  • Forensics Workstations for law enforcement
  • Administration Consoles for Servers in a Data Center
  • Production workstations for video and graphics in some environments
  • Production workstations used for live performance
  • Software development environments for life-safety critical environments.
• The perception of Apple as a closed company is not aided by the walled garden of an Apple-mediated software marketplace. This will undermine Apple’s claims about openness, the value of open source and will alienate significant portions of their developer community.
• Laws of economic inertia risk making it impractical for third party software vendors to sell their products outside of Apple’s App Store ecosystem. Retail boxes, online stores, distribution providers like Kagi etc. are all jeopardized.

As of today, I will not be purchasing my software from the App Store and do not recommend clients and colleagues to either. There needs to be a lot more thought put into how it works and how the above concerns can be addressed. For now, the traditional distribution chains solve many of these problems in many cases. In the cases they don’t, you should already have been seeking alternate vendors. If you stick to those chains and communicate your concerns to the companies whose tools you rely on (including Apple), you can help ensure your options remain workable.

**Updates** (note, there will, surely, be new articles on this subject, updates below will only be for corrections and minor additions during early days)

Also, via Daring Fireball: http://ifiboughtyourappalreadycaniupdateitthroughthemacappstore.com/

(some updates inline)

I wish I could tell you all the horror stories. They’ve happened with some of the high budget projects I’ve done at every gig I’ve had. I’ll do my best to warn you without being able to actually show you all of the skeletons.

Somebody, usually somebody with more management experience than technical field experience will have a legitimate and very serious problem with how some workflow or business function is done at your company. They’ll meet somebody, read something and an email will arrive asking you to look into a new product or service that promises to solve their problem. The problem will be real and it will be important. Now, as a technology manager, you’re at a crossroads. How do you communicate your assessment of their proposed solution? Sorry, can’t help you. Too many variables. Is your boss ‘science minded’? Is she somebody you can have a real conversation with who will work alongside you to evaluate their idea? Damn, you’re a lucky devil. Is he a puffed up MBA-having-suit-wearing-testosterone-juiced-schmuck who got the job despite all reason? You’re hosed. The reality is, you’re almost surely waist deep in the vast expanse of gray in between. What I can tell you is, do some due diligence and don’t rely on IT industry press ‘case study’ articles and customer testimonials.

I first learned this lesson the hard way at my first real job managing a network and support for a medium sized business. I sold my boss on a service contract for CE Software’s QuickMail. We were already using QuickMail (served with damned near bulletproof reliability from an SE-30. I was pitched a long term contract by CE for a roadmap of upgrades. I was handed all sorts of documentation about how other customers were doing well in these arrangements and given prospective ROI analysis that painted a nice rosey picture for the future. I pitched my then boss with passion. I didn’t do enough homework. CE never shipped what they promised. The roadmap was vapor. My employer got screwed for a few grand. I felt terrible about it. My boss at the time, I think actually saw it coming and let it happen to give me some on the job training. He wouldn’t no matter how much I begged him to, let me point the company’s pit-bull lawyers at CE.  There were lots of lessons for me in this experience and some of those will be the topic of future posts. But the key lesson is, don’t believe what you read. Test, test, test.

What I can tell you is this. If you read an article in the I.T. press talking about how Enormocorp successfully deployed the proposed solution, it’s a lie. I mean it. If you read an article in “How to succeed in IT” magazine  featuring an interview with a CIO who just deployed a multimillion dollar CRM system and the quotes talk all about the amazing ROI, it’s a lie. It can’t be used as meaningful data in making your decision about whether your company needs the product. If the sales guy shows you this article? If he has a stack of five others like it? if his whole presentation is all about how deploying his solution will help make your small company able to be as successful as his Fortune 500 poster child clients? You are in serious trouble.

Now, did the CIO interviewed actually lie? Probably not. The article wasn’t long enough for enough truth. Here’s how it happens. How do I know? I was the guy you shouldn’t have relied on.

I was an avid user and advocate for Retrospect (A LAN backup package then made by a company called Dantz). I made a decent portion of my living for years implementing a series of successful deployments of Retrospect. Honestly, and I mean this, I saved companies I worked for literally millions deploying Retrospect for them. I enjoyed a great relationship with Dantz during this time and some of those people I knew back then at Dantz are, to this day, people I’d call friends. Retrospect was, at the time, a truly spectacular product.

My relationship with Dantz was so good, I got seeded with betas before they even admitted they were working on a new version. Back then, everything wasn’t in perpetual beta. I got surreal levels of support and I ate a lot of good meals on their dime. At the height of their success I was one of a half dozen or so consultants and I.T. managers asked to do a promotional interview for them. I can count on one hand with a spare finger or two, the number of companies I’ve ever trusted enough to say yes to that kind of request. I did the interview, I had a few laughs. The somewhat colorful  out-takes apparently made an internal reel shown to employees. I told the absolute truth. At the time, Retrospect essentially had a monopoly the automated backup business on MacOS and deserved to. I never had access to sales figures but I personally had well more than a thousand nodes in the  field  that I’d supported, deployed or spec’d at some very big name clients.

The day that tape was made, if you bought into Retrospect and had a clue, you’d have probably done very well for your users and bottom line. If, a year later, you saw that clip and invested in a large scale Retrospect deployment, you’d have done OK. If, two years later you had? Perhaps, not so much.

This was because the Mac, the only platform Retrospect really supported fully at the time, was in a major transition to OS X. This was not easy for a company like Dantz to cope with. Apple was in a certain amount of chaos. MacOS was being fundamentally changed from the ground up and Dantz was investing in more cross platform support. Ultimately, Dantz was sold to EMC. By then, while still a useful tool, things were far from the “This damned thing just works” truth I’d spoken on the tape. By then? What I’d said on tape became a lie. It wasn’t when I said it but it became one.

Also, the promotional case studies tape, because its purpose was to talk about Retrospect, no deeper discussion of backup strategies, archiving and good disaster planning was even discussed. If you relied on Retrospect as your entire solution you’d have been in deep trouble. I didn’t lie about how great Retrospect was but anyone who deployed Retrospect without a lot of other work and concurrent procedures could well have ended up screwed. Anyone who added up the number of seats they needed, added the most expensive Mac they could buy to the budge for a server and thought that actually represented the real budget to deploy was in deep trouble. If you heard me say “buying Retrospect will solve all your backup, archiving and disaster planning problems” then you heard a lie. The fact that didn’t say that, and would never have said that doesn’t help you feel any better about having trusted what you’d heard however much you heard was different from what I’d said on that promo tape.

So, that’s a best case where the well intentioned quotes become lies. Here’s another reality behind most of the quotes and short case study articles you read and I’m saying this because I have read them about projects I’ve worked on. The case studies are often written and most publicized before the projects are even finished. They’re written during the deployments and, as is usually the case, right when everyone working on the deployment is in a honeymoon with the vendor and the vendor is psyched to have a poster child client. The foot soldier employees probably aren’t working with the system on a day to day basis yet. The total costs of the training haven’t been accounted for yet. The costs of changes in workflow imposed by the tool haven’t been accounted for yet (and often never are). You’re being pitched the success of the John Hancock Tower in Boston right before the windows have started to pop out in the wind.

One particularly sordid example I need to be circumspect about was a client who spent, literally, millions on big iron to serve a website using what was, for about ten minutes, the high fashion CMS du jour. The CMS maker’s CEO was driving around in his ‘explosive dot com ere growth funded’ Ferrari talking about how well the CMS was doing in an emerging marketplace. The hardware vendor was crowing about the partnership. There was press about the client’s choice of and success with the CMS.

The truth, however, was that the website hosted on that CMS never worked properly. The developers who ultimately had to wrestle with it on a day to day basis were in agony.  It never produced increased revenue. It had downtime incidents that amounted to days in a year. The CMS vendor folded in a hail of internal acrimony. The language of the CMS fell into a level of deprecation that would make studying Cobol seem a good career move today. The hardware ended up being a hundredfold or more in excess of what was ever necessary with the price tag and sever room infrastructure costs to match. None of the experienced technical staff working for the client wanted it to happen. Everybody, including me, counseled against it. Press quotes, books, testimonials and buzzwords overcame seasoned judgement and millions were lost. The press about it? About this deployment? The case study quotes? All one hundred percent positive.

If you’re being pitched an enterprise product to revolutionize your business, don’t believe what you read. Insist on much deeper dialog with existing and current customers. Plan a staged process of test deployment and evaluation. Listen to your internal staff’s concerns. Don’t listen to lies even when they may well have been spoken with all sincerity.

I know how to use Photoshop. I know things about Photoshop that some of the most brilliantly talented and award winning advanced degree’d amazing designers I know don’t know about Photoshop. I’m pretty damned good at sharpening pencils with a pocket knife too. Doesn’t mean I can draw.

I’m hardly visually clueless, I’m a photographer, by some definitions a professional photographer*, and, not to blow my own horn (to much),  I am a pretty damned good lighting designer because that was my profession for more than a decade.

What I am not is a graphic designer or illustrator. No matter how often I do it when the stakes are low and I can get by, sort of, I am not the right guy to do that job. I can be the right guy to work with designers, even to manage them on a project but I’m not the right guy to do it. When you need visual designer or an illustrator, hire one. Don’t kid yourself into thinking that because you know how to use the tools, or think you do, that you have the talent or training to do a job that’s at least as complex, refined, subtle and demanding of expert skills as being a PHP and MySQL coder.

A ‘web designer’ is a non-existent creature. There are graphic and UE designers, Illustrators, UE coders and back-end coders. There are Producers, there are Writers and there are Editors. Anyone who claims to be all of those things isn’t. Being multi-talented isn’t being multi-expert. Are you of more benefit to your team if you have more than one skill? Of course! Are you the team? No.

Contrary to intuition, it’s NOT more cost effective to hire a ‘web designer’ than it is to hire a producer, designer and developer who can work together. It’s only cheaper. Cheaper as in shoddy and a bad investment. Cheaper as in, you’ll fail or pay for a do-over.

Thanks to one of the most talented designer/illustrators I know for letting me hire him to render, well, me.

Rick Pinchera rocks! Know what the most fun aspect of this was? Not giving him any photo to reference or feedback to make him iterate and just letting him see me as he remembered. It’s depressingly faithful (I really do have a that good a face for radio) and it’s marvelously whimsical. Thank you Rick!

* Some define ‘professional photographer” as a person who gets paid to take photographs. I prefer the narrower, definition; someone who earns their primary livelihood taking photographs and that is not me.