Becoming the new standard discussion tool for open source projects

Installation Hosting
1

If you ran an open source project in the 90s and wanted to provide a place for your users or contributors to discuss things, you most likely did the following:

  1. Setup a mailing list, probably using Mailman.
  2. Start an IRC channel, probably on Freenode.

Fast forward 20+ years, and the picture looks… mostly the same.

Of course, we have Stack Exchange – which is a great thing! – but more open-ended or intimate discussion for these open source communities, even new ones, is still predominantly conducted using these ancient tools.

Some examples:

  • Fabric, a popular Python SSH orchestration tool and library, uses a mailing list and IRC.
  • Homebrew, a popular package manager for OS X, uses a mailing list and IRC.
  • boto, a popular Python library for interacting with Amazon Web Services, uses IRC.
  • Phabricator, a code review tool (plus other things) originally developed at Facebook, uses IRC.
  • The entire set of projects under the Apache Foundation, old and new, uses mailing lists for discussion.

These tools work well, and for some open source communities (e.g. Apache, which I discussed in a separate thread), moving off them is unlikely to happen. But for new projects, or existing communities willing to change their discussion tooling, Discourse should be a no-brainer. (I see, for example, that Docker knows where the good stuff is at. Good on them.)

What does the Discourse team think of positioning their product as the successor to the “mailing list + IRC channel” combo for open source projects? Perhaps by offering free hosting?

Obviously, this would be a strategic move with no short-term financial gain. Instead, targeting open source communities would win Discourse a couple of things over the long run:

  1. Capture mindshare with developers who run infrastructure at their companies and influence decisions about, for example, forum software to use.
  2. Grow on a community of users who are, as open source users/devs themselves, very well positioned to contribute back to Discourse.

What do you think?

6 Likes
2

I would love if more open source projects used us, and in the past we have offered hosting to FOSS projects we consume like Ember.js. However, at the moment we are quite focused on paid hosting efforts for our customers and building our infrastructure to support that.

2 Likes
3

It’s probably better to reach out directly to hosts to enquire about hosting sponsorships.

If you’ve got a successful open source project, DigitalOcean probably wouldn’t mind tossing you some credits to run a droplet for a Discourse installation.

2 Likes
4

My suggestion is a strategic suggestion for the product/company, not an attempt to get free Discourse hosting for my favorite open source project.

Of course, if I’m just looking for free Discourse hosting for my open source project, there are probably easier ways of getting that than having this discussion here. That’s not what I’m looking for.

Supporting open source projects as a “first class” offering of Discourse (perhaps in partnership with a hosting provider like DigitalOcean), I believe, has the strategic potential I proposed in my previous post, and lines up with the company’s mission:

The goal of the company we formed, Civilized Discourse Construction Kit, Inc., is exactly that – to raise the standard of civilized discourse on the Internet through seeding it with better discussion software:

1 Like
5

Totally understood! Y’all have already done more than enough to make Discourse widely available.

If at some point the company finds itself in a more comfortable position, I hope y’all consider my suggestion here. I think it would be another good step towards making the Internet a better place for discussion.

1 Like
6

I’ve been pondering these types of ideas too. Didn’t say anything yet because:

[quote=“NicholasChammas, post:1, topic:26305”]
Obviously, this would be a strategic move with no short-term financial gain.
[/quote]You can’t make too many bets like that as a young startup, and they’ve already made the bet of going “all open source, no upsell to PRO”.

That being said, a conservative soft-launch might be possible in the near future. Could try something narrowly targeted like:

(Popular) open source projects with a Google Group older than 2 years may apply for a free migration and 1 free year of hosting on [Host Partner]. Selection is up to the discretion of the developers.

As for this

[quote=“NicholasChammas, post:1, topic:26305”]
Grow on a community of users who are, as open source users/devs themselves, very well positioned to contribute back to Discourse.
[/quote]That’s definitely something they could try do more

1 Like
7

I suggest our 30 minute cloud install – not quite free, but at $10/month, very affordable.

If you’d like Discourse to sponsor your open source project and fund the hosting fees, email us at team@discourse.org to discuss!

2 Likes
8

I’m using Discourse for my Open Source project community.nethserver.org and I previously followed the same path of all OSS project: ML + IRC.
It’s a great tool and it has made my community more vibrant and active, we bought a pretty cheap plan on Communiteq (formerly DiscourseHosting)

4 Likes
9

Here are a few related discussions that people might be interested in:

To recap the key points from this and the linked discussions, if you are looking at Discourse for your open source community, here are your best options:

  1. Host with the Discourse team. The lowest price point as of December 2015 ($100/month) is probably too much for most open source projects, unless your community is really large.
  2. If you have an open source community and can make the case for it, reach out to team@discourse.org to discuss the possibility of the Discourse team offering you free hosting. (ref)
  3. Self host via your host of choice. You’ll pay around $10/month for the hosting but you’ll have to manage the instance yourself.
  4. Get a plan on Communiteq (formerly DiscourseHosting). Their lowest price point as of December 2015 is $20/month, which probably makes sense for the average open source community which doesn’t see much general discussion traffic. (I say “general discussion” as opposed to discussion on specific issues, PRs, etc. which carries on well on places like GitHub).

I’ll probably go with option 4 since I’d rather spend the extra $10/month over self-hosting and save myself the time managing the install. My project is way too small to justify $100/month, though in theory I’d prefer to host with the “Mothership”, so to speak. And I doubt a small project like mine would be a good fit for option 2.

4 Likes
10

It is very, very easy to manage a Discourse self hosted install on Digital Ocean. If you can open a web browser and click an “upgrade” button every two months, you are good.

(you also will need to SSH in and issue three console commands every 6 months to update the docker container definition as well, to be fair.)

If you run a whole open source project, I would imagine the above two steps are No Big Deal for you, but your call :wink: It really is that easy though. That is the goal.

2 Likes
11

Yep, it’s great to see that Discourse gets easier to manage with time, and that the team has prioritized making that particular experience easy. :thumbsup:

Still, for some people (myself included) management is a binary: Do I manage or not? As easy as Discourse is to manage, knowing that I’m on the hook for managing it is still somehow a psychological burden. :sweat:

To me, it’s worth a little extra money per month to get rid of that burden. It’s kinda like paying that extra $10 when you buy airline tickets for “travel protection”, even though you know you’ll never put it to use. It just puts a little voice in your head to rest.

1 Like
12

Perhaps, but I would rather have that extra $120 per year in my own pocket, and if the target audience is so price sensitive, I bet they would too. The clincher for me is that they run an open source project. That’s quite difficult, so clicking an Upgrade button in a web browser every month does not seem like a big leap. Heck relative to the massive amount of work in an OSS project that is like a vacation :slight_smile:

But for people who do not run an open source project, I completely agree with you.

13

Everything you’re saying is correct, but the key for me is not technical difficulty. It’s about psychology and about a person’s time and attention.

To expand a little on my previous comment: I recently started an open source project. I’m still in the “honeymoon” phase – it’s new! – so the project gets a lot of my time. Soon though, other things in life will recapture my attention, and my project will be demoted to one among many responsibilities.

Many open source projects, even fairly popular ones, have been abandoned because they took too much out of their maintainers over the long run. Their scope was too big; the architecture was bad; they never developed a vibrant community of contributors and maintainers; etc. The reasons are many, and often one amplifies the other. But the bottom line is that they were too much work to maintain.

Being acutely aware of this common problem, I’ve planned from the start to reduce any ongoing maintenance burden for my open source project. I want to ensure that I can stay an active shepherd of the project years into the future, and that means being very aware of what I’m signing myself up for. Every bit adds up over the long term.

So for me, even the few clicks every month to upgrade Discourse is something I carefully consider, because it’s a multi-year commitment. Also, I have to plan defensively and assume that every once in a while something abnormal will come up which will take more than a few clicks to resolve.

More so than money, open source projects take time and attention. Those are the limiting resources for the typical project. That’s why, even though a Discourse instance may technically be a joke to manage, I would still choose not to manage it. Better to spend my money (up to a certain limit, of course) and spare my time and attention, which are much more valuable and hard to come by, especially over the years.

14

Well, the whole idea of Discourse is that the person who originally sets it up can walk off a cliff and the thing will still continue to work, e.g. the community can earn enough privileges to do basic moderation and cleanup.

Longer term we do need to do what WordPress eventually did, which is make updates completely automatic. Not quite there yet. And to be fair it took them almost a decade to get to it :wink:

3 Likes
15

Well, I’ll admit you make me want to give self-hosting a shot. :smile: I guess if it becomes a pain I can always migrate to a managed host and wipe my hands clean of the matter. :muscle:

1 Like
16

That’s the spirit! As I said, I do agree with you in general, but not in the very specific case of open source projects.

17

I’m gonna talk in hypotheticals, so don’t let me derail you from getting into the spirit of self-hosting. It’s a good place to be; stick with it!

In another galaxy far, far away, I can see the following possibly materialising.

Categories as Google Discourse Groups

The thing about the vast majority of open source projects is that they’re really small. They’re just one or two people who made a handy library that they’ll commit some code to once in an odd while. The really trivial ones get by just fine with nothing but a GitHub issue tracker and a public e-mail.

The slightly more active ones will benefit from the type of back-and-forth public discussion that GitHub issues or 1-to-1 e-mail doesn’t lend itself well to. While a dedicated Discourse instance seems like an excellent solution to this problem, it can easily be too much too soon. A small upstart can look & feel like a ghost town if topics aren’t even coming in on a daily basis, and those avatar thumbnails are dominated by the same faces.

An inconspicuous Google Group on the other hand is much more low-key and lends itself better to a slow buildup. The catch? The Google Groups export story is absolutely terrible, so when you’re finally ready to transition from “group of early adopters” to “full blown community”, the migration burden holds you back.

I think it’d be wonderful if Discourse (for now I’m just talking about the software – whether this is something the company should take on is a different matter) could be used more like a Google Group.

Imagine a “http://discoursegroups.org” forum.

  1. Sign up (for free) by entering some project meta data
  2. Get a category of your own
  3. Start discussing

The problems that remain to be solved are:

  • There’s no built-in way to automatically provision a category for a new user upon request.
  • We’d need support for category-specific digests. No one would want a sitewide digest in this case.
  • We need support for category-specific moderators (coming in v1.7)
  • Parity with mailing-list features could be a lot better (The MOSS sprint has brought us pretty much on par with popular mailing lists).

On the other hand, we’ve already got a ton of features that far exceed what you’d get out of a Google Group. Putting aside the whole “with Discourse you can actually build a community” aspect for a moment, there are a couple more things that excite me:

Give your Discourse Group a personal touch

I love what they’re doing over at forum.gearboxsoftware.com, wherein if you drill down into a game-category, the look is tailored to that game.

Screen Shot 2015-12-02 at 15.51.56.png2516×1190 1.79 MB

We’re not as styling-agnostic as Reddit, but it’s good start, and more than Google Groups can do.

Category export

Category export is specced out and on the roadmap, and it’s a big deal. This means that, unlike Google Groups, if you created a Discourse Group you’d still own your data. Best of all, since Discourse is open source it’s easy to pack up your stuff and move into your very own home once you’ve outgrown your shared space.

Integrations

We can offer a level of integration with popular open source tools like GitHub and Slack which Google Groups will never come close to. (also see ost.io)

9 Likes
18

You forgot one of the options:

  • Self host using existing hardware belonging to the project.

However, this will only work if you have a Docker-capable kernel installed, and enough available RAM to service your load.

2 Likes