Skip to content

Communication and Community

A couple of days ago I posted this tweet. It was prompted by experiences in a variety of technical communities over recent months and year, good and bad. Anyone who knows me or has been involved in the IBM Collaboration Solutions community will be aware of how passionately I believe in the power of community and the importance of empowering those within the community. It was a topic I blogged about in depth earlier this year. And it shouldn't come as a surprise, considering I'm a board member on for open source community, OpenNTF.

In my last blog post, I talked about my enthusiasm for and enjoyment of Vaadin. It's an open source framework with an engaged community and a committed, open and communicative provider in Vaadin themselves. With regular releases, regular blog posts (by evangelists at Vaadin and beyond), active interaction with the community on forums, it gives someone on the periphery of that community confidence in the future of the platform and its community. That's important for those committing money for their company on training or deployment of a production application on that platform. It's even more important for developers investing their personal time in learning a new framework or providing fixes, enhancements and extensions for the platform.

When communication stops, however, FUD starts to set in. This is something I've seen on a number of occasions with a variety of technologies, open source and closed. It's why I've sought to be accessible and responsive in the open source projects I'm involved with. It's also why I've tried to ensure there are others who can take key projects forward, so it can be guaranteed a future regardless of my involvement. That leaves me able to stay involved as long as I wish (both actively developing and empowering others to develop them), free to pursue other projects, and confident in their longevity should any unforeseen circumstance ensue (god forbid!).

With open source, a lack of communication leaves the community uncertain whether or not they should step into the breach, cautious either because they may be stepping on the toes of those who have been heavily involved, or because they may be taking the project in a direction contrary to where the core developers expected to take it, or because there may not be anyone who has the authority to create an official release incorporating their work. There may be unspoken reasons that may justify some period of quiet, resulting in some patience from the community. But if that period of quiet continues, concern will increase.

In some cases even an admission from those responsible for the project that they have no intention to continue can be helpful. It allows the project to move forward. I was recently involved as an intermediary between a potential committer and a project owner, which resulted in the committer being welcomed as the new project owner, a satisfactory outcome for all involved. Even in the worst case scenario of no one wanting to take over, at least it gives clarity that the project is dead. But if the project is truly open source, it's not the fault of the project owner (providing they're open to upskilling potential new project owners), it's the fault of the community who collectively were not willing to take over ownership. There may be a need for specialist skills, but in most cases skills can be learned.

Sometimes even after a sustained period of quiet, there are whispers that those involved do intend to return to open source. When that happens, it's certainly welcome, regardless of the amount of time they intend to devote.

In closed source, the outcome can be more destructive because no community has ever been empowered to take the product forward. It results in significant effort to reinvent the wheel. If communication and transparency has been lacking, that effort is required with limited notice and no choice. If the product is a component in a larger stack and not easily replaced, the resulting frustration and disappointment (possibly more extreme - despair and anger) can mean a re-evaluation of the whole stack, particularly if the cost or feasibility of replacing the component is prohibitive. It can significantly impact those who have supported the product in good faith, as well as those who may appear to no longer care. At the very least it results in a loss of good faith which may be difficult to regain.

But whether open or closed source, communication can only go so far. Sooner or later there needs to be action to back up the words. Without action, the community will start to tune out. I'm reminded of Aesop's fable of the boy who cried wolf. But the action needs to show two-way communication. There is nothing so dispiriting as an outcome that is not relevant to the community or fails to deliver on the promise of the vision sold.

This may seem a negative and cautionary tale, but again I'm going to draw on my school and university days with Latin and Greek. There are a host of woes here. For those committed to a given open source project or closed source product, it's probably analogous to a Pandora's box. But at the bottom of that box, there is always hope. It may not be small and not the hope you were specifically looking for, but seek hard enough and it may be a hope that takes you in a new and unexpected direction. The road out of the darkness is never easy. A herculean effort with a lot of painful stumbling may still ensue. Even as the dawn rises, like Orpheus leaving the underworld, a bitter blow may await. But perseverance and adaptability is an inherent trait of the human psyche.