Philosophy

Introduction

This document is designed to give some insight into what Openesque LLC is and is not.

Comments, criticism, and entertaining diatribes are welcome. E-mail to feedback@openesque.com.

Pragmatic, not dogmatic, solutions

The name "openesque" was chosen for this company for a reason. Openesque was originally formed to provide open source solutions. In many case, an open source solution may be less expensive, more reliable, and easier to maintain then a proprietary solution. But, then again, it may not. Openesque will not try and talk you into an open source solution when it's not the best tool for the job.

Openesque has evolved into a design and development house for embedded applications as well. In fact, as of this writing, embedded systems are the only thing we're doing (by chance more than plan.) Openesque is still available for open system development as well… we have the skills and resources to bring to bear to solve a wide range of problems.

In many cases, it may not be obvious if an open source solution is best for the job or not. Of course, some would argue that an open source solution is never the best tool for the job. Others would argue that a proprietary solution is never acceptable. We'll present you with the facts as we know them, and then you can decide which solution is best for your needs.

"Pragmatic, not dogmatic" applies to the rest of this document, and the company, as well. This document describes guiding principles. Your situation may not quite fit them. As long as it's legal, moral, and ethical to do so, we'll do what you want (and pay) us to do. If it doesn't go along with the principles laid out here, we'll tell you so, but with that being said, we'll comply with your wishes.

Openesque trade secrets

Openesque doesn't have any "trade secrets." However, we will enter into non-disclosure agreements as needed, as long as they're reasonable.

We have a wide variety of resources at our disposal to solve problems, and a lot of experience in many different areas. We have solved a lot of problems in a lot of different ways. We're willing to teach you as much, or as little, of this body of lore as you care to learn (or have time to learn).

If you want to learn how to run everything yourself, that's great. That means that you will become another valuable resource to Openesque. You'll probably use your systems in ways we don't, and master arcane topics that we haven't. Today's Openesque customer might be an Openesque subcontractor in the future. We don't know everything about every application on every system… but we can (and do) find someone who does.

Even if you decide to run your own solutions, we will still be here as a valuable resource for you. Very few businesses can run solely on open source solutions, but open source is what we specialize in, research constantly, and work with on a daily basis. We keep up on the open source literature, mailing lists, and news that you wish you had time to.

Openesque products

Openesque also doesn't have any "products." Our product is solving problems: design, implementation, deployment, and maintenance.

We can and do provide turnkey systems where hardware and software is pre-assembled and pre-configured, and ready to go for you. In these cases, we use whichever vendors we believe provide the best products to satisfy the particular project requirements with.

Solve the real problem

Openesque is, first and foremost, a company dedicated to solving problems, not selling software or systems. In some cases, Openesque will recommend not using any software to solve your problems. That is, strangely enough, a very controversial topic.

Why would we do that? Because we strive for simplicity and reliability in all of our solutions. Some problems are not solved "properly" with software or technological solutions; rather, they are best solved by better use of your most valuable resource—your staff.

Openesque is not, per se, a management, efficiency, or workflow consulting house. However, while we may not be one per se, we often end up being one de facto. This is because any non-trivial solution that we propose and implement will affect your business in one way or another. It will affect the way your employees work, or it will affect the way your customers and/or vendors interact with your company. We don't want to sell you a one size fits all, whiz-bang solution to all your problems, because it doesn't exist. Every solutions provider is meddling with your business, whether they say they are or not. We're simply aware of that fact. It's unavoidable.

Pretty much everyone has heard some horror story of how some software package ended up reorganizing the company to fit the software instead of the other way around. That is what we try to avoid at all costs. If your business is successful, it is so because you know how to run your business well. We want to help you do that better, not change everything you do to fit our model. In order to do that most effectively, we need to understand what you do and how you do it. So, we're not trying to be nosy up-front; we're just trying to do our job as best we can.

"Complexity is the enemy"

Truer words were never spoken. I originally recall this quote from Chuck Moore, the inventor of the Forth programming language, although it was probably first spoken by a wise man long ago.

Are your "user-friendly" computers really user-friendly? Most people that I know who aren't in the computer profession can barely operate their computers. Another "Chuck" that sums up my personal dilemma can be found at dumbentia.com (PDF file). I absolutely hate to not help friends and family members in need… but if I helped everyone I knew with a computer problem at a price they could afford (i.e.: gratis), I'd go broke, and never get to see my family! Personal computers are simply too difficult to use. Even the highly-touted Macintosh is too complicated.

Complex <fill in the blank> lead to system failures (a security compromise is a system failure in my book) and lost productivity.

In my "old age," I have come to shun fancy GUI-based tools in favor of (a) old-fashioned command-line tools that are suitable for shell scripting and (b) well-documented procedures for their use in a particular production environment. You may be better able to bluff your way through a GUI application… but do you really want to bluff on your mission-critical applications? I prefer to learn how to do it right once, write detailed application notes on the subject, and then use those notes to refresh my memory. I've found this to be simpler, more reliable, and better suited to handing off to someone else when it's time for me to have a well-deserved vacation.

That does not mean that Openesque will recommend discarding your Windows workstations and replacing them with dumb terminals. We won't. That's simply not practical. It does mean that we're not impressed with flashy tools, and you shouldn't be either. We're most impressed with the best tool… which tends to be the simplest tool that accomplishes the mission well.

In the embedded world, complexity is also the enemy. Microsoft has done an amazing job of delivering software that is bug-riddled, difficult to use—and has convinced their customers that it's because they're stupid. Rest assured that your customers will not be so merciful unto you. If your appliance isn't reliable, safe, and easy to use, they will blame your company. It's better to have a simple appliance that works than a complex, multifunction appliance that lets the user down frequently. You probably own a few yourself.

It's sad but true that, in the embedded world, the best compliment you'll usually get is a shrug and something like, "Yeah… we use it all the time. It works." Sometimes, you'll get praise for your well-designed equipment. However, the best compliment you can get is to be ignored, because it simply works. If you crave more attention, just make it hard to use, or ineffective. Then everyone will know your product.

The job isn't complete until the paperwork's done

Probably everyone has seen the guy on the toilet at the auto parts place with that slogan, so I'll refrain from providing a link to one of them.

Part of the fees we charge are for producing documentation of the work completed. This is for your benefit as well as ours. It's for our benefit, as it makes it easier and faster to jump back into your system later on. Of course, that's for your benefit too.

Also, if one of your employees (or another system consultant) needs to know what we've done in order to integrate their solution with ours, you have the documentation available to do so.

Finally, as mentioned previously, we don't have trade secrets. The documentation we provide will (hopefully) help you understand what we did better. That way, if you choose to, you can maintain the system yourself. It's your system; you paid for it.

Software documentation and commenting

This topic has been beaten to death and burned beyond recognition in thousands of mailing lists and Usenet newsgroups. Here's how we do it:

• The comments describe what the code is supposed to do.
• The code describes what the code actually does.

Most software these days is horribly under-documented, or the documentation is horribly out-of-date. One of the few exceptions these days is OpenBSD, where they take pride in keeping the manpages up-to-date. It's nice to see, and doesn't happen often enough.

Even in OpenBSD, the source code itself tends to be vastly under-commented. This is often times by design; it's a controversial issue. Some people argue that comments are a distraction from that task at hand, and you're better off actually reading the code to see what's going on. My problem with this approach is that without comments, you don't know what the developer actually intended the function or subroutine to do. Properly commented code helps to find bugs in the code itself, and also to reuse the code as it was intended to be used.

Some prefer to document code externally, with minimal comments inside the source files themselves. I have found this to be impractical. A developer who's busy writing code is not going to take the time to go to the documentation file and update it, especially if that involves using a different editor.

When it's time to write or modify code (as opposed to fixing bugs in the code,) the comments should be written first. This helps to focus the coding proper that happens next. It's harder to write code when you don't know what you're about to write. And, while you (the developer) may know exactly what you're about to write, the person who takes over the project after you won't know what you've written, and why you wrote it the way you did, if the comments aren't there.

Business productivity software

Or: "No matter how few tools I have, I always have too many."

In many cases, "business productivity software" is a contradiction in terms.

I have a multitude of computers running a variety of operating systems. I have a BlackBerry which I find invaluable for keeping track of contacts, appointments, etc. I have Office XP Professional, which is (unfortunately) a necessity to communicate with people enslaved to these tools… although OpenOffice is becoming more viable with each release.

My very best business productivity tools are a legal pad and a pen. While these tools can "crash" (coffee spill, broken pen, out of ink, etc.,) I keep hot-swappable spares available in my briefcase at all times. Whenever I'm talking with a client or a vendor, I'm using this, even if a computer is available. Again, it's more crash-resistant, and I can instantly switch between text and graphics modes without changing windows.

Keep your eyes on the prize. Openesque is in the "computer business." If you're reading this, you may be in the computer business. However, most people are not in the computer business. They don't like computers, because they're complicated to use, and the source of a lot of frustration to them.

Simplify your systems and you'll make your customers happier. They'll be better off with a few tools that everyone can use than with dozens of whiz-bang, complex tools that are designed specifically for a particular application, but are difficult to learn and remember how to use. They have better things to do than blunder around a dozen applications and having co-workers scratch their heads along with you trying to figure out how to get an arcane tool to do a simple task.

Simpler tools are, generally speaking, better tools. You can get the job done now with them. Which is faster: a tool that will get the job done in four hours, or a tool that will get the job done in one hour… after spending four hours learning (or re-learning) how to use it? And, the fewer tools you have, the fewer tools you have to break. Of course, if you are doing something frequently, the investment in both the purchase price and learning curve of a specialized tool may well be worth it. But, often times, this isn't the case.

Even as a hardcore Unix user, I live by this rule. There are many userland tools that I have never used; there are others that I have learned, then forgotten, and never touched again, even though they're perfectly fine for what they're designed for. Why? Because the time I would invest in learning (or re-learning them via the manpage) would not be recouped with the time saved using the specialized tool. If I have a task that becomes repetitive enough to annoy me, then it's time to Google for a more elegant solution to the problem.

I can drive from Michigan to California faster in my car than I can fly an F-15 there… because I know how to drive a car.

An open mind is a strong mind

While I'm not expecting any dramatic changes, these opinions are subject to change without notice as the technology gets better, and as our experience continues to grow.

What will never change is our commitment to doing the job at hand simply and effectively.

Ronald J. Oliver, Manager
Openesque LLC
January 25, 2009 (original September 4, 2004)