Jeff Atwood on growing Discourse
indiehackers.com
indiehackers.com
I have no idea why this user-hostile functionality is present by default. It breaks ctrl+F, ctrl+S, the scrollbar, and loads of other browser functionality.
StackOverflow has such a nice UI and UX. The UI is nice in Discourse too, but its UX needs more work. Bigger forums are hard to follow, infinite scroll comes with its own problems. The themes waste too much screen space.
Post counts: a metric for how long they have been here, also an attempt to let new members know if this person knows what they are talking about. Yes, post count is a poor metric for level of knowledge, but measuring level of knowledge is not an easy problem(see controversy over IQ tests). Displaying upvotes could be better, but see reddit where people post the same dumb jokes to farm karma, or steal jokes from other subs.
Signatures: People like to express themselves. I'm not a fan of this one either, but hey. It can be useful when you see someone say something intelligent/helpful/etc, and their signature has a list of threads they started. You might find those threads filled with useful info.
Badges: This encourages desirable behavior. It can also help identify those who have a high level of knowledge.
I would add avatars: Have you every heard someone say they can remember faces, but not names? This is an attempt to help members identify each other.
Edit: post metadata: seeing the number of upvotes on a post gives you an idea on whether it is true or not.
This itself causes some issues (like with spammers joining simply for the 'SEO' benefits), but it's enough of a pattern that changing it will often kill a forum dead, especially in the webmaster/tech/marketing field.
Other things that encourage members (but that are often seen as clutter) include reputation systems (like the green bars vBulletin had), forum cash (points given for posts and other actions), fictional shop items (purchased with said forum cash), etc. Again, a lot of people on these forums rather like said systems and often find them useful, even if to an outsider that might be seen as overwhelming.
http://wiki.c2.com/?SecondSystemEffect
(C2's new design is a bit of that in itself, IMHO.)
If I know something useful is on page 10... well I'm just out of luck.
>At least with numbered pagination you can choose to view page [whatever] to narrow down the posts you want to view
Assuming you mean sequentially, isn't this the same as scrolling but with a click involved? If you don't mean sequentially, how would you know which page to click?
>If I know something useful is on page 10...
How do you know something useful is on page 10? Is it normal for forum users to remember specific page numbers within a post?
I also like page sizes as "breaks" to follow up on links etc.
Discourse's implementation of infinite scroll isn't all that bad (it keeps position properly and doesn't seem to have strange glitches, although I haven't tried it on a bad connection), and at least navigation elements are there. But they feel strange and trip me up every time: the secondary "scroll bar", or in thinner browser windows the "progress bar" at the bottom that overlays the post content and you have to click to get the scroll bar pop up. It feels like a mobile app, half-way designed for touch, not a forum.
In a paginated thread, you can only Ctrl-F for stuff on the current page, and Discourse is no different; it's no more "broken" than a traditional paginated forum with manual page turning. Similarly, you can only Ctrl-S to save the current page, not the whole thread.
Many forums have a "search in this thread" feature, and Discourse does, too. In fact, if you click in the page and press Ctrl-F, it intercepts the keystroke and shows Discourse's "search in thread" search box; some forums with manual page turning do the same thing.
Some people seem to get really pissed off at automatic page turning; I kinda understand why, but there are clear arguments for automatic page turning. Why make the user click "Next Page" when the software could do it for you? You'll notice that all of the most popular feed-based sites (Facebook, Twitter, Pinterest, Instagram) use automatic page turning, too, and that's because experiments show that people engage more when automatic page turning is enabled.
None of this will make you any happier with APT, but hopefully it will annoy you slightly less to know that this is a data-driven decision and not done specifically to annoy you.
Here's a thread with 970 comments for example:
I guess I usually simply stop scrolling before I get to the very bottom of HN.
Just to be clear though, are we talking about a "next" link at the bottom of the page, or Reddit-style "continue" links for subtrees of comments beyond a certain depth?
Also this 4MB number isn't correct; I count 700kb. Feel free to double check my work:
Jeff, I respect you, but I don't understand where you are going with that comeback.
Namely, even with bloody awful markdown, HN still delivers 1000 comments in 1/4 of the bytes.
Another interesting idea, as almost everyone doesn't actually comment, wouldn't it make more sense to load the editor javascript dynamically? As far as I know, the silent majority read comments but never reply. In fact, I vaguely remember Jeff even having a blog post that most people never participate, they just consume (could be wrong!).
Also, I haven't kept up with it, but mobile browsers used to have fairly aggressive cache invalidation to save space on the phone, so serving big chunks of JavaScript in the hope it might get reused one day wasn't actually a great idea.
Are you sure this is correct? I count 700kb of total content (including the actual HTML and CSS), not 4mb, so I think your comments are premised on a number that's off by almost 6X?
So how you feel about this depends on "how often you use the app". If you only plan to visit that one page, ever, then it's not a great tradeoff (though 700kb -- no idea where you are getting 4MB from -- of images is basically nothing on a webpage these days). If you visit many discussions and many pages, it's a win.
In other words a single discussion doesn't need 4000 comments, you just need to read 4000 comments across all discussions all time. I'm not sure your math is correct here, either: I just visited meta.discourse.org in incognito mode and I see about.. 700kb of javascript?
I'm sorry but I don't know where you are getting 4 megabytes out of 700kb. See above screenshot.
Answering Macha, below:
- Your chosen example is missing http/2 so requests aren't batched
- Discourse homepage by default shows user avatars for each participant, up to 5 in each topic, so there will be "more images"
I suggest testing with meta.discourse.org (hosted) or discourse.codinghorror.com (self-hosted) to make sure you're looking at apples to apples, and properly configured sites.
72 requests, 50s load time, 3.5mb data. It would have been smaller if you'd served the screenshot of the page.
HN for comparison:
6 requests, 50kb, 0.72s
Now how about your contemporary forum competition.
Here's a Xenforo forum:
http://i.imgur.com/tlzZ5WN.png
19 requests, 2mb, 5s
And that's with the massive background image you can see, which is 1mb in size by itself.
EDIT:
Since Jeff stated the comparisons weren't apples to apples, xenforo.com/community vs meta.discourse.org . Both boards running in basically stock configuration from their own sites:
* Xenforo.com: 43 requests, 1.4mb, 4s
* meta.discourse.org: 73 requests: 3.2mb, 4.5s
Definitely a better showing than the ACEO forums, but still loses the comparison.
Too lazy to take more screenshots, but reddit is 50 requests, 1.3mb, 3s for comparison.
I'm unclear where you are getting 3.2MB from, since sorting by filesize, here are the largest network requests at meta.discourse.org:
As you can see, starting at 11.5kb and below it's all images (avatars).
I suppose you could try with images disabled. If you want to make a case that 'not showing avatars by default uses less bandwidth', then I guess I can agree with that. But these images won't affect actual load time, as images rez in later, and all the dimensions are set on the page.
Regarding the 4mb thing, I pulled it out of 1wd's comment. It would be best if 1wd came back and explained. That said, I believe the discrepancy is probably between the size of compressed javascript in the network and it's uncompressed size. Firefox dev tools show 3.1mb for meta.discourse.org. I don't know how to view the total size in Chrome's dev tools, but if you click the "use large request rows" in the Network tab you will see that application.js by itself takes up 1.5mb.
This brought me to thinking why browsers still save page as source code and not as serialised actual DOM? I mean developers still could use curl to save source code, but regular users will save what they see on the screen, similarly to printing to PDF.
I know this because I once saved a JS-heavy page and when I loaded it back into the browser, I discovered the JS-generated menus were already present in the source and were re-generated by the JS each time the page loaded.
yes, regenerated because js files are also stored. So the menu generating functions and all constants needed to generate menus were probably present in downloaded js files. But imagine, site that is also fetching data via ajax and render that data somehow. When you save and then reopen saved page, you might not get exact state as you were in time of saving. There are many reason why state would be different (you could be logged off, etc...) So if you send saved page to somebody, he/she will see different state of page than you. All of this could be eliminated if browsers saved state of DOM instead of page source code (and js,css resources).
I don't think it's the case that I and other users don't know what we want. I do believe that "people engage more" on infinite-scroll-style pages, but I have no reason to believe this makes them happier or more productive. On the other hand, the jerkiness/glitches, breakage of common navigational tools, and slowness of Discourse pages are very annoying.
I should have been more descriptive than simply saying "broken", but I figured I was probably preaching to the choir and so I didn't go into details. In particular, it becomes much harder to use tools like ctrl+F and ctrl+S because the page content is dynamic and after scrolling down a little there's no way to easily tell which bits of the page are still loaded and which aren't. ctrl+F is useful not just for initially locating a key phrase, but also for jumping between bits of the page you've already read for comparison. In a manually-paginated thread this works fine, and I know for sure whether posts are on the same page (where I can use ctrl+F) or different pages (which I can open in separate tabs).
Basically, it becomes very difficult for a user to maintain an accurate mental model of the page content that they're using a browser to interact with. This is quite different from static pagination systems, where scrolling never changes page contents.
The scrollbar really is broken, because users expect its size to show the length of the page, which no longer holds for Discourse or other infinite-scroll pages. The fact that Discourse unloads earlier content makes this even worse, as you can't even remember an old scrollbar position to scroll to something you just saw or scroll halfway to the top to go halfway to the start of the page. Yes, Discourse does provide an alternative way to see some of this information, but user interface changes (having to move from the native scrollbar to the Discourse summary box) are frustrating for users: they break muscle memory and require learning a new interface, since they never work quite the same as the other one.
It makes me no less upset to hear that data was involved in the decision to ignore users' needs. I don't think it's intentional to annoy users, but hearing that there was some level of analysis involved rather than mere accident is upsetting because it shows the slight to be willful. I don't think websites should push worsened usability on their users in the name of driving up engagement metrics.
I think the arguments about automatic vs. manual page turning mostly come down to questions of control and implementation quality: users want to be in control (because the computer is a tool, and tools must be predictable), and it's difficult to avoid bugs when implementing automatic page turning on the Web. I'm not sure exactly why the latter is the case, but I've never seen a system without glitches in the history list, visual glitches, or slowness.
He appears to have accepted your statement without hostility and provided a fair reply. Please be careful not to interpret the lack of a pandering tone or excessive niceties as condescension. Remember, project runners hear complaints all day every day, they're never going to be able to make everyone happy, and this is a technical audience.
I can read "War and Peace" [1] as an HTML document on my 7 year old cheapo Android phone. The browser even "streams" the data, displaying each chunk as it loads over a slow connection.
As far as I know, you're correct that all forum software I've used paginates large threads, but I'm curious if they "have" to - as in, I think a team could probably build forum software that didn't paginate large threads (for reasonable definitions of "large") and still have good performance on a wide range of devices, if they were willing to make the necessary trade-offs. Whether those trade-offs are worth making, I don't know.
You can get and read War and Peace (or other similarly large books -- I frequently reference Adam Smith's Wealth of Nations) at Project Gutenberg. As a single HTML file.
The ability to search for any particular text instance within that document through browser capabilities is useful.
As is, I agree at times, the ability to present the information as some sort of consistently paginated context.
I'm thinking that somewhere between the 21st and 42nd centuries, computers might advance to a state where this is in fact possible.
I suppose you're going to respond with something along the lines of "because it's better than the browser's search function".
But again: why is that?
Why do the built-in browser tools suck as badly as they do?
Example, outside of search: I realised some months back that a chief reason we have browser Reader Mode features, to uncrappify crappy site CSS, is because browser default styling ... is so horrible.
And again: why is that?
Why do we have craptastic CSS entity defaults when, with a very little work, every page could look, without any styling at all, pretty damned readable:
http://codepen.io/dredmorbius/full/KpMqqB/
(And if that's not your cuppa, then themes such that you get what you want -- Night Mode, or whateves.)
Whatever browsers are being built for, it's not the people actually using them.
/me looks suspiciously at Chrome => Google => Advertising....
Gee... I wonder why that might possibly be.
Again: why is cabapility-in-the-browser so impossible to provide?
Why isn't "search post" vs. "search comments" something scoped into a browser? If comments are a ... not entirely novel or unknown concept within Web design and activity, why are the abilities, say, to have browser-generated lists of authors, or search by author, or post/comment distinctions, or persistent reputations of commentators so that I can tell if @dredmorbius@news.ycombinator.com is just an asshat or a space alien cat who really knows where his towel is (and independent of whether or not dredmorbius maps to any particular known "real name")?
It's not like the question's just come up within the past 5 hours.
Really: Why is the browser so fucking limited in this regard?
Even Chrome on my i7 doesn't instantly respond when loading those Gutenburg URLs.
I already knew where the post was, because I scrolled down to it. I don't need to be told where it was, I need to know where the specific phrase I searched for is.
I've seen complaints about it from the past, but given that 3 years has passed and it's still like that, I just give up any hope of being productive when having to use a Discourse site.
Unfortunately, they blew it. They created an over-engineered, over-complicated, bloated, heavy mess. Jeff bet on Moore's Law meaning that bandwidth/speed would eventually negate the bloat, but instead the world moved to low powered devices with mobile bandwidth.
They've spent years trying to get infinite scrolling working OK and installation OK. Why? Imagine if they'd actually used all their brainpower on features that forum owners actually wanted: automated spam tools, automated admin tasks, one-click install to any hosting plan (yes using PHP if necessary).
All the years of wasted talent, and now the other forum products have overtaken them on usability/maintainability. And they are STILL trying to fix the hijacked browser search feature, that you get lost in infinite scroll, and that you need to run a separate VM to run something as simple as forum software.
LESSON: beware second-system-syndrome, beware the CEO who has personal tech vendetas which are misaligned with your product strategy, and beware creating a team consisting solely of talented engineers who will do one thing: OVER-ENGINEER.
We're supposed to be building software with the users, while observing them, while participating alongside. This takes a few years to get right.
No plan survives contact with users, and that's as it should be.
I ran my own Discourse forum for a while. Users liked it well enough, but eventually I switched to using the free Steam community forums (it was a forum for a game) because it was costing me every month to run a separate server for it on Amazon.
During Discourse's life it also changed recommended install methods and auto-updates would occasionally break, so it was work to maintain. To be fair a lot of this was on relatively early versions.
I also found the Ctrl-F breaking and infinite scroll much more annoying than useful and tried to tell them[1] along with others. They listened somewhat and switched to only taking over Ctrl-F on long pages, but it's still not great. In fact I just tried to Ctrl-F for my post on the page I linked and got taken to my profile page instead.
[1] https://meta.discourse.org/t/discourse-taking-over-ctrl-f/16...
My instinct when I'm looking for something is to Ctrl+F, not scour the UI for a search bar.
Anecdotally, I know people who are not programmers who are the same way.
Maybe a better compromise would be including a modal or a hint highlighting the site-wide search box without suppressing the native Ctrl+F functionality.
Imagine Jimmy wants to know how to pin a topic on a Discourse forum. He searches Google for pin topic discourse or whatever, and he sees a result with a text preview saying "...icon in the upper right to get the staff menu for the topic; select Pin Topic."
That looks right, so he ends up here: http://www.phylobabble.org/t/discourse-admin-quick-start-gui...
That's a big post, so he Ctrl-F searches for "pin topic". Normally his browser would already be highlighting the text in the post, but nothing happens, so he tries clicking on the only result. This just refreshes the page and puts him back at the same post.
At this point Jimmy either leaves the forum to try another result that doesn't hijack his browser search, combs the whole thread manually, or mashes Ctrf-F enough that he discovers the Ctrl-F-F override and types "pin topic" again, instantly highlighting the section that he wanted all along.
Perhaps that's an option should you choose to self-host again? :-)
> one-click install to any hosting plan (yes using PHP if necessary).
Breaches on popular PHP forum software account for a disproportionate amount of the breaches we regularly hear about. It's caused issues for Linux Mint, Ubuntu, and the "Cosbycoin" compromise is hard to forget. I can't complain about any particular vendor because they have all had their share of issues in this space.
Yes, you can write good PHP - but start saying "one click on any hosting plan" and suddenly composer is out the door, every file is owned by the user the web servers runs as and you start pollyfilling for ancient versions. It means you can't assume SSL will exist, it means you can't get updates using git or any sane automation strategy, and look at how Wordpress deals with cron.
Wordpress is regularly lambasted for their support of ancient versions of PHP, which is something they do primarily to meet this goal.
In interested in what other options are out there. I rarely see Discourse on the open Internet and I cringe every time I get tempted to sign up to an old SMF or vBulletin installation.
Questions about feature priorities or technical architecture were met tersely and with a demand to know what kind of software I had ever built personally. So he wanted my resume rather that just discussing the merits of whatever topic.
Wasn't going to mention it but somehow your comment seemed to click.
Not sure what you mean about a tech vendetta, sounds like the tail end of a story.
"I’ve started to research Discourse as a general solution and started with embed capabilities. To be frank the whole situation seems to be a bit of a mess."
To be frank, I would describe what you posted more as rants than actual discussions about features. You wanted Disqus and were pretty rude about it. That's not what we're building at Discourse. If you have a problem with that, sorry.
seems apt, lol
https://meta.discourse.org/t/embed-discourse-comments-with-o...
I fully acknowledged the difficulty of your task, and tried to break down feed back into specific, actionable items.
Getting constructive criticism is not always fun, but it's part of our job. Besides that some people posting there are potential customers. Why call them ranters instead of a simple, we agree to disagree?
I think he's a great example of power of doing things. He didn't start a blog with any objective other than just to write. And he wrote prolifically. If you follow his blog posts, you'll realise that he's rarely more than a person who loves computers. But, because he did things without dissuasion, he kept improving, until the success started building on his efforts.
But no one should ever like they can't achieve anything just because a bunch of people don't like them or say mean things.
Just continue to do what you enjoy and ignore those who don't care for your passion.
So many devs and "idea guys" dismiss flawed ideas and wait around for that one great idea that will launch their career, not realizing most popular libraries/sites/etc. started as a pretty basic and flawed concept that was iterated into a work of art.
Ideas are worthless, execution is everything.
So probably what this article is saying is that the key to make money is to build yourself a name, then use it to sell crappy software and sell the support.
It's certainly not as simple to get started as with Nodejs npm or LAMP stack. But there are already easy to install discourse forum clones that use Node.js or PHP as backend language (use Google to find them).
Edit:
two of several clones that run on Node or LAMP stack (I am not related to any of them)
Nodejs: https://github.com/NodeBB/NodeBB
WordPress (and most traditional forum scripts like phpBB) work fine in these situations. Just upload a few files, set up a database and run the installer to get the thing working.
Discourse doesn't. It also generally isn't integrated into one click install software like Softaculous or Fantastico. This means that the audience using a typical shared host like Hostgator and clicking a button in their CPanel to set up their site can't easily use Discourse like they could WordPress.
So yeah, that's an issue here too. Discourse just requires too much control over your server for most shared hosting accounts and can't easily be integrated into one click install setups/setup by merely uploading a bunch of files. So the mass market won't ever touch it.
I'm honestly not a huge fan of Jeff Atwoods, and that started long before he started SO. To me it just feels like he's a bit too idealistic in his approach to things.
Also, id like to hear what's the reasoning behind using MongoDB for a forum. I mean, I'm just learning this stuff but a forum seems to be a perfect case for a relational DB.
I'll take a shot in the dark and say that the advantage of using a NoSQL platform to host a forum is that you can very quickly load all resources relating to a post by storing them in one database document.
That does mean you probably need to polyfill certain functionality, but the traditional case for NoSQL is made by saying a blog can load a given post's comments, media, etc. with one query. Forums are a similar animal.
NoSQL is great for prototyping and being productive fast, but that productivity comes with a lot of pitfalls. Pitfalls by the way that many devs have been blissfully ignorant of for decades because they have been insulated from them by normalized relational databases.
Unless you are experienced with/aware of those pitfalls, I would almost make a blanket statement that a traditional SQL database should be the default solution for the backend until you can explain why NoSQL is a better fit for a given project.
Also, what makes you think PostgreSQL is slow? What is "slow" to you?
I have to say the folks on meta.discourse were helpful though.
In the end, the users decided—I ended up integrating a Mailman 3 server with the website, and we're in the process of switching over to it. The users preferred the simplicity of LISTSERV-style mailing lists over a web forum. This probably would've happened no matter the choice of forum software, but I can't help but think Discourse's unpleasant UX played a part in them reaching that consensus.
I've done a few updates, and it was all entirely via the web interface, with a single click on "Update" button and watching it do its thing. Zero issues so far.
I'm not sure what you mean by "ton of configuration". It seems like most things just worked the way they were set up out of the box. I keep fiddling with various user- and posting-related settings, but that's mostly out of curiosity more than any kind of need.
I used to do all these installs for people by hand, and personally support them to ensure that we had indeed built something that was easy to support long term. I stopped doing this after a few years because I knew we had.
https://community.developer.atlassian.com/
I didn't really quite grasp the full picture of what was going on before. Seemed to be a mix of google groups and confluence. This is much better. Also interesting to see Atlassian walking away from their dog food in this case.
EDIT: Oh, how awkward. Yes, I was thinking of Discord.
There is at least one reason: to share a code base between the web and "desktop" version of the app.
If I had to defend it, though, I'd say that _every_ indie startup has seed money. Most of the time, it's from the founder, who commits their own time and money to the project. In this case, they got others to commit their money.
But it's definitely a blurring of the line between indie startups and rocket ship startups.
If that's the defining feature of an indie startup, that it's counter to a regular startup, then being self-funded is only one of many ways that indie startups can differentiate themselves.
All that said, I think the information from the interview itself _is_ valuable. As long as Indie Hackers doesn't become flooded with non-indie startup stories, and as long as the readership is aware that the lessons Jeff Atwood learns may not be applicable to them (which is true of any story on Indie Hackers, really), then it's okay.
The reality of a big shot in SV raising venture capital money is a lot different of mine, a struggling "indie hacker".
I'm not actually sure what Indie Hacker's idea of an idie hacker is.
There are all kinds of people who give "useful advice" that could, in theory, help an indie hacker, but are actually aimed at a general audience. In the extreme case, consider diet and beauty tips, relationship advice or stock investing strategies. Yes, those things are useful to many if not most indie hackers but they're also easily found on more general sites and can easily crowd out more focused content.
It's because, for me personally, the thing that makes IH special is the stories of people who didn't have degrees from elite schools, family wealth or VC funding and still successfully built something sufficient to cover their living expenses or even start hiring employees. Stories about people who do a lot with a little are a blueprint that can be applied by people of just about any background. Stories of parlaying medium-sized fortunes into large ones are most useful to people who already have medium-sized fortunes.
To be clear, I don't dislike interviews with founders of large companies. I sometimes watch them on youtube and have read books about many of the largest tech companies. It's just more useful for me to learn about how people went from 0 to 60 rather than from 60 to 200.
IH is still my favorite place on the internet for that, which is why I care about how well it serves that role. You'd have to dilute it quite a bit before it fell behind the next best alternative, though.
Personally, I'm partial to early-stage tech bootstrappers, which is one reason why I've interviewed so many people from that niche. It's just a lot more near and dear to my heart, and those are the people who tend to struggle to get coverage elsewhere.
But it's worth branching out, because other entrepreneurs have valuable experiences to share, too. And to the extent that we can get even well-funded companies to share their revenue numbers and behind-the-scenes strategies, that's a good thing for all of us imo.
[0] https://www.indiehackers.com/about
[1] https://media.giphy.com/media/l4FGycUhVUpsBuoqQ/source.mp4
So... once you hire your first employee and the staff is no longer exclusively founders/owners... the founders/bosses are still 'indie hackers', but the employee is not? Or none of them are anymore, you can only be an 'indie hacker' if the entire staff is founder/owners with no employees?
When only bosses can be 'indie', hmm. I guess that is a pretty good synecdoche of a certain kind of bay area techno-capitalist-hipsterist ideology.
At the end of the day, we can spend a lot of time bike shedding about semantics and the name "Indie Hackers," but what's more important is the overall purpose behind the site — a place for entrepreneurs to learn from each other and share their experiences transparently. Sometimes those entrepreneurs will be the Jeff Atwoods and Bezoses of the world, and that's just fine.
Disagree with this statement. There is money to be made in the low end market, and it's not as bad as you expect it to be.
Some products just aren't an upmarket product...mobile apps, for example. But, if there's a way to target your product to people who have a budget, you're going to have a much nicer time scaling up...you'll have money to hire people (and to a lesser degree, other resources that cost money) to do so. It takes a lot of $5/month sales to pay for one employee. But, $200/month sales add up really fast.
In that context, this is excellent advice. Once the product is built and already making you money, then you can easily pivot and see if there's any profitability in marketing the now-sustainable product to the lower end segments. But don't start there unless you really know what you're doing, because the low margins in that market amplify your risks.
I have the exact opposite experience. I really like discourse. We run it now since two years with exactly one issue when I did an update, but that was more or less my fault being not on 'stable' but on 'beta'. Self-hosting is not complex although I wouldn't want to do this without the docker they offer.
What I like about discourse
* discuss in real time (!)
* if you prefer email then you can get it, ask questions via email or get answers there if you are not online
* mute specific topics or subscribe only to a few categories
* you can like answers without having to say '+1'
* simple to self-host IMO
* open source
* our community likes it too ('it is simple to use and does what it should')
* the inbuild search is good
There are parts that work better than with Github:
* The email response is bundled over 10 minutes before sending, reducing emails a lot and allows for fast edits!
* you see in your notification where you get likes (you don't get emails because of this of course)
What I don't like:
* performance feels not that great for longer threads (similar problem on github IMO)
I don't think I ever saw a successful community run on top of discourse.
1. The people who like internet forums and more traditional communities don't seem to like it very much, and prefer sites using traditional scripts like phpBB or vBulletin or XenForo.
2. Those who find forums outdated find Discourse as or even more confusing than traditional forum scripts and don't really see the point in it.
So the succesful forums opening at the moment pick something else, because that's what their userbase wants. The ones trying to use Discourse for something new struggle because the software is offputting for their members and doesn't attract the new audience Jeff Atwood thinks it will. And the sites that switch to Discourse usually realise only too late that A: their forum problems are often down to their management and the state of society rather than the software and B: that their regulars detest the new design.
Discourse just doesn't seem to appeal to pretty much anyone.
But make sure you never mention it explicitly or else millions of angry users from a country will give a 1-star rating to a totally different app that happens to sound a bit like yours.
I'm interested in how to grow community. They started with press release, got 3 customers by offering them everything free + full "white glove" support, court more paying customers, scale infrastructure.
Still, if you want peace of mind, try selling to people who don't have money, but who will also not require you to give them support night and day, to write complex contracts and have a lawyer, to have a dedicated helpdesk and to write custom code for.
If you want money, money and money, ok, this is probably fine advice, but not all people want that. Many people, I believe, want to write software they enjoy.
Which is pretty tricky if you don't have money.
As opposed to optimizing your product so that poor people can enjoy it too.
It's free software.
They compete with existing frameworks to solve problems starving devs are having instead of looking around for the problems that small to medium-sized businesses are struggling with and getting little to no help with.