3 ms·

First off, very cool tool. README looks nice, demo looks nice, website looks nice, code quality looks nice, and in general the whole "product" aspect of it look

First off, very cool tool. README looks nice, demo looks nice, website looks nice, code quality looks nice, and in general the whole "product" aspect of it looks very good. My main concern is that your competitive advantage seems to be that you are a free /open core chat tool, but this advantage also attracts many bad customers. They'll want a chat tool that features-wise rivals a competing (paying) platform, but also with the added twist that, by being somewhat open-source, they'll also want support for their weird edge case setup that you didn't consider ("Why won't this work on a Raspberry PI?", "Can I use this on my company's intranet?", "Do you work on Windows 3.1?", etc etc). You'll add in more features and support for these things, only to find the rabbit hole going deeper and deeper -- and identifying the customers that are actually willing to pay becomes harder and harder as you have to filter out a lot of the low-quality requests. To help with filtering, you can push people to the hosted version where they have to pay, but now you've lost the competitive advantage -- and have to compete with the many other chat tools in the space. I think there's still a lot of room here, in the same way that Gitlab carved out a huge niche from Github, but those would be my main concerns.

areichert 6y ago
This is great feedback, and definitely something we'll need to think about. I had a similar issue at a previous startup I worked at, where we were basically building SaaS tools for logistics departments at commodity trading companies, and everyone had different edge cases/integrations they wanted from us. It's definitely a rabbit hole I want to avoid... You mentioned Gitlab, and we're trying to figure out how we can borrow from the playbooks of companies like them (e.g. Mattermost, PostHog, etc.) For now, we're just focused on getting users to figure out what the most common feedback and feature requests are, but longer term we plan on carving out a smaller niche and figuring out what our "target persona" is. Curious, do you have any advice on how to avoid these pitfalls?
- eggbrain 6y ago
  > Curious, do you have any advice on how to avoid these pitfalls? I can tell you some things I've found helpful, but I think sytse (https://news.ycombinator.com/user?id=sytse https://news.ycombinator.com/user?id=sytse) or antirez (https://news.ycombinator.com/user?id=antirez https://news.ycombinator.com/user?id=antirez) could give better advice than I ever could. Off the cuff, for me it always comes back to having a good filter -- which can take time to develop, and can depend heavily on what your goals are with the open core part of this, along with what the goals are of the company. For example, if 10000 users want support for feature X, but 10 users are willing to pay/upgrade to support feature Y, and these features don't overlap (or are mutually exclusive), you many need to make a choice as to which way your goals will point you. Luckily, there will be also a ton of features/improvements that will neatly overlap with everyone, and so you can make everyone happy as well. For prioritization of those, there's a lot of things you can do, but I always like this article's approach: https://www.defmacro.org/2013/09/26/products.html https://www.defmacro.org/2013/09/26/products.html. Another useful tool could be analytics -- the people that use your product the most are usually the people that become your biggest supporters, best suggesters, and paid clients. This might be a bit tough since if you add in an analytics tool to the codebase anyone could rip it out when they have access to the code, but you could do things like watch who is constantly submitting tickets / issues, reaching out via email, mentioning on social media, etc. Just some quick thoughts, but by no means am I an expert here.
  - areichert 6y ago
    Thanks for the reply! This is super helpful :) The defmacro article was a great read, definitely some great points in there. We're starting to realize how important having a good filter is -- a ton of people have opinions on what we're building, and we have to figure out how to distill/filter that feedback effectively (because a lot of it likely falls into the "distraction" bucket haha). re: analytics, that's also something we're trying to figure out how to do well -- like you said, it's tricky if folks can just rip out that code if they want to, but we're hoping that we can set up analytics tools that are beneficial to both us (for product insights) and our customers (e.g. to make sure everything is working well for them, alerting them to updates, etc) Thanks again for your thoughts!
AsyncAwait 6y ago
Not that you're necessarily wrong, but you can 'fire' those 'customers' too. The answer is not to not release as open-source. I find it a tad hypocritical that 99% of people who post on HN consume tons and tons of open-source every day and yes, they also want the edge cases to work and yet, not only are they not actively participating to make the body of free (as in freedom) software larger, they're actively discouraging people from contributing. From my perspective, it seems to have been a great choice to go open as far as increasing adoption/buy in for GitLab, why not this?
- eggbrain 6y ago
  > Not that you're necessarily wrong, but you can 'fire' those 'customers' too. For sure -- and you should! But in my mind, the goals of FOSS can differ wildly from a company wanting to release a great open source product, but also turn some of those users into paying customers. If your goal is simply the betterment of free software for developers, you take any and all contributions, as long as the code is of good quality and solves someones needs. If your goal is to figure out what features are needed by people who might be willing to pay if they were solved, you then have to figure out a way to filter the contributions and what you're willing to contribute back. It's just a trade off. > I find it a tad hypocritical that 99% of people who post on HN consume tons and tons of open-source every day and yes, they also want the edge cases to work and yet, not only are they not actively participating to make the body of free (as in freedom) software larger, they're actively discouraging people from contributing. Working in open source is tough -- it's many times a thankless job. I was one of the team members of Kandan (https://github.com/kandanapp/kandan https://github.com/kandanapp/kandan), which was a Slack clone with ~2.5k stars, and as much as we helped people, sometimes it also felt like it never was enough. One of the few helpful things that came from being true FOSS was that most people had an understanding that we did this as volunteer work, so they weren't upset when features or changes took long, or weren't merged into the app. But if the goal is to eventually move customers into other products, or onto a premium tier, it becomes a different game with different rules.
riffic 6y ago
It's so weird to see proprietary vs. free software concern trolling on Hacker News, yet here we are. It's 2020, I think people understand how to build a business model around FOSS these days.

areichert 6y ago

This is great feedback, and definitely something we'll need to think about. I had a similar issue at a previous startup I worked at, where we were basically building SaaS tools for logistics departments at commodity trading companies, and everyone had different edge cases/integrations they wanted from us. It's definitely a rabbit hole I want to avoid... You mentioned Gitlab, and we're trying to figure out how we can borrow from the playbooks of companies like them (e.g. Mattermost, PostHog, etc.) For now, we're just focused on getting users to figure out what the most common feedback and feature requests are, but longer term we plan on carving out a smaller niche and figuring out what our "target persona" is. Curious, do you have any advice on how to avoid these pitfalls?

eggbrain 6y ago
> Curious, do you have any advice on how to avoid these pitfalls? I can tell you some things I've found helpful, but I think sytse (https://news.ycombinator.com/user?id=sytse https://news.ycombinator.com/user?id=sytse) or antirez (https://news.ycombinator.com/user?id=antirez https://news.ycombinator.com/user?id=antirez) could give better advice than I ever could. Off the cuff, for me it always comes back to having a good filter -- which can take time to develop, and can depend heavily on what your goals are with the open core part of this, along with what the goals are of the company. For example, if 10000 users want support for feature X, but 10 users are willing to pay/upgrade to support feature Y, and these features don't overlap (or are mutually exclusive), you many need to make a choice as to which way your goals will point you. Luckily, there will be also a ton of features/improvements that will neatly overlap with everyone, and so you can make everyone happy as well. For prioritization of those, there's a lot of things you can do, but I always like this article's approach: https://www.defmacro.org/2013/09/26/products.html https://www.defmacro.org/2013/09/26/products.html. Another useful tool could be analytics -- the people that use your product the most are usually the people that become your biggest supporters, best suggesters, and paid clients. This might be a bit tough since if you add in an analytics tool to the codebase anyone could rip it out when they have access to the code, but you could do things like watch who is constantly submitting tickets / issues, reaching out via email, mentioning on social media, etc. Just some quick thoughts, but by no means am I an expert here.
- areichert 6y ago
  Thanks for the reply! This is super helpful :) The defmacro article was a great read, definitely some great points in there. We're starting to realize how important having a good filter is -- a ton of people have opinions on what we're building, and we have to figure out how to distill/filter that feedback effectively (because a lot of it likely falls into the "distraction" bucket haha). re: analytics, that's also something we're trying to figure out how to do well -- like you said, it's tricky if folks can just rip out that code if they want to, but we're hoping that we can set up analytics tools that are beneficial to both us (for product insights) and our customers (e.g. to make sure everything is working well for them, alerting them to updates, etc) Thanks again for your thoughts!

AsyncAwait 6y ago

Not that you're necessarily wrong, but you can 'fire' those 'customers' too. The answer is not to not release as open-source. I find it a tad hypocritical that 99% of people who post on HN consume tons and tons of open-source every day and yes, they also want the edge cases to work and yet, not only are they not actively participating to make the body of free (as in freedom) software larger, they're actively discouraging people from contributing. From my perspective, it seems to have been a great choice to go open as far as increasing adoption/buy in for GitLab, why not this?

eggbrain 6y ago
> Not that you're necessarily wrong, but you can 'fire' those 'customers' too. For sure -- and you should! But in my mind, the goals of FOSS can differ wildly from a company wanting to release a great open source product, but also turn some of those users into paying customers. If your goal is simply the betterment of free software for developers, you take any and all contributions, as long as the code is of good quality and solves someones needs. If your goal is to figure out what features are needed by people who might be willing to pay if they were solved, you then have to figure out a way to filter the contributions and what you're willing to contribute back. It's just a trade off. > I find it a tad hypocritical that 99% of people who post on HN consume tons and tons of open-source every day and yes, they also want the edge cases to work and yet, not only are they not actively participating to make the body of free (as in freedom) software larger, they're actively discouraging people from contributing. Working in open source is tough -- it's many times a thankless job. I was one of the team members of Kandan (https://github.com/kandanapp/kandan https://github.com/kandanapp/kandan), which was a Slack clone with ~2.5k stars, and as much as we helped people, sometimes it also felt like it never was enough. One of the few helpful things that came from being true FOSS was that most people had an understanding that we did this as volunteer work, so they weren't upset when features or changes took long, or weren't merged into the app. But if the goal is to eventually move customers into other products, or onto a premium tier, it becomes a different game with different rules.

riffic 6y ago

It's so weird to see proprietary vs. free software concern trolling on Hacker News, yet here we are. It's 2020, I think people understand how to build a business model around FOSS these days.