8 ms·

We shouldn't fetishize control as much. In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on yo

by SubuSS 7y ago

We shouldn't fetishize control as much. In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need. Running most of these OSS even at a medium employee count scale is a full-team-commit-nightmare. It essentially means your it department now needs a specialist who will be able to handle your org quirks, remember the tweaks and keep baby sitting it. Not to mention many OSS teams (I don't know about the above listed) are ever so sneakily introducing enterprise clauses about usage in their EULA. I don't want to name names, but even with paid software we are seeing this problem everywhere in trying to host: But at least here, we got the actual developers and experts on a call who can walk us through why x employees are fine and x+1 nukes their system.

CloudNetworking 7y ago
We don't need OSS in this case, we need open protocols so anyone can use any other client, proprietary or not.
- AnIdiotOnTheNet 7y ago
  We've had a perfectly good open chat protocol since... gosh, I don't even know. It's called IRC and it's so simple you can implement a server or client in python in under an hour. This is what happens when you over-engineer things.
  - pitaj 7y ago
    IRC has many drawbacks not shared by more modern protocols. Slack works when you're offline, saves history, has notifications, search, etc. IRC is not perfectly good or it would still be used.
    - AnIdiotOnTheNet 7y ago
      > Slack works when you're offline IRC doesn't do that, true, but there's a bunch of ways around it. > saves history, has notifications, search Trivial to implement in the client. > IRC is not perfectly good or it would still be used IRC is still used. Almost everything any fancier messaging protocol does can, and has, been implemented as a client-side feature with little hassle.
      - notafraudster 7y ago
        So corporate users can set up an IRC server; a network of per-user bouncers for offline state maintenance; an internal file hosting network for uploads; a bunch of server-based logging stuff and a central search repository to check history; train every middle manager to be an IRC server admin in order to add and remove people from channels for new projects; somehow intervene to disable DCC and other methods users could use to circumvent server-side logging; maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc; break IRC's protocol in their client and server to allow text in excess of the maximum line length; and separately find a SAAS video/audio chat vendor or roll their own... ... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
        AnIdiotOnTheNet 7y ago
        They could easily pay someone else to handle all that stuff just like we do with HTTP servers. We're not talking about the service, we're talking about the protocol. > maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc These already exist. No need to maintain a fork unless you want to add features that don't exist in it. And since IRC is so trivial a protocol, that's not even hard. > break IRC's protocol in their client and server to allow text in excess of the maximum line length You don't have to break shit. Just split lines into multiple messages and piece together messages from the same user when they were also the last one who said anything, or use a character that means "message continues", or any of probably a dozen other ways you could implement that on top of the already existing protocol and that will still gracefully degrade on clients that don't support it.
      - bradjohnson 7y ago
        Every time someone on HN says "you don't need x, just do a, then b, then c and you'll get something similar" I'm reminded of this comment: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
        AnIdiotOnTheNet 7y ago
    - scaryclam 7y ago
      Slack just freaks out when I'm offline (or it even thinks I am). To the point I often just end up writing an email as it's less painful than using slack.
- Arathorn 7y ago
  Open protocols without OSS tend not to be particularly robust. In this instance, we have both: open protocols like Matrix.org, XMPP & IRC - and open source servers & clients (like synapse & Riot.im on the Matrix side), which are no longer an opensource curiousity but ready for primetime as Slack/Discord replacements. Just as Apache is ready for primetime as an IIS replacement.
- wtetzner 7y ago
  Yeah, it's worked out well for email. You can use paid services, or not. It's up to you, but they all interoperate.
  - Biganon 7y ago
    They certainly DON'T interoperate. I have a mail-tester score of 100, use SPF, DKIM and DMARC, yet Microsoft still sends all my emails in the spam folder. There's nothing I can do about it, it's a black box. The only suggestion from them is that I subscribe to some paid program with another company in order to maybe, or maybe not, increase the trust in my mail server.
lixtra 7y ago
> In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need. That’s not even wrong because nowadays almost all software comes with some OSS contained. So the non oss set is basically empty. I wonder if HN comes with a huge cost of attention because it runs on some OSS lisp?!
pojntfx 7y ago
But isn't this not really and argument against FLOSS in this case? Isn't support the entire business model of, say RedHat?
robbiep 7y ago
But you don’t want to go full ducking SaaS with things as well, where you don’t know what is coming until the ‘improvement’ is foisted upon you. Software gone mad. Spoken as a SaaS vendor
jturpin 7y ago
I don't know about the rest of the software but Mattermost is easy to administer and requires minimal babysitting. I have it deployed with a simple docker-compose file which I only touch when I want to upgrade it, and there are Helm charts if you want a more production grade deployment. If I were to deploy it for my company I'd probably use the helm chart + a cloud hosted Postgres as the database and would likely never have to touch it between upgrades.

by SubuSS 7y ago

CloudNetworking 7y ago

We don't need OSS in this case, we need open protocols so anyone can use any other client, proprietary or not.

AnIdiotOnTheNet 7y ago
We've had a perfectly good open chat protocol since... gosh, I don't even know. It's called IRC and it's so simple you can implement a server or client in python in under an hour. This is what happens when you over-engineer things.
- pitaj 7y ago
  IRC has many drawbacks not shared by more modern protocols. Slack works when you're offline, saves history, has notifications, search, etc. IRC is not perfectly good or it would still be used.
  - AnIdiotOnTheNet 7y ago
    > Slack works when you're offline IRC doesn't do that, true, but there's a bunch of ways around it. > saves history, has notifications, search Trivial to implement in the client. > IRC is not perfectly good or it would still be used IRC is still used. Almost everything any fancier messaging protocol does can, and has, been implemented as a client-side feature with little hassle.
    - notafraudster 7y ago
      So corporate users can set up an IRC server; a network of per-user bouncers for offline state maintenance; an internal file hosting network for uploads; a bunch of server-based logging stuff and a central search repository to check history; train every middle manager to be an IRC server admin in order to add and remove people from channels for new projects; somehow intervene to disable DCC and other methods users could use to circumvent server-side logging; maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc; break IRC's protocol in their client and server to allow text in excess of the maximum line length; and separately find a SAAS video/audio chat vendor or roll their own... ... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
      - AnIdiotOnTheNet 7y ago
        They could easily pay someone else to handle all that stuff just like we do with HTTP servers. We're not talking about the service, we're talking about the protocol. > maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc These already exist. No need to maintain a fork unless you want to add features that don't exist in it. And since IRC is so trivial a protocol, that's not even hard. > break IRC's protocol in their client and server to allow text in excess of the maximum line length You don't have to break shit. Just split lines into multiple messages and piece together messages from the same user when they were also the last one who said anything, or use a character that means "message continues", or any of probably a dozen other ways you could implement that on top of the already existing protocol and that will still gracefully degrade on clients that don't support it.
    - bradjohnson 7y ago
      Every time someone on HN says "you don't need x, just do a, then b, then c and you'll get something similar" I'm reminded of this comment: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
      - AnIdiotOnTheNet 7y ago
  - scaryclam 7y ago
    Slack just freaks out when I'm offline (or it even thinks I am). To the point I often just end up writing an email as it's less painful than using slack.
Arathorn 7y ago
Open protocols without OSS tend not to be particularly robust. In this instance, we have both: open protocols like Matrix.org, XMPP & IRC - and open source servers & clients (like synapse & Riot.im on the Matrix side), which are no longer an opensource curiousity but ready for primetime as Slack/Discord replacements. Just as Apache is ready for primetime as an IIS replacement.
wtetzner 7y ago
Yeah, it's worked out well for email. You can use paid services, or not. It's up to you, but they all interoperate.
- Biganon 7y ago
  They certainly DON'T interoperate. I have a mail-tester score of 100, use SPF, DKIM and DMARC, yet Microsoft still sends all my emails in the spam folder. There's nothing I can do about it, it's a black box. The only suggestion from them is that I subscribe to some paid program with another company in order to maybe, or maybe not, increase the trust in my mail server.

lixtra 7y ago

> In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need. That’s not even wrong because nowadays almost all software comes with some OSS contained. So the non oss set is basically empty. I wonder if HN comes with a huge cost of attention because it runs on some OSS lisp?!

pojntfx 7y ago

But isn't this not really and argument against FLOSS in this case? Isn't support the entire business model of, say RedHat?

robbiep 7y ago

But you don’t want to go full ducking SaaS with things as well, where you don’t know what is coming until the ‘improvement’ is foisted upon you. Software gone mad. Spoken as a SaaS vendor

jturpin 7y ago

I don't know about the rest of the software but Mattermost is easy to administer and requires minimal babysitting. I have it deployed with a simple docker-compose file which I only touch when I want to upgrade it, and there are Helm charts if you want a more production grade deployment. If I were to deploy it for my company I'd probably use the helm chart + a cloud hosted Postgres as the database and would likely never have to touch it between upgrades.