Last Sunday I saw a tweet from TechCrunch founder Mike Arrington that said he missed the old Silicon Valley and might try to do something to bring it back. I was enthusiastic, and suggested what the tech industry needed was a new open platform to grow on. I was thinking of the IBM PC in the 80s and the web in the 90s. What Twitter might have been in the following decade, had they not punted.
Mike responded that he can't afford to do it, to which I asked if he was an investor in Slack, one of the famous unicorns of the new tech industry. A startup with a market cap in excess of $1 billion. It is both an open platform and a financial juggernaut.
That got me thinking. What would it take to fully develop Slack as an open platform, even beyond where it is now. The answer came to me right away. If Slack is the IBM PC, what we need is the Compaq. Or if Slack is Netscape, we need MSIE (the early versions of course, not the malware-infested wasteland that MSIE turned into).
Back in the heyday of PCs, the first round of PC competitors were near-clones, they could run PC software that was modified to work on their systems. The differences weren't huge, but they proved to matter. The near-clones eventually fell by the wayside, because if they didn't run PC software out of the box, users didn't want them.
The Compaq PC ran most IBM-compatible software out of the box, unmodified. I was a PC software developer at the time, we totally appreciated not having to create a new version for each PC competitor that came along. Compaq grew like a unicorn, and the IBM PC kept growing along with it.
I think Slack is big enough and important enough that it could serve as a foundation for a great new open ecosystem. A good Slack clone would have to work with the existing base of webhooks, unmodified. Exactly as they are. "Out of the box," as we used to say.
I don't think this would hurt Slack-the-Company at all. They are clever and moving quickly, and most important they understand and love their users. That's what it takes to maintain leadership of a market. The users have to think of you as the "official" platform, and the others as clones. If they hold to their principles, and I don't see why they shouldn't, the users won't be fooled.
Personally I'm not particularly interested in cloning the user experience of Slack, however I am interested in being able to run their webhooks in other environments.
Run incoming and outgoing Slack-compatible webhooks unmodified.
It must be open source, MIT license or equivalent.
Written in JavaScript.
No frameworks, no dependencies.
Runs in Node.js on the server, in browser-standard JavaScript on the desktop.
The layer that runs the webhooks must be a cleanly factored separate module, not integrated with the UI, so it can easily be incorporated in other kinds of software.
I can't think of anything else at this time, can you?
Stewart Butterfield, co-founder and CEO of Slack replied: "I would like this! We'd need to clean up our APIs a bit (working on it) and add a few simple capabilities. More the merrier!"
That's really cool. I was pretty sure he'd go that way.
I've got less than 1/2 of the webhook API implemented.
There's a lot of text processing that goes on when Slack receives a webhook call. I have a little of that implemented. But I do have an app that receives incoming webhook calls, and does the correct thing with them, distributing the data to all the clients that are hooked into the server.
I have to say the API is as clean and sensible on the server side as I thought it would be from implementing a client. Slack has a very practical engineering culture. I'm totally enjoying the work.