For those of you who have been following ThinWire, you have probably noticed that the framework has been receiving limited attention for a while now, and I want to take a few minutes to discuss why this is so that people are not left guessing.

The other thing I want to touch on is what the frameworks future will likely be and to ask if there are developers who might be interested in joining the project to help establish the future of the framework.

Where We’re At Currently

First, let me talk about the delays in development/releases. Part of the delay has been a result of backward compatibility testing that’s been going on by Custom Credit Systems (the company backing ThinWire) to make sure that the latest builds work correctly with the existing applications they have deployed with their customers. And since CCS’s customers are top U.S. banks, they tend to have a very rigorous testing process that spans months.

However, I’m not going to try and convince you that’s the only reason for the delays in ThinWire development. The other, more important, reason is that both CCS and I have been discussing various options for ThinWire’s futureĀ over the last six months. It was just about six months ago that I decided to leave CCS to consider other options. I won’t bore with you some run-on about why I left; it’s suffice to say that CCS is a good company and I just wanted to try other things since I’d been working for them for over 7yrs.

Where does this leave ThinWire? Well, I’m the lead developer who started the project back in early 2003 (it was an internal CCS project then) and while there has been help from others along the way, most notably the bright guy Ted C. Howard, there really hasn’t been any other developer working on the framework since it’s inception. Granted, there have been bug fixes from CCS and other community members, but generally, it’s been a one or two man show for most of it’s life.

So when I decided to leave, CCS and I had to sit down and figure out what was going to happen with ThinWire as a whole. In the beginning we started down the path of creating a new company dedicated to ThinWire that I would be in charge of and that CCS would only oversee from a distance. This idea worked on paper, but as time drew on three things became apparent:

  1. There are legal issues with who owns the codebase and the ThinWire trademark, as well as what the operational guidelines for this new company would be. Now, it’s easy to just squawk at such statements and say… What do you mean, this thing is open source!?!?! But in order to be competitive in the market, the new ThinWire company would have to have the ability to commercially license the code to others, which it could not do with the opensource LGPL code. Additionally, just because the code is open-sourced, doesn’t mean that you have the right to use the ThinWire(R) name. The same holds true for many open-source projects.. heck, even the term “Open Source” is trademarked. That’s just the way things work in the business world. This means that the new company would need ownership of the codebase and trademark in order to control it’s own destiny and it turns out that ironing out all the issues that brings up is not as easy as you may think.
  2. Unlike many other open-source projects, ThinWire is smack in the middle of the largest development paradigm shift since the internet came on to the scene 15+ years ago. Before Ajax it was possible that the web would be the primary platform of the future. Now it’s unquestionable. By utilizing the various techniques championed by Ajax, it’s possible to entirely replace all but the most resource intensive desktop applications and to do so while providing the user with a BETTER experience, not a watered down experience like you got with old school Web applications. So what does this mean with regards to ThinWire? Well, it means that the market is insanely competitive. Everyone knows this technology is the future, so everyone wants to own as much of it as they possibly can. And when market conditions are like that, it’s very difficult for a 1 1/2 person gig with no funding and no major company backing to get noticed or make much more than a dent regardless of how much effort is put in:
    2.2 Million USD, 39 person years
  3. For a number of developers, ThinWire doesn’t fit the definition of Ajax or Web 2.0 development:
    1. First, it’s built on a proprietary component model similar but not identical to Swing or JSF. Swing’s API is not designed for web development and when ThinWire was started, JSF was just a twinkle in Craig McClanahan’s eye and it most certainly was not taking an Ajax-driven model into account. IMO, to this day it tries to straddle too much and therefore collapses in it’s own weight. But that’s besides the point. CCS and I spoke with a few people from Sun early on (2004) to see if they had any interest in taking on ThinWire, but they pretty much said… if it ain’t JSF, then we aren’t interested. Sun could have been an industry leader and beaten Google to the Ajax punch.
    2. Then you have the fact that ThinWire is meant to be like Visual Basic for web development, which seems to be about the worst thing you could say about any web framework. However, ThinWire is all about allowing developers to craft web applications as quickly as possible… not as sexily as possible. And stability and memory footprint are much higher on the priority list for big banking applications then spiffy Fisheye widgets, transparencies or animations. Unfortunately, boring business applications don’t exactly get the blood of most developers sizzling :) Most developers look and think: it’s server-side, it looks like a desktop app, it’s Java (oh the humanity), therefore it can’t be cool! Sure, it’s not the kind of framework you want to build your next Facebook killer on, but that doesn’t mean it’s not the most appropriate solution for back office applications. As always, it’s about using the right tool for the job.

How You Can Help

Don’t take my “State of the Framework” as some kind of death sentence for ThinWire, because it’s not. The framework has a lot to offer developers in it’s current state and both CCS and other developers will continue to use it for years to come. However, if you and/or other developers are willing to help by joining the project and doing one of the following listed below, then there can be an active and bright future for the framework:

  1. Implementing some of the features from the rather extensive feature request list.
  2. Help find and fix the known bugs.
  3. Add javadoc documenation to the sourcecode or write tutorials of your own.

So, please, if you want to join, shoot me an email: josh at truecode dot org. I’m going to be trying to add 5-10 developers/contributors that are willing to take an active interest in pushing forward. I will still be involved and help as much as I can, but like so many other open source hackers, I’ve got other things going on that I have to attend to as well.

The Near-Term Future

To wrap things up, I’m am still working with CCS to persuade them to open the framework further, ideally under a BSD license. My goal in doing this is that it would free the codebase for any and all use and would ease the difficulty of managing code committers since there wouldn’t be any “who owns what code” issue to contend with. Under a BSD style license, all code would be owned by everyone… and even if you simply want to grab a small piece of the framework to include in your work, you’d have no trouble doing so. I believe this approach is the best option for the benefit of the community and everyone involved. If you have some thoughts you’d like to share on all this, either send me an email at: josh at truecode dot org, or add a comment to this post.

Thanks Again.