Goodbye, Slack. Hello, Spectrum
blog.apollographql.com
blog.apollographql.com
how do these kinds of posts end up on page one so often?!
Walls are about control of what's inside of them, including keeping users locked in when they get inside. Using custom proprietary protocols and not giving an easy way to get at your own data are two common aspects.
EDIT:
There are degrees to being walled garden. Slack is one, pure and simple. My scanning of Spectrum's site did not reveal ease of export or FOSS mentioned anywhere on the main page, or on the features subpage, so I immediately assumed it's pretty much as walled as Slack. Now that other replies mention it, I did find a Github icon at the very bottom, linking to some repositories, so maybe the walls aren't as high and thick as I assumed.
Is being hosted on a central server operated by a third party, without federation features, a wall? Technically, yes. But a small one, relatively easy to scale. Personally, as long as I can get all my data out, and as long as I can easily interoperate with it from outside of the garden, I'm comfortable with that. Closed protocols are essentially barbed wire.
And without a token from spectrum, the apps will be limited to "local" operation. Fat load of use cases that has for a chat application.
@TeMPOral has it right: it stays a walled garden as long as it's under central control.
Hangouts chat was a walled garden, even though you could connect via Jabber, and download your stuff via takeout.
The one exception seems to be that it's hosted at a Spectrum owned domain, https://spectrum.chat/apollo.
Chat, as any platform for communication, is going to have network effects, and that's what all of these "we're also slack but not" products aim for. That's the only reason I ever interact with slack or facebook. Not because I want to (I don't) or because I love their apps so much (I don't) but because some things/people are simply only to be reached there.
Can you provide an example of someone who does this right in your book? All instances are hosted by someone -- unless I'm reading you wrong it seems like the only thing that would satisfy you is a chat platform built on the blockchain.
Take for example podcasting: podcasts generally speaking aren't walled gardens - its a completely open protocol based on RSS. No locking. Spotify Podcasts, is a walled garden.
This is designed for local chat, exactly like slack. It is designed to chat with a community (an open source project, or maybe a company). In slack you need to register to every "team" you want to join, so how is it exactly the same to self hosted spectrum and ask users to register on your instance.
So it is a public garden, but you can take all your plants and plant then to your own backyard. It is not walled.
- Do I own the data? Can I get all the data back easily, in usable format?
- Can I interoperate with it with my own tools? I have my preferences that generally fly in the face of modern UX trends, and being forced to use the officially sanctioned app is inherently limiting.
- What's the migration path? If the current gardener gets bored with the service, can the garden be "restarted" under someone's else control, with all the data migrated?
Decentralization is inherently inefficient, so I don't mind if some things are centralized. It's how they're centralized, how the ownership and control is distributed, that matters.
>That being said, this codebase isn't your typical open source project because it's not a library or package with a limited scope—it's our entire product.
Not sure what you mean by that.
It's their full product -- you can get all their code from GitHub and run your own version of their service locally (so it would be like Facebook the company outsourcing the whole codebase behind Facebook the website).
But in any case, what's the problem with "We switched from one walled garden to another"?
Perhaps, the "walled garden" aspect is not what's important to the team, but they care about other interaction aspects? Are they allowed to, or is "walled garden" a no no, and people should not post their use of such services?
It's like a GNU zealot dissing a post about a video editor switching to/from FCP X as "we switched from one proprietary NLE to another".
Yeah, so? Should proprietary/walled garden software be disallowed? Is there something that makes those posts not interesting/useful? If they had switched to some open source alternative it would have made for a better post? Aren't there people that still want to use such services, and do care about the relative merits of different vendors?
Besides, doesn't a large slice of HN make their income either as entrepreneurs or as developers of "walled garden" SaaS products?
When I see a Medium post recommending a new software over another (especially over Slack since that gives me flashbacks), I just assume that there's financial incentive on part of the writer.
Note: I get that most people wouldn't even check it every day or catch up with unread messages most of the time. I'm referring to so many people chatting in near real time in such large groups and keeping up with the messages while they flood the place ("flood" is an apt term borrowed from IRC, though I'm using it slightly differently here).
I say that as an admin of Team Hephy, the fork/continuation of the Deis Workflow Kubernetes PaaS, which is open source and from the team that invented Helm. They didn't actively destroy the product when MS bought out Deis, they did collectively decide and deem it "not strategically important" and subsequently allowed the community to decide what to do with it, helpfully adding MIT licenses to everything on the way out, so there would be no difficulty for us. There's a strong argument for that position ("not strategically valuable") even without imagining that "Corporate got involved," as some of us believed. Workflow is not positioned where the demand is, and I can tell you that is objectively true. (I can't tell you why, though. New users absolutely love Workflow!)
Many of the Deis people now work at Microsoft, making more Open Source and working on Azure Cloud.
We're still kicking it here at Team Hephy. I hadn't heard about Sunrise. But if Microsoft is aligning their company against Slack, it is not such a big stretch to imagine that building an OSS competitor to Slack actually fits right in with the strategic goals, even if they are also selling their own brand of chat, in Teams.
(Has there been any news about GitHub's developer commitment to Atom? Many predicted that with the acquisition, Microsoft wouldn't commit resources to both Atom and VSCode, but as far as I know both projects continue to be developed.)
Additionally, discord's fine-grained structure is great but takes time to set up. Slack is pretty painless, isn't it? Technically if you're working at the same company you wouldn't need such finegrained control, unlike with random strangers on the internet.
When I see a slack alert, on mobile, I know I have something that needs my attention, because I have most alerts off. With discord alerts, I know that someone has pinged me with a question or wants to go grab a beer or something, but it's not urgent.
I enjoy separating my life/work like this, but maybe to others it won't pose an issue.
[1] https://zulipchat.com/plans/
[2] https://zulipchat.com/for/working-groups-and-communities/
Many IRC channels have logs that go back decades.
No. By targeting the enterprise market, Slack is not leaving money on the table, it's not losing money. The claim that there's money in targeting regular users needs proof.
What was wrong with each of those other options? To me, Discourse seems like a much better option, because it's designed to interoperate (rather than to trap).
Quite frankly, Teams is at least "good enough" and quite frankly I didn't even bother looking at the advanced functionalities (if available at all). But Teams fits a lot lot better with our existing Office 365-based infrastructure (domain authentication and everything) and it's already included in the office 365 subscription that we already pay.
Yes, you could do most of these with irc's v3 protocol, but no one seems to be investing time and money to do that.
Matrix bridges for irc are also interesting as you get some of these benefits, but to the dismay of the IRC users that will see links for messages longer than what their server allows, and weird usernames that include [m].
* Threads * Images * File upload * Markdown-like formatting (although very annoyingly it is arbitrarily different to markdown and doesn't support links). * Emoji reactions (you probably think that is frivolous but it is genuinely useful) * Channel history (i.e. you don't have to be online at the time to receive messages)
Some folks would vehemently disagree with this being considered useful.
Anyone who has used IRC when there are two simultaneous but separate conversations happening in the same channel will know how shit it is.
(See what I did there, putting a wink emoji after that sentence?)