MESSAGE
| DATE | 2003-04-08 |
| FROM | From: "Inker, Evan"
|
| SUBJECT | Subject: [hangout] In the Linux Loop - Computerworld Article
|
http://www.computerworld.com/softwaretopics/os/story/0,10801,80053,00.html
In the Linux Loop
By Minda Zetlin
APRIL 07, 2003
Using open-source software like Linux is a no-brainer for many companies.
It's stable and can be fixed easily if bugs appear, and you can't beat the
price. But some companies and government organizations are taking their
commitment to open source a step further by actively participating in the
open-source community.
The Linux operating system is only one example of the many pieces of
open-source software currently in circulation. In each case, the software's
license allows it to be freely copied and distributed by anyone, the source
code is available along with a working version of the software, and anyone
can modify or expand on the code. Most open-source software can be
downloaded free from the Internet and is maintained and expanded by a
community of developers who donate their patches and modifications.
These days, some corporate and government entities are getting into the act
as well. When their developers write patches, modifications or new
implementations of open-source software for in-house use, these
organizations are releasing that new code back to the open-source community,
thereby assisting in the software's ongoing development.
What's the payoff? It makes for better software. "If we find a bug or a
problem, we're interested in fixing that problem. We're also interested in
not fixing it again in the next version," explains Robert M. Lefkowitz,
director of open-source strategy at Merrill Lynch & Co. in New York.
"If you download open-source software, then take it in-house and don't share
your revised code, you wind up maintaining your own separate fork of the
software for all time," says Eric Raymond, president of the Open Source
Initiative (www.opensource.org), a Web-based nonprofit group that helps
define and promote the open-source concept. "On the other hand, by
participating in open-source projects, you make sure your corporate needs
have a seat at the table when large-scale design decisions are being made."
This is why Merrill Lynch sent the fixes it made to open-source software
during one of its projects back to the open-source community. "The way a
typical open-source project works is that there is a core team in the
community with direct access to modifying the code on its central Web site,"
Lefkowitz says. "People who want to contribute to that community submit
their code, which is looked at by a core team and integrated if found
appropriate."
Creative Archiving
Sharing can be especially helpful if your software needs are different from
those of most organizations, notes Jim Willis, director of eGovernment at
the Rhode Island Department of State.
His office used open-source software to design a repository for the vast
library of content, which ranges from rules and regulations to the minutes
of municipal meetings, that the State Department must keep on hand and make
available to the general public. A colleague from the state of Hawaii heard
about Willis' work and e-mailed to ask his advice about a similar project.
That got Willis thinking that states could help one another by sharing the
open-source software they had modified for special state uses. "We're now
trying to set up [an online] repository of which state agencies are using
open source and for what projects," he says.
Although the details have yet to be ironed out, Willis plans for the states'
open-source repository to be available to everyone, so the rest of the
open-source community can benefit -- and contribute. The plan is for Rhode
Island and Hawaii to jointly create and maintain a Web site that will
archive the documentation of the work each state has done on its open-source
software. The hope is that in the future other states will also document
their work.
"Documenting our practices with the intent to share them with others has
threefold benefits," Willis notes. "We learn from the experience of other
states, we share development resources with other states, and we have better
internal documentation of our own practices. All this for the effort of
articulating our practices and documenting our internally developed software
such that it makes sense to others."
Best Practices
For companies that decide to join in the open-source community, there's a
right way and a wrong way to go about it. Raymond advises that corporate
contributions to any open-source directory should come from individual
developers, rather than generically from the corporation. "In general,
people in the open-source community don't want to deal with corporate
entities. They want to deal with specific people whom they can reach by
e-mail. So you need to allow in-house developers to grow individual
reputations," he says.
Willis also advises against jumping in too soon. "Most developers aren't
ready to start giving back the day they start using a piece of open-source
software," he notes. "It takes a while to get to know the software well
enough to make a contribution." How long this takes varies from developer to
developer, he says. But he recommends waiting until you're quite comfortable
with the software before contributing.
Lefkowitz says source code is only one of several types of donation your
company or its developers can make. "A lot of open-source communities say
they have all the coders they need," he says. "But they need documentation.
They need that documentation translated into languages other than English,
and they need graphic artists to design and contribute icons."
For all contributions, Lefkowitz emphasizes the importance of creating a
corporate policy with help from the departments that could be affected by
open-source involvement. At Merrill Lynch, an eight-member Open Source
Review Board determines when contributing is appropriate. "We have
representatives from security, legal, network, architecture, infrastructure
support and purchasing," he says. "We work through the questions of where we
want to have engagements and where we have concerns."
Having a policy in place is especially important for controlling when and
how source code is released, which can have legal ramifications in terms of
liability and licensing, says Tony Stanco, an attorney and associate
director for Open Source and eGovernment at the Cyber Security Policy and
Research Institute at George Washington University in Washington. For
example, one large company created a separate foundation for releasing code
for liability reasons. The rules for releasing code vary for different types
of open-source software because they are governed by many different types of
licenses. But even without a policy, there's a good chance that your
company's programmers will share their open-source work - and it might not
even occur to them to ask for permission.
"A lot of it goes on under the radar," Stanco says. "Developers spend a lot
of time working on something, and it requires them to do modifications.
Because they know it's open-source software, they'll put it out to the
community as a matter of course." But, he adds, "that's why we have such
great open-source software."
Zetlin is a business technology writer in Woodstock, N.Y., and author of
Telecommuting for Dummies (Wiley, 2001).
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
____________________________
NYLXS: New Yorker Free Software Users Scene
Fair Use -
because it's either fair use or useless....
NYLXS is a trademark of NYLXS, Inc
|
|
