Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

71–80 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#71
post #50
post #36

For talking about a race, Wired seems to have neglected a crucial technology: ircv3[1]. I'm not very fond of IRCv2, and have moved away from it where I previously used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of promise. Why didn't the author bother to mention it? [1]: http://ircv3.net/

IRCv3 lacks a logo, a startup, and VC funding. So people who write tech news seem to often be unaware that it even exists.

It's also lacking adoption (which is understandable since it's not "officially released" yet).

Re: Open Sourcers Race to Build Better Versions of Slack

#72
post #56

Earlier quoted context omitted.

Mattermost claims to have "Native Applications". ( http://www.mattermost.org/community-applications/#native ) Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application." Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.

I think Mattermost has also Android and iOS native apps. The Slack native app for desktop was horrible last year, but right now it's acceptable, apart from annoying notifications polluting the application switcher.

Mattermost's applications are js-based. Brilliant marketing.

Re: Open Sourcers Race to Build Better Versions of Slack

#73

It's good to see a bit of a variety – we all know that monoculture ends up being a bad thing, and there are obvious downsides to applications hosted by third parties (though of course in some cases it's not a problem!). Of course, there's no real network effect with applications like this either (beyond integrations support) so there's a relatively low bar to switching when compared to something like Facebook. I do h…

Mattermost claims to have "Native Applications". ( http://www.mattermost.org/community-applications/#native ) Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application." Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.

Visual Studio Code:

1. is a much more complex application

2. has no perceptible performance issues

3. is also built on Electron

Re: Open Sourcers Race to Build Better Versions of Slack

#74

We need open protocols. Then let a thousand clients with different paradigms bloom

For reasons that have never been entirely clear to me, chat has been reinvented more times than perhaps any other common Internet utility, and every time it is, there are no shortage of investors lined up for it. I think the cycle is largely driven by fashion, as youth get online and demand chat apps that are distinct (if not different in any meaningful functional way) from the existing ones.

Re: Open Sourcers Race to Build Better Versions of Slack

#75
post #36

For talking about a race, Wired seems to have neglected a crucial technology: ircv3[1]. I'm not very fond of IRCv2, and have moved away from it where I previously used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of promise. Why didn't the author bother to mention it? [1]: http://ircv3.net/

There's also Matrix.org. There seems to be a lot of overlap between the two projects.

Re: Open Sourcers Race to Build Better Versions of Slack

#76
post #2

If only there was a well supported, standard, open and interoperable text messaging protocol (with multiple implementations) that companies could host themselves... Oh wait, IRC.

This comes up every time, and as usual you have totally missed the point . IRC is difficult to configure, difficult to host, difficult to use, and does not offer the same feature set as Slack. There is an obvious use case for something like Slack (obviously, because otherwise it would not have millions of users!) and covering one's ears while yelling "IRC! IRC! IRC!" is sort of wilfully ignoring that if it were a sui…

I honestly don't get this. I've been using IRC for a few years, but I don't think nearly enough for blind eye nostalgia to take hold.

It's not like you're stuck with ugly terminal only clients anymore. There is KiwiIRC, IRCCloud, and several other great web clients that not only let you connect to any server but provide bouncer services and backlog. There are also plenty of easy to use native clients that don't require any configuration.

There are some benefits of Slack, but the ones you mention aren't them. In fact, seeing how you CANT host your own Slack server I would say "difficult to host" is a flat lie against IRC.

Re: Open Sourcers Race to Build Better Versions of Slack

#77

What about reusing and polishing XMPP and existing decent software for it? About donating money to people who develop it all these years? No, we'll spread FUD upon XMPP or just ignore it but will proceed to use and abuse its legacy behind the closed doors. http://risovach.ru/upload/2016/03/mem/novyy--shablon_1085837...

For one thing, XMPP is complicated and difficult to implement.

Re: Open Sourcers Race to Build Better Versions of Slack

#78
A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up.

Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts?

Some sort of open protocol.

Urgh, I've been working on this lately and the entire field is depressing. Between one side that doesn't understand the legitimate need for open protocols, and another side that doesn't understand why IRC isn't the end-all-be-all of group chat (and why UX matters), it's just people talking past each other.

Every new attempt at making "the slack killer" makes this problem worse, because it comes with its own protocol. Its own users. Etc.

PS: If somebody has free time to work on an open source multi-protocol group chat gateway, email me, I have something started.

Re: Open Sourcers Race to Build Better Versions of Slack

#79

Earlier quoted context omitted.

Mattermost claims to have "Native Applications". ( http://www.mattermost.org/community-applications/#native ) Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application." Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.

What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.

That's true, but when you roll a "one size fits all" HTML app across all platforms, it's much much less likely to follow operating system conventions and very easy to get layout details wrong.

For example, Hipchat's settings overlay (https://i.imgur.com/V3UOyMI.png) which should:

• Be a separate window

• Be sized properly for its contents instead of having to scroll

• Use tabs along the top for the settings categories

• Not have clipped left edges on all of the checkboxes

• Put the close button in the top left corner of the window like the rest of the OS

Compare to settings in Textual, which is an actual native application: https://i.imgur.com/5GFURBk.png

Beyond the design aspects, there's also the issue of performance (the OS's UI layout system is well optimized for doing UI layout) and battery impact.

The average "Energy Impact" of Hipchat as measured by Activity Monitor is 24x as high as Textual's. Twenty four! That puts it in 3rd place, beaten only by Google Chrome and Spotify (which IIRC is a similar "wrapped our webapp in CEF or electron). Hipchat does a bit more than Textual (inline image display), but not enough to justify its abuse of my battery life.

Re: Open Sourcers Race to Build Better Versions of Slack

#80
post #17
post #7

Earlier quoted context omitted.

if only getting external collaborators or non-technical users into IRC didn't involve sending them a 15-step howto on configuring screen and ssh and could be as simple as "check your email and click the link you get" and, if only there was push button per channel access control set up out of the box so that some users can join some channels but not others! no, not channel keys, those are busted (what do we do when so…

Your experience of IRC clients seems like a bad one, I'm sorry about that. Have you heard of irccloud.com? You should check it out. My mum could use it (I'm not affiliated with them in any way besides being a happy customer).

irccloud isn't free, open source, or self hosted, so why not use slack instead?
Post reply on HN