Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

Post reply on HN
Print view View original

241–250 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#241

Post by haroldp »

scrollaway wrote: post #231
haroldp wrote: post #217

Earlier quoted context omitted.

I'm sure that I'm over simplifying, but can't you just put tokens or markdown right in the chat for those sort of things? If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?

No amount of markdown makes up for the lack of offline messages.

That is 100% true. But I use IRC and have offline messages. It's IRC, so I had to cobble something together to make it happen, and the UI is ass, but... I have that within the IRC protocol.

Re: Open Sourcers Race to Build Better Versions of Slack

#242

Post by luckydude »

This is why I sort of hate open source. Slack is doing a great job, their prices are right. So why is it OK to destroy that? With what is going to be not as good stuff?

I'll get down voted to hell but come on. It's cheap, it's good, so why not let the guy make a living? And for the record I don't even know who the guy is (or woman is).

I just hate the "it's cool, lets rip it off attitude". Because the ripoff is rarely better than the original.

Re: Open Sourcers Race to Build Better Versions of Slack

#243

Post by scrollaway »

seivan wrote: post #239
rekoros wrote: post #147

Earlier quoted context omitted.

We implemented them ourselves, and it took quite a bit of work. Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time. The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two yea…

Care to share your webpack config for getting React and TypeScript to play ball? I'm collecting a bunch to try to figure out what works best.

You can take a look at ours: https://github.com/hearthsim/joust

Re: Open Sourcers Race to Build Better Versions of Slack

#244

Post by scrollaway »

quadrangle wrote: post #240
rekoros wrote: post #127

Earlier quoted context omitted.

Thank you! We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse. That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.

Sounds like you just need the AGPL

Licensing has nothing to do with this.

Re: Open Sourcers Race to Build Better Versions of Slack

#245

Post by WoodenChair »

quadrangle wrote: post #240
rekoros wrote: post #127

Earlier quoted context omitted.

Thank you! We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse. That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.

Sounds like you just need the AGPL

Yeah because if you open source something under the right license, no abuse happens... What percentage of GPL violators has the FSF prosecuted? Or anyone else for that matter?

Re: Open Sourcers Race to Build Better Versions of Slack

#246

Post by scrollaway »

caf wrote: post #234
scrollaway wrote: post #231

Earlier quoted context omitted.

No amount of markdown makes up for the lack of offline messages.

Offline messages is a server issue, though - in principle there's no reason why you couldn't have a server that remembers offline messages and passes them to the client when it reconnects, framing them as regular IRC messages.

There is, actually. IRC has no concept of timestamps. IRC has no concept of foreign metadata, even, so shoehorning isn't even possible without looking horrible.

IRCv3 fixes all that.

Re: Open Sourcers Race to Build Better Versions of Slack

#247

Post by jlarky2012 »

seivan wrote: post #239
rekoros wrote: post #147

Earlier quoted context omitted.

We implemented them ourselves, and it took quite a bit of work. Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time. The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two yea…

Care to share your webpack config for getting React and TypeScript to play ball? I'm collecting a bunch to try to figure out what works best.

That's actually interesting topic :) Right now we use gulp and gulp-typescript. So far, I like approach that is used in https://github.com/Microsoft/TypeScriptSamples/tree/master/e... but I'm not sure if we are going to use it any time soon. As far as gulp config, what we use is pretty much close to gulp-typescript README examples

Re: Open Sourcers Race to Build Better Versions of Slack

#248

Post by alexschleber »

SwellJoe wrote: post #229
ar0 wrote: post #227

Earlier quoted context omitted.

Ghostery counts 27 trackers for me on this single Wired article, 19 of which are classified as "Advertising". I would not call this "not to be too invasive".

I didn't look too deeply, but yeah, that's ridiculous. I don't need any Wired article that much.

Exactly. The whole piece is For those ~15 lines of unwrapped text, the whole page is 1900 lines in total.

Re: Open Sourcers Race to Build Better Versions of Slack

#249

Post by taurath »

rekoros wrote: post #153
cyphar wrote: post #145

Earlier quoted context omitted.

Right, but surely if you're selling it that's much more incentive for a cease and a desist (regardless of whether it is free software).

Actually I don't think so. The main thing the owners of big networks are afraid of is spam. We provide a ridiculously expensive way to connect, say, Slack to Skype, which is ==great for Skype==, from almost every possible angle. It means Skype users can stay on Skype instead of switching to someone else's Slack team.

In that case great for skype, bad for slack. Someone, somewhere will decide they'd rather force those customers to use their service/client, or else they'd have an open protocol in the first place.

Re: Open Sourcers Race to Build Better Versions of Slack

#250

Post by lotyrin »

groovy2shoes wrote: post #82
lotyrin wrote: post #60

Earlier quoted context omitted.

It's easier to host (at least on the scale that most teams would, few nodes, few tens of users, no need for services -- basically `apt-get install ircd-of-choice`) than to use, but I disagree that it's easy to use. I can tell anyone in any kind of role (senior to junior, technical to non-technical) on my team to "Download (the/a) client for X and join #channel #channel2" "Follow the directions to set it up so changes…

Are you fucking kidding me? I've been using IRC since I was 10. If a 10-year-old can figure it out, I think a professional engineer can figure it out. Using your typical IRC client to join a channel is just 4 steps: 1. Download IRC client. 2. Pick a nickname. 3. Pick a server. 4. Join a channel. With something like kiwiirc, you can even omit steps 1, 3, and 4: you can give someone a URL to a particular channel on a p…

> Professional Engineer

Yeah, here's where you fucked up reading my post.

> anyone in any kind of role (senior to junior, technical to non-technical)

I'm talking about Joe Frontend, Billy Design Intern, Gary Office Assistant. Maybe you work on teams that are 100% neckbeards that aren't afraid to crack open an RFC to get daily shit done (and waste huge amounts of company resources on things that should be simple), but that's not the environment I'm talking about.

Not accounting for these people is the fatal mistake made by far too much of the tools and processes in software. I've watched people go into shops like this as non-technical helpers, work really hard and skillfully within the boundaries of their role, but get burned too many times by a hoity-toity technical bro "lol, you can't even open an ssh tunnel to the bastion host to connect to the internal IRC..." that they quit software, return to lower paid job they did during school and decide they have no skills, when they would thrive on a more balanced (and more socially skilled) team.

Post reply on HN