> We’re a YC-backed indie video game company releasing an open source alternative to Slack.
Don't want to troll you guys here, but if you're a video game company why are you spending so much time building a Slack clone?
I was expecting some short of explanation in your blog post like "we did this because this serves as a core piece of our company for X reason and Slack didn't fit our use case for Y reason".
> Don't want to troll you guys here, but if you're a video game company why are you spending so much time building a Slack clone?
I think a better perspective is that this is a tool they needed/wanted and built it - it's really no different than a map editor. Also some companies like Google have a X% time to work on a "personal" project during work hours - and this could be the result of that.
I can't tell if you're aware of the coincidence, but did you know that Slack was a pivot from game development just like Stewart Butterfield's previous unicorn Flickr?
What's wrong with that? Many great products started at companies which are not "supposed" to do that as their core business. Pivotal Tracker is one thing that immediately sprang to my mind. Why do you want to strictly limit what a company is working on, and potentially kill great ideas anyways. I believe as long as they're still functioning, their game development business is probably totally fine. The same applies to a person: I don't believe if you work on something as a full-time job you're then not allowed to have your hobbies, side projects(some of which are quite huge in scale) and personal interests. That would be horrible.
> Teams who can’t use SaaS rely on cryptic, decades-old technologies. As an example, the US Army uses myIRC to order missile strikes
"myIRC" doesn't exist. The name of the protocol is IRC. The name of a popular Windows client is mIRC. WikiLeaks called their leak "mIRC logs," which is where this trope came from.
The United States military (not just the Army) uses Internet Relay Chat for a whole lot of C2. It runs on a network, both IRC and IP, dedicated to the purpose. Given how long IRC has been in existence, that they've been doing it since the early 90s, that the use case is the perfect ideal for IRC, and that the average modern Web app is less reliable than my last Datsun, I have a hard time finding incredulity at sticking with something that works.
Even beyond that, IRC is text-based. It is not cryptic. An IRC client is a common first software project. About twenty lines of Go gets you a bot. You can make IRC look exactly like Mattermost with a week of hacking in your favorite framework of choice, and then you're not reinventing fanout. Entire products have been built atop IRC.
Even beyond that, guess how many protocols are decades old in just the software development workflow for this product. Pretty tired of "that's old, let's do it better," even though I hate finding myself on this side of defending IRC.
IRC federates easily, requires minimal resources, and is vastly more efficient when it comes to bandwidth usage. (you'll notice this over satellite links)
Yes, but Slack is slick, plaid, and even gorgeous.
Seriously, these days it seems most software like this is judged purely on its external styling and aesthetic beauty. You're right, Slack has no new features over IRC or any other decent chat clients in the past. But read any article that praises slack and if the slick UI (or whatever adjective is in style these days) isn't mentioned up front and center, I'd be surprised.
Of course the UI's 'slickness' and 'modernity' would be top discussion points for people writing such articles as they're usually not technical enough to argue the merits of tabs vs. spaces or braces vs. non-braces which the creators of such software usually argue about to the detriment of real issues.
Can you recommend your favorite protocol OR app for a small dev company where we share files and want to keep a centralized area where team members can chat, using various apps (or web interfaces)? The more robust the better, doesnt have to look amazing!
From the look of the screenshots ( http://www.mattermost.org/70-2/ ), I'd say there are some copyright concerns with the styles. This isn't a Slack alternative, it's a Slack clone. That's very problematic from a copyright stance. Why not create your own design style?
There's been a number of questions of what's coming from Mattermost, and how we design things. I wanted to share some raw, unpolished work we have of what's coming up.
It's a feature called "App Center" that we're working on to support 3rd party applications.
Would you find this interface interesting for building 3rd party apps?
What do you like about the design?
What do you wish we changed?
There's a couple 1st party Apps we'd start with, like an Admin Console and a Custom Web App. We're thinking there could be a marketplace for 3rd party workflow apps.
Example: create an "Expense Report" app where a user can upload the photo of a receipt from lunch from their phone and type "#expense #meals" and have a 3rd party app create a labeled expense report that would be viewable in App Center.
Would love to hear thoughts from the community. This is an early idea, it's just a Google Doc right now. Your input would help shape it.
One thing I really like and appreciate is that there's a dockerfile right in the root of the project, which makes spinning up a container a relatively nice experience... haven't run it or looked into the code though... that just struck out at me...
Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appears to be react based.. not sure what's running in ruby.
I think it's nice that they support Docker, but I was disappointed that their entire installation instructions were "install docker then run our image". I had to read the dockerfile and the "start" script to find out what the actual dependencies and setup steps are.
I definitely appreciate projects having Dockerfiles included, but yeah, that's not a good one. They should simply include instructions about how to link it to MySQL/Redis, or use something like docker-compose.
The way it's done now makes it inherently unscalable. Also, there are so many steps that it makes pushing an image to a Docker repository a massive pain.
What a horribly uncreative rip off. That may sound harsh but I'm a bit floored that this is getting so much attention...but YC right?
Reproducing functionality and growing an idea is fine. It's the blatant disregard to UX and UI where this company has literally pixel for pixel ripped off slack.
> It's the blatant disregard to UX and UI where this company has literally pixel for pixel ripped off slack.
I'm finding it hard to parse this sentence. Are you saying ripping off Slack is the blatant disregard, or are you saying Slack pioneered a blatant disregard for UX and UI?
Once a month an “insert something tech-related here” company releases an open source slack clone.
While I am grateful to all you guys, how much free time do you have to work on these clones instead of your main product?
I've tried so far let's chat and rocketchat and I liked them. I will give a spin to mattermost and I am sure I will like it too.
I think the one that matures first, will be a big hit because we need a slack clone —as evidently shown. But also as with any other open source / free software project it will need commitment.
That's all good, but the differentiating factor of Slack over Hipchat & the like is how well it integrates with everything your team is likely to use. It works seamlessly with Github, Trello and IRC.
I don't mean to devalue this product at all, but This is not a viable Slack alternative, it's a generic (and good looking) communication tool. This said, I commend the open source approach, it could probably help the product evolve towards something much better and integrated.
I've run numerous IRCd's for decades. They are completely stable and scale to 10's of thousands of users per VM. I can't even remember the last time I had one crash. There are already tons of integrations for IRC. It is just difficult to get people to understand the simplistic beauty of IRC. People like "shiny", as mobile phone addictions have proven. There are not many great web front ends for IRC that are secure at the same time as being shiny.
It is more oriented towards real time and spontaneous conversations, but my Firestr project is a p2p chat/app platform. I am working on the idea of more persistent conversations. Check it out, it is still alpha but works well. I am always open for help to make it more awesome too.
Such self-hosted services might help us a lot, as Slack is currently blocked in China already. I think the two main reasons are that the Chinese government is unable to inspect the data at will, and also they fear sensitive data being leaked to the US government easily, which is actually quite legit. No interest in politics nonsense and having full control over your own sensitive data is probably the best possible thing to do.
Help: anyone able to get it going on Mac with Kitematic?
Does it set up mail server that can get email to my Gmail account? I signed up but didn't get an email. Are emails dumped somewhere or possible to lookup whatever I need to get started?
Unlike Slack, Mattermost is open source...
Teams suffer when SaaS companies lose focus. Since it’s open source,
Mattermost can endure through its community. If quality declines,
anyone can fork the code and take stewardship.
Open source and focus are the wrong arguments here.
(a) Mattermost is built by a video game company, so there is no focus to start with.
(b) Moving from a SaaS product to a self-hosted open source component runs against the process of commoditisation so is ultimately only ever going to be of niche value. After all, why spend scarce and expensive engineering time setting up, maintaining, and potentially having to fork a product, when you could just pay $however-much/month and not have to worry about it.
The problem of SaaS is having your company data stored by someone you have to trust... So I reckon it depends on your use case: if I'm a small company who doesn't want to bother running/maintaining the service then I'm more than happy to hand it over to someone else and trust them. If I don't want to trust anyone with my data I'd rather have something simple to deploy and run myself.
The same way that having a closed client prevents you from customising it to fit your needs but can be helpful if you had no intention to do so in the first place.
Agreed, without a list of the features, or something to show what useability is like (does it support markdown? code highlighting? e.t.c.) it's tough to evaluate it.
Kudos to them for open sourcing it. It does look nice in the small pictures they have of it.
[+] [-] javiercr|10 years ago|reply
Don't want to troll you guys here, but if you're a video game company why are you spending so much time building a Slack clone?
I was expecting some short of explanation in your blog post like "we did this because this serves as a core piece of our company for X reason and Slack didn't fit our use case for Y reason".
[+] [-] pornel|10 years ago|reply
https://en.wikipedia.org/wiki/Slack_Technologies#Initial_fun...
[+] [-] nadams|10 years ago|reply
I think a better perspective is that this is a tool they needed/wanted and built it - it's really no different than a map editor. Also some companies like Google have a X% time to work on a "personal" project during work hours - and this could be the result of that.
[+] [-] dasil003|10 years ago|reply
[+] [-] tacone|10 years ago|reply
[+] [-] a13xb|10 years ago|reply
[+] [-] AnonJ|10 years ago|reply
[+] [-] volent|10 years ago|reply
On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative.
Here is a non exhaustive list :
RocketChat : https://news.ycombinator.com/item?id=9624737
Let's Chat : https://news.ycombinator.com/item?id=9040841
Friends : https://news.ycombinator.com/item?id=9461504
Gitter : https://news.ycombinator.com/item?id=6739074
[+] [-] jsmthrowaway|10 years ago|reply
"myIRC" doesn't exist. The name of the protocol is IRC. The name of a popular Windows client is mIRC. WikiLeaks called their leak "mIRC logs," which is where this trope came from.
The United States military (not just the Army) uses Internet Relay Chat for a whole lot of C2. It runs on a network, both IRC and IP, dedicated to the purpose. Given how long IRC has been in existence, that they've been doing it since the early 90s, that the use case is the perfect ideal for IRC, and that the average modern Web app is less reliable than my last Datsun, I have a hard time finding incredulity at sticking with something that works.
Even beyond that, IRC is text-based. It is not cryptic. An IRC client is a common first software project. About twenty lines of Go gets you a bot. You can make IRC look exactly like Mattermost with a week of hacking in your favorite framework of choice, and then you're not reinventing fanout. Entire products have been built atop IRC.
Even beyond that, guess how many protocols are decades old in just the software development workflow for this product. Pretty tired of "that's old, let's do it better," even though I hate finding myself on this side of defending IRC.
[+] [-] KaiserPro|10 years ago|reply
plus it works in screen natively
[+] [-] Dowwie|10 years ago|reply
Is there a defensible argument against using IRC?
[+] [-] joesmo|10 years ago|reply
Seriously, these days it seems most software like this is judged purely on its external styling and aesthetic beauty. You're right, Slack has no new features over IRC or any other decent chat clients in the past. But read any article that praises slack and if the slick UI (or whatever adjective is in style these days) isn't mentioned up front and center, I'd be surprised.
Of course the UI's 'slickness' and 'modernity' would be top discussion points for people writing such articles as they're usually not technical enough to argue the merits of tabs vs. spaces or braces vs. non-braces which the creators of such software usually argue about to the detriment of real issues.
[+] [-] dodgedcactii|10 years ago|reply
[+] [-] timdorr|10 years ago|reply
From the look of the screenshots ( http://www.mattermost.org/70-2/ ), I'd say there are some copyright concerns with the styles. This isn't a Slack alternative, it's a Slack clone. That's very problematic from a copyright stance. Why not create your own design style?
Gogs had (has?) this same issue: https://github.com/gogits/gogs/issues/1069
[+] [-] it33|10 years ago|reply
There's been a number of questions of what's coming from Mattermost, and how we design things. I wanted to share some raw, unpolished work we have of what's coming up.
It's a feature called "App Center" that we're working on to support 3rd party applications.
It's just a Google Doc of our early design that we're sharing on Hacker News to get feedback: https://docs.google.com/document/d/1s6vrticxgz9PsxePQ-dFrsKp...
Would you find this interface interesting for building 3rd party apps?
What do you like about the design?
What do you wish we changed?
There's a couple 1st party Apps we'd start with, like an Admin Console and a Custom Web App. We're thinking there could be a marketplace for 3rd party workflow apps.
Example: create an "Expense Report" app where a user can upload the photo of a receipt from lunch from their phone and type "#expense #meals" and have a 3rd party app create a labeled expense report that would be viewable in App Center.
Would love to hear thoughts from the community. This is an early idea, it's just a Google Doc right now. Your input would help shape it.
[+] [-] tracker1|10 years ago|reply
Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appears to be react based.. not sure what's running in ruby.
[+] [-] sciurus|10 years ago|reply
https://github.com/mattermost/platform/blob/master/Dockerfil...
https://github.com/mattermost/platform/blob/master/docker/do...
Surely even docker users don't want to run this app, mysql, postfix, redis, react, and compass all in the same container?
[+] [-] ctolsen|10 years ago|reply
The way it's done now makes it inherently unscalable. Also, there are so many steps that it makes pushing an image to a Docker repository a massive pain.
[+] [-] sehr|10 years ago|reply
[+] [-] synchrone|10 years ago|reply
[+] [-] DoubleMalt|10 years ago|reply
Things that would be essential for me to use it in a company are
- LDAP or OAUTH integration - Hubot integration
I'm not sure Zapier integration cuts it for use cases where I want a self hosted solution.
[+] [-] ryanSrich|10 years ago|reply
Reproducing functionality and growing an idea is fine. It's the blatant disregard to UX and UI where this company has literally pixel for pixel ripped off slack.
[+] [-] pbreit|10 years ago|reply
[+] [-] tadfisher|10 years ago|reply
I'm finding it hard to parse this sentence. Are you saying ripping off Slack is the blatant disregard, or are you saying Slack pioneered a blatant disregard for UX and UI?
[+] [-] it33|10 years ago|reply
[+] [-] andmarios|10 years ago|reply
While I am grateful to all you guys, how much free time do you have to work on these clones instead of your main product?
I've tried so far let's chat and rocketchat and I liked them. I will give a spin to mattermost and I am sure I will like it too. I think the one that matures first, will be a big hit because we need a slack clone —as evidently shown. But also as with any other open source / free software project it will need commitment.
[+] [-] uniclaude|10 years ago|reply
I don't mean to devalue this product at all, but This is not a viable Slack alternative, it's a generic (and good looking) communication tool. This said, I commend the open source approach, it could probably help the product evolve towards something much better and integrated.
[+] [-] pluc|10 years ago|reply
[+] [-] coldtea|10 years ago|reply
[+] [-] LinuxBender|10 years ago|reply
[+] [-] ywecur|10 years ago|reply
Having a decentralised network would be much better as it would remove all costs of self-hosting.
[+] [-] mempko|10 years ago|reply
http://firestr.com https://github.com/mempko/firestr
[+] [-] AnonJ|10 years ago|reply
[+] [-] tyrion|10 years ago|reply
Looking at the README it says that it does not work if my ISP is blocking port 25, which I don't think it is.
But anyway I created a droplet on digitalocean and ran the container there, but "MySQL init process failed."
I would love to try this project, or at least try a demo deployment somewhere :)
[+] [-] aargh_aargh|10 years ago|reply
[+] [-] mosselman|10 years ago|reply
[+] [-] pbreit|10 years ago|reply
Does it set up mail server that can get email to my Gmail account? I signed up but didn't get an email. Are emails dumped somewhere or possible to lookup whatever I need to get started?
[+] [-] richmarr|10 years ago|reply
(a) Mattermost is built by a video game company, so there is no focus to start with.
(b) Moving from a SaaS product to a self-hosted open source component runs against the process of commoditisation so is ultimately only ever going to be of niche value. After all, why spend scarce and expensive engineering time setting up, maintaining, and potentially having to fork a product, when you could just pay $however-much/month and not have to worry about it.
[+] [-] amandine|10 years ago|reply
The same way that having a closed client prevents you from customising it to fit your needs but can be helpful if you had no intention to do so in the first place.
[+] [-] ville|10 years ago|reply
[+] [-] richmarr|10 years ago|reply
[+] [-] vishaldpatel|10 years ago|reply
[+] [-] mijoharas|10 years ago|reply
Kudos to them for open sourcing it. It does look nice in the small pictures they have of it.