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 ) Sep. 30: Ohio LinuxFest. Greater Columbus Convention Center (pre- registration required at ) 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 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 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 . As before, a number of WPLUGers will be in attendance--send e-mail to 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 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.