3 ms·

Those bullet point against slack are really common around here, but I've yet to hear an explanation as to why they're a con. Example: It's closed source. Appa

Those bullet point against slack are really common around here, but I've yet to hear an explanation as to why they're a con. Example: It's closed source. Apparently that in itself is intrinsically "bad", and obviously so, because I've yet to see any explanation attached to that argument.

jeena 11y ago
You can't know what happens with the content you put in there.
- zepto 11y ago
  What does that even mean? Surely the same is true for IRC, since anyone can be running their own code for relays, bots, and clients.
  - yoo1I 11y ago
    The difference is that if freenet started to use my messages to #IluvCarrots and sell them to the carrot industry, I could tell them to shov it and migrate over to OFTC with little friction. If Slack starts doing that, and I want to continue to use my client software I'm pretty much screwed.
yoo1I 11y ago
Not sure that that really needs an explanation in an article about FOSS Software projects, but here goes: Using a closed source messaging system you never know, if 5 years down the line the company who owns you, and who is in control of your communication, decides that they would like to monetize your "contributions" to their system to synergize shareholder smileability, by adding ads to your projects channel. Or they might want to change their pricing structure so suddenly the barrier to entry to your project is suddenly higher. Or they get bought by google for their engineering talent and the whole thing ceases to exist. Or they exclude the bot that you write and depend on a little bit from their network with no explanation given. Or any other further or not so far fetched scenario in which the owners of the software can do whatever they want without consulting with you, leaving you with little alternatives. Using a free protocol with free software, if these things happen wrt to the entity writing the code that you rely on or the the hosting of services you rely on, you're still inconvenienced, but these things do not impact you as much, because you're free to continue to use the code without the new sucky modifications, fork if if your able (or rely on some other entity taking over the code) and run the damn service yourself. Forking and self-hosting aren't always the best solutions, but the more invested you are in a service the better they start to look.

jeena 11y ago

You can't know what happens with the content you put in there.

zepto 11y ago
What does that even mean? Surely the same is true for IRC, since anyone can be running their own code for relays, bots, and clients.
- yoo1I 11y ago
  The difference is that if freenet started to use my messages to #IluvCarrots and sell them to the carrot industry, I could tell them to shov it and migrate over to OFTC with little friction. If Slack starts doing that, and I want to continue to use my client software I'm pretty much screwed.

yoo1I 11y ago

Not sure that that really needs an explanation in an article about FOSS Software projects, but here goes: Using a closed source messaging system you never know, if 5 years down the line the company who owns you, and who is in control of your communication, decides that they would like to monetize your "contributions" to their system to synergize shareholder smileability, by adding ads to your projects channel. Or they might want to change their pricing structure so suddenly the barrier to entry to your project is suddenly higher. Or they get bought by google for their engineering talent and the whole thing ceases to exist. Or they exclude the bot that you write and depend on a little bit from their network with no explanation given. Or any other further or not so far fetched scenario in which the owners of the software can do whatever they want without consulting with you, leaving you with little alternatives. Using a free protocol with free software, if these things happen wrt to the entity writing the code that you rely on or the the hosting of services you rely on, you're still inconvenienced, but these things do not impact you as much, because you're free to continue to use the code without the new sucky modifications, fork if if your able (or rely on some other entity taking over the code) and run the damn service yourself. Forking and self-hosting aren't always the best solutions, but the more invested you are in a service the better they start to look.