I’ve learned a lot of things from a lot of people in my life. The following lesson/acquired knowledge came, more than likely unbeknown to him (it was a very casual conversation, so there is no reason he would have thought of it as anything other than a casual conversation), from Mike Champion,

The reason why I am a *HUGE* fan of shared source, non-commercial licensed software is,

- In many cases, the source comes from established software applications with proven commercial success.
- In cases such as this exists a *FANTASTIC* opportunity to learn and understand how something with significant commercial success was created.
- With this knowledge we are better enabled to build better product as a result.

To understand the hacker means to understand that the hacker learns through a hands on approach. I know very few hackers that learned how to hack and hack well inside the confines of a university.

On the other hand, I know *TONS* of hackers who, while they may never again utilize the source of a project they were once a part of, or have in many cases simply learned through reading the source of a project they were never a part of, they are enabled to write better software because of the knowledge they gained as a result.

OSS projects will come and go, but knowledge is King, and will stay with you as long as you continue to maintain and refresh this knowledge.

A month or so back I wrote an entry regarding a comment made by Oleg Tkachenko,

Another way to get rich - create great open source product, make your code unreadable, provide no documentation and then sell support :)

As I pointed out in a follow-up to the same linked post,

I almost titled the post “On SourceForge and Open Source Obfuscation”, (and probably should have now that I think of it), but chose not to for some odd reason.

Very few things come for free in life. In regards to OSS, while the price of the software might be free, generally speaking the documentation is either non-existent or completely missing, so the price you pay comes in the time you spend learning how to interact with the code base. And if that code base doesn’t follow standard design patterns, learning how to interact with the code base can prove to cost a much heftier price than originally anticipated.

Of course there’s always exceptions to the rules, and the exception in this case comes, oddly enough given their previous stance regarding OSS, from Microsoft,

Jim Hugunin’s Thinking Dynamic : The One True Object (Part 1)

I’m starting my design notes blogging today with my first entry on the dynamic type system that is one of the three key components in the DLR - and the one that I think is most important. The corner-stone of the DLR is support for a shared dynamic type system. This lets these dynamic languages easily and naturally talk to each other and share code. Equally important is that we want these dynamic languages to be able to work with the existing powerful static languages on the platform such as VB.NET and C#. We want to ensure that the huge wealth of both existing and to-be-written libraries designed for .NET all just work from dynamic languages. There’s a standard pattern for achieving this kind of interoperability through wrappers and marshaling layers. Here’s the pattern as I implemented it for Jython - Python running on the JVM.

The above is the first of what is suggested to be several months worth of blog entries from Jim Hugunin regarding the design of the MSFT’s OSS Dynamic Language Runtime. In an eWeek article in August of last year, Jim was quoted with the following statement,

Microsoft is working on a phased approach to enhancing its support for dynamic languages on the company’s .Net platform.

Jim Hugunin, creator of the IronPython language and a development leader on Microsoft’s CLR (Common Language Runtime) team, told eWEEK that Microsoft is working to help usher in support for dynamic languages on top of the CLR in a variety of levels or phases.

As I pointed out in Ruby on Rails and the .NET Platform: Sometimes To Embrace Means You Must First Be Willing To Let Go,

Jim goes on to describe a three-phased approach which includes the development of extended support for dynamic languages as part of the .NET platform, an instantiation of the best patterns and practices into a code base in which can then be extended from, as well as offering the “lessons learned” during the development of all of the above, in a format that I would assume be provided through channels such as Microsoft Consulting Services (though this is only a guess.)

As made obvious from the above, it seems Jim has every intention of seeing each and every one of these phases to the very end.

Nice! :D

If you’re not already, I would highly recommend subscribing to both Jim’s and John’s (Lam (RubyCLR > MSFT > IronRuby) web feeds. Jim Hugunin: Feed. John Lam: Feed.