Dallas TechFest
A friend of mine is helping organize the Dallas TechFest, which is a free conference sponsored by Microsoft, Sun and others. Dallas rarely gets decent technology conferences outside of single-vendor “marketechure” events, so this should be a lot of fun. It will be at the Addison Convention Center, which makes it doubly nice, since I won’t have to drive into the boonies (downtown Dallas).
TechFest has tracks on about everything interesting going on in programming, including the elderly statesmen (.NET, Java) and the young upstarts (Ruby on Rails, Flex). It also has an emerging technologies track, which should be interesting.
Check out the site for registration information. And don’t forget, it’s FREE!
The GPL is Cancer
I have never really cared about the GNU General Public License much before. I always regarded it as the license of choice for the real open source zealots and actively steered clear of it based on its viral nature. All the Java open source tools I care about are released under much less-restrictive, user-friendly license like the Apache Software License or variants of the MIT/BSD licenses. But that all changed this week when my favorite JavaScript library, ExtJS, changed their license to GPL v3.
I have been tinkering with ExtJS for a month now, and have really fallen in love with it. You’ll never want to code an html table again once you’ve worked with ExtJS. The library had been dual-licensed as LGPL or commercial. LGPL is much less restrictive than GPL, and it drew a lot of folks in to ExtJS. Without warning, on Monday, the license for ExtJS was changed to regular GPL in a point release. To say the community around ExtJS is a bit agitated would be an understatement.
This change has actually caused me to rethink my opinions about the GPL. I considered it a viral license before, based on the fact it infects everything it touches. Most other professional software developers share the same opinion. But now, seeing what it has done to ExtJS in less than a week, I have decided the GPL is a cancerous license – it doesn’t just infect the host, it kills it.
ExtJS got mindshare by having the LGPL license. Developers were willing to try it, evangelize it, and participate in the community. They felt a sense of ownership in contributing to it and helping the new users on the forums. The surprise change has destroyed that goodwill and the new license makes it very difficult for anyone to take an interest in it. Most companies are strongly anti-GPL, for good reason, so corporate developers won’t be allowed to play with it. And no company is going to go out and buy commercial licenses on blind faith with such a small, unproven software shop.
Now that ExtJS is licensed as GPL instead of LGPL, I expect to see the community evaporate. That leaves ExtJS competing as a purely commercial endeavor against the likes of Microsoft Silverlight and Adobe Flex. The customer-business relationship will be a lot harsher for ExtJS than one of a community-supported open source project. They will become slaves to their biggest clients, effectively ignoring the community that got them the mindshare to begin with.
I can appreciate the ExtJS folks wanting to make money with the work they have done. The dream job of every software developer is to be paid well to work with the technologies you enjoy. But switching to GPL was the wrong way to approach it. Like cancer, the GPL is going to kill the host.
Why Microsoft Sucks
In spite of the inflammatory title, please don’t interpret this to mean Microsoft sucks and Vendor X is a god. I have issues with all the major vendors and have just decided to vocalize about Microsoft first. I don’t really like picking on Microsoft. I’ve worked with them extensively, have been to Redmond, and have worked and socialized with many of their employees. They have all been excellent. Almost every “geek” I have dealt with at Microsoft has been the type of person I would happily have a beer with, which is the ultimate test for a team. So Microsoft doesn’t suck because of its geeks. The problem sits well north of them.
Stagnation
Microsoft’s biggest problem, and the reason Google is eating their lunch, is that Microsoft has stagnated technically. They make their money on the Windows OS and on Office, but both of these are at a dead end. There is no “must have” reason to upgrade either of these any more, and Microsoft’s solution is to try and lock in their enterprise customers with costly maintenance agreements. Like candle makers at the dawn of the electric revolution, Microsoft is desperately clinging to a dead business model, and rather than innovate and adapt, they will abuse their customers to hold on to a monopoly position.
Complexity
Microsoft has gone to the other extreme with their programming tools, .NET. I consider C# to be the only real .NET language. VB.NET is a joke intended to appease the legacy VB6 code monkeys, and no one with any brains would ever initiate a new project using VB.NET. Managed C++ was to appease the other extreme – hardcore MFC/Win32 programmers. But that is such a specialized group that they didn’t really care about .NET. C# itself is the result of a shotgun wedding between Delphi and Java. Microsoft stole the creator of Turbo Pascal (Anders Hejlsberg) from Borland, who created C#. Rather than play nice with Sun and do something beneficial for their customers, Microsoft chose to fracture the market in an attempt to maintain their platform monopoly.
All this would be water under the bridge if Microsoft didn’t continue the make things worse for developers. C# has morphed from a fairly clean Java clone to an absolute monstrosity of complexity. To give the impression of innovation, they have consistently added everything and the kitchen sink to each revision. Code written in the latest version, .NET 3.5, is simply painful to read if the developer actually tries to use all the features Microsoft has thrown in. LINQ is the perfect example of how to make a language unusable.
Enterprise software developers are not the cream-of-the-crop in the developer food chain. Most are minimally skilled and chose enterprise development to avoid having to deal with rapidly changing technology. The reason there are still VB6 developers is because of enterprises. Given their resistance to change, it makes no sense for Microsoft to keep adding in so much to .NET. The only explanation is that Microsoft is trying to appease their partners. Keeping the platform moving ensures there is huge consulting money to be made in “helping” enterprises keep up.
Resistance
Developers are the key to any software platform, and one area where Microsoft has really let them down is through their resistance to Open Source software. Almost every other non-Microsoft programming language (Java, Perl, Python, Ruby, PHP, etc…) has a thriving Open Source community around it that breeds innovation, increases reuse and creates a “survival of the fittest” mentality around technologies. Microsoft is a ghetto by comparison, an intellectual ghost town. All because Microsoft’s only motivation is ensuring vendor lock-in to protect their platform monopoly. This will be their downfall in the end. Go to an emerging technology conference or visit a major university and take a look at what the next generation of geeks is cutting their teeth on. You’ll see mostly Apple or Linux laptops, with very little Microsoft. Windows will not be the dominate platform for this next generation.
In summary, Microsoft sucks because they choose to suck. Every reason that is holding them back is entirely within their control. They are like the 80-old chain smoker on oxygen, dying of cancer, that can’t quit smoking two packs a day. They know it is killing them, but they choose not to do anything about it.
Application Servers are the new Database
In the past decade, enterprise software development has gone through a major paradigm shift. This shift was the introduction of middleware, a.k.a application servers. The objective of the application server was to break the client-server model and move logic into a middle tier where the application logic could be cleanly broken down into discreet, testable layers implemented with object oriented languages. This push to application servers was driven both by the acceptance of object oriented programming and by vendors eager to make boat loads of money selling their middleware to businesses.
One of the side effects of the push to middleware was that databases no longer mattered. The goal of middleware was to abstract out the database. The thinking was that you designed a clean domain model at the middle tier, and various ORM technologies would map that to your database. Developers, in theory, no longer had to be experts in SQL, DDL, stored procedures and indexes. Application servers were going to save us from all this, turning databases into nothing more than data sources.
Another effect of application servers was the introduction of server controls, or widgets, used to help generate HTML views in the MVC pattern. Examples include tag libraries, JSF and JSTL. The application server would generate the entire view and return the complete HTML document to the browser to be rendered to the client. Applications servers were just reinforcing a similar layer of abstraction at the other end of the stack. Browsers were simply windows into the views being generated in the middle tier.
And then came AJAX. Suddenly, through the magic of web services, JavaScript and the XMLHttpRequest object, the browser proved it could be more than a simple rendering engine for HTML documents generated by the application server. The browser itself proved to be a rich application development environment that could be dynamically updated without making expensive round trips to the server to get full HTML documents. This acceptance of the browser as a platform in its own right is causing another paradigm shift that is going to do to middleware what middleware did to the database – render it irrelevant.
The future of web application development will center around JavaScript and the browser, not on application servers. Browsers will make AJAX requests for JSON data back to services, and no one is going to care how those services are provided. In the same way the application server really didn’t care about the underlying database, the next-generation browser application is not going to care how the AJAX request is fulfilled.
Good web applications will still implement clean, layered abstraction via MVC, but it will be implemented in JavaScript at the browser level, not in Java or C# in the middle tier. The ExtJS library is the best example so far of what the future is going to look like. Other possibilities include Adobe’s Flex and Microsoft’s Silverlight, but both these require plug-ins which the pure JavaScript solution doesn’t need.
It is entirely possible that application servers go the way of the dodo, being supplanted by simpler tools which handle AJAX requests. Web servers will serve the basic content (html, js, css) to the browser, which will then make the AJAX requests to populate the model of the application.
A side effect of all this will be the death of XML used for intra-application communication, to be replaced by JSON. This can’t happen soon enough. I have seen way too many applications use XML internally to pass data around. XML web services were designed for tying together heterogeneous processes across system boundaries and are not an efficient protocol to be used inside a homogeneous system. Unfortunately, developers got “high on XML,” which led us to the mess we have today of trying to use XML Web Services for everything. JSON will kill this silliness through its terseness, performance and ease of use within the JavaScript application layer.
Another possible side effect of the marginalization of application servers and middleware is that databases could start to matter again. I would expect that a smart database vendor will implement connectivity directly via JSON, in the same way they provide JDBC or ODBC connectivity today. The browser will send AJAX requests directly to the database server, which will return a JSON-encoded resultset. Expect to see standardization around what the database JSON request/result protocol looks like.