In lieu of a review of Lotusphere 2011, which would likely just repeat much of what many of you have already seen elsewhere, I'd like to explain an upcoming shift in the focus of this blog. While for years I've tried to stay true to the site's title - "Tip of the Iceberg" - by posting primarily a quick look at concepts that I feel have the potential to have a huge impact, rather than attempting to exhaustively illuminate the entirety of each, of late I have observed that the bulk of my posts have arguably centered around a single common theme. This theme, unsurprisingly, mirrors the comparatively recent shift in the nature of my work at GBS. Until midway through Lotusphere, however, I hadn't boiled that theme down to a single acronym; now I have: DIY.

 

The term DIY ("Do It Yourself") is typically applied to home improvement projects, like remodeling your own bathroom without hiring someone else to do it for you, the self-construction of custom electronics, and so forth. Reflection upon how I have spent my time since my last trip to Orlando, and what I have been speaking and writing about during that time, revealed an unmistakeable parallel between my professional focus and some of the principles of the DIY movement.

 

Following last year's conference, I noticed that I was not alone in complaining to IBM that there was no debugger for XPages, but nobody was actually doing anything about it... we were all just waiting for IBM to give us one. So Nathan and I wrote one. And gave it away for free. 8.5.2 broke it (primarily because the way we designed it turned out not to be as forward-compatible as we would have liked), but that will soon change.

 

Since April, literally every line of code I have written at work has been part of an Eclipse plugin or a custom XPage component, or part of a larger product that relies very heavily upon both. This product was originally inspired by an observation that many were complaining about the lack of a rapid and easy way to move to XPages while still leveraging a longstanding investment in previous custom application development, but nobody was doing anything about it. So we did something about it. That something won the CTO award last week.

 

For years, I've heard others complain (and complained myself) about the lack of young attendees at Lotusphere, but every year, nobody did anything about it. So, while I personally had nothing to do with the "GROUP College" initiative, I was extremely proud last Monday to be a part of the organization that facilitated the attendance of 500 college students for the first full day of the conference. Time will tell whether the phrase on the shirt each of them was wearing - "the future of Lotus" - turns out to be true, but at least somebody finally did something, instead of just complaining and waiting for someone else to take the initiative.

 

Should IBM have done each of these things for us? Maybe. But what kind of "partner" would we be if we didn't meet them halfway? If all we did was stand off to the side and tell them what to do, then bash them for not doing it fast enough, we're not a partner... just a critic.

 

An old adage states that, "if you want something done right, do it yourself". I disagree. If IBM were to release their own debugger for XPages, for example, I have little doubt that it would be superior to what we created with Medusa. Additionally, that adage flies in the face of the focus of our Experts division (of which I was, until April, a member), demonstrably one of the best Lotus-centric consulting teams on the planet. Closer to the truth, in my opinion, is: "if you want something done on your own terms, do it yourself". Nathan occasionally reminds us in the office that another common saying does not apply to us: "you can have it good, fast, or cheap, but you can only pick two". In our organization, individual and collective standards dictate that, if we're going to do it, "good" is mandatory, so the only variables available for negotiation are "fast" or "cheap". Hence, if a customer wants fast and cheap at the expense of good, those are terms that dictate that the customer should probably just do it themselves. 

 

When dealing with IBM, fast is often simply not an option. They are well aware of this, and in recent years have taken significant steps - at least, as far as Notes and Domino are concerned - to empower us to bridge the gap between our desire for a given feature or fix and the timeframe in which they will be able to implement it. The two most significant, in my opinion, are the porting of the Notes client and Domino Designer to Eclipse (allowing us to write plugins that implement features we wish were already part of the product) and the addition of the Extensibility API to the XPage runtime framework (allowing us to write custom components that we wish were already part of the product). In the latter example, this is bolstered by the open source Extension Library, which not only shows us powerful examples of how to extend the platform, but provides us useful, functional extensions to the product that (in most cases) will eventually become part of the core product... but IBM has chosen to make them available to us now, instead of having to wait to use them until they have gone through the rigorous process necessary for making them officially supported features of the platform.

 

Even this has been spun to somehow be a net negative: IBM is too lazy to implement what we want, so they spend all their time turning the platform into an avenue for others to do their job for them. But despite what Microsoft's marketing team would have us believe, Domino still has a very large customer base. IBM has a huge amount of people to keep happy. In, like, 73 languages. If they constantly tried to cater to every blogger's personal preferences, how stable would the platform be? How rapidly would it advance? And how many end users without heavily trafficked blogs would they piss off in the process? Wouldn't it be better if we proved ourselves to be the cream of the crop that we'd like our readers to believe we are by contributing actual solutions instead of just bitching?

 

For the record, I cut admins a lot of slack in this area. For instance, there's precious little that Marie Scott can do about the stability of Domino's IMAP stack. She doesn't have the option of just fixing it herself. All she can do is keep that issue on IBM's radar until they do something about it, and she has been quite diligent in raising awareness of the need for something to change. Besides, she and Tom Duff did something that most of us only bitch about: there aren't enough books about Lotus products, so they actually wrote one (BTW: in the coming weeks, you'll be hearing about another book that's in the works... one that I'll be co-authoring). But, again, in general I don't mind admins complaining about missing features or stability issues: IBM needs to address those for them. But those of us who are developers that have individual pet peeves frequently have the power to address those pet peeves ourselves, and very few of us do.

 

In that vein, I'd specifically like to call attention to one member of our community for whom I harbor an enormous amount of respect: Declan Lynch. When XPages first hit the scene two years ago, he didn't cling to the old ways of doing things, or mock those who were excited about the biggest evolution in Domino development in a decade. He dove right in and explored the new features... and took us along for the ride, composing what remains to this day the most epic saga freely available on the journey of learning XPage development. With his excellent OpenNTF projects xTalk, fileSendr, and the new version of Blogsphere, he's provided the community functional examples of some of the amazing things that XPages can do that were difficult, hacktastic, or just plain impossible in previous versions of Domino.

 

While I'm on the topic of Declan's involvement with OpenNTF, I'd like to specifically call attention to something that I feel, in retrospect, I responded to poorly last year. As OpenNTF was making changes to how donated source code was stored and distributed, primarily in an attempt to shield project authors, project consumers, and the site itself from potential litigation due to unclear licensing terms, Declan identified something about their proposed implementation that he didn't like. So he got all up in their grill about it. At the time, I viewed his response purely as counter-productive negativity. That couldn't have been further from the truth. He had constructive, tangible, and feasible suggestions to offer. So OpenNTF made some changes in an attempt to address his concerns. Was the implementation of those changes perfect? Maybe not. But Declan single-handedly prompted that change of direction by contributing feedback that wasn't just bitching: he offered a specific suggestion for what should change. I respect that.

 

Events of recent months have brought into sharp focus for me the gaping void between that approach to dissatisfaction and the decision to simply criticize with nothing constructive or useful to offer. As previously mentioned, there aren't enough books about Lotus products; how many have you written? Not enough young people know about Domino; how many have you introduced to the platform or brought to Lotusphere? Too many people think Notes is ugly; how many have you shown the current version, or an application that exemplifies how beautiful a Notes app can be? Designer doesn't include every feature we wish it did; how many have you added by writing plugins to implement those missing features? Similarly, the core XPage runtime doesn't include every component that would be useful in a Domino application; how many of those missing components have you developed?

 

This theme was the entire reason I asked Maureen to co-present with me. It drives everything I do at GBS. And, while I hope this post doesn't rescind my status as "the only nice guy at GROUP" (yes, for those of you participating in the group chat that has of late devolved into a "let's bitch about GROUP" chat, you do have a mole... but I'm not going to Valerie Plame him), I will not apologize for any success that our organization may occasionally experience as a result of taking the initiative to do what others just bitch about. I'm proud of the contributions we've already made due to our management's willingness to invest in our "so crazy it just might work" ideas. I'm proud of the contributions I personally make to our own products and, hopefully, even IBM's products. Even if you resent the success of our organization and, by extension, resent me for being a member of it, I will not apologize for making a personal, and repeated, decision to stop bitching and start doing. Yes, for those of you who saw a few people wearing that shirt last week, it was my idea. As this post has no doubt by now made clear, I am extremely passionate about this.

 

But make no mistake: I am not telling you what to do. A previous paragraph contained question marks and not exclamation points for a reason. Your response to any dissatisfaction you might have is entirely your decision and there is nothing I can do to influence that decision. The purpose of this post has been to explain why you're likely to see me using #DIY frequently as a tag - both on blog posts and on tweets. So if I start to post examples of how to tweak Designer to make it do what I want it to do, I'm going to tag those posts #DIY. Similarly, if I continue to post examples of writing custom XPage components that I feel provide features that are missing from the core XPage runtime, from now on, I'm going to tag those posts #DIY. And... if I see a tweet asking why some open source project is missing some feature, and my response is: "it's open source #DIY"... now you know why.