|
http://www.spinellis.gr/pubs/jrnl/2005-IEEESW-TotT/html/v23n5.html This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:
|
Tools of the Trade
Open Source and Professional Advancement
Doing really first-class work, and knowing it, is as good
as wine, women (or men) and song put together.
— Richard Hamming
Diomidis Spinellis
I recently participated in an online discussion regarding the advantages of the various certification programs. Some voiced skepticism regarding how well one can judge a person’s knowledge through answers to narrowly framed multiple choice questions. My personal view is that the way a certification’s skills are examined is artificial to the point of uselessness. In practice I often find solutions to problems by looking for answers on the web. Knowing where and how to search for an answer is becoming the most crucial problem-solving skill, yet typical certification exams still test rote learning. Other discussants suggested that certification was a way to enter into a job market where employers increasingly asked for experience in a specific technology. My reaction to that argument was that open source software development efforts offer us professionals a new and very valuable way to obtain significant experience in a wide range of areas. In this column I’ll describe how we can advance professionally by contributing to open source projects.
The most obvious way to gain as a professional from open source software is by fixing and improving existing open source code. We all know that 40–70% of the effort that goes into a software system is spent after the system’s first incarnation. Yet coursework and textbook exercises seldom ask us to maintain an existing system. On the other hand there are many (perhaps too many) open source projects with lists choke-full of exciting additions and obscure bugs eagerly waiting for us developers to get our hands on them. By joining an existing open source software project we can immediately practice the art of maintaining other people’s code and sharpen our corresponding skills. Also, once we get our hands dirty, we will see ourselves gradually adopting a code style that is more readable and maintainable.
Joining an open source project is an easy way to rub shoulders and interact with highly respected professionals. From day one we can see how their code looks like, the way they address new issues, and how they interact with other developers. Even better, as we begin to contribute code to the project these colleagues may send us feedback that will help us improve. (The first comment I got from my FreeBSD mentor when I submitted code for review was that I had left blank spaces in the ends of the lines. Up to that point I never thought that these could be an issue; from then onward I configured my editor to color them in yellow, so I could easily spot them.) I can’t guarantee you friction-free interactions with the other developers, but those heated email exchanges can help us become better team players: we’ll gradually learn to focus on the technical aspects of an argument and not take personally attacks on our code.
Through participation to open source projects we can also perfect our non-verbal communication skills. Open source projects, being globally distributed, typically rely on a multitude of collaboration tools ranging from email and instant messaging to issue management databases, wikis, and version control systems. Communicating requirements, design and implementation options, and bug descriptions through these media in a precise and technically-objective manner is an important skill in today’s global marketplace, and one we will surely sharpen through our exchanges with our fellow open source developers.
An valuable feature of the open source landscape is the breadth of available applications, implementation technologies, and project sizes. By choosing cleverly we can maximize both our professional gain and our personal joy. We can select a project to learn a new technology, or to improve our skills in an existing one. We can thus transfer our skills from, say ASP to Ajax, or cut our teeth on advanced Java programming through Eclipse’s multi-million line code base. We can also enter a new application domain, like game programming, networking, or kernel hacking. Finally, the wide diversity of open source project sizes gives us an excellent opportunity to inject variety into our professional life. If we work in a small startup we can join a large project to gain a taste of a structured development process; if our company is process-heavy joining a small project allows us to experience once again the joy of coding.
Increasingly, software systems are not monolithic blocks, but complex large heterogeneous ecosystems. In such an environment the software professional is required to be a system administrator, selecting, configuring, connecting, and tuning subsystems into a robust and efficient larger part. Again, the typical classroom or corporate development setting is often a sterile affair involving preselected, preinstalled, and preconfigured components that just work. With open source software development we can get the larger picture. We’ll get a chance to experiment with the components, tools, and our development environment, choosing and configuring a setup that works and allows us to be productive. At different times we wear the hats of a system administrator tinkering with operating system releases, a database administrator configuring a relational database, a security officer implementing our security policy and installing patches, and a network manager making the pieces of second-hand hardware junk that inevitably piles-up in the basement of any self-respecting hacker talk to each other. Any of these skills is valuable in today’s marketplace, and the cross-disciplinary mixture that we’ll acquire from our involvement in open source projects is even more so.
Consider development practices like issue tracking, version control, unit testing, style guidelines, the daily build, code reviews, release engineering, and traceability. If you work in a small development group or a startup, chances are that you (or, worse, your boss) consider some of these practices obscure and irrelevant. Yet they are anything but. Although a single talented programmer can often get away with developing software by piling code layer upon code layer, this process is not sustainable in the long run. When the software and the team that builds it grows large, failure to adopt a process that includes the practices I named borders on hubris. Joining a large open source development project will get you first hand experience with many cutting edge development practices. Thus, apart from polishing your coding skills, you’ll also become a better manager by observing how things you may have heard only in a boring software engineering lecture actually work in large projects in the real world.
Later on, you’ll hopefully also contribute. Despite the size and complexity of some large open source development efforts, most projects are still typically too light on process, so it’s relatively easy for somebody with time and ideas to make a contribution in this area. Initially, this can be simply a skunk works subproject you launch on your own: a framework for unit or regression testing, a bug finding tool, or a more efficient release mechanism. As your idea is proven on the field and you gain the respect from other developers this pet project of yours can become officially adopted.
Proponents of the concept of psychological egoism maintain we are always motivated by self-interest, even when we behave altruistically: deep down we seek the better feeling we derive from our acts. This argument has been criticized as circular and non-falsifiable. Fortunately when working on open source projects we won’t have to entangle ourselves in this logic: there’s nothing wrong with advancing professionally while helping worthwhile projects. Nobody (yet) has promised eternal life through code churning.
We already saw how participation in open source projects can make us better programmers, system administrators and managers. As contributors to open source projects we can also often gain a significant edge in interviews: (“I see you’re using Firefox as your browser. You know, I’ve implemented the hyphenation functionality in the text rendering module.”) Developers with commit privileges in certain high-profile open source projects often find themselves in a seller’s market. Demand for their skills typically outstrips the available supply and they can therefore command better employment terms. Nevertheless, in the end, the best reward we gain from our participation in open source projects is the joy of contributing to a work that can potentially affect the life of millions of people.
Diomidis Spinellis is an associate professor in the Department of Management Science and Technology at the Athens University of Economics and Business and the author of Code Quality: The Open Source Perspective (Addison-Wesley, 2006). Contact him at dds@aueb.gr.