Open source as a way to improve code quality
July 11, 2007
A couple of years ago, I started releasing code that I was developing during working hours as open source. That was the first step on a journey that helped me clear my mind on a number of issues surrounding open source.
There are still people around there who look down at open source with a shade of fear and disbelief in their gaze, so I wanted to share my modest experience on the matter.
I am a corporate developer. Mostly. My free time is filled enough with real life activities so that I can't afford the luxury nor have the drive to continue developing at home. Yet I love coding. So I do it at work instead. I mention those private details so you understand that I am not one of those many half-blinded linux-worshiping microsoft-hating slightly fanatic open source zealots.
Yet I do believe in open source.
My conviction has grown out of one simple fact: open sourcing code makes code better.
That simple statement is the result of a rather complex mechanism, blending psychology, group dynamic and efficient knowledge sharing. But through the years, I have had multiple occasions to verify this statement.
There are a number of things happening when you prepare yourself to release code as open source.
First, you are going to release code with your name on it. And internet being as it is, what is released does not disappear. It stays available for everyone to see. Everyone: people living 12000km under your feet, people you will never meet, but also people who will start communicating with you, sharing ideas with you, building a social and professional network around you. People you will meet at courses and conferences. People who will become your colleagues. Head hunters. Your boss. Recruiters who will consider hiring you, or not, depending on what you just released.
To make a long story short, releasing open source code is not just about writing code. It's an important social activity with significant consequences.
So you don't want to mess it.
This leads to what may be the single most important effect of releasing open source code: you are going to be extra careful with what you publish, trying to write elegant, well designed, well documented code. You will try to follow standards to avoid getting flamed publicly. You will write tests to feel more confident. You will react quickly to bug reports so your stats looks good. You will refactor your code when you discover ways of improving it.
And in the end, your code will stand a higher level of quality, for everyone to see.
Now, compare that with what usually happens with code that is released only internally, close source. If you write ugly corporate code, google won't know anything about it. In most cases, your fellow colleagues won't even notice: they are too busy trying to match their own deadlines to take time to look at your code. That is, until you resign, move on to a better paid job and live them with the joy of deciphering your production.
Only your closest colleagues use your code, so you will cut on documentation, since they just have to raise their head and ask you when they wonder about something. They probably wouldn't even read the documentation if there was one: asking is so much easier...
Your future may be influenced by the quality of what you write, but only as long as you work for the same employer. And according to statistics, you are most likely to get another job within a couple of years anyway.
So while the social aspects of code release tend to improve code quality in an open source context, it can almost have the opposite effect in close source environments.
But enough with the social aspect of open sourcing. There is one more consequence to open sourcing that has a significant effect on code quality: your code gets used.
At your office, you may (if you are lucky) have a team of testers dedicated to hunting bugs in your code. But most of the time, the only tools you can rely on to improve your code are your own regression tests, your profiler, your code coverage tools and your own imagination. Also, you will run your code on a couple of computers running one operating system. And that's it.
When you release code as open source, it gets tested, reviewed, commented, discussed. People will send you patches to fix bugs they found. People will run your code on their fridge running operating systems they have hacked together by themselves. Your code will be twisted, ported, executed down to the very last instruction in the darkest area of the less used branch condition from the most forgotten subroutine. And every time a bug is found and fixed, your code gets better.
I could go on a while like this, but I suppose you got the point anyway.
Now to the skeptics around us:
Yes, developing open source code does take more time and resources than close source one. That's because quality requires time. And therefore, this time is not wasted.
Yes, some of this time will go to development that your company won't benefit of. On the other hand, you will get free testing and sometimes even bugfixes and new features. It's a choice to make.
Yes, your pointy-haired boss will have difficulties understanding why you should start publishing code, as open source, since he himself never did that when writing fortran for Big Inc International 30 years ago. Not to mention the fact that he just read an article in 'computer weekly' stating that open-source development may cause fingertip cancer. Be patient and explain about the gain in quality. Or change job. Or wait until your pointy-haired boss is replaced by an other one and try again.
There are still people around there who look down at open source with a shade of fear and disbelief in their gaze, so I wanted to share my modest experience on the matter.
I am a corporate developer. Mostly. My free time is filled enough with real life activities so that I can't afford the luxury nor have the drive to continue developing at home. Yet I love coding. So I do it at work instead. I mention those private details so you understand that I am not one of those many half-blinded linux-worshiping microsoft-hating slightly fanatic open source zealots.
Yet I do believe in open source.
My conviction has grown out of one simple fact: open sourcing code makes code better.
That simple statement is the result of a rather complex mechanism, blending psychology, group dynamic and efficient knowledge sharing. But through the years, I have had multiple occasions to verify this statement.
There are a number of things happening when you prepare yourself to release code as open source.
First, you are going to release code with your name on it. And internet being as it is, what is released does not disappear. It stays available for everyone to see. Everyone: people living 12000km under your feet, people you will never meet, but also people who will start communicating with you, sharing ideas with you, building a social and professional network around you. People you will meet at courses and conferences. People who will become your colleagues. Head hunters. Your boss. Recruiters who will consider hiring you, or not, depending on what you just released.
To make a long story short, releasing open source code is not just about writing code. It's an important social activity with significant consequences.
So you don't want to mess it.
This leads to what may be the single most important effect of releasing open source code: you are going to be extra careful with what you publish, trying to write elegant, well designed, well documented code. You will try to follow standards to avoid getting flamed publicly. You will write tests to feel more confident. You will react quickly to bug reports so your stats looks good. You will refactor your code when you discover ways of improving it.
And in the end, your code will stand a higher level of quality, for everyone to see.
Now, compare that with what usually happens with code that is released only internally, close source. If you write ugly corporate code, google won't know anything about it. In most cases, your fellow colleagues won't even notice: they are too busy trying to match their own deadlines to take time to look at your code. That is, until you resign, move on to a better paid job and live them with the joy of deciphering your production.
Only your closest colleagues use your code, so you will cut on documentation, since they just have to raise their head and ask you when they wonder about something. They probably wouldn't even read the documentation if there was one: asking is so much easier...
Your future may be influenced by the quality of what you write, but only as long as you work for the same employer. And according to statistics, you are most likely to get another job within a couple of years anyway.
So while the social aspects of code release tend to improve code quality in an open source context, it can almost have the opposite effect in close source environments.
But enough with the social aspect of open sourcing. There is one more consequence to open sourcing that has a significant effect on code quality: your code gets used.
At your office, you may (if you are lucky) have a team of testers dedicated to hunting bugs in your code. But most of the time, the only tools you can rely on to improve your code are your own regression tests, your profiler, your code coverage tools and your own imagination. Also, you will run your code on a couple of computers running one operating system. And that's it.
When you release code as open source, it gets tested, reviewed, commented, discussed. People will send you patches to fix bugs they found. People will run your code on their fridge running operating systems they have hacked together by themselves. Your code will be twisted, ported, executed down to the very last instruction in the darkest area of the less used branch condition from the most forgotten subroutine. And every time a bug is found and fixed, your code gets better.
I could go on a while like this, but I suppose you got the point anyway.
Now to the skeptics around us:
Yes, developing open source code does take more time and resources than close source one. That's because quality requires time. And therefore, this time is not wasted.
Yes, some of this time will go to development that your company won't benefit of. On the other hand, you will get free testing and sometimes even bugfixes and new features. It's a choice to make.
Yes, your pointy-haired boss will have difficulties understanding why you should start publishing code, as open source, since he himself never did that when writing fortran for Big Inc International 30 years ago. Not to mention the fact that he just read an article in 'computer weekly' stating that open-source development may cause fingertip cancer. Be patient and explain about the gain in quality. Or change job. Or wait until your pointy-haired boss is replaced by an other one and try again.
