Ones and Zeros

It’s curious.  In a world becoming more and more open-source and using more and more open-source software (OSS) Apple is thriving being proprietary.  They are using OSS in some areas, and are participating in open source projects as well.  WebKit in their Safari browser is one major example.  Yet much of their core system software is and will remain proprietary.

Certainly they’re successful.  Measured in name recognition, units sold, $20 billion plus of cash in the bank, or stock price they’re clearly a major force.  (I wish I still had my stock grant from my employee days!)

The argument in open source circles is that a proprietary effort like Apple’s will always fail in the long run when compared to open source.  IBM became a major driver of Linux, Microsoft has felt the pinch more and more, and even the federal government and DoD are proponents of Linux and open source software.  How is Apple not merely surviving, but thriving being proprietary?

I think it’s two fold.  First, while Apple is using open source software, they’re just using it where it’s not a key part of their company’s added value.  Second, they are using their proprietary software in an integrated ecosystem of software systems that all work together.  This provides a “user experience” that enough customers value over Apple’s competitors.

By leveraging open-source software (OSS) in non-key areas Apple frees up engineers and effort on their key proprietary areas.  This is a no-brainer.  Yet many companies fail to do this.  Apple’s using Mach UNIX as their base OS on the Mac, iPhone, and iPad avoiding rewriting the OS.  They spend their efforts writing more complex layers on top of the OS to provide a richer computing environment.  Better graphics, animation in the UI, richer audio, apps like iPhoto, Aperture, the iWork suite are all enabled by this as a random grab-bag of items.  By comparison Microsoft writes everything - they’re working twice as hard and getting rather less the same result.  Their last several releases have suffered by many measures.  Apple focuses only on writing the software that’s key to their system.

But Apple embraces the proprietary and customers (despite the grumbling about DRM) embrace the Apple products.  MP3 players existed before Apple, but the iPod massively expanded that market to the point where it is dominated by Apple.  Smart phones and smart phone apps existed before the iPhone,  but Apple’s remade that market as well.  Through these innovations they’ve fostered the development of things like podcasting, and created a whole new developer market for iPhone apps.

I believe they key to their success in proprietary software is that they’re creating a very well integrated software ecosystem.  Having an iPod is richer with iTunes, they enhance each other.  You get used to this, then find the iPhone works very well with iTunes too. It’s a natural upgrade path.  The lack of the involved setup and configuration necessary with many Windows software systems helps tremedously.  the Mac systems just feel right, things fit well.  The Windows seems clunky, a moved window isn’t refreshed smoothly - it’s the little things that make a system feel like it is working well.

It’s an ignored truism in software that customers just want to get something useful done.  It’s geeks like me that want to spend their time messing with software.  Yet even I want to focus on the things I want to play with - not the boring configuration & setup stuff on the way.  The Mac/iPhone software ecosystem allows me to do that.

This singular focus on how things feel and work smoothly comes, I believe, from Steve Jobs.  Certainly Apple is much larger that Jobs and all employees are important to Apple’s overall success.  But the leader stamps a personality on the company.  Jobs is famously driven a high standard of usability.  His equally famous control on information and access allows Apple to work on something till they’re happy with it and not be bound by a schedule to they are ready to release.

That’s a key point.  In engineering it’s said that there are three things: schedule, quality, and features.  You can control two, but the third must flex.  If Apple drives quality and features, then schedule must be flexible.  Their control on public information allows that.

So a way for companies to compete against OSS is to use their proprietary work to provide a smoothly integrated environment, a software ecosystem.  OSS efforts have a hard time with this since the level of coordination and interaction required is high.   Most OSS efforts (barring Linux itself perhaps) are smaller and more loose.  The weak point of current OSS projects is their democracy and openness.

(Note: I’m a proponent of OSS and have contributed to OSS projects.  I used OSS daily in my work. But I find it interesting that Apple’s been contrarian and successful in their proprietary efforts.  That probably isn’t a universal solution for companies facing OSS competition though.  Most companies can’t maintain the high standards of quality necessary the Apple solution.)

I spend my working days analyzing, designing, writing, and testing software.  But I’m not a software programmer, I’m an engineer.  Just like a writer isn’t a typist, I’m not a programmer.  A writer’s job is to communicate effectively, not to type.  But typing on a keyboard is what a writer does when working. Programming is a tool I use in my job to create software, but the goal is to make the software to fit a given need.

Just don’t call me a programmer, my title is software engineer.  Just wanted to get that straight.

Most software people consider themselves either developers or perhaps programmers. I try to be an engineer. Some basic engineering principles are:

1. Each project should have a set of defined goals as it’s purpose. Ultimately, the success of the project is tied to how well it matches these goals.
2. Software should be replicatible and trackable. Source code control systems allow tracking of changes and regeneration of older versions.
3. Testing should be able to match the project’s features with the project’s goals or requirements.
4. A project should not use any more computing time and space resources than necessary to achieve those goals.
5. Projects should be documented at a architectural level and at a detailed level so that future software engineers will be able to takeover the project.

Practical realities of time, budget, and managerial pressures pull us away from on or more of these principles. I don’t live in a dream-world of engineering.  I’m in the same real world everyone else is with funding issues, project changes in midstream, and schedule overruns. But that shouldn’t keep us from remembering what the process is actually supposed to be and to work toward that process.

Neophila: The trait of being excited and pleased by novelty. Common among most hackers, SF fans, and members of several other connected leading-edge subcultures, including the pro-technology ‘Whole Earth’ wing of the ecology movement, space activists, many members of Mensa, and the Discordian/neo-pagangeek). All these groups overlap heavily and (where evidence is available) seem to share characteristic hacker tropisms for science fiction, music. The opposite tendency is neophobia.

- New Harper’s Dictionary (via Wikipedia)

Yup, I’m a neophile. But I’m also seasoned enough to know that the new - while exciting and intellectually interesting - isn’t always better. The question is to use the right tool for the job at hand. That may be the newest thing, but it may be the old and familiar too. This requires some assessment of quality of the tool for the task. Unfortunately this is a step often skipped in the software world.

For software engineering to become a real profession, we need to recognize the following:

[Engineering is] The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to use economically the materials and forces of nature for the benefit of mankind.

- Wikidictionary on Engineering

Software engineering can’t just be using the coolest and newest things. Instead it is building software that satisfies goals in a measurable way, uses scientific and mathematic principles, and economically and efficiently uses those principles to benefit us as software users. Using the right tools at the right times is a key step in moving from software developers to software engineers.

As software geeks, we can experiment and test the new tools. That’s fine. But we need to draw a clear line between experimentation and research vs deliverable production software. Not all software is - or should be - production grade software. But for production software, an engineering approach is key. The software techniques and tools used need to be subservient to the goals of the project. It’s hard to remember that in the heat of writing code.