Live data from Hacker News

Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

news.ycombinator.com

71–80 of 112 posts

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#73
post #24

Since you are an open core business, how do you plan to deal with the situation where the community contributes features that are already in the proprietary enterprise version?

This is a hard decision to make. It would be considered on the basis of a couple of things. If it is derivate of already existing code, we would suggest not to do that. If it is an original work, then we would consider those. Having said that, we want to reduce such kind of conflicts happening in the community. So we would try to limit an entire module under EE License rather a part of it.

> So we would try to limit an entire module under EE License rather a part of it.

As someone not familiar with this license, can you expand a little more into what it offers?

Also another option for this is for you guys to maintain your own branch which would be used for the free hosted solutions so any enterprise feature PR's can be contained to the self-hosted option.

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#74
Oh, wow. I used Chatwoot in the past, happily surprised you went through YC! I did have trouble self-hosting once, I think I had to enable task queues in my Heroku or something. I might've eventually switched over to the hosted option which was much easier. I would use Chatwoot again on my current startup (https://learncoupling.com).

Is there Discord/SMS or Zapier integration?

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#75

Oh, wow. I used Chatwoot in the past, happily surprised you went through YC! I did have trouble self-hosting once, I think I had to enable task queues in my Heroku or something. I might've eventually switched over to the hosted option which was much easier. I would use Chatwoot again on my current startup ( https://learncoupling.com ). Is there Discord/SMS or Zapier integration?

We have sms channel available via Twilio. Discord / Zapier are integrations are there on our roadmap.

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#76

MIT license. Easy to copy and host cheaper. Curious how long this will work before you change it.

We have a enterprise edition in works. We will launch it soon. Whatever is MIT now, will stay as MIT.

Hope MIT core/features will continue to be improved, not abandoned. Adding new large features as enterprise only makes sense.

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#77
post #23

Product looks awesome! So for my understanding - to add email channel you have to forward an email to single monitored inbox, correct? What email protocols do you support?

That is correct. Our email channel is an implementation build on top of Rails Action mail box. It support ingresses for Mailgun, Mandrill, Postmark, and SendGrid. You can also handle inbound mails directly via the Exim, Postfix, and Qmail ingresses ref: https://guides.rubyonrails.org/action_mailbox_basics.html

Please consider adding Sparkpost support too.

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#78

No phone support though? That’s why we have to use zendesk...

We have had requests for phone support. At the moment, our primary focus is on text based messaging. We will get to the phone/video part in the future. We want to make the software simple and easy to use. Setting up Asterisk and using it with Chatwoot was too much to handle. So we deferred that work for now. We will come back to it later.

Good choice!

Re: Launch HN: Chatwoot (YC W21) – Open-Source Alternative to Intercom, Zendesk

#80

Earlier quoted context omitted.

This is a hard decision to make. It would be considered on the basis of a couple of things. If it is derivate of already existing code, we would suggest not to do that. If it is an original work, then we would consider those. Having said that, we want to reduce such kind of conflicts happening in the community. So we would try to limit an entire module under EE License rather a part of it.

> So we would try to limit an entire module under EE License rather a part of it. As someone not familiar with this license, can you expand a little more into what it offers? Also another option for this is for you guys to maintain your own branch which would be used for the free hosted solutions so any enterprise feature PR's can be contained to the self-hosted option.

Handling separate closed fork is one of the solution. Historically, it is an overhead for the team managing the project. You can read about the experience shared by Metabase [0].

[0] https://www.metabase.com/blog/Opening-Metabase-Enterprise/in...

Post reply on HN