Dana Blakenhorn calls for "Open Source Lobbyists" and I completely agree with him.  Companies and industries that have lobbyist in Washington do much better than those without, and unfortunately, those without lobbyists are usually all those that are not represented by a large company.  Ever wondered why kids have to be in booster seats until they are six now - and it's recommended until they are eight?  It's not because it's necessarily safer  - it's because the car seat manufacturers have spent money lobbying in Washington to make sure that car seat laws favor their business.  The tobacco industry, the drug companies, and yes, even software companies, all have lobbyists in Washington.  That said, open source will get its lobbyists.  As open source grows, more companies will have businesses that depend on it and those companies, as they get big enough, will end up hiring lobbyists in Washington because that's how you get laws that favor your business.

I mentioned in a previous post that I was irritated with unnecessary software complexity and bloat. The general problem of bloat is endemic in most human endeavors whether it be software development, company growth, or my kid's closets....still it's something to fight against. For software, there are two major categories of bloat. 1) Feature bloat and 2) Code reuse bloat. You might be surprised to see code reuse on the suspect list for bloat, after all, code reuse was supposed to save time, labor, space by eliminating redundancy and improving quality.

Landon's Reefer Model of Software Bloat

Think of your refrigerator. Now imagine you're feasting at the Cheesecake Factory where the single portions are enough to feed a whole family. You bring the voluminous leftovers home and they go into the fridge. The next day, you're invited over to a friend's house, but you can't take your Cheesecake Factory leftovers to the potluck, that would be tacky, so you whip up some of your world famous Tuna Casserole with all the fixins'. Turns out it's famous for reasons other than what you thought, so you bring it home with one scoop taken out of it and it goes into your reefer - you comfort yourself thinking "that's ok, all the more for me." Your current Reefer graph looks like this: For the rest of the week, you repeat the drama at every meal, and by the end of the week, your frig is busting at the seams with leftovers and it's starting to smell rank. Your tummy vs fridge consumption graph now looks like this: Software developers do the same thing. We see a cool piece of functionality in a library somewhere. To incorporate it, we add a JAR or DLL (gasp) file to the package, write some code that uses it, and then go on to the next feature (our next meal.) As every developer knows, there are dependencies to satisfy so most of the time you're not just adding one JAR for the bits you want - it comes with some camp followers. In each case we use some of the functionality but don't use every bit of functionality in the library we just added. In some cases, we may use very little of it, but the little we used we needed badly. Perhaps, the little we used saved us several weeks of effort, so that's nice. Then we sit back, pop a brewskeee and soothe ourselves with words like "ahhh, that's what code reuse is all about...saving labor...let someone else maintain it...let them fix bugs....that's the ticket." The thing about the 'O reefer is that eventually the food rots, you can't stand the stink, and you clean it out (at least you do unless you're a frat boy... in that case, the maid-fairy comes to clean it out for you.) With software, it also eventually rots, but takes a lot longer, so the bloat is a lot worse than a week of leftovers because it's harder to smell...and no maid-fairy is around to cleanup our software leftovers. There's a cross-over point somewhere in which the labor it takes to haul all this rotten software around overtakes the labor savings you gained by adding it in the first place. All of the sudden, code reuse takes on a Machiavellian aura in which the "careless reading" concludes the end (saving labor, gaining features) justifies the means (code reuse, bloat.) You have to live with the rot or remove it just like you would with your reefer. The only question left is when will you have to clean it out before you can't stand it anymore? So, while we love and respect our illustrious CTO, Rod Cope, I have to take exception to his remark, "Yes, both of these solutions can lead to dramatically increased disk space usage, but hey, when's the last time your new computer came with a 30 megabyte hard drive? Laptops now ship with fast 160GB+ drives; it's time to move on." I don't care how much disk space you have, it won't solve this problem. In fact, the more disk and memory you have, the worse the bloat problem gets. As software engineers, we need to still create minimalistic, functional software and fight the bloat at every turn regardless of how capable our machines get. Some things like our ability to deal with software complexity don't scale with Moore's Law.

http://www.apache.org/jcp/sunopenletter.html

I had a pesky telemarketer call me on my cell-phone from Programmers Paradise a day or so ago. As you probably know, they primarily sell Windows developers tools. She wanted to know if I had 5 minutes to respond to a survey. When I said "No", she continued on asking what tools I used, what tools I needed, etc. I really didn't have time to talk so I popped off with "I do open source development." I heard an "Oh, thank you for your time" and she hung up. I was pretty proud of myself, almost like I just skated on jury duty or something, but I realized that I really just preyed on her ignorance of open source. I can think of at least 5 things she could have sold me if she was savvy. Without digging very deep, some .NET open source development needs, guess what, Visual Studio, Windows, SQL Server, IIS...think MSDN sale. The reason I was on their list at all was I bought MSDN from Programmer's Paradise a few years back and didn't renew it last year. She found a ripe sale in an open source developer and didn't have a clue.