4 ms·
(I lead the Zulip project, one of the main open source alternatives to Slack.) The writing's been on the wall for HipChat for a long time; e.g. the user experi
by tabbott 8y ago
(I lead the Zulip project, one of the main open source alternatives to Slack.)
The writing's been on the wall for HipChat for a long time; e.g. the user experience has been stagnant for many years (e.g. they never added emoji reactions). And even back in 2013, every HipChat customer I've encountered was unhappy or at best unenthusiastic about the product. So we've seen plenty of folks migrate from HipChat to Zulip.
I expect most enterprises will end up on one of the open source Slack alternatives (Zulip, Mattermost, Rocket.Chat, etc.). Frankly, they should have been using one of them anyway. If you care about a really high level of security, you want to be using well-maintained open source software. The well-maintained part is obvious, but the open source piece is really important too: It's a lot easier for white-hat hackers to find and report security bugs in software with access to the source code, and so there will be fewer that haven't been found and fixed yet.
You certainly don't want to be using a PHP app that's had over 700 confirmed security bugs found by external people (https://hackerone.com/slack https://hackerone.com/slack) -- you can be pretty sure there are more being introduced every week.
I'll add that I expect to see more proprietary on-premise products that are the stepchild of a SaaS product disappearing over the coming years. It's a lot harder to ship software for the on-premise use case, especially if you have engineering culture used to just shipping for a single installation in the cloud (which almost everyone who works on proprietary software is). If you have the right processes and toolchain, it doesn't have to slow you down (and I don't feel it does for Zulip, with our amazing developer tooling and 98% backend test coverage), but very few organizations succeed at this. I've certainly heard some incredible horror stories from famous Silicon Valley companies about teams of engineers spending months on making a fork of a SaaS product shippable for each on-premise release.
- AntonyGarand 8y agoTo be fair, there are tons of very low severity vulnerabilities disclosed on HackerOne and this does not mean the application is vulnerable. Slack is definetly not vulnerable because it is written in php and you can pollute an iframe on their career website. Having such a program in place is actually good for the application security as it does get audited by tons of hackers thanks to the monetary rewards.
- tabbott 8y agoI agree it's theoretically possible to write a secure project in PHP, but it's very difficult, especially if you're hiring people like crazy. If you divide the amount they've paid out in bounties by the number of bounties paid, and compare with their bounty tier rules, it's clear that a lot of the vulnerabilities that were reported in Slack are relatively severe. (And I agree bug bounty programs are great; we also use HackerOne)
- omnimus 8y agoIt is not about the language is it... I don't think there is so big difference between php and python. Besides Slack is most probably using whole lot more tech than php. It is about Zullip being open source.
- tabbott 8y agoIt's also about the language. See, for example, https://www.quora.com/Why-is-PHP-hated-by-so-many-developers https://www.quora.com/Why-is-PHP-hated-by-so-many-developers
- _bear 8y agoThat is from 2014. There have been many changes in the programming language since. Most people nowadays are using frameworks and abstraction layers which make most of these points moot.
- kennydude 8y agoIf you use a framework like Laravel it probably covers most things. You could easily write a massively insecure application in core python, but things like Zulip use Django which shields you from most of it.