I read a book a while back that made me go "that's it!" Now, Discover Your Strengths is all about how we should spend our time doing things we are good at, becoming excellent at those tasks, rather than wasting our time trying to become mediocre at the things we aren't good at.  I intuitively did this for the people that worked for me - I gave them the tasks they were good at.  Usually, those were the tasks they enjoyed doing.  (From a manager's perspective that was the best way to get things done well and quickly.)  But I hadn't really looked at it from a personal perspective.  I'd been busy trying to be good at all the things someone in my position was "supposed" to be good at.    

 The Slow Leadership blog had an interesting story about the Romans today:

The Romans thought every one had a genius — a kind of innate allocation of ability and luck. Some people were blessed with the genius to be great leaders. The proof was simple: it came easily and naturally to them. If you had to struggle for something, that wasn't suitable for your genius. What would they have made of the modern notion that having to nearly kill yourself — and give up most other pleasures in life — is somehow required of anyone aspiring to a leadership position?

I agree that if you are struggling with something, it's probably not something you will ever be really good at.  I disagree that you have innate talents - I think you are good at the things you enjoy.  You enjoy them, so you work hard at them.  You work hard at them, so you become good at them.  The key is that you enjoyed working hard.  Just look at any professional athlete - maybe they have an innate talent for their sport - but they work very, very hard to become top in their sport.

So working hard for something isn't necessarily bad but if you don't enjoy working for it, then it's highly unlikely you'll become a genius at it. 

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.

This is an ultra-brief, brass-tacks, rubber meets road description of what Sun's decision to open source Java means for the average developer. Someone asked a question about what open sourcing Java meant and I was surprised I didn't have a good answer. So not much opinion or independent thought here, this is just a summary of what I've found out. I'm not a lawyer, yada yada. Don't consider this legal advice.

What's it mean?

The good news is that (going forward) Java will always be an open platform for development. No one is going to hijack it, it won't become abandonware. But with such an important platform there's always the danger of forking. Fortunately the key players have promised to keep the JREs compatible.

Read below about the Classpath exception, the new GPL Java is not viral. Usage of the Java platform is business as usual!

What license?

Sun chose GPL v2 for Java SE, Java ME, Java EE implementations. No open source zealots can see this choice as a weeny move, Sun is all in. You can get all code for JDK6 and JDK7 under the Java Research License in the meantime. As indicated in their FAQ, this isn't a vote against GPL v3, Sun just went with the version that's already out.

Here's one mans summary of the GPL.

You can re-distribute this stuff and even charge for it. But if you make modifications to the software you need to provide source code so that others can benefit from your modifications.

What will be open sourced?

Java SE, these are early versions of the JDK7 release. All will be GPL v2 + Classpath exception

• Java compiler javac
• Java HotSpot virtual machine
• Java class libraries
• JavaHelp 2.0 (JSR 97)

The GlassFish Java EE application server will be GPL v2 with Classpath exception (actually it's dual licensed under the CDDL as well).

Sun is gradually releasing parts of their Java platform. They're not releasing everything because of licensing issues. They refer to it as not releasing encumbered code that Sun doesn't have rights to open source legally. Look for this code to be early targets for open source clean room implementations.

The Classpath exception

The Classpath exception that Sun adopts for open source Java is an innovation of the GNU Classpath project. The GNU Classpath project is a GPL v2 implementation of the JDK by the GNU folks.

The Classpath exception means that code that you write to the GPL v2 Java APIs aren't required to adopt the GPL v2. This removes the possibility of the often misunderstood viral nature of open source technology. Businesses can continue to develop on the Java platform taking advantage of an open source community while still making money from their efforts and applying whatever license they prefer. However if you take the source code for the Java APIs, modify and distribute those, then the derived work needs to be GPL v2. Other than that, you have no fear of infection.

Basically the Classpath exception makes the license on the APIs very similar to the LGPL. The Classpath serves as a firewall between the GPL v2 and users of the Java APIs. There is precedent in the open source Java world to use the Classpath exception (by the GNU/ Classpath project) so Sun went with that.

The forking danger

Will IBM try to eclipse Sun with their own blue JDK? Will Microsoft embrace and extend, remember J++? The open source implementations (GNU/ Classpath and Harmony) have promised to build fully compatible implementations of Java SE.

Sun will still be the gate keeper for the Java Compatible and Java Powered brand and logo. Others can fork such that they have an incompatible JRE but they won't receive the special Sun seal of approval.

Licenses

• GPL v2
• Classpath exception The Classpath exception means that you can code your Java applications to these GPL v2 APIs and not have to conform to the GPL v2 license.
• Java Research License
• CDDL

This FAQ was very helpful for the details of what opensource Java means. http://www.sun.com/software/opensource/java/faq.jsp

After draft 3 of the GPLv3 came out we asked our Expert Community, a good representative sample of the open source community what they thought of it.  (Note, I'm not a statistician but I believe the Expert Community is representative of the open source community because the Expert Community represents most of the 250+ open source software products we ship plus a bunch we don't ship yet.) 

Overall, the Expert Community was pretty positive on the GPLv3.  The ratio was 3:1 - those that thought the GPLv3 was good for open source versus those that didn't.  Over 70% said they would support moving the projects they work with to the GPLv3 and, surprising, 77% expected that to happen very quickly - within a year of having a final version of the GPLv3.  (At least that was surprisingly quick to me  - maybe I've spend too much time in the corporate world!)

While bullish on the GPLv3, the community did have concerns about some of the provisions like DRM and patents.  I think that's wise - at least until the provisions get finalized. I wished we had asked some more questions about what their concerns were - maybe they will comment here!

Here's some of the data so you can see for yourself:

Expert Community respondents believe that GPLv3 is good for open source.

• 50% of the respondents said that they believe GPLv3 is good for open source.
• 29.5% are not sure
• 15.9% said they do not believe GPL v3 is good for open source

However, respondents also have concerns about provisions of Draft 3.

• 57% were concerned about provisions around patent issues
• 57% were concerned about provisions around digital rights management
• 43% were concerned about provisions around the use of  GPL-covered programs in consumer devices 

Of respondents that are working on GPLv2 projects

• 71% would be in favor of some or all of these projects moving to GPLv3
• 77% thought that it would take a year or less for their projects to move to GPLv3 once the final version of GPLv3 was released

 I think it's interesting how this data has been interpreted differently by different folks.  Some, like us, think this means that the  Expert Community members we surveyed are in favor of the GPLv3 (50% say it's good versus 15.9% that say it's not) while others have decided that if only 50% say it's good than half must think it's not good.   Is your glass half full or half empty?

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

So, this is interesting to me. Interesting only in that it is going to be annoying how much play this gets, particularly leading up to and at JavaOne. I can imagine it will be a large conversation point there, which bothers me. 

This is probably because (allow me to identify myself with marketing terminology) I am a technical pragmatist, and these types of things don't interest me in the least. It seems to me that there are just so many more interesting (and I'm thinking of using the word 'hard' here too, as offensive as that may be to some folks) problems to solve and ways to spend one's time than to have to hash this kind of stuff out.

Now, that being said, I begrudgingly recognize that this is the way the world works, that it needs to be done, that these types of issues do need to be dealt with, I'm glad someone is willing to do it, and I'm glad that someone is not me. Putting aside specifics regarding the Harmony project, if everything the letter claims is true, it seems to me that they (Sun) simply need to hold up their end of the bargain.

Seems to me that these types of things should be the easy things to knock out of the park. If you say you're gonna do something, do it (should I bother noting that this should apply in all walks of life, not just with regards to open source related drama?).

UPDATE: As of  9:15 AM US/Mountain time (on 04/10/2007), there are already 7 entries showing up in my JavaBlogs RSS feed about this topic.  I guess I'm probably adding to what I'm saying annoys me.  Hopefully the whole thing will be resolved swiftly.

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.