[wplug-announce] The Open Pitt, Issue 27
Vance Kochenderfer
vkochend at nyx.net
Thu Aug 31 22:41:10 EDT 2006
PDF version: <http://www.wplug.org/top/wplug-top027.pdf>
THE OPEN PITT
What's cooking in Linux and Open Source in Western Pennsylvania
===========================================================================
Issue 27 August 2006 www.wplug.org
===========================================================================
In this issue:
Breathing New Life into Old Projects
Important Meetings Ahead
From the Editors: The 64-Bit Question
Upcoming Conferences
---------------------------------------------------------------------------
Coming Events
Sep. 16: General User Meeting/Nomination Meeting, Topic: GNOME. 12:30pm to
4:30pm, Carnegie Library of Pittsburgh--Squirrel Hill
Sep. 23: Pittsburgh Perl Workshop hosted by the Pittsburgh Perl Mongers.
University Center, CMU (pre-registration required at
<http://pghpw.org/>)
Sep. 30: Ohio LinuxFest. Greater Columbus Convention Center (pre-
registration required at <http://www.ohiolinux.org/>)
Oct. 21: General User Meeting/Election Meeting. 12:30pm to 4:30pm,
Carnegie Library of Pittsburgh--Squirrel Hill
The public is welcome at all events
---------------------------------------------------------------------------
Breathing New Life into Old Projects
by Patrick Wagstrom
You've just found the perfect piece of Open Source software. Yes, this is
the program that's going to scratch the itch that you've had for months.
In fact, it seems like it's the only project that fills the little niche
need you have. After downloading, compiling, and installing the software,
you find that it doesn't quite do everything you hoped it would. In
general it works well, but there are just a few extras you'd like to see.
The normal process is to contact the developers and make a feature request,
either by e-mail or through a bug-tracking system. Be careful to do your
homework first and make sure you understand how the project handles such
requests. But what happens if the last code modification was over a year
ago and the developer hasn't shown any interest in doing further work on
the software?
Congratulations, you've found a piece of unmaintained software. The good
news is you can play a key role in reviving it. The first thing you'll
want to do is to get an idea of why the project is no longer maintained.
In some cases it's because the project has been superseded by something far
better--if so, you may want to look at the new tool. Often, however, it's
because the project was quite small and the developer just doesn't have
time anymore. It's a shame that many projects languish, but you might be
the person to help out.
There are a few questions you'll need to ask yourself before embarking on
this adventure. The first one is: "Do I really have time to work on this
project?" Maintaining an Open Source project involves a decent amount of
work, not just for coding, but also packaging, bug tracking, reading and
managing e-mail lists, and writing documentation. If you're going to take
over a project, make sure you're willing to do all of these.
The next question is: "Do I have the skills necessary to maintain this
project?" If you're not familiar with the programming language or the
underlying technology of the project, take some time to become adept in
these before offering to maintain it. Also, make sure to learn about some
of the standard tools used in Open Source, such as CVS or Subversion,
Bugzilla, and mailing list administration.
The final question to ask is: "Will I have the resources to maintain this
project?" Here, we're talking about physical resources such as server
space, a machine to compile on, tools for graphics, and the like.
Fortunately, you can find Open Source versions of most every tool you'll
need, and server resources are freely obtained from sites like
SourceForge.net and Google Code Hosting.
Now it's time to think about the social aspects of taking over a project.
You'll want to try to get the previous developer's blessing to let you
maintain the code. If you fail to ask before you just post your own
version of the software, you could very well ruffle some feathers.
It is quite possible that you may get no response from the e-mail address
in the documentation--be sure to search for the author elsewhere on the
Internet. Explain that you have an interest in maintaining the project if
it's no longer maintained and offer up a few patches to the software and
ideas for future development. This will help convince the maintainer that
you're seriously interested in it. If possible, make a web page that shows
off the new features you've added and provide a way for the original
maintainer to test it. Your goal is to convince the maintainer that you're
dedicated to the project and will be a good steward. With any luck, he'll
be swayed by your work and proceed to cooperate with you on the transition.
However, there are times where the original author cannot be found or does
not reply to your messages. In these cases, Open Source licenses permit
you to branch and fork the software and redistribute your modifications.
Start off by setting up a small site on a server you have control over to
showcase your modifications. For my purposes, I usually use Trac, an Open
Source project management tool. This lets me continue to develop my own
branch of the code while awaiting final word from the maintainer. It's
important to make it clear to visitors that you're not the official
maintainer of the software and hope to one day merge your changes back in.
It is generally bad form to just take a piece of software and repost it at
SourceForge unless you are the official maintainer, so start small. If
over time it becomes apparent that the original author is no longer working
on the project and you've developed a following of new users, consider
changing the name of the project and making an official announcement about
turning your branch into an independent project. This avoids confusion and
helps prevent bad blood in the Open Source community.
Of course, every project is different. Some may be parts of larger
foundations, such as Apache or GNOME. This will involve a little extra
work in creating accounts on the servers and transferring maintainer
rights, but generally is a pretty painless process. Remember that the
people you're dealing with are probably also very busy, so patience is the
name of the game.
With any luck, these hints and guidelines will make you the happy
maintainer of that abandoned niche application you can't live without.
Patrick Wagstrom is a Ph.D. candidate at Carnegie Mellon University
researching communication and collaboration in Open Source development. He
has been using Linux since 1994.
---------------------------------------------------------------------------
Important Meetings Ahead
Two critically important WPLUG meetings are coming up in the next months.
Nominations will take place on *Saturday, September 16*. As things
currently stand, according to the bylaws there will be seven seats on the
Board of Directors to fill. Members should start thinking about who they
would like to nominate (it's perfectly acceptable to nominate yourself;
it's known as "volunteering").
The following month, elections will be held during the annual meeting on
*Saturday, October 21*.
Both of these meetings will be held at the Squirrel Hill branch of the
Carnegie Library of Pittsburgh on the corner of Forbes and Murray Avenues.
There is metered parking in the attached garage and both metered and free
parking on the surrounding streets.
It is vitally important that enough members attend these meetings so that
we can validly conduct business. Don't be the person who throws a monkey
wrench into the works by staying home. If you can only attend two WPLUG
meetings this year, make it these two.
---------------------------------------------------------------------------
From the Editors: The 64-Bit Question
There's been some buzz lately about comments made by Eric Raymond at the
recent LinuxWorld Conference and Expo in San Francisco. On-line articles
have tended to focus on (and often misinterpret--see the interview at
<http://www.redherring.com/Article.aspx?a=18176> for his fuller
explanation) Raymond's discussion of proprietary drivers.
While the proprietary vs. Free Software debate may have greater
entertainment value, less attention is being paid to his thesis that the
move from 32-bit processors to 64-bit chips represents a unique opportunity
for Linux to gain market share.
Two similar shifts have occurred in the past twenty years; the change from
8-bit to 16-bit PCs was accompanied by the rise of MS-DOS, and Microsoft
Windows took hold during the transition from 16-bit to 32-bit processors.
Raymond says that he and Rob Landley will soon release a paper detailing
their analysis of the situation which predicts that the next dominant
operating system will be fully established sometime in 2008.
As Intel and AMD 64-bit chips begin selling into the mass market, there
appear to be three potential contenders for that crown: Windows Vista,
Linux, and Mac OS X. Raymond thinks that Linux must be friendlier to
non-technical users to come out on top, and it looks like he may soon be
working with Linspire to do just that.
---------------------------------------------------------------------------
Upcoming Conferences
The Pittsburgh Perl Workshop will take place at the University Center on
the Carnegie Mellon University campus on Saturday, September 23. Early-
bird registration may still be open when you read this at $20; otherwise,
the cost is $40 (admission for students is half price). See
<http://pghpw.org/> for details.
The Ohio LinuxFest, to be held Saturday, September 30 at the Greater
Columbus Convention Center, is one of the Midwest's premier events for
Linux and Open Source. Registration is free and is open until Sept. 22.
Learn more and sign up at <http://www.ohiolinux.org/>. As before, a number
of WPLUGers will be in attendance--send e-mail to <pwagstro at andrew.cmu.edu>
to get on the local mailing list for discussion of ride- and room-sharing.
===========================================================================
The Open Pitt is published by the Western Pennsylvania Linux Users Group
<http://www.wplug.org/top/>
Editors: Elwin Green, Vance Kochenderfer
Copyright 2006 Western Pennsylvania Linux Users Group. Any article in
this newsletter may be reprinted elsewhere in any medium, provided it is
not changed and attribution is given to the author and WPLUG.
More information about the wplug-announce
mailing list