These are from my discussion with Karthic around building and engaging with a community around open source projects. Notes are not in any particular order and I haven’t really edited them much.
Showing empathy and being welcoming as a community, especially to new users, on the communication channels is very important. Sometimes more important than anything else, including the product. If the product is not quite ready for prime time and doesn’t have all the functionality that a user is looking for, the warmth that the community extends to the user will go a long way in ensuring that the user stays and engages with the product, maybe even decides to contribute functionality they are looking for. Users are much more willing to be forgiving and understanding if they feel welcome. The Caddy core team saw this first hand when interacting with users.
Caddy (https://github.com/mholt/caddy - https://caddyserver.com/) was started by Matt Holt as a webserver built using Go. Matt doesn’t have any funding for Caddy though he’s starting to see sponsors such as Minio and Digital Ocean more recently. This was started last year and has already reached over 6000 Github stars, which is pretty amazing for an open source project that has a small team of contributors (5 that are distributed in different time zones) and almost no funding. Definitely a few things we can learn from their.
Caddy used to use Gitter until recently when they move to their own Discourse - https://forum.caddyserver.com/. And they seem to have a pretty active community already including contributions for their logo! When they were on Gitter, that’s all they used. Conversations didn’t splinter across Gitter for the community and say another tool for their core team. Now that they are on Discourse I don’t see any trace of Gitter around (at least its not mentioned on Github anymore). All their conversations, especially around the product, is in one place.
Minio (https://github.com/minio/minio - https://www.minio.io/) also exclusively uses Gitter and there’s a lot of activity there. We used to use Gitter and we still advertise it but anyone visiting our Gitter for the first time isn’t going to feel like there’s a lot going on. They will take a look at discuss but they may think twice before saying something. Also for new users Discourse doesn’t have the same sense of immediacy as Gitter or IRC.
We have internal technical discussions on Slack, none of which is visible to the community. Having this be visible to the community would help the community see that there are active ongoing discussion happening. Need to rethink how we can be more open with our technical discussions and do this in Gitter instead of Slack for the community. Caddy and Minio stick to one channel.
Github Issues. We need to really take advantage of Github Issues and how it’s perceived by the community, including enterprise users. Github Issues shows whether there’s community engagement. And for enterprise customers this matters a lot. Seeing a lot of activity on Github Issues gives users and especially customers, enterprises included, a lot of confidence that there’s a thriving community and they have a pool of potential hires in the future. This is a key point. I checked both Caddy and Mino. They use Github Issues for both bugs and features. And it’s best if these get filed from outside the core team. I can’t remember which, but one of them has had something like 3000 issues filed over the past year.
Stackoverflow. Both Caddy and Minio have used Stackoverflow to their advantage. The thinking that’s common to both is that they should go where the users are and engage with them. For JS, Android, iOS developers, but especially for JS, a lot of them hang out on Stackoverflow and the community helps each other out. Same goes for Java. So both the Caddy and Minio guys started engaging with their target community on Stackoverflow:
So they didn’t just wait for users to find them. They actively started engaging with their target userbase and this led to users taking interest.
Usability. It matter. Like a lot. Even for an infrastructure product. This is something Minio realized early on given their main co-founder AB Periaswamy’s prior experience with building Gluster, which was acquired by Red Hat. Take for instance client libraries. Even though Minio’s in Go, they built client libraries for Amazon S3 compatible client libraries in all the languages that matter to users: Go, Java, Node.js, Python and .Net. They just went ahead and did it and it’s paying dividends since had they done Go alone they would have targeted a very small subset of users. Some of the most successful web developers use nothing but JS and they can now use Minio and be up and running in no time. Minio also has a command line client that supports Unix commands. This was said to appeal to the sys admins in the community. The Minio server is supported on Linux, OS X, Windows, FreeBSD, whereas Caddy is supported on Windows, OS X, Linux, FreeBSD and OpenBSD out of the box. Neo4j supports .NET, Java, JS, Python, Ruby, PHP. Something for us to think about when it comes to client libraries and user adoption.
Cady got a lot of traction by doing a couple of things. They announced support for HTTP/2 and auto encryption using Letsencrypt’s free SSL/TLS certificates. Even though HTTP/2 doesn’t have a lot of support yet, Cady was able to get a lot of attention by doing these two things. Auto encryption made it really easy to set up a secure server.
Making it real easy to install and start using the product. Both Caddy and Minio make it a 3 step process. For instance with Minio:
$ curl https://dl.minio.io/server/minio/release/linux-amd64/minio > minio
$ chmod +x minio
No installing Go or any other dependent package.
Examples and reference implementations. Minio spent time coming up with example apps and reference implementations to showcase their easy of use. Karthic showed me how for each client library they use a simple example app and reference implementation to showcase Minio. They made the UI for these apps really slick to appeal to users. For the UI they hired a UI designer out of Sri Lanka. They have a sandbox that is hosted on a server that anyone can try out.
A key point that emerged from the discussion was that even for something like MInio that is a distributed object storage backend, they were targeting users not just developers for adoption. So someone like a student that wants to try out Dgraph and install it on their laptop should not be be intimidated by Dgraph being distributed.
Anyway I’m going to stop now since this is quite long winded. But wanted to do a dump of the discussion I had today and see this continue on various levels.