Kode Vicious - @kode_vicious
PDF
KV the Loudmouth
A koder with attitude, KV answers your questions. Miss Manners he ain’t.
To buy or to build, that is the question. Of course, it’s rarely that cut and dried, so this month Kode Vicious takes time to explore this question and some of its many considerations. He also weighs in on the validity of the ongoing operating system wars. Have an equally controversial query? Put your thoughts in writing and shoot an e-mail to [email protected].
Dear KV,
I was somewhat disappointed in your response to Unclear Peer in the December/January 2006/2007 issue of ACM Queue. You answered the question, but I feel you missed an opportunity to look at the problem and perhaps expand Unclear’s professional horizons.
What requirement is being satisfied by having Unclear build a P2P file-sharing system? Based upon the answer, it may be more effective, and perhaps even more secure, to use an existing open source project or purchase commercial software to address the business need. Indeed, if the definition of P2P is loose enough, encrypted e-mail would meet your security criteria and might solve the business problem.
If Unclear is just a koding gnome, content to write kode as specified and not ask why, then I withdraw my concerns. Otherwise, it seems to me that an opportunity to teach Unclear, and your readers, was missed.
Sincerely,
Buyer not always a Builder
Dear BB,
Perhaps I’ve missed the marketing hype around this, or it has wound up in my spam box like all those ads for enlargement technology, but last I checked there wasn’t an off-the-shelf P2P system one could buy. That being said, you bring up a good, if tangential, point—and one interesting enough to prevent your letter from winding up with all those aforementioned enlargement ads.
The buy-vs.-build, or as I like to think of it, the integrate-vs.-build question touches just about every part of a product. I like to say integrate because that can take into account using open source software, as well as buying software from a commercial vendor. Although many people might like to build everything from scratch—the Not Invented Here school of software construction—that is rarely an option in most projects because there is just too much to be done and never enough time. The problems that need to be addressed are the cost of integration and the risks.
Cost in this case is not just that incurred in buying a piece of software. Free or open source software often has high costs. The number of people on a local team required to maintain and integrate new releases of a component is definitely a cost that must be accounted for. Producing documentation is also a cost. For commercial products the costs include those just listed, as well as any money required to license the software in question.
In reality, the cost could be seen as just one of the risks involved when making the decision on whether to integrate or build a component of a system. The risks of integrating a component include the likelihood that the company or project that provides that component will continue to exist, and whether the component owner will change the system in a way that doesn’t agree with your product over time. Plenty of people have been bitten by software that was changed underneath them.
It all comes down to control. If you can architect your system in such a way that the risks of integrating a component can be mitigated successfully, then integration, barring exorbitant costs, is probably a reasonable way to go. If you need absolute control over how a component works now and in the future, then you’ll have to build it yourself. There is a spectrum of choices, but those are the two poles that you must navigate between.
KV
Dear KV,
I suspect that you don’t get many letters from CFOs, but one of my people left a copy of Queue in my office the other day. I read your column and thought you might be interested in this question. Getting directly to the point, does the operating system still matter? I ask this because every time we initiate a project in my org, a small but loud group of people push me to pick an open source operating system for the project. It seems that they care more about that than about the application we’re rolling out to our staff.
Reading over the trade press, I see claims and counterclaims about various operating systems, based on security and total cost of ownership, but all these claims seem to be written by proponents of one of the systems in question. At this point, it seems like the operating system doesn’t really matter anymore, just so long as my application runs on it. What do you think? Should I just fire the loudmouths?
Tired of Zealots
Dear TZ,
You’re right, I don’t receive many letters from CFOs unless they’re printed on pink paper and include words like “...please empty your desk by...” I also rarely condone firing the loud ones, for what must, by now, be obvious reasons.
Many pundits (i.e., people paid to have opinions) now claim that the operating system is a commodity that, in itself, has little intrinsic value. I don’t get paid to have my opinion, but I claim that pundits have little intrinsic value.
Let me try to answer this question without going too deep into Operating Systems 101. The reason that the operating system matters, and will continue to matter as long as there are operating systems, is that the operating system is the ultimate arbiter between your application and the underlying computer. The operating system controls access to the CPU, memory, and all the devices. A good operating system is like good service in a restaurant: there when you need it and invisible when you don’t. A poorly designed or implemented operating system is like the waiter who constantly asks, “Is everything all right?” when your mouth is full.
Two of the most important measures of operating system quality are security and efficiency. Does the operating system you want to use have a good security track record? No operating system, or piece of software, is perfect, but there are clearly classes of problems that may affect your application and these are the ones you, or likely your staff, need to study to make an informed decision on which operating system to put under your application.
Efficiency is also important. Although there are plenty of micro-benchmarks that show that one operating system is better than another, the speed of a context switch is unlikely to impress you—though I would be impressed if you knew what it meant. For an application, the question is one of a macro-benchmark. Simply put, “How much work can people do in the application in a given unit of time?”
Another question would be around how integral the operating system is to your product. If your company builds products where the operating system is an integral component, such as a consumer device or piece of networking equipment, then the quality of the code, your ability to modify it and distribute your changes, documentation, and how long you think the company or project that supports it will last all come into play. These concerns were addressed in the previous response to the letter from Buyer not always a Builder.
So, the short answer is, “Yes, the operating system matters.” And, please, don’t just fire the loudmouths. I might be one of them.
KV
KODE VICIOUS, known to mere mortals as George V. Neville-Neil, works on networking and operating system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor’s degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who has made San Francisco his home since 1990.
Originally published in Queue vol. 5, no. 4—
Comment on this article in the ACM Digital Library
More related articles:
Amanda Casari, Julia Ferraioli, Juniper Lovato - Beyond the Repository
Much of the existing research about open source elects to study software repositories instead of ecosystems. An open source repository most often refers to the artifacts recorded in a version control system and occasionally includes interactions around the repository itself. An open source ecosystem refers to a collection of repositories, the community, their interactions, incentives, behavioral norms, and culture. The decentralized nature of open source makes holistic analysis of the ecosystem an arduous task, with communities and identities intersecting in organic and evolving ways. Despite these complexities, the increased scrutiny on software security and supply chains makes it of the utmost importance to take an ecosystem-based approach when performing research about open source.
Guenever Aldrich, Danny Tsang, Jason McKenney - Three-part Harmony for Program Managers Who Just Don't Get It, Yet
This article examines three tools in the system acquisitions toolbox that can work to expedite development and procurement while mitigating programmatic risk: OSS, open standards, and the Agile/Scrum software development processes are all powerful additions to the DoD acquisition program management toolbox.
Jessie Frazelle - Open-source Firmware
Open-source firmware can help bring computing to a more secure place by making the actions of firmware more visible and less likely to do harm. This article’s goal is to make readers feel empowered to demand more from vendors who can help drive this change.
Marshall Kirk McKusick, George V. Neville-Neil - Thread Scheduling in FreeBSD 5.2
A busy system makes thousands of scheduling decisions per second, so the speed with which scheduling decisions are made is critical to the performance of the system as a whole. This article - excerpted from the forthcoming book, “The Design and Implementation of the FreeBSD Operating System“ - uses the example of the open source FreeBSD system to help us understand thread scheduling. The original FreeBSD scheduler was designed in the 1980s for large uniprocessor systems. Although it continues to work well in that environment today, the new ULE scheduler was designed specifically to optimize multiprocessor and multithread environments. This article first studies the original FreeBSD scheduler, then describes the new ULE scheduler.
© ACM, Inc. All Rights Reserved.