-------------------------------------------- | |
Protocols vs. Apps | |
2019.08.09 17:52:14 -03 | |
-------------------------------------------- | |
In a Telegram discussion group, people were chatting about | |
alternatives to Slack - the chat application. I didn't much of the | |
discussion going on, because as I explained there I'm not a Slack | |
user and have not understood the appeal of Slack at all. | |
The Slack users in the group presented the main advantages as bein | |
ease of integration with other tools and a nice GUI (app) on | |
different platforms. | |
I come from the IRC world, I can see the value in the threaded-vie | |
in Slack, but what's left? Ease of integration? How many IRC bots | |
and botnets are there? This is very easy to implement. | |
So I started thinking about the second point: the app. | |
I like IRC because it doesn't force me into any single app. It | |
gives me the protocol and I can choose how to implement my client. | |
But the feeling I'm getting from the Slack users is that they don' | |
want that. They want *one* app, one *official* app, preferably | |
available on *most common* platforms (including mobile ones). | |
In the information overload world we live in, people don't want | |
choices. Do I have to pick an app? No, too complicated. | |
Now I'm let wondering if my talks about Site Reliability Engineeri | |
could be improved with this in mind. I present SRE as a protocol, | |
an API. It's up to you to find the tools to implement it. | |
What if what people want is not an SRE protocol, but just one SRE | |
app? Just a single choice: Yes or No. | |
Maybe I need to rethink my arguments. |