Atlassian launches Stride, its Slack competitor
techcrunch.com
techcrunch.com
I'm not sure when chat rooms became a business tool. Personally, I find myself distracted more than anything from all the notifications these apps cause, I get less done.
I have to be sure to quit every chat app and put my phone in "do not disturb" to disconnect and focus, and then I get coworkers mad that I'm not online.
At least with email I could take a while to reply without anyone blinking an eye.
Yes, I echo your concerns about having some "reply" time. Particularly since so many of my co-workers are all too eager to install these on their phones and use them outside of the work-place (i.e. always available to some degree). I absolutely refuse to install the apps, that's my line in the sand!
There are IRC solutions to this but IIRC it's something silly like a client that stays connected 24/7 to manage your user, then another client that connects to that client for your actual interface.
But that always has to happen in such distributed systems, Matrix has the same – your home node actually connects to the Matrix network, and you connect to that.
Even on XMPP you end up running an XMPP server somewhere which connects via federation to the actual network, and your clients just connect to that server.
Seems odd you would want to have you're internal company discussions hosted on a server outside your control. It's especially relevant to companies outside the USA who might not want to have their data under US law.
I wouldn't recommend IRC for office communication. XMPP is probably the better tool.
Our legal department wouldn't let us use Slack, for exactly this reason
What IRC client provides:
- inline image uploads
- multiline messages
- chat search, including messages sent while your client is offline
- pretty code formatting
- pretty text formatting
- file uploads
- user management
I know that IRC accomplishes something like 95% of what a team needs to communicate, but Slack absolutely shines at that last 5%. We currently use Hipchat, and it supports a lot of what I mentioned above, but it supports it badly and it hurts to use by comparison, when I'm in slack for other non-work teams.
We need to stop pretending that IRC is a good solution, and admit that it's only a "good enough" solution. It's an MVP you ship to prove to your customers or investors that you've got something, it's not a product you'd spend money to market.
All of that exists, and can be used.
I was a huge proponent of IRC but the lack of developments the past... decades has killed it for me. Discord is straight up better. Yes it's proprietary, but no, IRC is just not a good alternative at this point, it hasn't kept up.
And I love to death what the IRCCloud guys are doing but it's just not good enough to use as a proper communication tool especially in a company.
Admitting this is the first step to fixing it. If you want open source alternatives to win, you can't get stuck telling people the things they like aren't worth supporting. I like the fact that I can do text, voice and video in the same tool; that I have a searchable message history; that I don't have to manage the server myself; that I can make interesting bots with a webhook system and a websocket API; that I can interact with people programmatically over an OAuth2 API; that I can use markdown in messages, embed files and youtube videos, pin messages; that I can manage large communities using a thorough group and permission system (I'm managing a Discord server that has 20k+ people on it, this is stuff that can't be done over IRC quite simply).
And you know what, I like the custom emojis too.
Quassel isn't good enough (speaking as someone who loves quassel). IRCCloud isn't good enough (speaking as someone who loves IRCCloud and heartily recommend everyone here to support them by buying a subscription).
I used to say: Our best chance is that Hangouts is open sourced. Nowadays, I'm rooting for Matrix but I think our best chance is that Discord is open sourced. These protocols, they get developed with very little awareness of what people actually want -- they copy features left and right, try to either support everything and end up a bloated or unusable plugin mess (XMPP) or support nothing and end up unpopular. Most of them are toys. In the end, we need serious players, passionate about creating not just protocols but good interfaces to them. This is hard to find in open source.
Today, I'm in 10 and active in none. All the channels I left, even some of the ones I'm still in now, have switched to Discord, Slack or Matrix. The two only channels I care about are actually both mirrored on Discord using the excellent Matterbridge (https://github.com/42wim/matterbridge/).
I was a heavy IRC user. The audience is gone.
Your concept of "better" is distinctly different from mine. In my world, software without completely useless and unnecessary features is better than bloatware. irssi + tmux + logging + grep works great for 100% of actual not-embedding-useless-cat-videos-to-avoid-having-to-actually-get-work-done use cases.
In the interest of adopting your own borderline-uncivil tone: Stop assuming objectivity in your notion of evolution and improvement being the same as everyone else. It's not. Just stop. Please.
I respectfully disagree. It's incredibly helpful to be able to video/voice call a coworker instead of typing back and forth. It's also incredibly helpful to be able to quickly past a screenshot of an issue you're seeing, or to paste a quick snippet of code, or log, with nice formatting.
Yes, I could use my phone or another app, and I could paste my image to imgur and share a link, or point them to github - but that's another step, another roadblock on the road to communication and understanding.
Why I'm working on copy-paste of images and long text for quassel.
Why people are working on WebRTC via IRC.
All this is coming.
And when it gets here, then IRCCloud and Quassel would be a good answer to my original comment. But now, those clients don't provide those features, while Slack does.
And almost all functionality already is there anyway, as said.
The only company that ever funded anything for Quassel for example was Nokia. And that obviously ended ages ago, it’s all volunteers now.
If I have to install a special client (quassel) to access these features how is that any better than installing a XMPP client?
Only thing IRC has going for it is the existing userbase, most of who run clients that won't support these new features.
And we've got all the developers of all the major IRCds and cloents together, working on these things. In contrast to XMPP, where support for an XEP between clients is spotty, and in contrast to Matrix, where a single dev team runs the server with ~50% of global users, builds the clients, and servers.
I agree that XMPP is a better protocol, but with the people we have, we can, long term, change the IRC protocol, too.
Either way neat, and good luck. Like it or not, IRC is certainly going to be around for a long long time. It's going to be a long time before you get project devel/help channels to move elsewhere!
Then it doesn’t matter how each client does it.
This already works between Textual, IRCCloud, QuasselWebserver, and a handful more.
I'm going to stick with the one that does the things that I want it to do now, and doesn't require me to hope that the other person can see what I'm trying to post.
There’s a major tradeoff to be made there.
In my experience it is pretty rare in software development to have the need for a voice/video call. There are use-cases but they are rare and better handled by a specific software.
> It's also incredibly helpful to be able to quickly past a screenshot of an issue you're seeing [...]
And also painful. Sometimes I get screenshots from terminal screens showing error messages and have to retype them when e.g. grepping for keywords in source.
> [...] quick snippet of code, or log, with nice formatting [...]
If it's short just blob it into the chat window. If it's long then please use some paste service, as screenshots of logs are a nightmare (see previous point).
> [...] but that's another step, another roadblock on the road to communication and understanding.
Why is there another step? You can have multiple programs, tabs, terminals, shells, sessions, etc. open at the same time.
Disclaimer: I'm an ex-Atlassian (Product Manager) and my feedback is genuine, coming from experience. I'm also super happy to see my ex-co-workers getting Stride out but my opinion is not a Marketing plot. Software now requires the collaboration of many different roles, many of them who would prefer Slack/Stride over IRC.
And in mine, it's very common! I lead a distributed team, and frequently it's easier and quicker to move from text chat to voice in order to explain something.
It becomes an alerting system, task tracker, logging system, code review system and I could go on...
IRC is for realtime communications, other Comms are better off on GitHub Issues etc.
My experience has been slack gets abused.
I haven't had this problem at all. We do have certain notifications trigger Hipchat alerts, but they also send out emails, etc. - Hipchat is just a convenience for that.
Maybe it's a Slack problem but not a Hipchat problem?
It would be really neat to create a IRC server that bundled supported web, desktop, and mobile (ios and android) clients with first-class support for that last 5% of features, but I'm doubtful of how much money there really is to be made. People are cheap, and Slack is "free" - I mean, it's actually not free for the organization, but users don't pay a monetary price to download the client to use the system, so I see charging users money for high quality IRC clients as an uphill battle.
A one-click setup powers my IRC clients with multiple devices and logs even when I’m not online, powers a fulltext search ( https://gluu.kuschku.de/dl/videos/2016-09-16_04-03-36.mp4 ), powers a fully public logger https://gluu.kuschku.de/logs/ and much more.
All this exists, is free, and just works.
And there’s many more such systems that provide this functionality. From IRCCloud to many web clients.
re IRC it's not a hard problem to solve whatsoever
https://get.slack.help/hc/en-us/articles/201727913-Connect-t...
* Service packages are poor replacements for fine-grained permission controls and registration.
* Always-connected clients are poor replacements for message history and push notifications.
* DCC is a a poor replacement for video chat, screen sharing, or file sharing.
* /whois and /away are poor replacements for user status tracking.
IRC had nearly 30 years to evolve and has not. It's time to move on.
That’s why IRC has away-notify, which does exactly what slack and co do for status tracking.
> * DCC is a a poor replacement for video chat, screen sharing, or file sharing.
That’s why people are working on an RFC for WebRTC negotiated via IRC.
> * Always-connected clients are poor replacements for message history and push notifications.
That’s why message history and push notification RFCs are being worked on, and already implemented in some IRCds (Snoonet transmits the last 5 minutes before login marked as such, for example, others transmit everything you request)
> * Service packages are poor replacements for fine-grained permission controls and registration.
That’s something that I hate, too, but some modern IRCds have far better permissions systems nowadays. Oh, and registration and login happens via a standardized SASL anyway, so you can also auth via OAUTH if you have to.
A reference implementation of a WIP RFC is rather different from a thing you can download and install and have working right now in a server that isn't likely to change their implementation in a way that makes those features unusable (since they're headline features being sold to enterprises).
There's also the fact that most IRC clients suck, with interfaces that look and control like xterm circa 1980. Fine for the people that read Hacker News, offputting for everyone else.
Do any of these RFCs or newer IRCd's support full message auditing for the legal folks?
SASL is nice, but unless you're into something like Okta or some other homegrown thing, most are going to use plain old LDAP/AD. And AFAIK, permissions on most IRCd's are still pretty spartan. There's no way to make a room visible to one class of users but not others, as there's either visible to all or invisible to all.
This is konversation in 2017: https://blogs.kde.org/2017/09/05/konversation-2x-2018-new-us...
The version of Quasseldroid I am working on right now: http://i.imgur.com/obsJDyg.png
Textual, a macOS IRC client: https://www.codeux.com/textual/public/images/v600media/Yosem...
> A reference implementation of a WIP RFC is rather different from a thing you can download and install and have working right now in a server that isn't likely to change their implementation in a way that makes those features unusable (since they're headline features being sold to enterprises).
That’s why the IRCv3 Working Group isn’t some people in an ivory tower, but actually the implementers – the developers of the largest IRCd implementations, and of all major clients cooperate to design and ship new functionality. This means that basically every client and server has an implementation by the time it ships.
> SASL is nice, but unless you're into something like Okta or some other homegrown thing, most are going to use plain old LDAP/AD
The guys at CoreOS have a simple single-click deployed system for bridging LDAP/AD for that purpose. Alternatively, RedHat also has a solution for that, and provides enterprise support for their product (Keycloak), too.
For a developer I'd say I'm a little more people minded than average, and a lot more big picture success oriented. And in both regards your personal productivity doesn't really matter.
The biggest problem in software development is actually not per-coder-performance but that the right things get solved, and that the solution are actually good and quickly finished. Think about how much time you wasted using a colleagues API that simply wasn't designed well, at least for your usecase.
So, if more information means you are working on the right things, and that you understand your users better, and therefore make your tools more intiutive and usable, a hit to your performance, even 50%, is not a problem.
The funny thing is from a big picture perspective sometimes it would be good if some developers would just reduce their code output, without providing anything else, because it would help keep all other developers in the loop.
While I think it's fair to say these sorts of applications do disrupt people and reduce their productivity, I'm certain that they help focus team efforts in a way that meetings just don't.
You can't split off 3 members of the team and have an important technical discussion during a meeting (or if you can, your project manager / meeting organizer isn't doing their job). You can't come back later and see exactly what it is you said that you'd do after a meeting. You can't tell a bot to create a bunch of tickets or what the current status of a system is.
If you find that your chat apps are not providing you with any value, maybe you're using them for stupid purposes like sharing funny pictures & this mornings cool tech blog post, or you're subscribed to the support channel, or your team is treating them like a social hang out space.
It's not that its a bad tool; its that you're using it wrong.
You're right that the applications can be used productively. I find that my work Slack is a lot less focused on being productive than the dev channels that I follow in Discord for open source projects.
The other big issue is the discussion of asynchronous versus realtime communication: https://blog.doist.com/why-were-betting-against-real-time-te...
I do find that in some Discord servers we accidentally exclude people living in different time zones, which is not as much the case with an async medium like Google Groups or other mailing lists.
There is nothing wrong with doing that if it's in the right place - the off topic channel. The same is true if discussion that doesn't concern you is happening in a general channel - you tune out and don't see a message that are relevant to you.
If your team needs that kind of overhead then something massive is broken and a chat room is not going to fix it.
As a general rule, on large teams informal communication is vastly less efficient than formal communication. A major goal should be avoiding having the same conversation repeatedly.
For design docs, formal notifications, etc., there's still email and services like Quip. They are not mutually exclusive.
Having day to day discussions in informal channels and consolidating them into a more formal form of communication is a workflow I enjoy working with.
The overhead of constant context switching has a high price. If this is happening on your team, no tool can fix it. You have to fix the culture, and that's much harder.
1) me understanding the domain
2) finding a well factored solution to the problems in that domain
These things are incredibly hard. Using chat is like skipping a meal or a nap. Communication isn't valuable in and of itself.
Your insights good, it needs to be needed by managers and staff that the team is working as a team.
Ask your team who is most talented in their eyes. They'll agree on a small number of names. And if you ask them why they believe it, it's something like "because he wrote our test automation" or "he's the guy you ask about that really nasty part of ancient code". Everything else is only for self-fulfillment of the developers.
Sure, there's a new "method" every few years but these seem like tinkering around the edges.
I admit this is not a fully-formed idea but I've wondered about a concept where an entire team would be compensated as a team, but then the team would be responsible for hiring/firing. (Which seems only fair -- if you're going to be compensated as a team you should have control over it.) A group "audition" interview technique is discussed in Peopleware that I have sadly never seen implemented, but something like that could form a part.
But as long as people are compensated on an individual basis there will always be an incentive to treat communication and particularly assistance or training of other team members as a second-tier function, to be done only reluctantly if at all. But viewed from the throughput or potential of a team, someone who increases the performance of multiple other developers has a much greater shot, in my experience, of being the mythical "10X developer" than even a very strong individual contributor. And the reverse is certainly well-known to be true: someone who hurts the performance of people around them, even if they produce good code at a reasonable rate, may actually be worse than useless to the team as a whole. Producing an incentive structure that takes those issues into account that's based on measuring individual performance is extremely difficult, and I've begun to think impossible, given that the industry has been trying to do it for decades with little apparent progress.
It's the same result of you get what you measure
The more I think about it the more it seems like small consulting shops basically are team based comoensation, but it still ends up with 1-2 people deciding who gets paid what more often than not
Most problems that we solve on a daily basis aren't cutting edge, they are complicated business logic or customer facing UI that needs to be tested more than anything else.
Communicating requirements and vision at this point become more important than having your "rockstar" engineers outshine everyone else.
That said, one thing I've learned is that you can't please developers.
The same people on this forum that are deriding "personal communication" in favor of more formal communication are the same ones that complain about project managers and "unnecessary" status updates and communication.
I typically just do whatever the team wants, makes no difference to me whether they like to figure out everything in conversation or desire more formal status updates etc.
At the end of the day if I see the team gelling and working at a good clip, I don't mess with them and try to stay out of their way.
The same people on this forum that are deriding "personal communication" in favor of more formal communication are the same ones that complain about project managers and "unnecessary" status updates and communication."
I agree with all of your points, except this one. My own view is that managing a technical team is just extremely demanding, and many managers simply aren't up to it. Developers are educated, intelligent professionals who spend a lot of time thinking and talking about a range of specialized technical stuff. If managers can't keep up with their team on their own resources, they end up asking for more of the team attention to compensate. And from the point of the view of developers, that is unecessary communication that they don't get value from.
This is a valid point, some kind of asymmetry in the communication.
I don't think this contradicts what I said, rather branches off into another subject, whether your reporting manager is doing a good job or not.
Furthermore, chat is not high quality communication. It is mostly junk comms. If we wanted to encourage communication that moved the organization forward, we would have a structured medium that would automatically populate a knowledgebase.
Chat is not that medium. Chat is shat.
Until I encounter a problem, switch into chat, and find that someone else already solved that problem and it was archived by the chat system.
Flow maintained.
My chat apps run on a separate monitor that is purposefully not within my visual range of the monitors used when I'm coding.
The thing I hate is the opposite. When I'm told off for not replying to a message. Ergo need to keep it in visual range and stop what I'm doing on each message. Even if it's an inane broadcast from a team member.
Except organized differently, and easier to author rich content with. And the performance is better, messages are sent instantly. The overall UI is better in many ways.
That said email having subjects makes it different.
Some people delete emails after reading them, some put in folders, some tag everything, some have an inbox with 100000 unread emails. If I tell a colleague that I emailed them the info a week ago half of them will not find it and just ask me to send it again.
With chat I can just say "it was posted in the QA chat room about 2 weeks ago" and everybody will find the info equally easy.
Oh yes!
I once worked with someone that was so prolific that I had no chance to keep up-to-date with their changes and get my own work done.
Unfortunately, a lot of companies are starting to measure "time working" via "time on Slack." My company is one of them, but it works out for us because my team exists in multiple time zones (making the interruptible hours of the day fewer).
This is not a problem that's specific to Slack. I guess if you're working in an open floor plan, you would have the same problem - or perhaps many people would be more shy to bother someone in person than online. Slack (and apparently this new tool too) doesn't help though. It seems to support an ever increasing array of notification options. You can set your status to "do not disturb," but people can and will still ping you when they feel like it.
Sure, teams need to be working on the right things, in the right way, and need team leaders who can focus on the overall product itself, as well as the overall technical direction. But sometimes (often?) you just need people to avoid and ignore distractions and get their work done.
This doesn't just apply to developers; I hear from many non-technical staff where I work that things like Slack sometimes cause more interruption then they're worth, and need to sign out to get their job done. There is definitely such a thing as information overload, and there is definitely such a thing as interruption/notification overload.
Anecdotally, I really enjoy the Reactiflux discord server/group: https://www.reactiflux.com/
I've also transferred all my skype and hangouts contact lists into Discord. It's a lovely tool, lock in be damned.
- replies/threads (where you can reply to a specific message)
- star/flag messages (to retrieve them later)
- unable to set font size in the mobile app (the font size is too small for most people)
Let's just add another layer of indirection, and a layer of depth to the streams of information you manage!
Ugh.
But if you don't have threads, and the number of participants in the same chat room grows, how do you manage the intertwining of messages belonging to different subjects?
For the record, I very much like Discord, and I want to use it for a large group of volunteers looking for a coordination and discussion tool. We currently use Telegram. This is why I'm asking this weird questions ;)
I'm looking forward to Matrix eating all of their lunches. There absolutely no reason to have competing standards in this space. A horrible duplication of effort.
That comic would be more applicable if we were all debating XMPP vs Matrix.
Matrix needs you! We are facing a funding crisis.
UPDATE: The situation has changed and our need is more urgent even than before.
This doesn't send a very positive signal to larger companies considering this platform.
2. We're offering donations by patreon, liberapay, IBAN(!), bitcoin & ethereum. I'm a bit confused as to why letting folks donate by bitcoin or ethereum would be a turn-off for a manager at a company. If you really think that adding Stripe to the mix would help things we can do that; we've just added paypal too.
Basically, it's a catch 22. We need to advertise that we need funding in order to get people to fund us. If that turns off some people rather than encourages them to donate, then such is life :/
That's exactly what any other protocol evangelist would say, be it IRC, XMPP...
"Atlassian, the company behind popular tools like Jira, Trello and Bitbucket, has also long offered a team communications service in the form of HipChat. Over the last few years, Slack has had an outsize influence on this space, though, and the Atlassian team decided to go back to the drawing board and see what its take on a Slack-like team workplace communication service would look like. The result is Stride, which is launching today."
It says "back to the drawing board".
There's obviously a smart team behind this, and the protocol obviously has a lot of potential - I'm positive there are other ways you could fund this.
Also, I'd take Slack convo over someone coming over to my desk to pull me into a whiteboarding session.
As for notifications - that comes down to personal preferences and team norms. Disconnecting / setting do not disturb (which I notice is an explicit mode in this app) is important. People should know when to get a hold of you, how best to escalate, etc so you can do your best work.
IRC has been around for decades and is often used for the same purposes that I now use Slack for with various open source communities. Before slack, it was IRC for many years.
That is a team management problem, not a tools problem.
> I'm not sure when chat rooms became a business tool.
As soon as somebody figured out they could use something other than email lists to send messages to people in a business setting.
If people get mad at you for not being available, then it has nothing to do with which, if any, chat apps you use. It's a disagreement in expectations.
Then set your notifications and coworker's expectations appropriately. Chat tools can't fix bad culture.
Seems like a neat feature - if it became the norm across app apps, it may solve the concentration problem.
in that sense it is more like steam and xfire.
other than that I completely agree, but it still beats people coming over to your desk every few minutes and asking questions for which you need to stop your music and drop everything immediatly.
But maybe my marketing skills are just not up to the task.
I use both in a very similar way though.
Slack has a bazillion integrations with different services. Discord's integrations are mostly focused around game streaming. Slack lets you use a different email and identity for each team. Discord gives you a single unified identity that you use everywhere and doesn't even expose email. Slack has customizable data retention policies. I'm pretty sure Discord doesn't, but I don't actually know what limits it even places on message history. Discord lets you block people (which makes sense for a social group). Slack very intentionally doesn't support blocking or ignoring (because it's for business communications; if you're being harassed, that's an HR issue, employees should not be able to simply ignore each other).
And of course there's more, like SSO, user provisioning, custom user groups, guaranteed uptime, etc.
Don't get me wrong, Discord is great. But it's not really the right tool for companies. The only reason a company should use Discord instead of Slack (or Stride or whatever else) is because they're cheap and don't want to pay for their business communication tool.
For me, Slack and similar work really well for small companies or teams (20 or less). I haven't experienced work chat in a larger company or team, so I could see it getting messy.
As for people getting mad at you for going offline to buckle down and get work done, that seems like a business culture issue that isn't going to be any better at the same company if they got rid of work chat.
How do you do that with Slack?
In my experience, this is typically the expectation to respond immediately regardless of the query.
Nope.
Alternatively:
Channel -> [gear icon] -> Notification Preferences -> Just mentions
(But more seriously, even with a good MUA and either client-side or server-side search, the way mail messages are constructed, with tons of reply quoting, makes searching them a pain.)
In lots of business cultures there's no expectation to search email, because it's so hard to get useful results that way, so if you send it in an email you can expect to have people just ask you to send it again. Even if you can use search, it still sucks.
Slack is not perfect but it's at least designed for search.
And in outlook's web interface, this all seems to be even worse. Emails somehow just vanish. Not good.
Being on a remote team, without slack we'd be a lot more disjointed without having chat.
We have some business folk who insist to chat through email, and it always ends in a very convoluted chain with 15 people in...and it's horrible....
It is the absence of that feature that causes me to ignore e-mail.
Turn off notifications for chit chat and have your client only notify when someone says your name in the chat room.
Most protocols/clients have a 'DND' status you can use (coworkers respecting that is another matter). Most clients allow you to tailor the notifications in a way that works for you - ie the 'URGENT' channel notifies you but 'Off topic' channel doesn't. Messages from Bill don't alert you but messages from the boss and Juliet do.
Imagine a newly hired developer posts a question on Stride about some feature-request/bug for a product. A chatbot smartly intercepts this question, posts a response linking to the precise jira ticket that addresses this feature request, when it was closed & who worked on it last. This exists. Imagine the savings in cost & time.
New developer posts a question - hey how should I implement this feature in xyz language ? Bot intercepts, posts a response connecting to the API docs of xyz, or better yet, posts a code snippet from stack overflow implementing the algo in xyz. Imagine how much $$$ that saves in onboarding & training costs. This exists too.
Maybe the Atlassian Stride chatbot will have more meangingful jira webhooks that the Slack chatbot won't.
This is really a next-gen NLP+AI play. Nobody cares about the actual chat per-se - Chat is just a QA platform, and superior QA bots indistinguishable from human are one of the primary goals of AI.
Otherwise it's probably less featureful than the ones you mention.
It's still in soft-launch at the moment while we finish off a couple of key features that we identified in beta.
Without defending Slack (because I have reservations about it too), your coworkers should stop being mad you're not online, that isn't Slack's fault.
You have been abandoning us on JIRA and Confluence as well. There are many features that are not available on our self-hosted versions even when fully upgraded. Your licensing and pricing terms get worse year after year even though essentially absolutely nothing useful (to us anyway) ever gets added.
We even use Trello a little here and there... I expect that to go south too.
Well, at least we have GitLab and soon Mattermost, both suitable for much of what we need, for free. Thank you for making our decisions easier.
Additionally, they jacked up the prices on the Service Desk software users and changed who can do what at what prices.
All in all, I wouldn't choose Atlassian for any new installations/companies. I would definitely look elsewhere. And, I've been using their products since before FishEye was an Atlassian product (and they destroyed that product too).
This is why you hire dedicated Scrum Masters / PMO, and direct the PMOs to automate away what they can, as the domain becomes clearer.
Jira is actually really great for this because the REST API is so powerful, which can allow the PMOs to build systems which extract work from elsewhere, populate all the necessary fields which are repetitious and tedious for users to fill out, and then submit everything against the REST API and watch it all turn into issues.
When you start to understand that what Atlassian really did with Jira was build a powerful general UI abstraction over relational tables that even non-technical users can use, then you start to understand the sheer power of what's on the table.
AFAIK, they offer migration from Hipchat to Stride https://confluence.atlassian.com/stride-documentation/upgrad...
> We'll move all of your teammates, rooms, files, custom emoticons, and message history over to Stride for you so your team won't miss a beat.
On a former team we were forced to use hipchat and their android client just nuked my battery. It was like night and day; remove the app and my battery lasts 24-30h; with it hipchat installed it would last 10 hours. This was a stock Nexus device btw.
I don't think Hipchat is a POS - it gets the job done - but it is lacking some features that I would consider to be fairly basic. (Why can't I edit messages except with the s// syntax? Why can't I do basic text formatting?)
I do agree with you on the lack of faith, though. Jira's text formatting is even worse than Hipchat's.
I only log into the site from a desktop browser. No point reading messages when I'm AFK anyway.
> All of your rooms, teammates, files, custom emoticons and message history from HipChat Cloud will be in Stride waiting for you, just as you left it.
https://confluence.atlassian.com/stride-documentation/upgrad...
But I hear you on Atlassian seeming like they're abandoning things. I'm still waiting for them to fix Bitbucket's online editor which breaks when you try to edit files with different character encoding https://bitbucket.org/site/master/issues/13450/file-characte...
Are there any good options now?
Check list of items in confluence? Click and ... bam - tickets where you can track discussion, media, code, etc. Link back to the definition doc, and the doc has a status view of the ticket(s).
I've wondered if they've got some patent on this which has prevented other folks from replicating it. Or... is everyone else so focused on "disparate tools that talk to each other" that this tie in has never made it on anyone's radar?
If this was in redmine (for example) - having the wiki be aware of the ticket system - that would be great.
[1]: http://www.redmine.org/projects/redmine/wiki/RedmineTextForm...
EDIT:
Specifically, allowing people who are primarily text driven to be reading a doc/wiki page, right click a sentence or phrase, then create an issue right from that screen, without leaving, and have them linked back and forth, is... seemingly obvious, yet I've not seen it done elsewhere. Someone else pointed out gitlab - I've not tried it there yet.
Disclaimer: I work for the Add-on developer
The creation of jira tickets from confluence already seemed useful enough for my use cases - not sure that I'd need a plugin to do more, but interesting to see that you've got something (and to know others want it).
My original post was pointing out that this wiki/ticket connection is something I've only ever seen in jira/confluence, not in anything else.
I didn't really have a major problem with JIRA, but we self hosted them on AWS, and the resource requirements of JIRA, Confluence, Fisheye etc. meant that we had to set up separate instances to stop them crashing all the time.
Phabricator gives us the same functionality as all the Atlassian tools I mentioned above, but on one virtual Digital Ocean $10/mo server. It is much more reliable, and has a better, much more integrated UI.
Faster too - MUCH faster. I can really tell when I go back to JIRA to log a bug and have to wait 5 to 10 seconds for a form to build itself and load.
There was no explicit performance tuning happening here, either. 1 instance of Jira talking to 1 instance of MySQL behind 1 instance of nginx on a modest VM.
I'm not doubting you, but this is a common enough complaint that I assume there's a footgun lying around that I've managed to luckily step over.
Before our company started using Confluence, our team ran a Dokuwiki server. FOSS, can hook into AD, many plugins and extensions available. Worth looking at... yes, it does have Markdown based editing, though it has a rich editor to assist.
EDIT: Apparently they have a WYSIWYG plugin. Haven't tested it.
Generally Markup works well for coders, but if they're non-coders it can sometimes be a challenge to get people using it I've found.
It can link me all over Wikipedia style as needed, but I want the manual to come with my $ git clone and not have to fart around in some other document repo.
I dislike that it doesn't support MarkDown as a native language, but it does have a solid WYSIWYG.
I'd say Confluence is the best of their products and the one that I'd be most likely to use again in the future.
I've also used their CI solution at another company and I found that one easier to use than most of the other open source ones, although I haven't tried some of the newer ones in the last few years or GitLab's CI integration.
Linking between documents is super easy (as opposed to similar "low tech" solutions like Google Docs, Markdown files, etc), and features are sufficient for our use. Due to its simplicity, I find it one of the most exciting products recently. (Not affiliated whatsoever)
* No feature parity
* No pre-built packages or support for configuration / infrastructure management - everything must be packaged completely from scratch, without recommended package specifications or Dockerfiles etc. to build off of. Nope - "here's a tar.gz. Have fun!"
* No proper enterprise support and no access to source code. We have a couple feature requests which are deep, burning desires which we'd love to either throw money or developers at but we can't because we have no relationship with Atlassian and we have no idea if Atlassian will ever address them because they don't publish product roadmaps.
* Essential enterprise products like Crowd and Bamboo get short shrift and make it clear that communication inside Atlassian is lacking.
Example: Bitbucket Data Center shipped with support to enforce GPG-signed commits. But because Crowd won't manage user GPG public keys, administrators can't revoke user keys without disabling access to Bitbucket entirely (so, GPG keys never get revoked), and Bamboo administrators can't enforce that project builds only use Bitbucket repositories with GPG-enforcement enabled, so for enterprises which actually need to enforce audit trails (for compliance, for building trust with deeply conservative customers...), the feature is worthless.
Another example: Bamboo supports elastic build agents... but only on AWS. No support for vSphere, OpenStack, or heck any other public clouds like GCE or Azure. No Dockerized build agents for build jobs which don't themselves need Docker.
Another example: Crowd is utterly lacking of any kind of investment. Sun Directory Server Enterprise Edition? Supported. OpenID Connect? 2FA? RSA SecurID? Yubikeys? lolnope. It finally got active-active clustering this year, though, so maybe that's a good sign?
It's too bad their suite is in a class of its own because for all its faults, it's in a class of its own. Everything else sucks, one way or another.
To be fair to Atlassian, they basically invented on-prem with SaaS-style pricing (and did us all a great service), and their biggest competitor here (Slack) isn't available on-prem either. Some of these features that you list in Crowd are ironically very similar to missing features in our products, but we're actively working on them -- while not losing focus on being the fastest and easiest key manager to stand up.
Running a software business can be challenging -- especially with a myriad of customer environments and feature requests. My feeling is that Atlassian got really big really fast and may have lost sight of their key differentiator -- which, to me, at the time, was pricing and simplicity. It looks like this new product might have brought back their flair on both counts.
Also, telling on-prem customers to run
curl -# https://usrfy.io/upgrade.sh enterprise |sudo -sE
to manually upgrade.... for a security product... completely DOA.
That is a good point and that doc page is really incomplete. Upgrades are completely automatic in Userify, and without diving too deep into the `curl https | sh` debate :), security conscious are always well advised to do the regular curl > file.sh anyway, even with CA cert checks. Just a good idea.
So now that it's clear to me that it is possible to do an on-prem install, I decided to look at your curl->sh install script.
You guys are basically justifying the fears of our security folks. After grabbing sudo from the user, without asking permission, you pkill NTPD (!), add pool.ntp.org (never mind that we may run our own NTP servers, specifically to remove Internet-based dependencies to lower risk...) and start NTPD again, invoke an install-pip script from a server you don't control (https://bootstrap.pypa.io/get-pip.py) without attempting to see if maybe there's a local package of pip available, and then install the EPEL repository. Which is, you know, a perfectly fine repository, but there's a reason why the software included in it isn't included with the official Red Hat repositories and so adding the EPEL repository without asking permission to do so can wreak serious havoc on servers with auto-update scripts installed with the intent to only grab security fixes for installed software.
Why can't you guys just open-source some real packaging and respect the sysadmins who you want to be your customers?
> Upgrades are completely automatic in Userify
Most enterprises who are paying sysadmins to manage their server environments do so at least in part because they want their sysadmins to, you know, manage their server environments, like not upgrading services during peak usage (cough, Windows 10, cough).
I'm not saying I won't still try out Userify... I'm saying that, when one of my chief complaints about Atlassian was a lack of packaging support, you came in to champion a product that not only doesn't provide packaging support, but reminds me why packaging support is necessary. If Userify meets our needs, we'll end up needing to package it internally, which means it has to go on our priority list somewhere, and probably not near the top.
Sorry if this sounds harsh... just trying to keep it real.
Pull requests are gratefully accepted: https://github.com/userify/userify-server-tools
Why don't you discuss with one of our solutions architects (or me) by email instead? Most enterprises definitely do package for their unique environment, and we certainly will assist. My email is jamieson.becker@.
But I meant what I said.. we work with a lot of larger companies that need to integrate Userify into docker, ansible, terraform, chef, cloudformation, etc. There's so many different ways that people prefer to manage their systems that we don't want to push a single One True Way(tm).
We instead try to cover 80% of the use cases with a simple script that can be deployed in a typical cloud scenario which is open sourced at github -- and then customers can customize when necessary or even provide pull reqs back if their customizations are generally applicable.
Some of the parent's complaints are themselves a result of issues that customers have run into, and if this buried in an RPM, it'd be a lot less transparent on what it does and how it works. For example, we force a pip upgrade, because the version that's built into RHEL6 is too old and can't build cryptography, etc. We also don't forcibly add pool.ntp.org -- we run ntpdate against it to get a quick clock set. We have to add EPEL because RHEL6 and RHEL7 don't provide Redis in their own repos. This is designed to be run, as the docs clearly state, on a clean RHEL7+ or Ubuntu 16+ instance with defaults. How you customize it, either before or after, is entirely up to you.
Anyway, Userify is certainly not for everyone. A lot of people still prefer to manage their keys with shell scripts or Chef or something, which usually works great for small teams with flat perm structures.
Sorry for sidetracking the discussion about Atlassian. Even though we don't use their software, I'm a big fan of their success story. Mike Cannon-Brooke's deck on how they scaled Atlassian from $10k on a credit card is really quite awesome.. I can't seem to find the video of him presenting it at a conference, but the deck alone is great:
https://www.slideshare.net/mcannonbrookes/scaling-atlassian-...
Hipchat is already suffering from poor support, its windows client is awful since it went to "version 2".
> Starting soon, we will begin to upgrade all HipChat Cloud teams to Stride. HipChat Cloud will continue to work as it does today until your team upgrades to Stride. After upgrading, HipChat Cloud will remain in 'read-only' mode so that you can reference your API configuration in HipChat Cloud and receive integration notifications for those apps that are not yet in Stride.
That's been mostly true for a while anyway. You still can't delete or sanely edit a message in hipchat.
I've been using sed expressions for almost three decades to alert my fellow chatters of an error in my previous message.
The first time I did that in HipChat... It edited my previous message. I nearly fell off my chair. It was and is probably my favorite HipChat feature.
s/favorite/favourite/ for my English fellow humans. :)
:)
My team often uses gifs to document and demonstrate workflows in UIs. It's easier to consume than a series of screenshots, albeit harder to maintain.
In which way? I often see this touted as a benefit, and rarely see it work effectively, or productively.
Fewer Gif's, fewer emojis — they can be
funny and endearing in the right context,
but just feel forced and obtuse in a work
setting.
The emotional responses being grasped at by most workplace humor is contaminated by power differential, and practical need for a high signal-to-noise ratio so that shit actually gets done. Snappy banter is frequently an accumulation of unwanted cruft, depending on the performer and the audience.
When HR or an operations manager, or anyone else with serious authority in their hands, try their hand at anything other than Dad humor, unless they're extremely clever, and the joke is deftly crafted (usually not the case), the result is often inadvertently crass, and compounded by the Dunning-Kruger effect augmenting their awareness of how unfunny or otherwise tepid their material really is.
Microsoft's Guide to Humor https://www.microsoft.com/en-us/education/training-and-event...
https://www.nytimes.com/2016/04/02/technology/april-fools-un...
This is the sort of thing that scares most people into tepid, mediocre Dad humor at work. Sometimes, that's a healthy fear to have, even if finding yourself burdened by such constraints is unfortunate.
It'a native desktop client built for professionals with a focus on performance. It supports Slack, Skype, Gmail, and will soon support Stride as well.
No emojis, no gifs, etc. is awesome. It gets the job done, and gets out of your way. It's not trying to focus your attention on chatting instead of doing your job.
I still really don't like having chat go to an external party, but if I have to, it makes it easier to use.
I guess noone has built it because for techies, IRC is good enough, and there isn't a clear path to monetizing it?
ScoutLink uses it for kids with great success.
We’ve been floating the idea of developing a native client for slack (we have experience in this field, having developed a Windows client for iMessage) but haven’t decided if it would be worth our while.
[0] https://softwareengineeringdaily.com/2017/08/11/typescript-a...
--------
Hi Sean,
Thanks for getting in touch with your feedback. This is something which I actually raised with our engineering team the other day and it's something we have discussed in depth. For now, we don't actually have any way of knowing when the app is minimized from the webapp portion of your app. Because of this, the gifs do not stop running when the app is minimized. We are considering our options here though and looking into what we could do in the future to improve this behavior.
If there is anything else that I can help you with in the meantime, please do let me know.
Best regards,
https://electron.atom.io/docs/api/browser-window/#event-hide
The best part is I can use the back button to go to previously viewed rooms/messages.
It'a native desktop client for Skype, Slack, and many others. It's only 4 MB, it has minimal CPU usage, and can handle hundreds of thousands of messages without lag.
1. No linux client 2. UI/UX is not as polished as slack 3. Can't paste images from clipboard 4. Doesn't support webhooks which means that service integrations are almost nonexistent
But why? It seems that Stride is trying to be the more productive version of Slack, and I think action items and decision notes have potential, but if I keep getting :partyparrot: instead of information related to my job, I'm going to keep basically ignoring my communications app.
I don't mind planning poker cards having the coffee mug, or the occasional friday afternoon song playing out the speakers, etc, as long as there is a social contract where everyone respects moderation.
Tools can encourage good behaviour and discourage bad behavior though.
I've found that GIFs end up being a bit too far down the "pop culture" spectrum to be worth having in Slack, for example. Net negative for comfortable communication when not everyone is on the same meme spectrum
I will come down hard on anyone in a room that just starts hunting for a magically relevant giphy gif by spamming the room. Fuck Giphy and their irrelevant search results, but fuck even harder people who love to dilute the signal-to-noise ratio.
1) Grant your users access to the new tool
2) There is no 2.
Pain only comes when you're storing organizational knowledge in an instant message tool.
Feature-wise, the "Actions and Decisions" tools sound pretty interesting. Definitely a pain point with Slack. We've been using Slack for a lot of our planning for the Longhorn PHP conference (https://www.longhornphp.com), and it's honestly not been great. Conversations & decisions about particular topics get buried; if someone wasn't present for a conversation, it's likely they'll never see it. I know Slack isn't a project management tool - we've been using a mix of Google Docs and Trello for that. But even as a communications tool it feels fragile and incomplete.
Presumably, they'll add Stride to that form eventually.
I'll be interested to see how the Remote Desktop Control premium feature works too. That seems geared towards collaboration/pairing.
#1 question though...will they have a Linux client that they actually care about. The Hipchat linux client was largely an afterthought that hung regularly. It was better to just use Rambox and keep the web version open.
Would ppl be interested in beta-testing it? Would ppl here be interested in paying for something like that?
Here are some links to screenshots so you know its not just vaporware :)
https://twitter.com/harisamin/status/727634194814373889
Good luck with your project!
Why launch a new Slack clone when you already have something so closely matching the architecture of Slack? I assume "technical debt" but that's rarely a good reason to start from scratch.
A new possibility to build a brand and reputation? From what I can gather HipChat has a pretty "meh" reputation.
Am I the only one that can't keep track of what service (or app) I need to use to communicate with which person, team or organization?
I'll stick with e-mail until these services finally agree to federate.
Do you plan to sunset HipChat Cloud?
For now, HipChat Cloud will continue to be supported, but eventually we will encourage all HipChat Cloud customers to upgrade to Stride.
From memory, Slack started out as a HipChat competitor. Not to mention, what is the on-premises story going to be (which was a major selling point of HipChat).
[1] Linking the cached version since the hipchat blog now points to Stride: https://webcache.googleusercontent.com/search?q=cache:c6dtRh...
On the usage of chat Im lucky that 2500 of my colleagues are not in the same timezone, and the ones that are, are already too busy to spend time talking about it. So i dont have a constant torrent of activity to respond to. Internally we use Yammer, and like email, it allows me to attend to it and get involved at the time and duration of my choosing. Bottom line how such systems get used is a matter of your preferred work style, corporate culture, and market needs.
And you have commend Atlassian for coming up with a name that is indicative (to me anyway) of impact the product should have. "Stride" suggest big steps, not baby steps. Its walking with purpose, cadence, and at speed. Their other product "hipster" suggests completely the obvious i.e. react viscerally ('quantitative gut feel'), follow trends ('follow the crowd not your own intelligence'), bleeding edge, oh....and you may need to grow a beard and use a satchel and rider a fixie in order to use it properly.
One of the things I really liked about Hipchat was the information density vs Slack.
Stride seems to be very loose in how much information it shows.
See screenshots as a comparison.
[1] https://tctechcrunch2011.files.wordpress.com/2017/09/actions...
[2] https://ga0.imgix.net/screenshot/o/10167-1442255801-0858462?...
Disclaimer: I worked on secure.chat in the past.
I've restored to using slack on Safari now. This problem still occurs, but reloading the slack tab is easier then finding and killing the slack process.
For just keeping track of what's happening around, I would love a view showing all the messages across all (or selected) Slacks/channels.
https://cdn-images-1.medium.com/max/1600/1*I50CoGFK328HeWSvu...
:)
If two employees want to chat in secret, companies sure don't want that happening
Tech isn't always sexy. Sometimes tech is just good business sense.
In my mind, when someone says they are a "technology company", what that means is that they want to sell technology (new approaches to solving problems). Making the same thing over and over with minor variations and calling it "tech" just because it runs on computers (30 year old tech) is just excusing it.
The truth is, Atlassian saw the $$ that slack is making and wanted to get a piece of the pie, I highly doubt they thought: "Eureka! I've come up with a new technology to improve communication of a team. Its like email but in real time!"
>> Sometimes tech isn't about innovation, discovery and breakthrough. Sometimes it's about integrating existing technology into the workflow of your customer base.
Technology companies don't just create new things. Business is not 100% innovation. Not even the giants like MSFT, Google, FB, Amazon, and Apple spend all of their employee power on creating something new. Sometimes it's giving your customer base what they want.
I don't think anyone is billing Slide as the next frontier in chat software. Atlassian is porting over existing functionality to work natively with their other products. With the wide adoption of Slack, it's obvious that chat software is something Atlassian's customers are probably using, so why not make that hooks into the other products?
It doesn't matter if you're a tech company, a real estate company, a law firm, or a medical practice - if your customers want something that integrates well with what you're offering, it makes good business sense to see if it can work.
Getting zero results in their docs.
Guess we will have to wait for someone else to fill this niche.
Bubbalicious for Business is even a better name.
So is Wrigley's for Work.
Jira and Confluence get a lot of hate, but I feel like that's mostly because of how it's set up by organizations.
At my organization we've set up Jira (and later Confluence) in a very developer-centric way, by looking at the best way it could help the developer first, project manager second.
This has led to universal adoption and no complaints or ill attitudes toward Atlassian products.
Any tool can be made obnoxious if managed incorrectly.
I feel like Jira is trying to be too many things, instead of focusing on one goal, which leads to the bad setups that you mentioned. Though I agree that at the end of the day, it seems more like the org's fault, rather than Atlassian's.
Confluence feels amateurish: email notifications never work right, and the search is a joke. The buttons are unintuitive, and the overall organization of pages is a mess.
Debugging either of them when they crash all the time is a pain. Upgrades never go smoothly, and Atlassian can't even read their own core-dumps.
> Atlassian, the company behind popular tools like … Trello
It's somewhat of a misleading statement that. My take on the "behind" is in the sense that they designed and created the product from its conception. I really love the Trello UX and believe that Atlassian products are the exact polar opposite. The only way an Atlassian product seems to gain love from a community is if they emulate something already in existence.
I wasn't aware that Atlassian acquired it.
My mistake.
Even has a words filter so you can just filter out words you don't like from conversations, if you don't like vernacular.
So good Paltalk bought Camfrog just for the video tech, then resold it back to Camfrog.
The only real downside to Camfrog is a lack of chat history, excepting in your IMs. Rooms do not have a chat history (admins have log access, though.)
When these other apps provide a real chat function instead of it being a bolted-on afterthought, I might be convinced to switch. Until then, Camfrog's been the only social/chat/networking program/app that I've paid money for.