Interface21 Followup

Since the conversation has become public, I think it's only fair to mention that Rod and I had a pleasant and productive chat on Friday about the issues raised in our back-and-forth. He graciously apologized for his tone and I repeated that I had a lot of respect for him.

We're going to look into how I might contribute to Spring and what might be possible in bringing our two companies closer together on common interests.

Rod lived up to his reasonable and knowledgeable reputation, and I'm happy that whatever unintended rancor may have arisen, it is not an obstacle to working together for the benefit of all.

Now where did I put that Kumbayah MP3...

Good things sometimes come to those who sit patiently: Halo 3 review

Having finished Halo 3 a scant few minutes ago -- and having taken yesterday off work in order to play uninterrupted by annoying responsibilities -- I figure this is a great time to write that crappy game review I've always wanted to write. So here goes!

Warning: There be spoilers ahead. If you care, come back here after you get a life.

Go ahead, I'll wait.

Hmm.

Everybody else ready? Let's begin.

I see no real need to start off in the standard review fashion of rehashing the game's history, the previous two entries in the series, or the jaw-dropping amount of money it's going to make. You know all that anyway if you're reading this. If you don't, allow me to summarize for you:

Microsoft buys small game developer, invests tons of money, and game developer creates better-than-average first-person shoot-em-up on Microsoft's somewhat dodgy console, singlehandedly legitimizing its existence.

As I write this, Metacritic has collected 33 "professional" reviews of the game, none of which I have read. As Bioshock did last month, the game is causing these esteemed journalists to soil their pants in the sort of way that would have earned them sound ass-thrashings for their incontinence in high school. I have to agree with Yahtzee's comment on how the insane and ridiculous level of hype for these games eventually backfires when you realize that, well executed and beautiful as they are, after beating them you're still not going to be any more attractive to hot women who currently go out of their way to avoid breathing your stink.

You see, before I say one word about the game I'm already slightly annoyed by it. Whether it's rational or not, it's a bias and therefore should be up front in any review that claims to be objective. On to the real deal.

Visually, Halo 3 is impressive, but not new. On my dying 27" standard definition TV, the water effects are cool, the lighting has gotten better, and the sheen is applied liberally to all surfaces. While many gamers are really excited by these kind of environmental effects, I really don't care that much. The game is what matters. I doubt anyone will be disappointed by what's here, but it's not the Twenty-third Coming (or whatever we're up to for game messiahs). The art direction has again been pushed from Halo 2 as that game did from the first one; new ships, new weapons (though some are redundant, like the fuel rod gun/rocket launcher, and we see far too little of the flamethrower), and what seems like a grim determination to not repeat settings from the previous games.

Halo 1 fans no doubt remember dragging themselves through gray corridor after gray corridor after gray corridor, except sometimes when they were purple. Precious little of this appears in 3, and it's not missed. Yet there are fewer large open spaces than in 2. The number of vehicle segments has been scaled back as well; you only get one go with the Scorpion tank, a couple of brief periods in the super-jetpack Hornet, and a few Warthog outings. Eventually the forced variety and lack of cohesion in the play begins to feel a bit forced, as if the novelty is what you're supposed to care about rather than solid and flexible play.

The story is weaker this time around. Halo 2 offered the innovative device of switching back and forth between the Arbiter's story and the Chief's story. In addition to offering two distinct styles of gameplay, this also helped the story by telling it simultaneously from two viewpoints. One gets a rich view of the Covenant world and mindview through the Arbiter's eyes that the Chief would never have a chance to understand. 3 abandons the switching and tells the story entirely from the Chief's perspective, relegating the Arbiter to an AI NPC that follows you around and basically distracts the big evil from focusing solely on you. It feels unsatisfying to remember how much time was spent creating the Arbiter's character and then see him turned into a walking turret. The final confrontation between the Arbiter and the Prophet of Truth can't help but feel like an anticlimax.

A few other things in the story annoy me. So first Guilty Spark finds you, apologizes, helps you through most of the story, and then suddenly turns on you just before his role in the story has to end? I knew he'd be useless in the story once the new Halo was activated, and so I knew they'd have to get rid of him at some point before that happened. When you get to the control room, the dialogue is so predictable you'll be able to finish their sentences. Apparently they knew they needed Spark to activate the Halo, but didn't bother to find a more believable path in the story. Then there's the Flood. Truth tries to activate the rings, so the Flood help you. The second the rings are off, the Flood turns on you. And who didn't see this coming? The Arbiter and Chief look around, their body language thick with anger at the betrayal. Don't they remember being sent back and forth by Gravemind in Halo 2? Wouldn't they expect some kind of underhanded dealings? Captain Keyes also shows up just in time for her convenient extermination. The plot seems to lurch from point to point without much thought on how to get there.

Finally, I'm glad I sat through the credits to watch the end cinematic. I was all ready to rip Bungie a new one for killing the player offscreen at the end of the game, but they managed to save it by exiling him in the middle of nowhere while setting up the inevitable Halo 4. Regardless, the ending is just unsatisfying in a way that's hard to describe. The war, which began as a struggle against the Covenant, turned into a war against the Prophets, who were then killed, which then turned into a war against the Flood, who were then wiped out. We never get to see the real effect of the war on Earth, nor of the personal toll borne by those who survived. There can't be anyway, since every important character other than the Chief, Cortana, and the Arbiter gets whacked. What's left to care about? Why am I supposed to get teary-eyed when this Lord Hood guy gives a weak Gettysburg Address paraphrase on a dirty hill?

To the next point: The AI is just godawful. Countless times I was manning a turret and gleefully plugging infinite ammo at the bad guys when my own squad would calmly and without hesitation walk directly into my line of fire. Of course I'd cut them down before I could stop firing, so it got to the point where I had to make sure I was shooting over their heads. This was almost always too high to hit the bad guys. At times in the game I saw soldiers jumping on top of boxes or sliding down a hill to get to a battle. So why is it so hard to code them to go around a friendly turret or at least crawl under it? It's not like it's advanced soldering you only learn after five years in the freaking army! Enemies sometimes fly into battle on slow-moving rocket packs, making perfect targets for the sniper rifle. Brutes will drop bubble shields and then walk out of them, making it easy to pick them off. Snipers will give away their positions while still too far away to hit you with any accuracy. Grunts seem not to understand the concept of cover. There were too many lapses to list, and all of them together add up to a constant annoyance during play.

The point about thumbstick control being inferior to the mouse and keyboard has been made before, so I'll just amplify here that it does in fact suck and that the mouse/keyboard is in fact better. The major culprit is just not being able to turn your firing direction fast enough, as well as making it too hard to rotate your view at a comfortable rate. This problem isn't really fixable, so no need to hash it out further, but it does suffer by comparison to the PC.

Finally, the checkpoint/save system, which worked pretty well in the first two games, takes a step back here as well. Most of the time, getting past one knot of enemies or one particularly tricky bit of vehicle maneuvering earns a checkpoint as soon as you're in relative safety; however, there are times when you'll be in near-constant battle for upwards of a minute and make it past one or even two checkpoint positions without the game crediting them to you. At that point you become panicked not because you're being shot at but because if you get ganked by some cheese-rific enemy placement you'll have to fight the entire damn sequence over again. Again, this takes you out of the flow and just pisses you the hell off, especially when you take the same path, aggro 10 less enemies, and are awarded a checkpoint only 30 seconds after your previous one. The inconsistency is maddening.

After all that ripping, did I like the game? Well, yes. It's a solid, if unspectacular, first-person shooter that looks great and offers at least a try at a serious scifi storyline where most other games are happy to get by on violence and tits. It's got more bugs than it should, and the execution is off in some key places, but Halo fans won't be disappointed, and shooter fans will definitely find the good points to outweigh the bad.

But it's definitely not the Forty-second Coming.

**** (4/5)

Open Source FTW!

Wow, I write one little blog and the heavy hitters take notice. First, thanks to all who read and commented. I'll try not to let success go to my head. Second, there are a lot of touchy political things going on in this discussion, and while I don't wish to offend anyone, being honest about my beliefs and my practices is bound to piss someone off. To that person I say "sorry, but I'm famous now". :)

Seriously, there are a couple of things I want to look at.

From Rod's blog, where he paraphrases my support company point into an incorrect metaphor:

Rod claims that dependable car repairs requires trained mechanics. This must come as a surprise to all the non-mechanics employed by every other garage in the world. Someone has to do the sales and run the business and fix the building and keep the website updated and find new customers, etc., etc. Mechanics don't get you any of these, and who's going to tell me they're not required for a successful garage?

As Rod surely knows, car mechanics almost never design or build the cars they are paid to repair. A very small group of designers produce almost all the automobile designs used in the world. The guy at your local Fix-It-Cheap Auto Service doesn't work for Toyota and probably never has, but (assuming he's a competent mechanic) you don't insist that he has to before you trust him to fix your car; he's read the manuals, studied the engine specs, read the latest bulletins and recall notices, and worked on dozens of cars very similar to yours. He fixes your car for a hopefully reasonable price and you're out and happy.

Rod, Juergen, and the other i21 engineers are like the car designers. They decide how Spring should be architected, and then they write code that implements the design they've settled on. While they certainly can support Spring, there's no reason some other engineer (me) can't study the same code and achieve the same level of expertise as far as a customer's support needs require. In my experience, a customer wants their immediate needs met when they open a support case. If we help them fix their problem, they're happy, and if we educate them on how to avoid similar problems in the future, they're very happy. Working with the community to find the best long-term solution that works the best for all Spring users is the second problem and one any good developer is happy to help with.

One thing i21 might look into is having a certified Spring technician program backed up by a rigorous curriculum that makes that really mean something. Toyota certifies mechanics on very strict tests. Cisco, Microsoft, Red Hat, etc., all have similar programs. The companies make money on course and training fees and crank out qualified engineers that spread the mindshare into every corner of every company they serve.

Rod speaks out against companies who, he says, try to make money off open source without fairly compensating the original developers of that code. SourceLabs is not such a company, as our active participation, including committer access, to several projects will show. By implying that these companies are parasites, he makes the fallacious implication that the original developers are always owed a cut of revenue derived from the code. If that's not what he means, it's hard for me to suss out any other interpretation of his statements on this issue. I strongly disagree with this opinion; a true open source project (the FSF term "free software" might even be applicable here) does not belong to any one person or entity, but rather to the community of its users. Rod seems to think that the purpose of Spring is to enrich Interface21; I believe the purpose of Spring is to make developers' lives easier. I make this claim because Spring is licensed under the Apache Software License, which explicitly allows free distribution and even (urk) proprietary forking. If Spring does not truly belong to all of us, then it is mislicensed. If Interface21 honestly feels that Spring belongs to them, they should change the license to reflect that instead of misleadingly claiming to be an open source company.

Finally, Rod claims that SourceLabs has not committed anything back to Spring. I could make the admittedly weak argument that I've personally sent two little tiny patches to the build file which were both accepted, but Rod has also said that valuable contributions to Spring include evangelizing and helping to broaden its community. We have been doing this since the company's inception. I've personally given one of my canned "Spring rocks" speeches to customers, and I've also encouraged other people I know in my professional sphere to use it. Such contributions are valuable not just because Rod says they are but also because they make life easier for everybody using the Java platform, whether they're our customers, i21's, or nobody's.

I'd like to close by offering my help in a professional capacity as a Spring enthusiast with time on his hands to Rod and Interface21. It is explicitly part of my job description to improve Spring however possible. Guys, where can I help? I'm happy to assist with anything you'd like assistance with: code, test cases, documentation, even giving speeches or talks at conferences and venues I visit. My offer is not contingent even on future employment at SourceLabs; I'm volunteering as an open source developer. Have Juergen (or whoever handles this sort of thing for you) drop me a line. I don't want committer access unless and until you've decided I earn it. I don't insist you adopt my patches. I don't insist on helping design the car. But I will help you however you'd like to make Spring better with dedicated time each and every working week.

So how about it? Would you like the help? Let me know.

Nonsense about Interface21

Rod Johnson, a man I respect and admire, has managed to step on one of my hot buttons. He's put up a new blog entry that reiterates his earlier complaint against other companies that offer support or services for Spring. While I agree with some of them, his brush is far too broad for the truth.

Before I start, full disclosure: I work for SourceLabs, a company that offers 24/7 enterprise-level support for Spring as part of a fully integrated and certified Java enterprise software stack. I'm proud of our products and how we've helped our customers.

Rod starts off with this:

OpenLogic needs to understand that the opening comment in Stormy's post that "Developers that work on open source software typically have day jobs that pay pretty well…so they work on open source software for free and write code during the day for big bucks" is largely wrong, understand where the open source software they hope to profit from comes from, partner appropriately, and set a price point that allows for genuine support. An alternative would be to stop claiming to provide enterprise support, and be clear that what is being offered is a kind of on-call development assistance, with no guarantee of being able to resolve critical issues.

Actually, Stormy's not largely wrong. Companies who sponsor open source by hiring its developers are neither a necessary nor sufficient condition for a successful project. The obvious example is Linux, which rapidly evolved into a stable and usable kernel long before the words Red Hat or SUSE entered the conversation. Back then, all Linux developers were far-flung, spare-time volunteers who didn't receive a dime for their work. When the first Linux companies decided to try offering support, there wasn't a "Linux21" company headed by Linus they could negotiate with, and Linus never claimed that he was the way, the truth and the life of Linux support.

Jesus may have said that no one comes to the Father without coming through me, but Linus explicitly disavowed control of the Linux community at a very early stage. He maintains his position through the universal respect of his judgment and that he has demonstrated that he is beholden to no one. Whether he succeeds or fails, he tries to do the best thing for Linux, not whatever company he's working for. Red Hat's Linux support is not somehow delegitimized for lacking an explicit Linus Stamp Of Approval, and neither is Canonical's, Novell's, SUSE's, etc. Plus, aren't those companies making money just fine, and isn't the competition between them good for all Linux users, individual and corporate? One might also mention XenSource, who never claimed to be the only legitimate source of Xen support, and yet recently sold for hundreds of millions of dollars. There are tons of consultants who are expert in Ant, Maven, Zimbra, JSF, etc., who may compete for contracts, but none of them can seriously claim to be the only legitimate option over the others.

Rod claims that dependable support requires committer access to the source code. This must come as a surprise to all the non-engineers employed by every other support company in the world. Someone has to do the sales and run the business and fix the servers and keep the website updated and find new customers, etc., etc. Committer access doesn't get you any of these, and who's going to tell me they're not required for a successful support company?

Good support means that you have a personal relationship with your customer. You know what they need, what other software they're using, what they're most concerned about, and you establish a bond of trust with them that you will be there for them. That goes way beyond giving them a pager number and saying, "Call me if it breaks".

Despite what Rod would have you believe, I (or anybody else) can offer top-quality Spring support thanks to the ASF license Spring uses. You don't need to be a Spring committer to fix bugs in it, and you don't need Interface21's permission or endorsement to use it. If there's a bug that impacts your production server, I can find it in the code myself, talk to the customer, and figure out what the best solution is: patch, workaround, client code change, etc. I can do that because I have access to the source code that matters -- the one the customer is using -- and because I understand, through careful and tedious preparation, what the customer needs.

Moving on, we next have this:

It may seem strange to you, but it's normal for individuals and companies to want a return on investing millions of dollars, passion, blood sweat and tears in something. Interface21 sustains and develops Spring and we do a good job. I think it's perfectly reasonable to expect that we can leverage this investment into an advantage in the support market.

Sure, Rod. You want to sell support for Spring, be my guest. Play up every advantage you can in the market, but it is a market. If you want to argue that control over committers makes you the best support option, go ahead, but as I said above, it's a pretty weak argument.

Authors and thousands of these developers contribute to the success of the project and community through their evangelism. That's an important way of contributing. OpenLogic does not; it merely aims to make money from projects that others have built, evangelized and conveniently maintain and enhance. Now that's a "sweat deal".

OpenLogic may not contribute to the projects they use, but at SourceLabs we do. Our credibility as an open source company depends on it. I'm a committer on the Apache Commons project. We have people in house who have committer access on Struts, Hibernate, and Maven, and we're also involved daily in Tomcat, Axis, and other projects. We have brought Spring into companies because we like working with it, thus increasing mindshare and support for Spring without anyone at Interface21 knowing anything about it or lifting one finger.

No one at Interface21 can seriously claim to be actively engaged with the other pieces of a full Java enterprise stack; Spring, for all its awesomeness, is a framework, not a stack. It doesn't provide everything an enterprise customer needs, and supporting only Spring is not going to cut it with companies who also need help with Hibernate or Struts. In fact, Rod has to say that if you do need help with the other parts of your Java solution, Interface21 can't help you since they don't control the source code of those projects.

It's true that aggregation in and of itself is not worth much. But neither is control of the code. Open source allows everyone to compete on a level ground in whatever arena seems valuable enough to conquer. I hope Interface21 isn't just afraid of a little competition from companies who understand that doing support right is much more complex than having an SVN account.

One final point for Rod: why did you open source Spring at all? If you're so convinced that no one else can offer credible support for it, why not just make it proprietary?