 |
|
 |
|
| Greg DeKoenigsberg | |
|
|
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.
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.
This was first published in April 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation