Friday, August 7, 2009

A critique of an open-source software critique, or why OSS can be awesome

It's been years since I've written a critique that anyone but myself has had the (perhaps unfortunate) opportunity to read, but this particular entry - - just begged me for it.

For full disclosure - my bias here about open-source software (OSS) should be noted. I run Ubuntu on my work computer with all sorts of OSS and freeware installed (OpenOffice, the GIMP, Inkscape, FF, NXServer+NXClient, etc.). I also posses a custom-built (by me) machine with Windows 2000 Pro, MS Office, Visual Studio, and Adobe Photoshop. I do work almost entirely from my Ubuntu machine, heavily use the wonderfully free Google Docs for interaction with clients, and have not run into any problems that have hindered my productivity. I daresay that my Windows 2000 Pro machine is also very stable, and I can be just as productive on it when I work from home.

So in short, I am totally thrilled with the state of OSS; some, probably a lot of it sucks, so I just don't use it. Same reason I never bought Neverwinter Nights 2.... But I have my biases, as does everyone, and now you know them!

OK - back to the article. I'll start with the positive - there are definitely one or two sound tidbits. I certainly agree that Apple makes a product that is becoming far more desirable than the Microsoft + Dell/HP/whoever model, so long as there's enough money in the bank to afford one.

Also, I do agree with the basic premise that commodities developed without any motivation for making it good, will - in most cases - suffer from being not-good.

However, overall, the article's argument is not sound - it is not the case that open-source software programmers suffer from an inherent lack of motivation, necessarily resulting in a sucky product. Less rooted in logical critique, I also found it annoying that before presenting the primary argument, the article defames open-source software with a smattering of ad hominem attacks (more on this later). I mean, great political technique but come on, it's not like we should all try to argue the same way Fox News reports.

SO ... on the surface, a lot of the points do pass validity checks:

a. Good software is "well thought-out, and easy-to-use, and easy-to-install, and highly efficient, and bug free."
b. Open source software is "painful to use" and "incontrovertibly, a total usability clusterfuck."
c. Therefore, open source software fails to be easy-to-use, so it is not good.

OK, so now we need to know why open source software fails to be usable. Gladly, there is some language to back this up.

a. Programmers, left to their own devices, are lazy, both in terms of creating efficient software efficiently, and not wanting to do extra work that does not make their software more efficient.
b. Programmers, primarily care about creating an "underlying, beautiful implementation," and on their own are unmotivated - as it follows from a. - to make intuitive, usable UIs.
c. Companies need to make usable, bug-free software so people will buy and use it, and so less money will need to be put into maintenance.
d. A company employs these lazy programmers and uses a salary (and probably pushy managers) as motivation to create usable, bug-free software.

e. (a. and b. restated more simply) Without motivation, the programmer will develop unusable software.
f. Since a programmer who makes open-source software lacks corporate-provided motivation, and since we've already established b., he will therefore create unusable software.
g. From f. we can conclude that Open-source software is developed without proper motivation and is consequently unusable. And the suck.

I just have to question the premises a., b. and consequently f. It's hard to argue over a. as aside from just disagreeing (which I do) and being a bit offended (I'm not that lazy), neither of us has statistical proof, so I'll just leave it be. There are possibly certain truths to b., but it might moreso be that a good amount of programmers are unable to create intuitive UIs because it's hard. I don't know for sure - an HCI person might have answers.

But I can certainly attack f. by proposing alternative motivations. There are certainly other reasons a programmer would be motivated to create a great, usable UI - hubris, for example? How many cocky programmers do you know? Or perhaps they simply want to take pride in their work, and expect a windfall from the product that is not immediately monetary in nature. Maybe they'll pull a Google, release massive amounts of open-source and freely available software, and slowly gain possession of the world's information and trust until they assimilate us all into Google-Borgs. Motivation enough for ya?

So I do agree in principle to e., that an unmotivated developer would be likely to cut corners, and the end product would suffer. But an unmotivated producer of any commodity will probably develop a pretty sucky product, and it is not the case that all open-source software suffers from an implicit lack of motivation. So throwing the baby out with the bathwater because it's not immediately monetizable is just short-sighted.

OK - now for some more fun, let's pick through all of the slander in the opening argument and try to find some meat:

a. The means of business entities with successful ends infers the "goodness" of the mean.
b. Open source software is not used by successful business entities - that "I can point to" - as a means to their end.
c. Therefore, open source software lacks "goodness".

Phew - who sees validity or non-questionable premises in that?

It does not follow that if a business is successful and uses product X, that a business that uses product Y will not be successful. If there was some data presented that showed the statistical significance of unsuccessful companies running on open-source software vs. successful companies running closed-source software, perhaps this would be acceptable. Instead, the validity of the argument simply runs out of steam after "I don't know of any successful companies that use open-source software."

OK so this wasn't a ridiculously rigorous academic analysis but I think I hit a few good points, and if I missed something by all means, critique me! And if you made it all the way down here, thanks for getting through it, and be sure to let me know what you think.

Friday, June 19, 2009

GWT / AJAX Performance Tools

Performance is important in your Web applications, especially in your client code. If you're a GWT user, I wanted to highlight a particularly useful benchmarking library - Jiffy and it's Firebug counterpart. It is the case that Safari's developer tools and Firebug by itself make user-injected benchmarking code less relevant for macro-benchmarks. But, if you're interested in fine-grained measurements and creating a rolling log of them, I found the developer tools a bit lacking.

Benchmarking is really just about specifying two points - a start and a stop. Giving that benchmark a label can be useful, and being able to review logs of these benchmarks over time would also be nice. Jiffy does all of this, with minimal setup time, and if you install the Firebug plugin, very immediate results.

First I downloaded the jiffy.js source and plugged this script tag into the HEAD of my GWT application's main HTML page:

script language="javascript" type="text/javascript" src="jiffy.js"

Then I created this simple class to wrap the required Jiffy calls as Java methods:

public class JiffyUtils {
public native static void mark(String markerName) /*-{
if( $wnd.Jiffy )

public native static void measure(String measurementName, String markerName) /*-{
if( $wnd.Jiffy )
$wnd.Jiffy.measure(measurementName, markerName);

...and I was ready to go! I inserted numerous marks and measures into a particularly slow, esoteric series of operations and determined where my bottlenecks were; oddly enough, it lead me to the discovery of the slowness of HashMaps in GWT 1.4 and, to a lesser extent, in 1.5 (Google for "HashMap optimizations gwt" for a bit more info.

Turns out I didn't need continual performance measurements, but Jiffy does offer a bunch of support for it. You can either get a JSON object out of Jiffy with all of your measurements by wrapping a call to
in a JSNI method, which I used momentarily but did not rely upon heavily. You can also use the Jiffy Batch and Realtime logging, which is explained on their site and would be useful for those interested in maintaining backlogs of their performance metrics for analysis.

Wednesday, April 8, 2009

GWT 1.6! Has it been that long...?

Google had some rather sizable announcements yesterday afternoon - the launch of GWT 1.6, Java support for App Engine, and an Eclipse plug-in for better integration with these two products.

App Engine had been a small pain to develop in all of its Python-y goodness, but is a fantastic platform in theory, and will definitely yield a result after jiggling enough bugs off of the farm. It's good to see the chains coming off, and it will be fun to watch it continue to evolve.

More important (to me, at least!), GWT 1.6 boasts performance benefits (parallel compilation is wicked fast on multicore boxes ... just pass the compiler the -localWorkers flag and you no longer have to wait 8 minutes for your app to build!), slicker Widgets, and a nifty new Event handling model. Do watch out - if suddenly your events aren't being fired after an upgrade, make sure if you've overriden the onBrowserEvent method you invoke super.onBrowserEvent(...) - that's where the default Event handling happens! The WAR-based implementation is probably cool, but I haven't taken advantage of it at all (RESTlet is my friend), so let me know what you all come across!

For more details, check out their blog.

...and now, back to your regularly-scheduled life...