I read an article about Slack that praised their speed of integrating feedback and iterating with the following example: "the Slack team quickly identified small changes that had a big impact: Within the list of channels, they added fields for a description and the number of people using that channel."
One time I asked why, since cgroups and the pattern of container based deployment had been popular for a decade before Docker started, that containers are so popular right now. We ultimately decided that someone constructing a really easy to use suite of tools around the concept was the reason it has all this love and growth.
Not that I totally disagree, but, signing up for Slack is easier than using NickServ for the average person. There's a bunch of features that make HipChat, Slack, Hall et al easier to use than IRC, especially for someone who doesn't want to learn anything new.
Replacing RSS with walled-gardens solutions from Internet Bigcos is another example.
In general I agree that ease-of-use is a big factor. Having said that, I was witness to decidedly non-technical teens in a mid-size town quite happily using mIRC in 2004, so maybe we're not giving people quite enough credit. If you tell people something is hard to use they'll believe you.
The real lesson is to look into what has been done and worked before and see how it can be improved if you're looking for "new" ideas and businesses.
My friend's mom used irc in the 90's / early 2000's for dating chatrooms. IRC can be plugged into the browser and embedded into applications seamlessly.
In contrast, I've never even heard of all the things mentioned above.
On Slack the channel owner will form a hierarchy too, if it's less problematic it's because Slack is usually used in a professional setting where flaming is generally frowned upon. You see these kind of issues pop up on the easy-to-use Twitter as well.
It's a social question. The most the tech did wrong was not making flooding impossible in the first place.
Having a botnet with all your servers really isn't a bad idea. I mean, easy admin access, live monitoring, the ability to query everything and have all interested ops people examine the output... pretty handy. Seems like it'd beat a lot of these monitoring services and tools people pay for these days.
No, I'm referring to a botnet. In the OP case we've got just a single bot which controls things, I'm more thinking 1 bot per server sort of thing so you can administer individual servers simply by directing messages at them.
Server goes down? You see it quit on IRC or send an alert message nickalerting relevant admins when a service halts. Need live information on just about anything, just direct a message to a given server. Could even direct logs to a separate IRC channel for each type of service, relevant admins can join and set alerts up just based on message content and keep track of small logs via IRC logging too.
You can make a lot of low visibility processes very visible using such a setup. Of course, it wouldn't be appropriate for a giant company, but for a small to medium sized one I think it could work quite well. For devops types who are already comfortable with IRC at least.
check out https://github.com/andyleap/srvbot. Still needs to do real time handling, but you can run commands on multiple servers and optionally receive output
There are a couple articles/repos out there with detailed steps on running Hubot on AWS. While the ease and simplicity of deploying Hubot outside of Heroku is not a tenth as easy, there are a couple of options out there.
Now we've got dependencies on node, npm, ruby, rails, heroku, some datastore, a queue for hubot, whatever your actual builder is (capistrano/chef/whatever) etc etc.
Right now I do all this with Jenkins+bash scripts. Inelegant and not as robust as I'd prefer, but so simple. I could just use a Jenkins adaptor for hubot, but then what's the point? I want locking environments, advanced permissions, and so forth.
I'm mostly complaining because I'm dying to implement chatops (mostly for slack-based deployments) but the information is really light, or the tools are too environment-specific, and I don't have people to bounce ideas/questions off of.
So as long as I personify a piece of software, it too can become the subject of worthless press articles?