Open Advice/From Beginner to Professional

From Beginner to Professional

by Jonathan Riddell

in: Open Advice

This text is available under the CC-BY-SA license. (see also: Open Advice/Info)

Contents 1 about the author 2 notes

There was a bug in the code. A nasty one too: a crash without saving data. That is the problem with looking at code, you find things to fix. It is easy to get involved in Free Software; the difficult part is getting out again. After the first bug fix there are more and more, all within reach. Bug fixes lead to adding features, which leads to project maintenance, which leads to running community.

It started with reading Slashdot, that mass of poorly filtered tech and geek news with comments from anyone who can reload fast enough to get at the top. Every news story was interesting and exciting, a fresh insight into the tech world I was becoming fascinated with. No more did I have to accept what was given to me by large software companies, here in the Free Software community I could see the code develop in front of me.

As a university student it was possible to complete the exercises given by lecturers very quickly, but exercises are not finished programs. I wanted to know how to apply the simple skills they had given me to the real world by writing programs which solve real problems for people. So I looked for the code, which was not hard to find, just lying around on the Internet in fact. Looking closer at the code for the programs I was running I saw beauty. Not because the code was perfectly tidy or well-structured, but because I could understand it with the concepts I had already learned. Those classes, methods and variables fell into place, enabling me to solve the relevant problems. Free Software is the best way to make that step from knowing how to finish exercises in a class to understanding how real programs get written.

Every computing student should work on Free Software for their dissertation. Otherwise you get to spend six months to a year on a project only for it to sit in the basement of a library never to be visited again. Only Free Software makes it possible to excel by doing what comes naturally: wanting to learn how to solve interesting problems. By the end of my project NASA programmers were using my UML diagramming tool and it won awards with lavish receptions. With Free Software you can solve real problems for real users.

The developer community is full of amazing people, with the passion and dedication to work without any more reward than a successful computer program. The user community is also awesome. It is satisfying to know you have helped someone solve a problem, and I appreciate the thank you emails I receive.

Having written useful software, it needs to be made available to the masses. Source code is not going to work for most people, it needs to be packaged up. Before I was involved in it I looked down on packaging as a lazy way to contribute to Free Software. You get to take much of the credit without having to code anything. This is somewhat unfair, much of the community management needed to run any Free Software project can also be seen as taking the credit without doing the code.

Users depend on packagers a lot. It needs to be both fast, to keep those who want the latest and greatest, and it needs to be reliable, for those who want stability (which is everyone). The tricky part is that it involves working with other people’s software, and other people’s software is always broken. Once software is out in the wild problems start to emerge that were not visible on the author’s own computer. Maybe the code does not compile with a different compiler version, maybe the licensing is unclear so it can not be copied, maybe the versioning is inconsistent so minor updates might be incompatible, screen sizes might be different, desktop environments can affect it, sometimes necessary third party libraries do not even have a release. These days software needs to run on different architectures, 64-bit processors caused problems when they became widely available, these days it is ARM which is defeating coders’ assumptions. Packagers need to deal with all of these issues, to give something to the users which reliably works.

We have a policy in Ubuntu that packages with unit tests must have those tests enabled as part of the package build process. Very often they fail and we get told by the software author that the tests are only for his or her own use. Unfortunately it is never reliable enough in software to test it yourself, it needs others to test it too. One test is rarely enough, it needs a multi-layered approach. The unit tests from the original program should be the first place to start, then the packager tests it on his or her own computer, then it needs others to test it too. Automatic install and upgrade testing can be scripted on cloud computing services quite nicely. Putting it into the development distribution archive gets wider testing before finally some months later it gets released to the masses. At each stage problems can and will be found which need to be fixed, then those fixes need testing. So there might not be much coding involved but there is a lot of work to get the software from being 95% to being 100% ready, that 5% is the hardest part, a slow and delicate process needing careful attention all the way.

You can not do packaging without good communication with your upstream developers. When bugs happen it is vital to be able to find the right person to talk to quickly. It is important to get to know them well as friends and colleagues. Conferences are vital for this as meeting someone gives much more context to a mailing list post than a year of emails can.

One of the unspoken parts of the Free Software world is the secret IRC channels used by core members of a project. All big projects have them, somewhere out there Linus Torvalds has a way of chatting to Andrew Morton et al about what is good and what is bad in Linux. They are more social than technical and when overused can be very anti-social for the community at large, but for those times when there is a need for a quick communication channel without noise they work well.

Blogging is another important method of communication in the Free Software community. It is our main method of marketing and promotion for both the software we produce and ourselves. Not to be used for shameless self-publicity, there is no point claiming you will save lives with your blog, but used to talk about your work on Free Software it builds community. It can even get you a job or recognized in the street.

Those Slashdot stories of new technology developments are not about remote figures you never meet in the way newspaper stories are. They are about people who found a problem and solved it using the computer in front of them. For a few years I was editing the KDE news site, finding the people who were solving problems, creating novel ideas and doing the slow slog of getting the software up to high enough quality, then telling the world about them. There were never a shortage of people and stories to tell the world about.

My last piece of advise is to stay varied. There is such a wealth of interesting projects out there to explore, learn from and grow, but once in a position of responsibility it can be tempting to stay there. Having helped create a community for Kubuntu I am moving temporarily to work on Bazaar, a very different project with a focus on developers rather than non-tech users. I can start again learning how code turns into useful reality, how a community interacts, how quality is maintained. It will be a fun challenge and I am looking forward to it.

about the author

Jonathan Riddell is a KDE and Kubuntu developer currently employed by Canonical. When not at a computer he canoes the rivers of Scotland.

notes