Linux and Corporate Development - A Challenge to the Linux Community

Aug 25, 1999, 22:01 (22 Talkback[s])
(Other stories by Bill Meahan)

[ The opinions expressed by authors on Linux Today are their own. They speak only for themselves and not for Linux Today. ]

Contributed by Linux Today reader Bill Meahan.

Note: The bulk of what follows is from a talkback I posted to an earlier article here on Linux Today. Having thought about it some more, the topic probably needs wider circulation. Hence this article.

Do you know the difference between a "Corporate developer" and a "commercial developer?" No this isn't part of a riddle or bad joke. It's a distinction that has great importance to the acceptance of Linux in the corporate world.

This acceptance is about much more than whether or not Linux has a good spreadsheet or whether one can do word processing, desktop publishing or image manipulation. Having such "office productivity" applications is certainly a prerequisite to full-blown acceptance of Linux (at least on the desktop) but it is insufficient in and of itself! The biggest value of that graphical shell from Redmond (at least in larger corporations, not "Carol's Typing and Resume Service") is the ability to easily develop and deploy applications which support the corporate business practices. These applications are not "products" in and of themselves (that is, not the ultimate thing the corporation delivers to its customer base) but serve the Corporations's own internal business needs. According to several surveys, there are far more "Corporate" developers than there are "commercial" developers. At least outside of Redmond or Silicon Valley :-)

This difference between "Corporate" and "commercial" is crucial because it impacts many of the recurring debates within the Linux community:

1. Whether or not "Corporate" applications themselves are "Free/GPL/Open Source" is a moot point. These applications will rarely, if ever, be distributed or sold outside the walls of the corporation for which they were developed. Generally, they are far too specialized or far too intertwined with a corporation's own "unique" business practices and procedures to be useful for anyone else. Even if they might be useful elsewhere, they are likely to embody a particular corporation's "competitive advantage" and there's no way a corporation is going to help its competitors by giving away its advantages. (Note: it is the business practice that is the advantage, not the software.) Besides, within most corporations, any application developed in house is already free ("free speech" or "free beer" - take your choice) to other entities within that corporation, regardless of the development tools or deployment platform used.
2. In the "Corporate" world, speed of delivery is almost always more important than program efficiency. Implementing a better business practice (supported by technology) sooner rather than later almost always saves more money than any supposed lack of "efficiency" within the application itself will cost, special applications controlling the speed of an assembly line notwithstanding. Or in other words there is truly a "cost" to deferred delivery with the cost rising as the time to delivery increases. Hence the widespread use of RAD tools and things like Delphi or Visual Basic, regardless of how unappealing they might be to "commercial" developers.
3. Technology is usually cheaper than people. When you have to hire folks to develop your "Corporate" applications (as opposed to relying on programmers driven solely by passion, interest or ideology) you are going to pay handsomely for them, and few corporations are willing to wait until a passionate, interested ideologue shows up to develop its "Corporate" apps. Current agency bill rates in the Metro Detroit area, where I live and work, average somewhere around $50-60/hour with specialist bill rates often double or triple that amount. Thus, "throwing hardware" at a problem is usally cheaper (overall) than paying a specialist to tweak and twiddle an application until it's highly efficient. Remember the "speed of delivery" cost? And aside from the cost of developers, the new application might allow the corporation to downsize or to avoid hiring new employees or to re-deploy existing people to more cost-effective pursuits.
4. "Good enough" really is good enough. Hence a choice of development tools is driven more by familiarity, installed base and availability of programming talent than by considerations of pure technical merit. This may sound strange to those for whom "performance" is the Holy Grail of computing but that is the reality of corporate life. In the light of the above, what does switching from "good enough" to the (technically) "best" buy me, especially if I have to spend beaucoup bucks hiring other developers or retraining my development staff?

Like it or not, for Linux to be fully successful in the "Corporate" world, it will have to support the Delphi's, Visual Basics and Powerbuilders (or their exact equivalents) since these are the tools of "Corporate" development. Even if they do offend the ideological or those with an overdeveloped worship of pure technical merit. And Linux will have to deliver real value (in terms of supporting the business), not just a low (or non-existent) price.

Now, "commercial" development of general-use applications, like the 4,234,526th text editor this month or the 1,256,623rd ICQ client this week, is a whole different story. For that, debate on, O Linux community!

---

For the curious (or enraged), I am a software development supervisor for a large Fortune 2 (no, I didn't forget any zeroes) company where I've done a lot of specialized programming and development (from high-speed machinery control to help-desk tracking systems) for most of the 27+ years I've worked there. I started programming in 1965 and I've seen a lot of stuff come and go in the computer world so I seldom get passionate about computer-related topics any more. Though new to Linux, I've been around Unix since Bell Labs Version 7 and on the Net since about 1979. Had an AT&T "Unix PC" (aka "3B1") at home for several years and taught my daughters to use GNU Emacs and TeX to do their high-school papers. (Boy, were they pissed to be forced to use WP 4.2 for DOS in college :-) )

I love Free software and snuck Perl 3.0.44 (old numbering system) into the company long before the Web caused it to become a "strategic" platform. And I'll never admit to being the guy who built an entire test-stand calibration system in Perl using gnuplot and TeX for reporting or ran a C-News UUCP node for several years. Nope, not me. So please, send all flames about being a "newbie" or "not getting Linux" to /dev/null. That's where procmail on my home Linux system will send them anyway.