Slack Platform Launch
slackhq.com
slackhq.com
Or rather, another incarnation of IRC chat bots, email listservs, and stuff that's been around forever as commodity autoresponders, only now it's worth millions in investments to write the equivalent of a weekend hack IRC bot because of artificial scarcity imposed by a non-open platform.
There are lots of people building things on proprietary platforms all the time. Why single out FB and Slack? AWS is proprietary. Twilio is proprietary. It's not as if it's hard to find examples.
And so what if some small team implements an auto responder bot and gets a couple hundred thousand in investment?
The gatekeeper function of the platform means they can shut you off at any time.
If instead, Slack published a protocol so anyone could author a client, then bots would just be normal chat users, for the most part, on par with regular users, and a bot would simply be something you deploy somewhere to sit in your channels, just like IRC bots.
I think Slack is a great app, very good UI, but I'm a little sick of proprietary messaging. We really don't need proprietary centralized messaging networks. Standardize a federated open protocol and let people compete on the clients and let the community agree on extensions to message payloads that clients pay attention to, or ignore.
ps. your https://actor.im/platform page 404s
FB and Slack are platforms in which you write directly for it and it cannot be used or moved elsewhere.
AWS provides many things but, unless you're directly integrating with them, you can move onto another service if you need to (and even direct integration you can later abstract and move away from many of their services to alternatives). Same with Twilio; they provide SMS and other like services but others do as well so you can move your app to any platform with, mostly, minor code changes.
You can't make a minor code change to move your Facebook or Slack app to another vendor / platform. In fact that wouldn't really make sense.
My point is that we have certain implicit biases (I too hate FB and Salesforce as platforms) but those biases aren't really based on some kind of general principle that "proprietary platforms are always bad and dangerous".
Proprietary platforms run by untrustworthy companies are bad and dangerous.
But do proprietary platforms run by trustworthy companies exist? If so, what happens when a new CEO, product owner, etc takes over and makes changes that could ruin existing relationships? Seems inevitable for every platform to evolve to some degree; what if the evolution is simply not compatible with what you built? Does that make them untrustworthy?
It all seems kinda nebulous to me and I'm not sure I'd want to put all my cards in one basket :)
Where is this unicorn proprietary platform that is run by trustworthy company?
Not everyone grew up on IRC with bouncers, irssi on a remote server, and their own server where they could upload attachments to in a single keystroke.
Now it's true that there are new alternatives for non-technical people such as IRCCloud, but (a) it costs money for individuals (b) it's frankly not as good, UX-wise. Hence not as popular.
Why is that so hard for people to understand?
This happens over and over again.
- Google wasn't the first search engine. - Facebook wasn't the first social network. - Microsoft didn't build the first operating system.
They all just did it in a way that appealed to mass amounts of users.
Now, to answer why is it so hard to understand? Many people here are programmers/engineers and fail to understand how marketing and nice packaging can sell. Especially if they are old enough to know how IRC works.
To extend what you wrote, I'd compare Slack with iPhone. All the tech. to build the iPhone was there, but Apple managed to put it all together in beautiful, easy to use package. Slack is the iPhone in its area.
No, Netscape/Mozilla didn't need to "own" HTTP and HTML completely, and turn the Web into a giant App Store in order to innovate in the Browser client, neither did Google, Apple, or MS. At various points, proprietary extensions were tried, and either failed, or got standardized when they became popular or proven their need.
All Praise to Slack's UI, I love all the flourishes, like auto-detection of paste of code bits and offering to create snippets. I get it, I really do.
I just don't think we need another messaging platform owned by a single company.
Unfortunately it's not in the best interest of anyone capable of engineering open/distributed platforms to actually do so. Why would they? It's way easier and more profitable to create something on your own terms, something you can control. I would risk that it's better for the customer.
People are flocking from WordPress to SquareSpace, from self hosted SMTP servers to Google, from private hosting to cloud hosting.
Is this a good thing in the long term? I don't think so either, but doing it any other way would be heroism and we are short on heroes.
UI is absolutely important to getting users on to a platform It's also a totally distinct issue from the network used for communication. There's no reason we can't have a good UX with an open protocol too, and that's what was being talked about.
For example if it was a rich client based on IRC, I could join in on a chat without being a slack customer. I could also be a customer of a competitor that would offer something similar, but more tailored to my usage. Now that would move the chat ecosystem further.
But that is not happening, because Slack's business model is hegemonic: they want everyone to use Slack to maximize profits.
If the protocol were to be upgraded then one would have to wait for all of the vendors to support the new features or we would end up working with the common denominator. Real world examples are hardly scarce, we see this thing in the open web with myriad (semi-) proprietary extensions. Samsung has also hard time getting developer support for their unique features.
In the end, the end users would suffer because of inconsistencies. Open platforms are good, but in my opinion they will always lag in user experience behind well executed proprietary solutions.
Once Slack is installed and the norm, you lose some choice. You're prisoner of the way they want chat to be.
I'm sure glad Firefox exists, because otherwise I'd have to hop in the Chrome bandgwagon and sell my data and habits to Google without a choice. The competition there goes further of course, as Mozilla upholds different values, and competing teams try to make their products faster and better.
And then, they fall. Look how Microsoft used to sell a product but now capitalizes on users' data. What will happen when Slack falls? What if I don't want my chat data hosted by some company, but in house, and my business partners use Slack? Where will the choices go?
If Slack falls then, well, we'll pay the price of migration, but seeing as it is a tool for ephemeral conversations I see it as less of a problem as migrating e.g. my e-mail.
We could have a rich ecosystem of competing chat clients over a distributed messaging bus, it's just that there's no economic viability in it.
If SMTP were re-invented today, it would never be open and federated.
Real world friendships have ended because of how emoji are rendered differently on different phones.
Slack could still have an awesome UX and be open, people would use it out of choice because it has the best UX.
We hope that a Matrix-enabled client (https://vector.im is looking promising) will get the UI/UX right - and thus actually offer an open and free solution where you can run your own server (should you choose) and own and control your own data!
My biggest issue with Matrix still has to do with its privacy properties though. Homeservers simply know too much about their users. End to end encryption from clients to homeservers appears to be optional in Matrix (and even with e2e encryption, metadata will still be fully exposed to homeservers), and message histories are stored in plaintext at rest.
Now, this probably won't be a huge problem in the ideal scenario where the Matrix network would be composed of a large number of small independent homeservers, but history has shown that decentralized systems that aren't fully decentralized tend to eventually converge towards centralization as it becomes more popular (just look at what happened to email). And in a world where Google, Facebook and Microsoft's homeservers might eventually have a combined market share of over 90%, the privacy aspects of Matrix leave a lot to be desired.
What's sad is that's so true. I overheard the other day my 13 year old niece saying she didn't like a certain girl hanging out with them anymore, because she's the only one "with green chat bubble".
Yes. They excluded a girl from their group, because she didn't have a blue chat bubble. (Essentially an iPhone).
As the surveillance engine grows, those of us who have gone through the pains of open-sourcing our workflows will be way ahead of everyone else... but I fear we aren't addressing this main issue which is ease of use/adoption for general user cases.
And no, giving me an API does not make it open.
Short story; we need better FOSS UI/UX.
This is an "apples and battleships" comparison.
As a startup founder – chatlio.com – betting on the Slack "platform" I have to say that it feels pretty great to know that they are not planning on cutting us off tomorrow morning... :) Might happen anyway of course, but this announcement means we can work somewhat more serenely for a while longer. I see this as a kind of "stability pledge" to third party dev shops.
Nope, it has value because it can be used by people who aren't massive nerds.
Don't say "it'll never happen"...
Mailing list archives are handy when you are looking for a solution to a problem. With Slack, a lot of that knowledge disappears.
> but one thing that concerns me is that the discussion that happens is no longer (easily) searchable.
No it is not. Look at the top right and type your words. If you use free plan, only 10k message will be archived, other than that it will be deleted.[1]
> Mailing list archives are handy when you are looking for a solution to a problem. With Slack, a lot of that knowledge disappears.
Its a tool for direct communication for group, not for documentation. I think you miss a hammer for screwdriver.
How do I find the answer to a question that was posted two months ago, for an open source project that is not paying to keep more than 10K messages?
History vanishes with Slack. I get why this is very cool for internal communication. I just question the use of Slack for open source community driven projects.
Chat and ChatOps aren't going anywhere, and Slack already has a gaggle of nascent competitors, both commercial and OSS.
If you build on Facebook or Twitter and they tell you to pound sand, it's game over. If Slack does the same, you can add support for everyone else - if you haven't already.
You aren't building a "Slack app," you're building a chat app which happens to support the Slack API. Huge difference.
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
It really is true. My previous employer had a dream of turning their extremely specific web app into a platform, with an app store and everything. I assume that being a platform means big bucks, idk.
[1] https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_la...
E.g. let's look at Eclipse: It was based purely on AddOns right from the beginning. And still many people want to replace it with other things (probably without AddOns).
Rather than putting more money into the mothership, you bet on external tools that will help the mothership grow.
It is also a way to reduce the costs of acquisition of the best integrations. If the majority of slack shareholders hold the majority of the shares in the best integration, it effectively lowers the price of acquisition to turn the tools built on slack into internal products/features.
Now that it has established itself beyond almost any doubt, its INVESTORS have established an $80M bet around those who make the company a core component of their strategy. Slack, which has very low burn, seems to have contributed to this fund but we can safely assume it was a small amount (if at all).
This is a sign of strength. We're still creating transformational companies with real revenue models, and these companies often facilitate other great companies. Tech is strong - valuations may be wrong one way or another, but tech is a great place to deploy capital.
The massive amount of integrations for it helps a lot too. Their goal, from what I've read, is to be a giant log for everything in your company, not just a chatroom service.
There are parts we don’t like about Hipchat (the shortcuts for the emoticons are just weird), but we are using it company-wide where Slack was just used by developers (and Hangouts was used by everyone else).
This integration will allow you to receive updates in a Slack channel when an alert is triggered in New Relic. If you would like web, transaction, server, and mobile alerts to be posted in separate channels, you will need to set up separate integrations.
You can quickly hit the limit of ten integrations on the free service by having to set up a separate integration for each channel you want things to appear in. So…between GitHub, Bitbucket, Semaphore, a custom API integration, and a couple of others we ended up hitting the limit of 5 integrations (which is what the limit was as of May or June when we made the switch to HipChat; it’s double that now, but we’re starting to use even more tools, so it’s the same problem).
really? $7 per active user per month? How little do you pay your staff? At the median wage, save an average of 90 seconds a day per person through better communication and it pays for itself. And it's pretty likely any team members using slack are at a 2-10x salary multiplier on that, a $100K engineer only needs to save 24 seconds a day...
As a company we are not short of options: Slack (the dev team liked it, but no one else used it and even a large part of the dev team didn’t use it), Google Hangouts (what everyone else used), Skype (no one here uses it), and now HipChat—which everyone in the company uses. This means that we weren’t choosing between $0 and $7, but:
• $0 (Slack) which provided something most people in the company didn’t use, and whose limitations we in the dev team hit fairly quickly (both 10k message chat history and the limited number of integrations).
• $0 (HipChat) which provides something most people in the company do use, and whose limitations we have only recently hit (the last six weeks) and are not currently bothering us (the limitation is just the 25k message chat history).
• $0 (Google Hangouts). Not really $0, but we already pay for it as part of GApps so it’s an incremental $0. The group chat functions suck, and there’s no integrations to speak of, but it is available.
• $2/mau (HipChat). Adds video/voice calls and screen sharing and unlimited chat history. We only need the chat history, and that isn’t bothering us.
• $7/mau (Slack). Just removes the 10 service integration limitation (which IIRC was 5 a few months ago) and the chat history and a few other features we don’t really care about but nothing to write home about. There’s also the $12/mau level and they are working on an Enterprise level.
There is absolutely nothing that Slack provides—except a bigger bill—that HipChat doesn’t provide as well for less. (And, even if Slack were better than HipChat, it isn’t 3x better. Sorry.)
This isn’t to say that Slack is a bad thing, just that it’s stupidly expensive and/or limited compared to other hosted options.
Why would you ever want to entrust a log of everything in your company to a third party service? Honestly curious.
Sure, you wouldn't have wanted to host the Apollo Program's lab notes on Soviet servers, but your cat selfie startup isn't quite as high-stakes as that.
Unless your cats are taking selfies on Mars. In which case, yeah, maybe developing an in-house chat service is worth the investment.
I find this to be a pretty interesting comparison. To the best of my knowledge, the entire stakes of the space race were "we might lose face".
My perspective is framed by working with an EMS provider (PCB design & assembly) who does business in some highly regulated fields. We've started using Slack in the last couple months for some of our teams, and love it, but the idea of using it as a catch all strikes me as questionable.
If we used Slack for actually talking about the design/assembly portion of the business, and not just coordinating sales and marketing efforts, our customers would flip shit. And rightfully so.
At the end of the day, Slack is really useful, but I just don't see its use getting expanded much. At least for us. There's lots of stuff that just shouldn't get communicated across there. Coordination across the sides of the business that don't use Slack wasn't an issue in the first place, it was never really even considered afaik.
hn-username @zulip.org , or https://groups.google.com/group/zulip-devel
And then what if Slack gets hacked?
http://slackhq.com/post/114696167740/march-2015-security-inc...
Q: Were my messages taken/read/accessed?
If you have not been explicitly informed by us in a separate
communication that we detected suspicious activity involving
your Slack account, we are very confident that there was no
unauthorized access to any of your team data (such as messages
or files).
Yikes.
Second (this is the point I think hn-like forums grossly underestimate) is because the alternatives are not really alternatives. In practice the likelihood of using Irc or some open source chat within a company with the same wide buy in as slack (or Skype etc) is 0.
The way to judge this is adoption.
It may not be quite as "slick" looking, but it works very well.
Slack has said before that they're going to release a self hosted version at some point, so they have to know this is true. I think it makes sense for them to focus on the larger market (personal use and the SMB sector) for now though, even though the enterprise market will really make them money, because it's a much lower pressure space where they can afford to experiment.
The lawyers and Congressional subcommittees are going to love this.
there are many, many offerings, like Google Apps Vault, to facilitate this.
UX/integrations/apps/speed/etc might all be the answer but it was visceral for me.
EDIT: This is a fairly recent problem. A month or two ago, I had never experienced this.
Folks on Macs had no idea what I was complaining about though. Go fig.
If I have to cycle through 4 rooms to get to the conversation I want, it can take seconds just to Option+UpArrow there.
Plus I can't manually reorder rooms as I like. I don't get why everyone talks about the Slack UX. Slack has snippets. Which I find mostly useless. Especially since they kill performance. But HipChat lets you reorder rooms as you see fit. Which is something I actually used and miss desperately.
At least Slack has finally gotten rid of the useless Channel vs Group distinction?
Slack also has a nicer UI and better integrations for us, and generally just always works how I want. I don't know if I'd call it a "revelation", but it's way better than any comparable product I've used.
[0] - I think HipChat recently added support for more granular notification settings, but I don't use it anymore. Also, it took over 3 years of this being their 1st or 2nd most requested feature before they addressed it, so I don't give them any credit for having it now.
[1] - They might get an email depending on their settings, but the HipChat app would never give a notification.
I dunno what notification settings hipchat is missing, but I'm not sure I need whatever it is missing. If I get tagged in a message, I get notified. Not sure that I want more than that. We have our deploys and a few other things hooked up to hipchat - at first when we started using it we went crazy with the third party integrations, than realized we didn't actually need all the noise the integration notifications gave us and turned a lot of it off.
We don't even pay for it and we get all of this.
I first used HipChat more than 2 years ago, and the notifications worked perfectly and were as configurable as I wanted them to be. Offline notifications worked well.
We tried Slack when it came out and couldn't figure out why anyone would use it over HipChat, since it had no native client at the time.
A pattern I have seen in Slack that never happened in Hipchat is "Let's put notifications into the channel" > "ugh, this channel is impossible to talk in because of the notifications! let's create a new channel with no notifications". Kind've kills the point of notifications.
Aside: does 'notifications' need to become 'n10ns'?
Slack's notifications lack customization which makes them annoying. Either you get the whole package, intrusive desktop pop up and all, or you get no notification. Where's the option to have sounds but no pop ups? Where's the option to lump notifications so you don't get spammed?
A portion of the difficulty is owing to them using a web app in a SSB (single site browser) instead of a properly native desktop app.
I would love to be able to tile different channel/message windows, like we all did with IRC clients. Unfortunately this is fundamentally intractable in an SSB-architected app (including Electron, node-webkit, et al.).
Right now I'm not seeing a difference between this and HipChat but everyone seems to love it so I'll use it I'm just kinda indifferent and unimpressed with it thus far.
There, you now have sound and no banner-style alerts. You can customise a lot more and all apps that are able to do notifications go through there.
Often it's an innovation along some other dimension - process, business model, etc. In this case it's Slack's business model and "platform" strategy. Other tools like HipChat were just that, a tool. Slack is a platform in the sense that it enables businesses and developers to leverage and extend the platform, thereby adding additional value to the platform. This leads to so-called "Network Effects" where as more apps are built on the platform, the more valuable the platform and the more likely others will want to build on that platform, etc. in a virtuous cycle.
How many man-hours am I going to spend fracking around Rocket Chat, Mattermost, and Sandstorm?
I think I'd much prefer just paying Slack to worry about that for my hypothetical new business with 10 employees. 6.67 * 10 * 12 = $800/annum.
Peanuts. Especially compared to the value of my time or my employees time.
1) Install Sandstorm (curl https://install.sandstorm.io | bash)
2) Install Rocket Chat (one click)
3) Set up a domain. Done
Regarding maintenance: I set it up 2 months ago and it's still running smoothly.
People underestimate the costs of "rolling your own" or even going FOSS. It's absolutely never "set it and forget it."
Most of these services that charge nominal fees ($5 - $100/mo) are interesting because you don't have to control your own support procedure and ostensibly they're build to scale.
Have you tried Sandstorm? It is in fact designed to be "set it and forget it" -- that's a major goal of the project. Everything auto-updates, you never have to edit config files, it can configure DNS and fetch/renew SSL certificates automatically, installing new apps takes one click, etc.
(Disclosure: I'm the lead developer.)
For individual users and small companies, single-machine Sandstorm is pretty reliable, but it's true we don't automate kernel updates yet (which will require scheduling reboots for off-hours). We'll add that eventually.
(Sorry for all the vaporware.)
That being said, to roll your own you'll need to run a box somewhere, select secure defaults, and keep on top of patching the box itself. It's not worth it unless you're really willing to spend the time to do it correctly.
That said, we plan to build a "Sandstorm OS" that auto-updates everything including the kernel, and doesn't even have an SSH interface (wouldn't be useful anyway).
$80M is the price they have to pay to go in monopoly position as soon as possible and become a platform.
Slack was founded in 2009 and has raised over $300M (yes, three hundred million dollars) [1]
By having six investors in the fund, each fund can mitigate risk of Slack's platform not getting traction while lowering the barrier for developers to enter. This slideshow by A16Z outlines why the venture capitalists (including some on the list of Slack fund contributors) are tightening their belts around investing and telling companies like Slack to generate reliable business models rather than IPO prematurely.
This premature IPO behavior was the reason for the last bubble, and I think this investment fund is proof that we are NOT in a bubble. The new strategy for these investment funds is to allow their startups to generate revenue on a much more stable basis without the need to go public (and get cash for equity) for this to happen. Most B2B companies would eventually benefit from a recurring-fees model built around the Slack platform, and this enables smaller, fledging companies to scale much more quickly towards long-term cashflow positivity.
In all, the kings of tech companies are those that find some sort of platform or natural monopoly. Slack may be next in line to follow Airbnb, Uber, Twitter, Facebook, and Google respectively. Overall, by allowing a method to build these platforms while not going public, investors increase returns for their companies in the short AND LONG term while maintaining a course of innovation!
It's an interesting point that bringing multiple sources of external capital to bear on an ecosystem via a multi-sponsor fund, rather than into the business itself via an IPO, allows the business to grow at a natural rate, and avoids Slack contributing to a "bubble" in which companies race to go public to launch their own platforms. I think we've learned from the last time around that the public markets aren't the best place to manage expectations in technology.
As for why the sponsors made this investment, there's a very good case to be made that (a) efficient free-form communication within agile teams at small and large companies is a pattern as crucial to developing modern businesses as a CRM, and (b) Slack is perfectly poised to capture and hold this new market in the same way that Salesforce was. Certainly worth a $13mm commitment that's diversified amongst companies whose teams could still pivot should Slack not work out.
[0] https://www.salesforce.com/company/news-press/press-releases...
ON THE OTHER HAND: Twitter and Facebook make money on ads, and that's what caused them to change course. Salesforce apps are still a huge business and that's closer to Twitter/FB than Slack.
Of course you are correct that you would never want to bet your business on their platform.
Now, if there is "synergy" with that integration, then it makes sense, but this assumes you have a profitable standalone business to begin with.
If your app is another way to poke people, you will lose. If your app was the first way to post pictures on twitter, you're screwed.
Slack is still very much at the bottom of the growth curve. I have seen electrical contractors who need a way to chat with onsite workers at various projects switch from using WhatsApp/SMS to Slack. If one click job scheduling apps start appearing in the Slack App Store they will be quickly adopted by these businesses. I would be surprised if Slack or something like it has not completely wiped out internal email in 5 years.
What I can tell you is that it factually has wiped out internal email for our team at Charge.
And I think that's pretty common for most teams that have used it. Why write a slow clunky old email when a Slack message will do?
Because email is threaded conversations, while slack is not. I can write 5 different emails and respond to each thread individually, but I can't do that in slack: I can write 5 messages, but my peer(s) can't answer each one individually - they can just write 5 messages and I have to figure out what they respond to.
Email has the added benefit of working nicely when you're on a connection that's not always available (mobile, traveling, etc.) I can write the message and have it sent later, download all messages and read (and answer) them without a connection. Slack (and other chat applications) just falls flat on it's face when the connection drops from time to time.
Now, all of that might be properties that you don't need because you're never traveling and always on the same schedule, so that you're able to answer questions in real time - but don't assume that's true for everyone.
http://techcrunch.com/2013/03/01/twilio-and-500-startups-lau... http://recode.net/2015/05/20/twilio-launches-50-million-deve...
Not much I guess. Twitpic anyone? [1].
1. https://blog.twitpic.com/2014/09/twitpic-is-shutting-down/
I'd love to create a Browserling integration. Browserling (www.browserling.com) is a live interactive cross-browser testing service and this integration would let you embed a live browser directly in Slack.
Use case: Let's say a user reports a bug in IE10 on Windows 7 in your webapp. You just use `/browserling windows7 ie10 URL` command in Slack and that will embed a real interactive IE 10 on Win7 that runs your webapp at `URL` directly in Slack.
1. We've browser sharing scheme:
www.browserling.com/browse/Platform/PlatfomVersion/Browser/BrowserVersion/URL
www.browserling.com/browse/win/vista/ie/9/news.ycombinator.com
2. We've Live API (https://www.browserling.com/api) that hundreds of people use and that let you already embed real browsers in your webapps.
Combining these gives you great super powers.
We're mad open source fans and have open sourced hundreds of libraries including browserify, dnode, node-png, and many others (http://www.catonmat.net/blog/browserling-open-sources-90-nod...).
We're constantly inventing new things (http://www.catonmat.net/blog/top-10-browserling-inventions/).
We're a small and enthusiastic team, so we can quickly respond and adapt to our customer needs.
Zero inbox, quick response times is how we roll.
Our customers love us and we love them.
I give my phone number (415-423-1954) to everyone. Call me at night to chat about yesterday's football game or to yell at me that IE6 doesn't work on XP.
And finally we love to have fun at Browserling and we started our own nerdy webcomic about web developers and browsers https://lol.browserling.com.
1. Remember when Dropbox was dumb, because rsync? (Bunch of naysayers here citing fee alternatives).
From what I'm seeing, bots and integrations are great and here to stay.
Businesses will gladly pay money in exchange for time and complexity not spent rolling your own.
2. This seems like a boon for us happy slack users!
However, my question for those using chatops is basically how do you keep the repository for the bot "tame"? It needs access to _everything_ if you want it to be useful, which means having lots of secrets exposed to the bot.
This is essentially a command line script, as you say. But having that functionality and being able to discuss the results amongst your fellow editors is very powerful.
http://www.niemanlab.org/2015/08/the-new-york-times-built-a-...
[0]: https://medium.com/slack-developer-blog/launch-platform-1147...
I can't help but post this based on my experience pitching to vendors to join an app store.
Slack CEO: Yammer made $1.2B. We need to make $12B. For that I need to make a hit song with 10,000 background dancers with me on the stage.
Board: How much can you pay each dancer?.
CEO: $10/hr
Board: Ok. Announce an App Store.
You are already a hero and there are hundreds of them to jump on stage to dance with you in that 5 minute song.
CEO: Now you are talking!
Because we already used self-hosted GitLab when they announced the inclusion of MatterMost (FOSS self-hosted alternative to Slack) we simply activated that and have been quite satisfied with it.
- If you've never used Hipchat, Slack is completely revolutionary. - If you've used Hipchat, Slack is still cool...and then you see the price comparison and ponder...WHY?
I think the slack platform could eventually branch out into more traditional ERP areas (accounting, production etc.) and it could be an interesting potential shift from "everything from one hand" to "let's configure our ERP from different services"
Building a platform like this is nontrivial and there's tons of problems ahead but I like the general idea.
It seems like text chat is hard to get wrong, and with so many options, I wonder why (real) people choose slack specifically.
Slack builds upon a lot of core concepts that IRC had but differs in a few ways. 1) Simplicity, you can get up and running in a few minutes and have your whole team connected. 2) Managed hosting, maintenance and client updates 3) Excellent UX, features are intuitive and new features are introduced with guidance 4) Cross platform support and fast mobile clients 5) Integrations, being able to push and pull data across you apps from the place your entire team can communicate is incredibly powerful. The discoverability and ease of deployment (some can be deployed in a few minutes).
I think they have a great position in the SMB market. Surprisingly some enterprise organizations still use IRC internally due to the control they have over server/data etc. There is probably an opportunity for Slack to develop an on-premise solution for enterprise.
And of course, discussion threads. This is something Slack still doesn't have, and is a one of the reasons to stay with Flowdock instead. Everyone knows what happens with IRC channels when there's hundreds of people and multiple simultaneous discussions. Good luck trying to follow the conversation if you weren't following it realtime.
That said, it sadly seems that Slack will eat the whole pie, and it is probably the most future-proof choice at the moment.
Searching your conversation history in Skype is terrible. Slack really does this well.
Slack has a great core experience and I understand why it's doing so well. But it's weird to see an $80m fund to invest particularly in Slack addons when a lot of existing features don't yet have API support.
I really like! I'm imagining, say accounting integrations which are cryptographically signed by the accounting software and go into a channel.
I bet I'll be paying for an enterprise inside-the-firewall version of slack in the next few years, or wrestling with some competitor that's not quite as good, one way or the other.
Here's a fresh integration with Slack Button in Ruby, https://github.com/dblock/slack-bot-server serving a "Hello World" bot. Hope it helps someone.
Past tense! Much better/realistic parallel, than Facebook F8.
It's kind of weird actually. There's two sorts of people that defend these announcements, I've found:
The first thinks that they are going to build an "amazing" platform some day and that they'll follow this model for "growing revenue". So of course they defend it.
And then there's the second group that has some "great idea" who plans to build on Slack's platform. Personally, I look forward to 2 years of stories about how Slack was unfair to them, or changed the rules on them, or broke an API. Or didn't review fast enough, or any of the other complaints that pop up monthly about other closed platforms.
Useful, yes, 1/2 of interactions, questionable.
Or not.
GitHub does a great job with markdown, especially with programming-language-specific highlighting. And even things like strike-though text and URL's, which aren't specific to software development.
It's one of the few aspects of Slack that has me open to alternative services.