Open source community building, engagement and outreach

Users
1

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
$ ./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.

4 Likes
2

We need a serious discussion around which chat client we want to use:

While I’m tempted to go to IRC, but also wary of it. It has the benefit that the communication is truly transient (unless you set up special ways to make it log to a server or something). It’s the oldest system already used by a lot of people and costs us nothing to run. Also, IRC shouts FOSS.

Or, we can open up our Slack, and just pay for the users. Nicer interface, modern system, closed and expensive. We need a decision maker here, who can talk to a few people and figure out the right thing to do.

IRC, btw, has also come a long way. If you read the article:
https://drewdevault.com/2015/11/01/Please-stop-using-slack.html
you realize you can run shout to help with non-tech devs. Or, maybe irccloud.

@pawan: You spent quite some time setting up wisemonk on Slack. So, this decision would affect your work the most. Well, it’s not too hard to switch it to IRC, in fact, the whole thing might just get a lot easier – but still. You just spent effort on this, so I think you’d be the right person to be the decision maker here.

Note: Btw, this is an interesting discussion, and I don’t see anything particularly private in it. So, making it public.

Interesting snippets from HN discussions:

The only big thing that Slack has over IRC is being able to catch up on what was said earlier. However, to be honest, for open source projects, ‘chat’ of any kind should be for quick and unimportant discussion

Anyone who wants to avoid the possibility of lock-in using Slack should be laser-focused on making IRC competitive rather than trying to convince people that poor UX is just the price of freedom.

  • On top of searching history

Just set up an IRC log bot to log all channel traffic to a web site …

My notes:
In addition, we can easily add bots to IRC which when asked a question, can also search http://discuss.dgraph.io, and private message them the results. Over time, this can be very useful way to both quickly answer a question without human intervention and direct people to the more structured form of communication, i.e. discourse.

Also, Mattermost:

Repeated community requests for real-time integration with GitLab, Discourse, GitHub, Jenkins, Twitter, Dropbox, Google Drive, and other leading applications led to us building incoming webhooks and open source integrations services for Mattermost v1.1.

Actually, Mattermost seems like the right sweet spot for us! @pawan

2 Likes
3

Hmm, this is a very interesting and important decision.

I think the idea here is to go for something which

  1. Makes onboarding of new users very easy. Something like Gitter.
  2. It should be something that we use daily. So that we can easily move development specific discussions to the relevant channel as well as respond to user queries quickly.

I am not sure if IRC would fit the above criteria. I have to read more on it.

I think evaluating Mattermost would be worth the effort. I will set it up and we can use it for a week and we can evaluate how much a hassle it is to run and maintain it.

4

http://www.slant.co/topics/4554/compare/~rocket-chat_vs_mattermost_vs_irc

Don’t discount IRC so quickly. Do spend some time reading through the articles above. It’s possible that a lot of our developers would be comfortable with IRC.

Also, check out the reviews for their Android App:

Looks like it’s a slow hybrid, instead of a native app. But, might still be better than mobile apps for IRC.

5

Yeah, reading up on it.

@core-devs - Looking forward to your advice on IRC vs Slack vs Gitter?

Docker, Django and ReactJS, Angular guys use IRC :astonished:

From this article.

Problems with IRC that Slack tries to solve

Code snippets: Slack has built-in support for them. On IRC you’re just asked to use a pastebin like Gist.

File transfers: Slack does them. IRC also does them through XDCC, but this can be difficult to get working.

Both of these are important issues. Say a user who is facing some problem while using DGraph comes to these channels. Slack/Mattermost would provide all options to him so that he can get across his point easily.

6

Context: I work for an investment bank. We build platforms for our finance-oriented users.

I think I’m lucky to have a perspective of both an intimidated student and an enterprise user in a short span.

I remember trying to set up Hadoop on a couple of machines back in college and it was a nightmare. Then I found an IBM VM image that was already set up (with working default configs) - and I was good with Hadoop. Things are much better now with Docker and DGraph is not nearly as intimidating. Consider putting out a docker image out there with a typical DigitalOcean like step by step instructions on how to ingest your sample dataset (ideally single bash command) and how to make your first egress (again, single command). And then give a real life example. For the curious, creativity will take over at this point.

Enterprise users are usually locked down with legacy sources and lack of time. A couple of things we did -

  1. we built a procedural language that compiled to SQL for business users .
  2. We built into that procedural language the ability to ingest from legacy sources into a [shiny new DB] (csv, legacy DBs et al).
    With these in place, our users have been adopting new SQL technologies at an amazing rate because they can re-use business logic and reuse old sources.

You’ll probably spread yourself too thin if you start thinking for the enterprise (which tends to be very domain specific) but getting the students/enthusiasts behind you will do you a ton of good. When you do plan to go enterprise, build something like a Kafka adapter for ingestion and help them design a more industry specific layer over GraphQL.

I was going to write a Kafka example over DGraph but figured learning Go first would do me good. Will probably do it next weekend.

3 Likes
7

Been reading about Mattermost and it seems very compelling. I think we should consider it along with the rest.

One area that I was particularly interested in, and it matters to all, was mobile push notifications:
http://docs.mattermost.com/deployment/push.html

It has the ability to do encrypted push notifications so that’s nice.

Gitter’s notifications aren’t all that great. Slack is better but there’s room for improvement. Not sure about IRC.

8

That’s interesting koppula. Where do you feel Slack is lacking? These points would be important when we compare it against other alternatives.

9

@apoorv-kumar agree about enterprise users; we’ll need to eventually build tools to support them and their needs wrt legacy solutions. Making it easy to port their data over from tables to Dgraph would be a step in the right direction.

We definitely want to make it really easy for developers, students, sys admins, and other enthusiasts to get started with Dgraph and play around with it. You have some great suggestions that we should take a look at.

10

Cost and ownership of data are two of the biggest selling points in Mattermost’s favor.

1 Like
11

So, after a day of toiling over which software to use, IRC or Mattermost – I think we should just stick to what we already like and have, i.e. Slack.

Let’s just continue to use Slack, and let’s just our open the doors for our open source community here. If and when money becomes a problem, we can look into other solutions. We already spent quite some effort in getting Slack up and running for us. I think it would be a waste of our time to try to migrate to another solution right now. Particularly, given Mattermost is still under heavy development, and doesn’t have native mobile apps.

In terms of data, any useful structured data is on discuss.dgraph.io anyway. Slack is just for temporary interaction, and as with 10K message limit, we’re still quite far from having our history archived.

I tried IRC again today, and immediately realized how much it sucks. Slack doesn’t suck, we like it. So, let’s use what we already like.

If it isn’t broke, don’t fix it. If it works, don’t replace it.

2 Likes
12

Sounds good, let’s get it rolled out. I wasn’t looking forward to IRC so glad we don’t have to think about it. :slight_smile:

2 Likes
13

At Caddy we used to use slack for reaching out to the community in the first few months. But once the community started getting active on the repository and also seeking support and queries on slack, it become really hard for us to be responsive on both Github and Slack. For instance when the number of issues filed and pull requests made by the community started growing, it was really hard to be response on github comments/conversation /issues/PR’s and at the same time answer the queries on slack. Moving to gitter worked out really well there. For first time we were able to get the activity stream on the repo meanwhile we are interacting with the community, so it helped us being responsive on both ends. Also the brand perception of Gitter is more open source friendly, lot of amazing go developers are hanging out in Go based open source projects on Gitter (CockroachDb, Docker,CoreOS, Mattermost), Gitter is minimalist in design and built for one reason, that is to help developers communicate better while developing on Github, whereas Slack is built for whole is used for variety of purposes. Gitter vs Slack is a tough argument, but in the past Gitter has worked out better because of the above reasons.

14

Hey Karthic

I do understand that Gitter is used by many open source communities but didn’t understand how it was easier to answer queries on Gitter than on Slack?

We did use Gitter for sometime but ultimately

  1. The lack of native apps which led to a delay in notifications ruined the experience.
  2. Also, since we were using Slack for internal communication(it has a bunch of integrations and works out well compared to Gitter), we thought moving the community to Slack would help us better attend to their queries.

Slack does have an additional step where you have to signup again for every organization, but after that, I think its pretty much the same experience as Gitter. You just have more than one rooms per organization.

15

Lets look at the factors in the order of decreasing priority which could be the guidelines to look upon while making a decision in this regard.

  • Helps being responsive for any activity on the github repository and the at the same time being able to interact with the community.

  • This is the most important criteria, if you cannot be responsive enough its not possible retain the enthusiasm an individual has shown to spend his personal time, its of utmost importance that a fast response is provided for any comments/issues/PR’s on the repo, it applies for any interaction on gitter/slack by anyone from the community.
    This is where gitter wins.
    When there are not many external contributors or a large community of users any platform works.
    But when it scales up, being responsive to all activities on github meanwhile interacting with the community becomes challenging.
    How does Gitter makes it easy?
    On the right hand corner of the channel you’ll all see the activity that goes on the repo meanwhile interacting with the community. That makes the job a lot easier when you have to interact with hundreds of community queries and be equally responsive to tens of activities on the repo.
    Otherwise you have to be split across slack and Github notifications. The context switch is expensive and it’ll affect the productivity of the team.

  • Be where the developers are.
    Because of their tight integration with Github, Gitter has built a brand and perception that its almost a subset of Github. Whereas Slack hasn’t built a developer friendly brand, this makes developers onboarding really easy into Gitter. Onboarding new users onto a new platform is a billion dollar challenge, the friction should be as least as possible.
    Here are few reasons why Gitter is able to build that brand.

  • Login with Github option alone makes it possible for anyone with a Github account to onboard, an developer by default has a github account.

  • Login with twitter makes onboarding more easy.

  • Besides that there is the usual email subscription.

  • To view the conversation there is no compulsion on even logging in or to have an account!

Now look at the home pages of Slack and Gitter (attached), be in the shoes of a new developer, what perception of the brand do you get when you see them? That tells you the brand Gitter has built.

Where do you think a developer wants to be, In a “Messaging app for teams who see through Earth” or in “Home for developer communities” ?

  • Minimalist and does few things well.
    pawan : As you pointed out Slack has tens of integration and options. Minimalism is a philosophy any open source community respects. There is no need for tens of options. The goal is to have tight github integration and meanwhile being able to talk to community ! Gitter is really minimal in its design and does one thing really well.
  1. A mobile app with a good experience.
    As you see this comes down in the priority list. Choosing a platform with good notification is great for personal use, but this is more than that !
16

I’ve used both Gitter and Slack. And I really wanted Gitter to win. But, even after so many tries, it still sucks. Slack is just way better experience than Gitter.

I get the argument about Slack being closed source. But Gitter isn’t completely open source either.
https://www.reddit.com/r/opensource/comments/4lir55/gitter_or_irc_which_do_you_prefer/

Their web backend is entirely closed source. And you still have to pay them. On top of that, their apps are hybrid and bad.

The integration with Github is nice but really doesn’t help in any particular way. Slack can give you all the notifications easily as well. Also, for us, Slack isn’t the only channel. We prefer to talk on discuss.dgraph.io. Slack is there just for some real time conversations.

I also don’t buy that open source community wouldn’t use Slack. Golang is running solely off Slack and IRC and decided against Gitter for similar reasons:

The thing about Gitter is, the OS community wants it to win. But, their tech is just not good.

1 Like
17

Matt Holt’s(who started Caddy) comment in the link Manish shared above.

Personal opinion: Gitter is nice, but everyone already uses IRC or Slack for Go chat. I moved my project from Slack to Gitter because of the lower barrier to entry, but now I kind of regret it, since Gitter is really rough around the edges. I definitely think Slack/IRC is good for now, at least as far as “official” channels go.

I also like the simplicity of Gitter, but it doesn’t work well.

18

Sharing a screenshot of a very brief interaction on the CockroachDB Gitter:

711×359 62.8 KB

19

Another one from the same Gitter channel where a new user does a blog post about their experience with the product – user evangelism is really cool:

694×649 97.8 KB

20

Simplicity wise, wouldn’t you say IRC is the best? :wink:

1 Like