[H-GEN] [Fwd: Managing Open-Source (From Business 2.0)]

[Arjen Lentz]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]


 From http://www.business2.com/articles/web/0,,47035,00.html

Managing Open-Source
You can use cool tools, but keep those business needs first and foremost.
By Jimmy Guterman, February 07, 2003


Most of you have better things to do than read Microsoft's (MSFT) SEC 
filings. So allow me to share this juicy run-on sentence from the 
Redmond giant's most recent 10-Q statement: "To the extent the 
open-source model gains increasing market acceptance, sales of the 
company's products may decline, the company may have to reduce the 
prices it charges for its products, and revenues and operating margins 
may consequently decline." In other words, open-source software 
development, in which a program's underlying code is free for all to 
inspect and alter, is enjoying so much success in corporate America that 
even Microsoft has to take notice.

Some refer to open-source software as "free" software, which isn't quite 
true. Sure, the basic software can be downloaded gratis from the Net, 
but there are substantial programming and training costs associated with 
large open-source projects. Still, many executives feel that open-source 
software gives them more flexibility and control -- and large companies 
like IBM (IBM) are betting heavily on the security and stability of 
popular open-source platforms like Linux.

Companies are undertaking large-scale open-source projects like never 
before, and there are management challenges unique to the open-source 
development process. I've seen several of these up-close, including a 
yearlong implementation of a Python-based content management system at a 
large regional website, and I've talked in recent weeks with nine 
managers who have shepherded successful open-source deployments. If 
you're overseeing such a project, here's what these managers say you 
need to know:

     * Make sure your business case is as airtight as your technology case.

       Some open-source projects fail because the tech staff is more 
focused on using cool new tools than in solving concrete business 
problems. Be able to detail in a sentence or two what the end result 
will be and why the open-source approach is right for this particular 
project.

     * Don't let functionality requirements turn into religious arguments.

       Just as some technologists advocate an open-source approach 
merely because it doesn't involve Microsoft, there are programmers and 
engineers who feel that one particular open-source tool solves all 
problems. Chances are the person at the next desk uses a competing 
open-source system as a software Swiss Army Knife. You want to let your 
tech staff use cool new tools because it motivates them and adds to 
in-house knowledge, but, again, the challenge is to keep those employees 
focused first and foremost on identifying technologies that solve 
business problems. And if it's the next guy's favorite program that does 
what needs to be done, so be it.

     * Document, document, document.

       And then document some more, both in your code and in manuals. I 
have been shocked by the low quality of documentation in some of the 
most popular open-source programs. Some of them are written by experts 
for experts, so no one with less knowledge than the writer can get 
anything out of them. Some of them are simply unprofessional, not even 
proofread before being uploaded. And since so much open-source coding is 
done by people working for free, some programs don't ever get 
documented. Technology staffs experience great turnover: Complete 
documentation means that your company's ability to run a system doesn't 
end when a developer walks out the door.

     * The community wants to help.

       Someone out there knows more about the program than you do. Even 
if your top developer does exit swiftly before documenting this system, 
the major open-source platforms -- Apache, MySQL, Perl, PHP -- all boast 
large, active communities of experts who are eager to help, either for 
free (answering a brief question posted online) or for a fee (if your 
system needs a lot of help quickly). Someone on your tech staff may be 
part of that community or can act as a liaison to it.

     * Accept that open-source development never ends completely.

       Iterative development is the key: Roll out features on a regular, 
agreed-upon schedule, and solve existing problems while working on new 
features. Each group of people who use a new program -- from QA testers 
to end users -- will discover, over time, new sets of issues that need 
to be addressed. Unlike some proprietary systems, which tend to provide 
patches only to fix major bugs and don't deal with non-acute problems 
until the next release, open-source developers are legendary for what 
might be termed "iterative repair." Continuing to devote staff time to 
this cause means that the programs will be that much more secure, 
reliable, and useful to the organization. If you commit to open-source, 
my colleagues tell me, you commit for good.

---end of forwarded msg---


-- 
Purchase Training, Support, Licenses @ https://order.mysql.com/?marl
Brisbane  24-28 Feb 2003: MySQL/PHP, see www.mysql.com/training
Melbourne 24-28 Mar 2003: Using & Managing MySQL
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Mr. Arjen G. Lentz <arjen at mysql.com>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Technical Writer, Trainer
/_/  /_/\_, /___/\___\_\___/   Brisbane, QLD Australia
       <___/   www.mysql.com

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/