When Red Hat Linux senior community architect Greg DeKoenigsberg and others sat down to write the chapters of Practical Open Source Software Exploration: How to be Productively Lost, the Open Source Way, they had in mind the rookie user of open source software and also a practical way to teach how to develop open source software in the classroom (it isn't exactly a widely approached subject at many universities). The textbook covers everything a novice student of open source software development would need, from getting and building code to fixing and documenting it after project completion.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
I asked DeKoenigsberg, the primary author, some questions about the book and advice he offers for those beginning a journey into open source software development.
In regard to the release of this book, you essentially chose to follow Linux's business model by stripping the "business" from the equation. You released the book under a license that allows for an open source community of reading and updating. Could you explain this license a bit more and why you decided to go this route?
Our goal is not to sell a textbook. Our goal is to drive adoption of open source development methodologies in universities. Numerous professors have asked for a textbook, so we produced a textbook -- but we also recognize that any textbook we produced would likely be inadequate for a classroom experience. We created just enough content to get professors started, with the hope that they will improve the text as they go.
Have you received any recent updates to the book from the free and open software (FOSS) community?
We have received feedback, yes -- we will incorporate much of it into an upcoming release.
In your foreword, you mention that open source software participation in the classroom is a rare event because educators are put off by the steep learning curve. Do you think more books like this will get teachers to re-examine their stance on open source software? Where do you see its role in the classroom in the future?
The mere existence of a textbook doesn't gain us much. The textbook is necessary, but not sufficient, to drive this kind of change. Mostly, what needs to happen is that professors need to have positive experiences with open source, and believe that participating in open source can help them and their students to achieve their goals -- which is why we sponsor the Professors' Open Source Summer Experience as well.
Could you explain why you chose Subversion as the Source Control Management Tool (SCM) of focus in this book? Is it the easiest to work with for novice projects? Why not Concurrent Version System, for instance?
Subversion is the most commonly used SCM, and the tools and tutorials for moving from Subversion to distributed SCMs like Git and Mercurial are better developed. It seemed like most flexible choice.
When a software developer has too many bugs and too little time, a situation that you allude to, he or she can use a bug tracker to do the work of sorting through the more important bugs to fix. Are the less important ones, though, still not bugs, and how would a rookie open source software user determine whether or not down the line that these could still be problematic?
All bugs are problematic to someone, of course; no one would bother to report them if they weren't. Still, developer time is a finite resource, and triaging bugs is absolutely necessary. More people triaging bugs means more people looking closely at the code -- which, ultimately, will lead to more developers. Sure, a rookie triager may make mistakes, but mistakes are how we learn. Better to have triagers trying to help your project and making occasional mistakes -- and they will -- than having no one trying to help at all.
Out of all of the aspects of open source coding that you mention, including building and debugging, which one would you say, out of personal experience, is the hardest to master for a novice?
Building software is by far the most painful experience for most novices, because every project builds in a subtly different way. There are some general principles, but creating a software project that builds cleanly is non-trivial -- and if the developer has trouble creating a build environment that is easily replicable, the typical user will also have a hard time, and usually a much harder time.
What's the single best piece of advice you have for a student who wants to learn more about open source software but may be hindered by great limitations in either skill set or what his or her curriculum is covering?
Start with a real life problem, and a reason to solve it.
This Q&A is based on textbook release 0.8 of "Practical Open Source Software Exploration: How to be Productively Lost, the Open Source Way," the most recent update of which is March 26, 2010. All chapters are available under Creative Commons BY-SA-3.0 and are copyrighted by their respective owners.