The Importance of Community

Back in April, after Engage and an XPages on Bluemix seminar at IBM Ireland I wrote a piece called “The Future of (Domino) App Dev in a Single Word”. That word was community, and the feeling was driven by public and private initiatives around XPages and XPages development. This seems a profoundly apposite moment to revisit that sentiment.

The Evolution of XPages

Let’s step back seven years. Web development had taken off and more and more applications were being delivered for browser access. But Domino web development was a challenging world, with a host of proprietary hacks (view templates, search templates, CSS files in pages etc) and unhelpful editors (no support when creating CSS stylesheets, JS Header area didn’t enforce best practice or give typeahead, and the JavaScript Library editor still throws errors on perfectly valid JavaScript).

This is when XPages appeared. I want to walk through my recollections of why XPages became a successful technology for me and possibly for others.

IBM delivered a workshop for business partners and customers in Dublin, testing a tutorial that would subsequently be posted on the Domino app dev wiki (in September 2010). The next appearance was at Lotusphere 2009. I wasn’t there, so I don’t know its impact or if the tutorial would have been in the labs where developers typically can run through samples. This was before I was heavily involved in the community.

My first experience was at training by an IBMer (Tim Clark, before he left IBM) in March or April 2009. For some that training may not have led to anything. For me as a developer, it only led to something because of the significant power and ease of repeat controls, compared to what I was currently doing with web development. At the time there was not much more support available from IBM in terms of documentation. The Help files for XPages have always been fairly limited, something I realised most significantly when I had server crashes because I was not recycling Domino objects. There was no book at this point and that would not come until January 2011, two years after XPages itself. But ICS did have technical evanglists at the time, Niklas Heidloff and Paul Hannan, as well as a lot of blogging by Stephan Wissel. Their work was critical, particularly looking at the content on OpenNTF.

But despite their efforts, I firmly believe XPages was not have been a success as quickly (if at all) without the community. Declan Lynch’s 50-odd part series on XPages was a vital source of reference for my first XPages project. That just gave a read-only front end to an intranet where all the administration was done in the Notes Client. That approach made it a much easier project than I have seen some developers choosing for their first attempt at XPages. But even still, there were a number of aspects which I just could not have delivered based on IBM’s documentation alone and for which Declan’s blog series proved critical.

As time went forward, time and again community resources have proved crucial. Blog posts by brilliant community developers like Tim Tripcony elucidated the arcane elements of XPages in a way that was missing elsewhere. Videos hosted by David Leedy’s NotesIn9 have been vital for years, both for new developers and to allow experienced developers to share their knowledge. I know David receives a lot of questions from developers, many more than I have from my blog.

I’m not sure if Niklas Heidloff or Paul Hannan received a similar number of queries. But since they left, there is not really anyone visible from IBM to act as a conduit and aid for developers. It’s an aspect I realised earlier this year. It’s not a position for one of the development team, it’s not a role for support, it’s often not a role for a business partner – their focus is selling services / products, not empowering for free on a platform. It’s a position the product’s owner should fill. Empowering business partners is good, but empowering developers business partners may not know about is better, and that can often just be a case of pointing them in the direction of useful blog posts, useful chats, the correct forums etc. After all, a technical evangelist may know a hell of a lot, but those elsewhere in the community may be using the technology in different ways and therefore blog or make videos that cover very specific aspects that the product’s owning company would not consider. They may also get there quicker. I know Tony McGuckin set up a seminar (for business partners only?) covering performance I think in late 2011. I didn’t attend, because my work with Tim Tripcony on sessions meant I’d actually already dug into and spoken at conferences about things like Phase Listeners, custom language and the XPages lifecycle. The role of a technical evangelist is also to be aware of these kinds of community members and link them with the right people, if required, to get great content out quicker than they would otherwise do so. It’s about empowering the many, not feeding the ego of an individual by being able to say “I wrote this” or “we should write this”. Success comes from a collaboration, not ego.

This was shown even more so with the XPages Extension Library. Not only was it put on OpenNTF first, to enable a very open beta program. But the book about it was written by IBMers and the community in collaboration. The idea and approach for the book itself was driven by an IBMer, Phil Riand. The work of Paul Hannan in coordinating with IBM Press and ensuring the team delivered on time (or near!) was critical. But very specific technical knowledge of the community was also important. This was shown also with the work on Bootstrap, for which Mark Leusink was a massive contributor.

But what was also critical was a heavy commitment to XPages from IBM. The work in the Extension Library alone was massive. It was so important to XPages development that for some years now I would not develop an XPages application that didn’t depend on the Extension Library. That work continued apace in the core until 9.0.1 was delivered, and more recently in the Extension Library. (And the latest version should definitely be shipped with each Feature Pack.)

There are still some customers who have not embraced XPages, I know. They didn’t care about the success or failure of XPages. IBM didn’t have that luxury. They will almost certainly not be interested in the future evolution of ICS application development, and I don’t have a problem with that. But a strong community involvement is important for the future evolution of ICS application development.

Lessons Learned from Beyond ICS

As I’ve stepped beyond ICS technologies, the role of community has been reinforced, both for good and bad.

The good has been shown by my experience of Vaadin. The quality and depth of documentation, samples, webinars, blogging, training, certification, forum activity and extensions developed and facilitated by the Vaadin team themselves and their technical evangelists is impressive. Documentation has not only been created, but regularly updated to take into account agile enhancements in the product (maintenance releases every 2 weeks). The resources committed to Vaadin are considerable.

But there is still a strong requirement for activity from the community, via guest blog posts like the one I contributed, involvement in webinars (e.g. Tim Berglund for Vaadin with Cassandra, Rene Winkelmeyer on integrating SalesForce with Vaadin), and add-ons. This has even been visible on Bluemix with contests alongside IBM to encourage using the two technologies together.

The less impressive has been visible as I’ve dug into TitanDb and Cassandra. Since TitanDb 1.0 was released about a year ago, the developers from Aurelius who contributed TitanDb have gone quiet. The documentation is pretty thorough, but there has ceased to be any communication with the community as their efforts have been directed towards a proprietary graph API, DSE Graph. As a result, the community has become concerned with several threads on Google Groups over the last few months asking whether it is right to use TitanDb for their next production application. Coordinated by an IBMer, it looks like there is a growing community seeking to drive TitanDb forward towards Apache Incubation, but the project is a year behind because of the silence and I wonder how many have chosen other technologies as a result of the ongoing silence. And without the community, the product would definitely die.

The Future

Has XPages reached its end? I have enjoyed developing with Vaadin (which started in 2002 and is nowhere near its end), but XPages is a quicker development process. Vaadin was always intended for me as a companion to XPages, which is why the OsgiWorlds version of my “XPages to Web Application” series was the endpoint functionally, although the stepping point to the CrossWorlds version in narrative. It’s rapid application development as well as my familiarity with the framework means developing applications is quicker, which is something that I am sure appeals to customers. I certainly planned on using XPages quite extensively for the project methodology work I planned for OpenNTF. I’ve had interest in training on XPages this year, so there are customers who see a benefit. The first three months of this year saw me deliver two very enjoyable sessions on XPages and those sessions have contributed answers I’ve delivered on StackOverflow since. I contributed work to the Extension Library release in May this year. There were a number of enhancements and investigations I had earmarked for the full XPages component list, based upon the announcement at IBM Connect of this being open sourced. (Incidentally, I was aware of this two years ago and it was a key reason why I didn’t pursue a second edition of XPages Extension Library book further.) And there was and still has been a roadmap of enhancements to OpenNTF Domino API and other projects.

So has XPages reached its end? In my opinion, definitely not. No technology as flexible as XPages can reach its end for those who have the imagination to dream.

And I have a fervent imagination of dreams for further enhancements, more blogging and sessions about best practice, more blogging and sessions about embracing Domino as a multi-model database platform, completion of Xots for scheduled processing. Others are dreaming of things like Bootstrap 4, working with some of the front-end developers who have blogged about using jQuery plugins to turn those into XPages components. Beyond XPages, the community has dreamed of providing NodeJS on Domino, I started but didn’t complete wrappers for Views and Documents to use in Vaadin.

Certainly Domino has not reached anywhere near its limit of possibilities. Beyond basic Domino, ODA already has the ability to store Java objects easily in Notes Items and store data in graph architecture based on Tinkerpop, but sharding of an individual vertex type across NSFs could be investigated for the future to investigate benefits of scalability. Alternative indexing options like Lucene or Apache Spark may be worth investigating. Removing some of the limitations was on the roadmap earlier this year, but that’s something the community cannot contribute to.

But whatever the future road, the role of the community is critical. Cloudant does not appear to have taken off to a large extent – 618 questions on StackOverflow, 967 on developerWorks with only two experts with reputation greater than 1, a community on developerWorks with seven people. Community is at the core to any successful technology. Community, the consumers of the technology made Bootstrap a framework developers could not ignore. Community made jQuery a clear winner over Dojo. A small community for Apache Wink makes it much harder to find answers on and so use effectively than Jersey and RESTEasy. What ICS has had is a very passionate, innovative and committed community. That kind of community is key.