Friday, March 27, 2009

Don't Like It? Code it Yourself!

Jeff Atwood writes on a topic that's interested me for quite a while:

Coding Horror: Don't Like It? Code it Yourself!

To me, at least, sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project. For example, I've sponsored several bugfixes in a key .NET open source library that we use for Stack Overflow. These are bugfixes they considered low priority, but were serious issues for our site. I was happy to give back to the project, and it was certainly a more realistic option than us carving out a chunk of our own development time to contribute the bugfixes ourselves.

That said, I am concerned that this sort of aggregated sponsorship system hasn't naturally evolved on its own by now. Is it not sustainible, or incompatible with the kind of intrinsic motivations that drive most open source development?

In my previous job, we wrote software that heavily relied upon open source and GPL'ed software. The entire department developed and deployed software (primarily) for Linux systems, used gcc, Tcl/Tk, and a bunch of smaller open source tools. When compared to the more proprietary systems used (AIX, HP-UX), the savings were huge - both in software, hardware, and overall productivity.

At one point, the department decided to look into providing a "better"(?) debugging experience. After some research, they settled on a proprietary debugger. A year passed, licenses were finally purchased, and ... it was quietly released into the department, with very little fanfare.

I eventually found out about it, tried it out, and found the experience to be underwhelming to say the least. Several of the touted "features" were still in development (visualization of STL containers) and not to be delivered for another year, and the rest of the "features" had been in DDD/GDB for years. As an added hassle, it required the object files to be post-processed to obtain debugging symbols in their proprietary format.

To make a long story short(er), I found out we had paid many times my annual salary for a set of licenses for software that didn't have the features found in open-source software, and we had to pay this amount annually.

I fed this information up the chain of command, which just got the manager of software-development-environment angry at me. I proposed we use the money to instead hire a contractor to work on any bugs/enhancements for GDB/DDD, using the logic that not only would it be cheaper, it'd provide a return on investment faster, as well as be available to the entire department/company/world from here on out - at no extra cost. At the very least, it seemed to me, it was a tiny price to pay for the company's ability to use the open source Linux systems for development.

Management wasn't interested, not in the slightest. About the only argument they'd give me for keeping the status quo was that companies preferred working with other companies, and not contractors.

This always seemed to be more of a duck than a real argument.

I figured, if the software was good enough to use, it should be good enough to pay to improve.

Tuesday, March 3, 2009

More Advice

Way back when I wrote a tip about Emacs Lisp's advice.

How I wish other languages had this capability. A couple of questions came up recently on that were (imo) best answered using advice. So, if you're struggling to see when to use advice, I think they're pretty good examples.

"Diff, save or kill" when killing buffers in emacs

Can I change emacs find-file history?