If I had a $100 for every time I heard an engineer say that they were going to use a “porting layer” to keep their application “OS agnostic” I’d be a rich man. Most every software engineer dreams of writing magical portable applications that run anywhere with just a simple recompile.

I’ve got some advice for you: Set your expectations low. Very low.

It’s not that API emulation, porting layers and OS abstraction layers can’t make portable applications. There are examples where they can and do. The problem is that your new abstraction layer will likely only slightly abstract your application from your chosen OS. You can say it will port smoothly from WonkOS 6.6 to DinkOS 2.3 when you move next year… but if I were your manager I’d ask you to prove it before I invested a dime.

The problem with custom abstraction layers and API emulators is that most of them grow up in the dark and eat only mushrooms.

• You’ll also see abstraction layers that claim to enhance portability but yet have never actually been ported somewhere. You are in the dark. Who knows if it will help? How do you know it is better than just writing good portable code and fixing it in the future if needed?
• Most custom OS abstraction layers are used with just a single application: the one they were written with. It remains to be proven if the abstraction layer could be used with another application because there isn’t another one (written by unrelated authors) available to try. Is this really an application porting abstraction layer or just a convoluted method for this one application to make API calls? You’ve got feed that abstraction layer more than just mushrooms (your single application) to make it grow up big and strong.

So what should you do?

1. Strive to write more portable code.
2. Pick a API family that can take you to more than one OS. Pick a winner. Don’t pick some oddball micro-kernel message passing university R&D project… unless it emulates well a winner API. You’ll need more than just POSIX for many modern devices. This is one reason that I think Linux based device software platforms are on the ascent. It isn’t just the Linux API but the greater family of community software projects that become de facto standards and portability layers. GTK, Gstreamer, mundane stuff like libusb, etc.
3. If you really need a portability layer than get one from a 3rd party (proprietary or FLOSS). Something that has been proven to help and has helped a lot of applications.
4. If the available 3rd party options aren’t good enough why not consider investing effort to improve them rather than creating one from whole cloth?

Option 4 might be controversial but I figure that if there is a problem that more than 10 people in the world have had there is likely some sort of FLOSS project to try and fix it. Picking one of these up, enhancing it, and using it for your own project while helping the community has got to be better than doing it from scratch. At least you’ll have some sunlight and a diverse diet for your new creation to grow up in.

A non-exhaustive list of options to consider.

• Mapusoft
• Xenomai/SOLO
• v2lin
• Open Source Abstraction Layer (OSAL)

ShareThis

Pogue’s latest post in the NY Times Blogs about technical support is sure to strike a chord in anyone who has ever bothered to call a technical support line. Every once in a great while I’ve bothered to do so it I have to admit a certain degree of loathing to the whole process. What I hate about it is always getting asked the “dumb” questions. Read the rest of this entry »

ShareThis

Last post started with a link to a humorous blog about some of the, ahem, “interesting” questions that some support teams get asked by their customers.

I can say, luckily, that our customers are likely far above the average. I respect what they do, the projects they pull off, and the questions they ask. I’ve even learned some great lessons from them and that’s the subject for this post.

First of all I think of a television show I saw a few years ago. The show was detailing the inner operations of a US nuclear submarine. My brother in law served as a nuclear engineer on one of these boats for several years. Both the show and my conversations with my brother in law convinced me that what makes a nuclear submarine “safe” to operate isn’t technology as much as it is process. There is no master computer that can make all of the risk of operating a combination nuclear reactor, weapons platform, dormitory, and submersible vehicle disappear. It is inherently risky. What makes the risk palatable, manageable, and acceptable to otherwise sane sailors is the process and the training and discipline of those who execute the process.

The boat is safer because the sailors and what they do make it safer.

Could technical support be better if we, both users and providers of technical support, made it better by the processes we follow? I’ve seen cases where I think that to be true.

At MontaVista we offer technical support to our customers for the embedded Linux distribution and a wide array of Open Source software that constitutes our product. I’m not on the support team but I’ve been on the sidelines enough to have made some observations. Most of these are guided by a key customer I’ve worked with for almost 4 years. They are top notch engineers and seem to excel at getting high quality support out of all of their vendors. They’ve shown my how their processes help get the best out of vendor support:

1. Help teach your vendor support team about your expectations, the kind of projects that you are engaged on, and the needs that your team will have in the upcoming months. Have these details ready before they are needed.
2. Be personal, friendly, and professional. Real people are on both ends of the email chain.
3. Both sides should be vigilant about follow-ups and meeting expectations.
4. Introduce technology providers who are delivering to the same customer product. You never know when they will have to work together to tackle a technical issue.
5. The customer’s expectations matter the most but it is important that the vendor support team is being asked for something they can reasonably be expected to deliver on. Work in advance to make sure both sides understand what that is. Find better support channels to the vendor if the ones you have aren’t right for the customer’s expectations.

If markets truly are conversations than it is likely essential to make sure that the conversation of technical support transcends emails and trouble tickets. Find ways to go beyond just the support email.

So in the comments I’d love to know if you would ever consider participating in…

• private blogging between customer and tech support to keep up-to-date on what’s new in your projects?
• a shared private wiki so customers and tech support folks could cooperate closely?
• social worknets to glue partners together with their mutual customer?

ShareThis