Entries
RSS 2.0

Comments
RSS 2.0

Cleveland Day of .NET Aftermath

Yesterday, I presented at the first annual Cleveland Day of .NET in Beachwood, and it was a fantastic experience. I was able to meet some brilliant people — although at times it was a little surreal, since I already “knew” them from Twitter and it was like I was meeting them all over again. The presentations that I attended were all excellent, and the conversations in the hallways and at lunch and dinner were even better.

Off the top of my head, it was great to meet: Dan Hounshell, Alan Stevens, Joe Fiorini, Mike Eaton, Leon Gersing, Sarah Dutkiewicz, John Stockton, Corey Haines, and Brian Prince. I know that I’ve forgotten some people from this list, and I’m sorry… the day was really a whirlwind, and my memory is horrible. If I’ve forgotten you, please post a comment or send me a tweet and I’ll make it right! Thanks very much to everyone involved in organizing, sponsoring, and attending the event.

For my first time presenting in front of a larger audience, I felt like it went pretty well. I was admittedly a little intimidated — although very excited — when it ended up being standing-room-only during my presentation. Thanks to everyone that came to watch me speak, and I hope you found it useful! Thanks also for the kind words and great feedback afterwards, and a special thanks to Alan Stevens for “refactoring” the projector when it decided to overheat halfway through. :D

Here are my slides, and you can also download them below:

As promised, a more complex code sample that illustrates some of the principles I discussed in the talk is available to download here. The code sample illustrates some of the more advanced uses of Ninject — stuff that I never could fit on a Keynote slide. I encourage you to tear it apart and get your hands dirty. The best way to learn the value of IoC is definitely to try it for yourself.

Slides (Keynote): designing-for-change.key.zip
Slides (PDF): designing-for-change.pdf.zip
Sample project: wargame.zip

Discord&Rhyme Joins The Lounge

Twitter is fantastic, because you can use it to meet some really interesting people. One such person I ran into in the Twitterverse is James Avery, who runs The Lounge, an internet ad network focused on technology. When he invited me to join the .NET Small Publishers Room, I was flattered, because I had already subscribed to several of the blogs that were featured there. It’s an honor to be featured alongside such auspicious company.

For those that read my blog from the site itself, you’ll notice a small ad in the top right corner. For those that read the RSS feed, you won’t notice any changes.

Bait-and-Switch and Software Licenses

Jack Slocum and the rest of the Ext JS team recently released version 2.1 of their fantastic toolkit. If you’re not familiar with Ext, it’s a user interface library that lets you write rich Internet applications (RIAs) using JavaScript. It’s more than jQuery or Prototype, in that it gives you full-fledged components like dialogs, grids, and trees in addition to the typical animation and language-enhancement features of the other JS libraries. If you develop RIAs and you haven’t tried Ext, I highly recommend you check it out.

That being said, the Ext team slipped in a little surprise with their latest release. Up until version 2.1, Ext was released under a dual-license model, with one option being an LGPL-compatible license and the other a commercial license. From this point forward, they’ve changed the options to GPL (as in, full copyleft) or a commercial license. This means that in order to upgrade to the latest version, all products which had previously relied on Ext will now have to start distributing the source — of not only Ext, but also their own products — in order to remain within license.

As you might imagine, this caused quite a stir within Ext’s already-quite-large user base. First, let me say that I am absolutely a believer in open-source software. Open-source means you can use the code in your own projects, commercial or otherwise. You can read the code and learn from it. You can contribute patches and ideas, furthering the project’s development. However, there is a tremendous difference between what I would call open-source licenses (Apache, BSD, MIT, et al.) and copyleft licenses like the GPL.

(Note: some people will disagree and say that GPL is still open-source, but I’m not trying to debate semantics. This post will refer to the two types of licenses separately.)

Ninject, for example, is open-source (Apache 2.0, actually), and I fully encourage anyone and everyone to use it in as many commercial products as they like. If you make a billion dollars through a product that uses Ninject, I’d appreciate it if you bought me a beer, or maybe my own private jet on 24-hour standby, but otherwise I would be nothing but happy for you. :)

The GPL is fine for things like operating systems and applications, which are essentially standalone. These products aren’t going to be re-used in other products. However, libraries, frameworks, and any sort of middleware should never, ever, ever be released under a copyleft license like the GPL. Copyleft is viral, in that the second it touches any part of your code, you must open its source. Ostensibly, that is perfectly reasonable, but the difference between closed-source and open-source is a business decision, and a very significant one. Your business model determines whether you can or should run your project as open- or closed-source.

Ask yourself: are you really going to build your business model around the license of a library like Ext? My guess is that most people would just find another way, and that discourages adoption of the library. It’s true that if people are making money off of Ext, it’s reasonable they pay the creators, but changing the license of the library after there are a lot of products that already use it is downright unfair. The Ext team is playing dirty, and people have every right to be upset.

There’s nothing wrong with wanting to be compensated for your work, particularly when you create something as widely useful as Ext. However, waiting until version 2.1 to change the license model for your software (not to mention changing it on a point release rather than a full dot-oh) strikes me as a little bit dishonest. Unless we give them the benefit of the doubt, it sure seems like they leveraged the openness of LGPL to get control of market share and build their user base, and then pulled a major bait-and-switch once they locked users in.

Bear in mind, also, that Ext was originally called yui-ext, and was built on top of YUI, the Yahoo! UI Library, a BSD-licensed toolkit. Basically, the Ext team stood on the shoulders of open-source, putting on airs as though they were participating, and then when the time was right they slammed the door shut.

Worse yet, the Ext community has contributed back a large number customized components and enhancements to the library. The Ext team hasn’t explicitly rolled these enhancements into the core, but they have undoubtedly learned from them and enhanced the code library as a result. I’ve also seen several cases where people submit code change suggestions (essentially patches) on the forum, which end up being rolled into the core. It’s not fair to have it both ways — accepting outside ideas means you have a responsibility not to screw the people that contribute those ideas.

At best, this is a terrible blunder on the part of the Ext team, and at worst, it’s a blatant misuse of open-source licenses. This is not what the GPL and the LGPL were created for. Also, it’s cases like this that add to the FUD surrounding open-source. After seeing things like this, I don’t blame businesses being afraid of adopting open-source in their products, for fear of the rug being pulled out from under them. And that’s not fair to real open-source libraries.

Of course, all this nonsense begs the question: how do you GPL a web application, anyway? In a typical website based on Ext, there’s client-side code written in JavaScript, which uses Ext for the user interface, and then there’s server-side code written in any of a myriad of languages which doesn’t come near Ext. Does using Ext on the front-end mean you have to open-source your entire product?

There’s all sorts of gray area there, which Jack desperately tries to explain. His reasoning? If your server-side code generates markup, then yes, you need to open-source it. What if the JSON/XML that I send back to the UI influences the layout? Do I need to open that source also? Now I need to employ a whole legal team to try to decipher whether or not I’m GPL-compliant.

Jack tries to defend the decision thusly:

In the end, we want Ext JS to be open source friendly and still have a good business model in place to grow. The old Ext License was not open source friendly and pretty much killed all options for use in open source projects. That wasn’t our goal so we had to address it.

To be perfectly blunt, that’s a crock of shit. The only reason the old Ext License wasn’t open-source friendly is because it wasn’t really the LGPL and therefore not OSI-approved. Why didn’t they use the LGPL, you ask? They were worried that someone would fork the project. Tell me again that they weren’t planning this all along.

Oh, and by the way, they’re not opening up the project’s Subversion repository. You can download official releases, but you can’t have direct access to the latest builds — unless you buy a commercial license. That’s technically fair, but doesn’t exactly jive with the concept of open-source.

On one hand, I feel for Jack, who has been a target of personal attacks because of this license change. He attempts to defend himself on his blog. However, it’s easy to see why people are upset, and I can’t believe he didn’t see it coming. I understand that you need to protect your intellectual property, but you need to recognize that open-source is a give-and-take (quid pro quo, as the Ext site says) — you give users free access to the library, and in exchange you get community support and good ideas. Changing from LGPL to GPL doesn’t protect the library from being misused by “major companies”, either. Sorry Jack, but they’re still banking on the fact that you don’t have the money to sue them.

To be fair, it does look like they’re considering a FLOSS exception like MySQL has, so non-copyleft open-source projects can continue to use the library. Why even change, then? You’re going to end up with essentially the same outcome as a result.

Using the GPL in this way arguably causes a chilling effect not unlike closing the source completely. By requiring users to release their source, you are shutting out a potential segment of users. It’s very easy to see that if Ext had been licensed under the GPL since inception, it would not have nearly the mind-share it does today.

Since I use Ext in my “day job” in for-profit products, we were happy to buy a commercial license. However, now that it’s licensed under the GPL, its much more difficult for me to consider using it in side work or hobby projects.

Great IoC Presentation by Justin Etheredge

Justin Etheredge gave a great presentation on dependency injection and inversion of control last week at the Richmond Code Camp. It gives a very good introduction to DI, which is something that I’m going to try to tackle at the Cleveland Day of .NET in a few weeks. Plus, he uses Ninject in the examples and was kind enough to quote me in the presentation, so it’s got to be good, right? :)

Seriously, though, if you weren’t able to see the presentation, Justin’s posted the slides and related code samples on his blog. I highly recommend you check them out if you’re interested in learning more about dependency injection!