I’ve been preparing these past few weeks for my Sun Certified Developer for the Java 2 Platform exam; and something occurred to me, but before I get into that, a little background.
When I was about 17 years young, I went to a family party, and bumped into the hosts son, who at the time was making some serious cash to the tune of $50K (this was back in ‘94) writing Cobol apps. He had a flash car, nice clothes, and said to me (I was just about to submit my selections for University placements), get into programming, you’ll make money son!
So that’s exactly what I did! I enrolled in a Computer Science and Software Engineering degree, learnt Ada, ASM, C++, Delphi, Java, amongst other things, and then scored a job writing Visual Basic applications. That was cool for a time, but then I started to move into framework teams, where the language of choice was C++ and Assembler, then started my own business, where most of the work was in .NET.
Now, this post is all MY OPINION, it’s based on my inner feelings and thoughts. But you know, I used to put some heavy hours into my 9–5 job, and I have to be honest, I was never really fired up. Yeah, occasionally I would come across a problem here and there, that really tweaked my springs, but overall, it was business app development, and not too phunky! So then I decided that if I really wanted to get some lead in my pencil, I needed to tinker on the side. Nothing substantial, but I would find out what other mates were working on, and grab the latest SDK or compiler they were using, and start playing around with it. I did it partly to keep my options open from an employment point of view, but deep inside me there was a geek, a coder provocateur, that was crying out for a complex challenge to solve, something bigger than retrieving rows from the database.
So I would tinker, I would write my own ISAPI extensions in C++, I would download the latest versions of Swing and go through the samples, or just install Linux just for the hell of it (and the challenge of getting a sound card driver installed that wouldn’t meltdown my whole system). I was like a programming junky who needed a regular fix. Then one day, a mate of mine called me up and said, hey, I’m going to write a framework in C++, wanna help. I said sure, I tinker at home, but I’d love to work on something more substantial. He and I tinkered for a few months together, emailing each other code updates, and builds, and we had a blast. Then one day, at work, my boss asked me whether I knew off anything we could use internally to solve this problem, and I thought immediately of the project my mate and I had been working on after hours. I demo’d it to my boss, and he loved it and said go for it, use it in the solution. It was like the best of both worlds, on one hand I was being paid to write code, on the other, it was my own tinker project that I was writing the code for! But then my mate had his first child, and he dropped off the radar, and suddenly I had to maintain this project after hours, and I tried to get others involved, but they weren’t interested in my project, but wanted to start their own, and my boss wanted more work done, which required more and more framework changes, and finally I fell into a nasty black hole. We ended up scrapping most of the code from that solution and ended up buying some components from a third-party vendor. It taught me a valuable lesson about OSS and commercial software; done mix business with pleasure.
So as I start thinking about OSS and commercial software, I realise you need both. There needs to be a place to tinker, to stimulate new ideas, to see if your spark can become a flame. But at some point, if that flame catches on, and people start using it in production systems, someone needs to put their hand up and say, “Yes, I support this, and if you have any problems, or want changes, then we will own the risk and effort required to meet those needs”. And yes, generally, that kind of statement involves cost. It’s why we pay for many things in life, because we need to be comfortable that someone else is investing in the discovery and development, while we concentrate on the use.
And it doesn’t matter if the code is easily downloadable or modifiable, that’s just a transparency thing. To a production grade development team, being able to wade through lines and lines of code to identify, isolate and change a framework or product aspect is useless if that effort takes them off the critical path. What is more important is that they can escalate that issue to a “owner” where there is a service level agreement, and expect it be fixed or resolved, and move on with the rest of the project. Otherwise, the line between working and tinkering becomes the difference between project delivery or project stall.
So to me, OSS and commercial software isn’t about the language you develop in, or the company you work for, it’s the line that gets crossed from “I’m discovering something here and want others to learn and experience from it” to “I’m using this in my next production application and need to be able to hold someone accountable should it not work as promised!”.
Actually, it’s that old legal term that sounds best, “All care taken, no responsibility accepted!”