A ‘Leopard’ Wish List

With the Apple World Wide Developers Conference, (WWDC)getting closer, and with it, the much anticipated preview of Mac OS X 10.5, aka “Leopard”, the “What we want to see” calls have started up. While most are pretty sensible, some are not what I would term…realistic.

However, there is value in putting wish lists out there for others to see and comment on. If nothing else, it can help you feel like you’re not the only one wishing for a given feature. Obviously, I’m about to do the same thing here. However, this is more of a “What I’d like to see from Apple for the Leopard time frame.”

One of the things I see a lot of are variations on “Apple must become an ‘Enterprise’ company.” Now, even allowing for the fact that “Enterprise” can mean whatever the user wants it to, I disagree. HP, Microsoft, Dell, IBM, those are “Enterprise” companies. They aren’t much for surprises. The last time Microsoft tried was with “Origami” and that didn’t work all that well. The only surprise is how bad the real product name turned out to be.

Apple is all about the surprise, the “wow” factor. “Just one more thing” is not a catchphrase for a product that was laid out in a roadmap six months or a year ago. It’s a catchphrase for a surprise, a product you didn’t think you needed, but once you see it, you realize that you’ve been severely deprived in not having it.

That brings me to another point. Roadmaps. People love to castigate Apple for not having roadmaps. Well, I’ve been in this business for coming up on 20 years, and I’ve yet to deal with a roadmap outside of the mainframe/mini/big iron Unix space that wasn’t polite fiction. Best example: Any Microsoft roadmap.

Ways to Support Mac Network Admins

Roadmaps are good only if you remove any hint of a date, and even then, not so much, as the “Now it’s part of ADO.NET and SQL Server” fate of WinFS shows. Apple may not give you any warning of when they’re announcing a product, but at least when they do, it’s a real product. Short-term and reliable beats long-term and fantasy in my book.

Apple is not an “Enterprise” company. It never has been, and never will be. It isn’t big enough, and it would have to spend so much money and effort to become one that it would stop being Apple. The company tried that a few times. Didn’t work so well.

However, having said that, there arethings Apple can do to help support the people who support and administrate large Mac networks. Note that not all of these are my own ideas, but they’re all good ideas, so I’m doing my best to get them heard.

1. While Apple has always tried to make sure that they take good care of the folks in the K-12 space who get the unenviable duty of being a part-time network administrator, I think that a lot of their tools are trading simple for simplistic.

   The DNS tool in Server Admin is the best/worst example of this. First, DNS is not an easy thing to grasp as a concept. Even worse, a bad DNS setup can cause real problems that reach out far beyond your network.

   The problem is, the DNS tool in Server Admin is so simplistic that it ends up causing as many problems as it solves. There needs to be an understanding that a tool doesn’t have to be so crippled that it’s effectively useless to be easy to use.

   The tools that Apple provides to Mac administrators need to be reworked to where they can be better used at all levels of functionality. The Open Directory administrator tools are in great need of this. Better visualization of the directory structure is desperately needed, the ability to use OUs directly in the tools, drag and drop, etc. It may make the tools more complex overall, but there’s always the option of the “Advanced” tab that lives in so many other of Server Admin’s components. In either event, the current Server Tools UI is just too limiting for anything but the simplest networks.

   Oh yes, and the “I rewrote all your files” thing has to stop. If Server Admin simply MUST completely rewrite the files, then it needs to scan for non-standard content, warn us that this will be overwritten and gone, and automatically create a backup of the original file. Not an unreasonable expectation.

2. No one with any experience expects that Apple will ever reveal future products. That’s not a problem. However, letting us know when things are due to be end-of-life’d, (EOL) is not a future prediction. We don’t need to know the minute the product’s released. But when a new major version is announced, a kbase article letting us know when the now old version will be EOL’d, will be good.

   If they want to put it on a regular schedule, that would be excellent as well. For example, once a new OS is released, the previous version will only receive critical bug fixes and security patches, and will be EOL’d three years from that date. This doesn’t reveal future plans, nor does it create unrealistic expectations. In fact, it avoidsunrealistic expectations that crop up in a lack of facts.

3. Create more separation between Developer and IT, or maybe better, make more use of the Enterprise IT areas on apple.com. For example, there’s a ton of useful information in the Apple Developer area on Mac OS X Server administration topics. But the the URL?

   http://developer.apple.com/documentation/MacOSXServer/Conceptual/XServer_ProgrammingGuide/

   Sysadmins and developers may work in the same departments in the enterprise, but they aren’t the same jobs, and administrators new to the Mac are not going to say “Oh, I’ll just look in the dev. docs, because APIs and server configuration are the same thing.” They aren’t, and it causes more confusion than it should.

   That’s not to say it should be a complete wall, or that common information needs to be duplicated. But creating “enterprise.apple.com” or something similar would make it easier to present the information that administrators need in a way that doesn’t require them to parse through developer documentation.

4. Along the same lines, create an “Apple Enterprise Connection.” (Again, I’m just using “Enterprise” as a descriptive term, I like it better than “Sysadmin”. Don’t read anything more into it than that.) Model it after the Apple Developer Connection. ADC, EDC. Simple. It doesn’t have to be free. The ADC isn’t, and nor should this.

   It takes time and effort and resources to support this kind of effort, charging for it makes sense. But it would allow for IT administrators to get the information and resources they need without the perennial explanation of why an administrator has to go to a developer conference, and Yes, I know Microsoft has their TechNet conference, but this isn’t Microsoft, it’s Apple, so this is the only tech conference they have.

   That’s a harder sell than some may think. This would help finding documentation, making more IT – specific documentation available, etc. The continued combination of both in the ADC is just making it harder for both sides to quickly find what they need. Bite the bullet now, spend some time creating a good, logical program, and unveil it the day Leopard server is released.

5. Since I mentioned the WWDC…it’s getting crowded. There are, out of all the sessions listed, not including labs and hands-on stuff, 33 sessions in the IT track alone, and overall, 62 sessions that jump out at me as of being immediately useful to sysadmins.

   As anyone who’s been to a WWDC since they started the IT tracks, the space contention and overcrowding gets worse every year. When 20% of all the listed sessions are in the IT track alone, and just over a third of ALL the sessions are in the IT arena, it’s time to think about creating a WWEC, or WorldWide Enterprise Conference.

   There’s a limit to how big the WWDC can get before it becomes unwieldy. For that kind of conference, unwieldy is very bad. Better to have two smaller conferences, and increase the overall satisfaction levels than to keep shoehorning more and more IT people into a developer conference, and making it harder for the attendees to get their money’s worth out of it.

6. Apple has a rather large Enterprise support group. Maybe not large compared to IBM, but it’s not three guys in a minivan either. The people in this group create reams of documentation for fixing real world problems. Document it, and ship it out once a month to subscribers. Charge for it. I know that if I got a set of DVDs every month with real world fixes that were in PDF form with a solid index, that would have an ROI of about 10 minutes. IBM has been doing this forever with Redbooks. Redact specific customer information, but get the general fixes out there. I know it seems strange, but the less I haveto pull the trigger on a formal support call, the better I feel about it when I do.

7. Promote the Apple Certified System Administrator (ACSA) program more. Promote the XSAN training more. Apple has some of the best training programs and trainers in the business, but you have to go looking for them. (http://www.apple.com/training/if you didn’t know.) They need to take advantage of every possible chance to get people into that program. Boot camps during Macworld Expo, Boot Camps the week before the WWDC. (If I’m going to be at the WWDC anyway, staying an extra week for something of immediate value and ROI isn’t hard to justify. I know it’s easier than justifying a week somewhere else or a day here, three days there, etc.)

   One of the smartest things Microsoft ever did for Windows Server was the MCSE program, and Apple should start considering that every time someone gets an ACSA, they just gained another network running Mac OS X Server.

8. Better IT documentation in general. Recently, I tried to find an authoritative source for how much machine I need to be a streaming server for h.264. I could find a nice bandwidth calculator on Apple’s Quicktime Streaming Server site, but nothing that talked about CPU, RAM, etc. The QTSS site just assumes you’ll use a dualie Xserve G5. As it turns out, that’s about what you need, but not having that information added a month to the troubleshooting process.

   Again, the documentation team at Apple doesn’t have to be the sole source of this. If they work with Enterprise support and the Enterprise SE’s, a lot of this stuff would need possible reformatting, but that’s it. Along with this, whenever a kbase article is released that talks about a specific fix to a bug in Apple’s bug tracking system, aka RADAR, reference the specific bug number.

9. More detailed release notes. Not just a list of general fixes, but a list of the specific RADAR numbers fixed. Apple did this early on in Mac OS X’s history, and it was greatly appreciated. The security notes for various updates, patches and releases have gotten better, but outside of security, the current release notes are far too general to be of real use. Yes, they’d be long and boring, but support people can deal with that. We like it. Long, boring technical details. Bore us until we cry. Really. We won’t complain. Well some will, but the vast majority of us will appreciate it. Note that none of this involves releasing future information. We just need more and better details on current products.

10. OK, just so this has something to do with Leopard specifically…currently, when a Carbon application gets wedged, overly busy, whatever, and you get the spinning colorwheel of doom, you can’t move the application’s window out of the way like you can a Cocoa application’s. Fixing that would be right handy. Oh, and let me delete specific list and record items in AppleScript.

    Hopefully, that’s not too ridiculous a wish list for Apple in the Leopard timeframe. As I said, a lot of those issues come from other folks, so for those, I’m just helping them reach a wider audience. I don’t expect Apple to morph into HP, or even the DEC of old. That would effectively ruin the company, and no one wants that. But, more care and feeding of sysadmins and support folks who are supporting all the Mac users in education and the Enterprise is certainly attainable without major trauma.