The Graph Revolution from ics.ug and engage.ug

Over the next few weeks, I’m going to be putting together a short film tribute (about 5 minutes) to Lotusphere through the years. I’m working now on the soundtrack, but I need help curating the significant number of photo images I need to assemble for the video (300-350 pictures)

If you have or know of a great library of Lotusphere pictures through the years, please share in the comments. If you’re willing to be one of the 5-10 people I’m hoping will volunteer to comb through these libraries looking for certain images, please let me know in the comments, too! Volunteers will be expected to keep the brief and their assignments confidential until the video is published. 🙂

Thanks, I look forward to hearing from you!

Plenty of people are talking about the bittersweet celebration that was IBM ConnectED 2015 in Orlando this past week. I agree that in many ways, this was the best Lotusphere ever, as the attendees were focused on making the most out of an event that will likely never be again. IBM was much less overbearing than in the past, focusing on Verse and Bluemix without the kind of announcement-gavage we used to choke on all week. Customers and partners were serious about making plans and taking action, as opposed to the casual introductions-leading-nowhere conversations in prior years. The smaller, integrated showcase saw a huge jump in traffic. (I actually regretted not having a booth, as the TechnOasis was always packed.)

Hatchets were even buried.

It was a great conference.

There’s also been a lot of talk about what happens next. I wanted to share a few thoughts I’ve had about 2016 and how to make it even better. In no particular order…

Take the Reins: The community around the ICS products has demonstrated increasing independence from IBM over the last 5 years as Big Blue’s delivery has declined and customers are looking for new solutions. This is even reflected in conferences, with events like Engage and MWLUG popping up all over the world, offering high-quality experiences on tiny budgets. The people that run these events have shown great capacity for it. Let’s leverage that and get more UG runners involved in whatever happens next year, possibly including a Global User Group conference of some kind. IBM can be a platinum sponsor if they want.

Simplify the Content: The ATLUG group held our Day of Champions last April where we did a single track of 20 minute session by well-known, seasoned presenters. It was fantastic. Nobody put any code on the screen. The content was about vision, inspiration, principles, and poetry, not feature lists and install procedures. With this approach, the conference could have fewer tracks and therefore fewer schedule conflicts. I did a 1 hour session at DanNotes on the graph2 Tinkerpop implementation from the OpenNTF Domino API. I presented the same vision in 5 minutes at SpeedGeeking. The DanNotes audience was enthusiastic but felt like they needed to learn more about the “how.” The SpeedGeeking audience said exactly the same thing. More time did not achieve better understanding.

Support the Interaction: One of the biggest reasons to go to Lotusphere is because the attendees and presenters are the best of the best.  There’s always some expert walking past you in the halls or chatting at a nearby table. And while this spontaneity is great, it’s something of an all-or-nothing proposition. Either you have some kind of session, or you have some kind of booth, or you can hunch together over a laptop on bench and try to read source code and look at tiny icons. How about a middle ground of scattered tables of varying sizes with monitors. along with a few ad-hoc meeting rooms with presentation screens that can be reserved or simply “use if open?” Coupled with shorter sessions, this could be a great way to expose a large audience to a conceptual message as a whole, and then do one or more follow up deep dives in a more on-demand fashion. Bonus points if the tables & screens have some kind of automatic topic publication to a shared system when you sit down.

Change the Venue: Lotusphere is not about the technology, it’s not about the brand, it’s not about the Swan & Dolphin; it’s about the people.  While this venue may have been great conference hosts in 1995, today they are a Motel 6 at Ritz-Carlton prices. The rooms are tiny and ugly and have smelly carpet and bathrooms without doors at $270/night. The layouts are confusing and poorly-spaced (serving meals in the Dolphin while the sessions were in the Swan was a slap in the face.) The bars and restaurants are priced for pro-athletes and bankers on expense accounts, not IT professionals. More and more people have to stay off-site to be able to afford to attend, and that means more exhausted and possibly drunk attendees getting behind the wheel to get to and from events. It doesn’t have to be Vegas; it doesn’t even have to be in North America — but it needs to be some place where the experience matches the price.

Go Mobile; Go Social: Everything about the event should be paperless. Attendees should be able to find each other, plan sessions, set up meetings, invite friends for drinks, check schedules, swap contact details, and split bar tabs from a conference-sponsored mobile platform. This kind of anywhere, any time digital collaboration is what the conference is supposed to be about, and it needs high-quality tech to support it. We shouldn’t be getting conference booklets in the age of the iPhone and we don’t need a slight rebrand on an existing product.

As always, I hope readers will take time to comment.

I am delighted to share that I have again been selected for the IBM Champions program. I was an IBM Champion in 2011, and I quite enjoyed the increased access to IBM engineers and executives that came as a result. Unfortunately, I wasn’t very participatory in the program itself.

I’m hoping to change that this year by getting more involved with IBM’s initiatives in this program. And the very first instance of that will be at ConnectED 2015. I hadn’t decided for sure whether to attend, but having the honor of being a Champion means that I will definitely go and hopefully share some great ideas (and drinks) with the community.

Congratulations to the class of 2015. I’m pleased to note that the OpenNTF.org Board of Directors has 6 IBM Champions on it now!

My old blog is now available at http://avatar.red-pill.mobi/nathan/escape.nsf

All entries have comments disabled. But if you have feedback about anything there, you can leave a comment here and I’ll be notified.

Thanks!

While working on some code this morning, I played some videos of Jonathan Ive talking about Apple’s design process (h/t vowe) and it got me thinking about how certain recent experiences have been interconnected. I thought it might be interesting to share these thoughts regarding:

1. Guiding my kids through disputes
2. Disengaging from Twitter
3. Domino SSL concerns

As father to a 5 year old and a 3 year old, one of my most important missions is to ensure my kids have empathy. We’ve had many long conversations about imagining how other people feel and how you might feel in their situation, especially when in conflict. This has tremendous value in keeping a peaceful and trusting household, as we can share very complex concerns with only a few words. We can instantly reset volatile situations by saying something like “Meta, I’m feeling ignored” or “Axiom, how would you feel if…” Watching this sense develop in them is amazing, especially as they start achieving self-empathy, and demand better relationships with their friends.

How does this relate to the Apple design process? Good design is all about having empathy for your users; asking yourself “how will someone feel when they experience this and how can we make that feeling ever more enjoyable?” When you listen to Ive talk about his first experience with a Mac, he points out that bad design makes users feel inadequate to the device. It’s a marvelous insight that requires deep empathy with both his past self and his future customers. When Ive talks about specific designs, he goes into detail about unseen parts of devices that might only be experienced on a subconscious level and that nevertheless are hugely important.

In stark contrast, we have Twitter. I started using Twitter again at MWLUG, hopeful that my experience might be different from last time. Eventually, my experience became the same as before: tweets are a medium utterly lacking in empathy, because you can’t express the subtleties and nuances of human emotion in 140 characters. It’s fine for the sharing of *information* but it’s horrendous for the sharing of *meaning*. Conversations devolve into snark because the medium itself doesn’t allow for explanation and reasoning, only conclusions. In some ways, it’s the perfect mechanism for viciousness. And it’s brilliant at erasing self-empathy, too, as people internalize every tweet as if they were the subject of whatever was said.

So where does Domino SSL fit into all this? In the delicate realm of corporate communication, empathy remains a rare and precious quality. Not surprisingly, Apple is very good at empathy in their communications. IBM, not so much. While people have asked for years for an update to the SSL stack on Domino, recent changes in certificate vendor policies have brought urgency to the matter and many people have begged, pleaded, demanded and cajoled IBM for a reply. The outcome has been almost complete silence for two months, with only a single sentence response from the very-brilliant-but-also-very-non-executive Dave Kern (one that I note fits quite comfortably into a tweet,) that IBM is formulating it’s reply. And this simply reflects that IBM, as an organization, lacks the practice of looking at the experience from the perspective of their customers and partners. If they did, they would see that the experience is fear that since IBM doesn’t care enough about customers and partners to provide a plan of action, they might not care enough to take action either.

None of this is to claim that I practice perfect empathy either. I have a long history of unempathetic communication, but since becoming a father and an entrepreneur, I’m working hard to change that.

Do you practice empathy in your relationships?

Paul’s remarks today about why companies should use open source software were met with a response from Ben about why open source should be used with caution. Not surprisingly, both make great points, but the exchange also prods me to finally write something I’ve wanted to publish for a while, going back to a conversation from last year that perpetuated a number of mistaken ideas about open source software. So here, from a Notes/Domino perspective, is the truth about the most popular myths about open source (in no particular order):

1) Myth: Open source software is poor quality. There are tens of thousands of bugs reported in Bugzilla sites for Firefox and Eclipse. The recent Heartbleed vulnerability shows that open source can’t be trusted for quality.

Truth: The quality of software has almost nothing to do whether its open source or not. The difference between Firefox and Internet Explorer, or Eclipse and Windows, is that you can see what bugs have been reported on open source software. You have no idea what bugs have been reported for proprietary software. And when a bug with the severity of Heartbleed is discovered in an open platform, there are tens of thousands of developers and organizations all over the world that can analyze it and publish a solution. When a vulnerability is discovered in Oracle Database, there is one vendor on the entire globe that can solve it.

2) Myth: Open source software isn’t well-maintained. A quick scan of checkins at SourceForge.net or OpenNTF.org shows tons of projects that have been abandoned by their authors. There’s no telling whether code that you commit to will ever see another version.

Truth: While it is certainly true that you can find open software that hasn’t been updated in a long time, there are many excellent open packages that are actively and frequently updated by the project contributors. Public open source repositories make this easy to check, especially with sites like GitHub, where you can look at frequency and size of commits on any branch and on any fork. Of course, proprietary software doesn’t afford any protection from this problem, either. In fact, entire websites like Macrumors.com have been devoted to reading the vendor tea leaves to guess when new versions will be available and what features and fixes will be included.

3) Myth: Open source software leaves us vulnerable to lawsuits. Companies that use open source get sued by proprietary software vendors because the open source code is often copied or stolen from private software companies.

Truth: If you go to SourceForge or BitBucket and just download a random project, there absolutely is a risk of finding illegally reused code. However open source groups like Apache, Eclipse, the Linux Foundation, Dojo and even OpenNTF employ specific processes and legal staff to perform “code clearance” that verifies that all contributors are legally entitled to contribute and that proprietary code is not reused in open source projects. These clearances are vital because so many proprietary vendors are also redistributing open source code and cannot leave themselves open to lawsuits. IBM spent $100 million successfully defending itself against such claims from SCO and has since set the standard for code clearance in the industry.

4) Myth: Open source software is written by students and amateurs. Professional software engineers work for big software vendors and get paid to put real innovation into proprietary platforms. Open source is what newbies do to pad their resumes.

Truth: If you’re calling John Carmack and Linus Torvalds amateurs, you need to quit your IT job and consider a career in custodial services. Most open software is written by career professionals, many of whom are employed by companies like Red Hat, Google, IBM, Oracle, SAP, Facebook, Twitter and yes, Microsoft. In the IBM Notes/Domino community, most open source is written by either IBMers or IBM Champions. And while many of them enjoy the nonstop stream of groupies and free beer that come with being open source contributors, most of them do it because they are addressing their own business needs in the process.

And yes, I’m kidding about the beer and groupies. Unless you’re providing them, in which case it is TOTALLY NORMAL AND WE ARE VERY GRATEFUL.

5) Myth: It is our policy not to use open source software.

Truth: You might think this is your policy. But if it is your policy, it has about as much to do with your business operations as The Lord of the Rings has to do with global politics. It is impossible not to use open source software in today’s IT. If you use Linux or Firefox or Java or Chrome or Android or MacOS or iOS or Oracle or any IBM product or any web server or any web site or any modern router, firewall, VPN, SIP gateway, VOIP system, or even lease a car built in the last 3 years, then you are using open source software. You can’t NOT use open software in the modern world because even the most proprietary, closed, opaque platforms include some open components in them, because these vendors understand that reusing open software maximizes their return.

6) Myth: Open source software has nefarious code from hackers, criminals and spies. They put in secret backdoors so they can break into the systems of people who don’t understand the importance of security.

Truth: It’s certainly possible that any given open source project might contain malicious code intended to compromise your systems. Of course, it’s also possible that any given proprietary software might contain similar code. In fact, as we know from whistleblowers, it’s quite certain that Microsoft, Google, Apple, Yahoo, Facebook and any other number of proprietary vendors are forced to provide backdoors to government agencies and are legally forbidden from telling anyone that they did it. The advantage of open source is that you can see for yourself when the backdoor is left open.

7) Myth: We can’t get support for open source software. If we use it and something goes wrong, there’s no one to hold accountable and no one to give us a fix. A bunch of kids can’t be counted on to fix bugs in a timely fashion.

Truth: Every major software vendor on the planet sells support & maintenance services on software that includes open source. Companies like Red Hat, Sencha, and Ubuntu have built global enterprises on open software. Even for relatively small projects, open source contributors are frequently willing to sell support contracts for software they maintain. And of course, using proprietary software is no guarantee that a vendor will continue to support any given product, version or feature. Customers are constantly forced by vendors to perform expensive upgrades to continue to receive support for mission critical software.

8) Myth: Using open source will invalidate our vendor support agreements. If we use OpenNTF projects on our Domino servers, when we call IBM support they will just hang up on us. We need to have full support from IBM for our systems.

Truth: This is not an open source issue. If you count on a vendor to provide support for a commercial product, that vendor will not provide support for any third-party product that they didn’t provide to you, whether open or closed. You can’t call Microsoft for support on Gimp when you’re running on Windows, but neither can you call for support on Adobe Photoshop. You can’t call Microsoft to report a problem on your Windows-based IBM Domino server. More importantly, you also can’t call for support on first-party products either. If you write your own Windows program, or your own Notes application, or your own Java application, you can’t get Microsoft or IBM or Oracle to provide you with service level agreements on your own code.

But even if you could, so what? What does support from a commercial vendor on closed software actually mean? It means that, if you can convince them to admit that the problem is indeed theirs, then they have complete discretion on whether to do anything about it. And if they choose to do something about it, then they have complete discretion on when they make the solution available to you, and whether it actually addresses your needs. And even if it’s available to you and it addresses your needs, you still have to evaluate and deploy it to your entire infrastructure. If it fails your testing, then you’re back to step 1 with your vendor. If you’re very lucky or very rich, this might only take 5 or 6 years.

9) Myth: Open sourcing some software means a vendor has forfeited ownership of it. Once a company like IBM or Google or SAP licenses some software under open source, then they no longer control it or support it and it’s left to customers to fend for themselves.

Truth: Major software vendors contribute code under open source all the time without giving up ownership. In fact, open source licenses must specifically claim ownership in order to be valid. It is only by asserting ownership that any party can say “here are the conditions for use of this code,” even if the conditions are “do whatever you want.”

Open sourcing software is a way for vendors to gain wider adoption, spread testing responsibilities, and invite customer participation in a given package. It often increases the user and revenue base of an otherwise fledgling or diminishing product. Eclipse, Android, OpenOffice, Fedora and Java are all great examples of commercial platforms that exploded in adoption and in quality when they were open sourced. Relicensing a product is simply a way of empowering users, and thus strengthening the commitment to customer success.

10) Myth: Open source is for ideologues. We run a business. The bad business practice of giving away free stuff is economically foolish and the people that do it are closet communists.

Truth: Open source is great for bottom-line ROI, provided that your business is not based on extorting customers by holding their business hostage. Since open source turns every user into a potential tester and developer, it creates enormous opportunity to spread R&D costs across entire ecosystems of adoption, rather than concentrate them in one specific firm. Since software has zero marginal cost to distribute, capital investment in fixes and features are the only real costs, so spreading those out among many firms can dramatically reduce risks. When the software is used by vendors and customers to support other commercial ventures, then the revenues from those ventures can become almost pure profit as expenses vanish. It doesn’t work for every software business model, but it does work for many of them, as the tremendous success of Twitter, Google, Red Hat and IBM have made clear.

If you think I’ve missed something, or if you think one of my truths is false, please chime in. I’m perfectly happy with this list being a living document and I invite any well-argued corrections. Please note that I am aware that in some organizations, these myths might not come from the IT department, but rather the Legal department. Russell cautioned me, “you can’t teach an attorney” and while I agree that perhaps *I* can’t, I do know that other attorneys can, so if you’re encountering objections from Legal, try to find a lawyer who’s open to reason (yeah, yeah… plenty of jokes) to champion your case for you.

Hand this list out to your colleagues, your boss, your admins, your IT management and even your legal staff. Memorize the 10 myths and be ready to pounce when you hear them advanced by the Luddites of IT world, and together we’ll drag those relics kicking and screaming into the 21st century.

My friend and colleague Christian has been doing some performance optimizations for WebGate’s XPages Toolkit. And he’s found some interesting results revealing the exceptional performance of NoteCollection.

But being the obsessive that I am, I wanted to take the idea a bit further, so I thought of a few ways that the process might be faster. First, instead of walking the NoteCollection in the traditional way using .getFirstNoteID()/.getNextNoteID(), I decided to try it with .getNoteIDs(), which simply outputs the array of ints from the NoteCollection in the most direct way possible. Second, I thought it would be useful if the XPT’s DominoStorageService could create an object instance from just a Document’s metadata rather than the Document itself. That way actually accessing the source data could be deferred until properties and methods are actually called.

Of course, this would require some significant code on Christian’s part, so I decided to grab a shower while waiting to hear back from him…

Read more ›

Agent Smith was very good at multitasking

One of the best things about computers is that they can do more than one thing at a time. This is such a useful capability that we have a dizzying array of descriptiors for it: multitasking, multiprocessor, multiuser, multiplexing, multithreading — the list goes on. Unfortunately, along with being one of the most useful things about computers, it’s also one of the hardest to get right. This difficulty means that, for many platforms, doing things at the same time is simply not presented as an option.

Our beloved Domino is much like this. Yes, the server can do more than one thing at a time by using distinct processes and threads, but you and I as developers aren’t generally in control of this multithreading and concurrency. And that’s not surprising, since concurrent programming is hard.

It’s particularly tricky in Java and Domino because of something called “thread affinity.” That probably sounds like some kind of knitting technique, so let me elaborate…

Read more ›

When I first got the news about Tim, I wrote the following that night. I’ve wanted to share it every day since then, but also wanted to let his family get through their memorial process, so I’ve left it in draft mode. Some people might find it too specific or visual, and if you’re one of them, then I apologize in advance. I also realize I’ve been (as the man himself would have pointed out) a bit of a one-trick pony lately. I do have some interesting and exciting technical stuff coming up. But for now, here’s my last word about the true impact Tim’s life and death have had for me…

It’s the first night of our Tim-less world, and my family is asleep after a torturous and cathartic day. I’ve had more than a bit of tequila as I processed the sorrow and hot regret of losing my best friend. And I type this, doubting whether I’ll ever click “Publish” because so many people need to agree to discuss it that, at the moment, it seems impossible. But I hope they will agree, because all of the people that knew and loved and admired Tim need to understand the truth of what happened. Or at least as near to the truth as we can ever know about anyone.

Sometime between Saturday night and Sunday morning, Tim locked his apartment door, got in his red Mini Cooper, and drove to a secluded boat ramp on Lake Allatoona. Tomorrow was no longer for him.

When they found his car, he was parked facing the water and the battery was dead. I imagine he made sure that the last image he saw was light bouncing off the shimmering waves reflecting the spring trees. I imagine he listened to music while he drifted first to sleep and then…. to sleep. I imagine it was Rachmaninoff’s Piano Concerto No. 2, but it might also have been Peter Gabriel or Ben Folds Five or Dream Theater — Tim’s taste in music was more impeccable than his code.

As of this writing, no note has been found. He did not leave us a message. I believe this is because he was the message. Everyone that knew Tim has shared stories of his generosity, his laughter, his gentleness, his humility, his brilliance. And these are the things for which he should and will always be revered.

But beneath this he carried a dark and heavy passenger. He struggled to form intimate relationships. He struggled to find new ways to stimulate his incredible mind. He struggled to separate his fantasies about how the world should be from how it really is. Even his Twitter byline “I laugh in the face of the impossible” underscores an abiding contempt for reality over the world he wanted.

There is no evading reality, not even for an intellect as powerful as Tim’s. And the reality is that Tim could not figure out how to be happy. He tried all the remedies he could think of by being talented and hard-working and generous and kind and open. And when that didn’t work he tried being closed and cynical and lazy and dismissive. And when that still didn’t work, he tried them all again. And again. And again.

Strangely, we praised him for this. We called him a great contributor, a brilliant programmer and a gifted writer when he shared. And we called him introspective, quiet and “a geek” when he shut out the world — because this is the cultural idol that we sacrifice to in our nerd chic revolution.

I am more guilty of this than anyone; than everyone really. I saw the road he was heading down on the day he resigned from Red Pill, cutting off a collaboration that had spanned over half a decade and rocketed us both into stardom. I saw it so clearly that I wrote it down and then sent it to all the people from whom I wanted empathy and understanding, but not to the one person who needed it most.

I failed my best friend, because I was scared to be as honest with him as he needed me to be. And on that day when I was too furious and fearful to even say goodbye, I let him drive away in his pin-striped coffin; too stubborn to throw myself on the hood and beg him to stay. Too angry to confess how much he really meant to me. Too frightened of failure to express my fears to the only people that might have helped prevent it.

Weeks and months later, I told myself I’d accepted his choice and that being his friend was the best thing for him. We broke bread together again. We laughed. We shared ideas. We collaborated. And it was brilliant. And he did great work in his new job, even though he admitted that some days he never bothered to climb out of out bed. But it was never the same. In those moments that we opened up our hearts about the things that truly moved us, I never grabbed him and hugged him and pleaded with him to please PLEASE let us find virtue together so that he could discover purpose and joy in his life beyond the facade of being smart and popular.

I didn’t demand virtue from him. I accepted his tale of the introverted and enigmatic geek tragedy, not bothering to look behind his eyes to find the veiled, private hell he was suffering. And when he found that tale couldn’t shape the world into what he wanted, he seized control of the one thing he knew he could shape for himself. He couldn’t control good and evil; he couldn’t control who loved him or why or how; he couldn’t control whether tomorrow he would be treasured like he was today. But he could control whether tomorrow ever came.

And so he did.

So this is the message he has for us all: fight for the people you love. Don’t just accept them. Don’t just let them breeze through their days. If you love them, help them raise their standards not just in words but IN LIFE. Because if you keep accepting someone’s fantasy of virtue, you’re just daring them to keep the story going while ignoring reality.

Tim’s story ended far too soon. I wish I’d acted when I saw that end. I wish I’d been truthful with him. I wish I had given him more time. I wish he had given me more time. I wish I could see my friend again. I wish I’d said goodbye a thousand times.

I wish.