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

Shrugs.app – A native Slack client for macOS

shrugs.app

Post reply on HN
Print view View original

221–230 of 236 posts

Re: Shrugs.app – A native Slack client for macOS

#221

Post by tptacek »

tumult wrote: post #128
tptacek wrote: post #68

Earlier quoted context omitted.

Why isn't it fair? They run the service. What gives other people the right to tell them how to run it? If you don't like their terms, there are about 100 alternative projects you can use. There are pretty clear, practical reasons you might want to control the client of a commercial network service.

Author of Ripcord. You’re wrong, and creating and using software compatible with services is fair.

I don't agree that fairness requires service providers to provide open APIs. Open APIs are better, ceteris paribus, but that's as far as it goes.

Re: Shrugs.app – A native Slack client for macOS

#222

Post by josephcsible »

edmundsauto wrote: post #76
josephcsible wrote: post #71

Earlier quoted context omitted.

What part of your argument wasn't true of the phone company too?

The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)

If Slack isn't the sole-source provider, then neither was the phone company, since you could also communicate by sending letters.

Re: Shrugs.app – A native Slack client for macOS

#223

Post by tadfisher »

gtirloni wrote: post #132
tadfisher wrote: post #86

Earlier quoted context omitted.

There are reasons, but it's also not smart. Organizations that pay for Slack pay for the service, not the shitty client.

You want to reduce Slack Inc to an API provider. They want to be a client provider too and they own the API server. Do you see where this won't work?

The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.

Re: Shrugs.app – A native Slack client for macOS

#224

Post by gtirloni »

tadfisher wrote: post #223
gtirloni wrote: post #132

Earlier quoted context omitted.

You want to reduce Slack Inc to an API provider. They want to be a client provider too and they own the API server. Do you see where this won't work?

The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.

You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

Re: Shrugs.app – A native Slack client for macOS

#225

Post by gtirloni »

tumult wrote: post #208
gtirloni wrote: post #207

Earlier quoted context omitted.

"You may not copy, modify, create derivative works based upon, distribute, sell, lease, or sublicense any of our software or services" This seems to make it pretty clear they don't want you to create 3rd-party clients for their service.

Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.

If I rephrase it like this, does it make it clear?

"You may not create derivative works based upon any of our services"

Re: Shrugs.app – A native Slack client for macOS

#226

Post by tadfisher »

gtirloni wrote: post #224
tadfisher wrote: post #223

Earlier quoted context omitted.

The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.

You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

> But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

Only because it's next-to-impossible to call the API, because of the way they lock features to their client!

Re: Shrugs.app – A native Slack client for macOS

#227

Post by tumult »

gtirloni wrote: post #225
tumult wrote: post #208

Earlier quoted context omitted.

Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.

If I rephrase it like this, does it make it clear? "You may not create derivative works based upon any of our services"

In the imaginary world where that's what the terms of service says, that's still fine for Ripcord -- Ripcord isn't a derivative work.

Re: Shrugs.app – A native Slack client for macOS

#228

Post by mulmen »

amedvednikov wrote: post #139
mulmen wrote: post #119

Earlier quoted context omitted.

How do you see top posts?

Click on the username => submissions

Ah, ok, I would call that a “submission” but it’s an “Ask HN” so I see where you came up with “post”.

Note that the submission page is sorted chronologically, not by karma. So the concept of “top” is really more like “first”.

It seems you meant to point out that @Mandatum admitted to lying but the way you phrased it really made it difficult to verify the claim and came across to me like you were accusing @jessefied123.

There were some very strong responses [1] to your accusation and I’m concerned that anger may be directed at the wrong person. When making these kinds of accusations you should try to be more clear. Use names and provide links. Also consider if the benefit of the accusation is worth the risk of misunderstanding.

[1]: https://news.ycombinator.com/item?id=31928612

Re: Shrugs.app – A native Slack client for macOS

#229

Post by mulmen »

smileybarry wrote: post #218
amedvednikov wrote: post #98

Earlier quoted context omitted.

From this user's top post on HN: > Over the years I've found writing on HackerNews, Reddit and other online sites has given me an outlet to get creative and engage with folks in a way that will shift discourse towards something I'm more interested in. I regularly lie and pretend I know about topics and areas I have zero experience in. I began noticing I received more upvotes and engagement

Should clarify: the comment above me by @amedvednikov is referring to this comment chain's original poster -- @Mandatum -- not the parent or link submitter, and the post mentioned is: https://news.ycombinator.com/item?id=30838788

Big yikes. Thanks for clearing this up. I totally misinterpreted the accusation.

Re: Shrugs.app – A native Slack client for macOS

#230

Post by edmundsauto »

josephcsible wrote: post #222
edmundsauto wrote: post #76

Earlier quoted context omitted.

The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)

If Slack isn't the sole-source provider, then neither was the phone company, since you could also communicate by sending letters.

That's a different medium, although I understand your point: Slack is the sole source provider of communicating on the Slack network. Personally, I don't think this is a problem or should be fixed because of how I see the tradeoffs and side effects. Similarly, I want Apple to run their own app store and not allow sideloading because I prefer the set of tradeoffs that come with that, versus the other reality.
Post reply on HN