At my job we use Quip strictly for collaborative design docs (i.e. architectural design, project scope, tutorials etc). Personally I don't think it can be a true wiki platform since it lacks robust indexing -- this is without doubt its biggest shortcoming.
Correct. Quip is not a wiki. I would call it an “opinionated and stripped-down version of GSuite with excellent collaboration support”. Quip also has chat stapled to it.
Slack is missing doc management/creation. Quip is missing a good chat solution. It’s almost like PB&J.
I think it would be great for both products if they were integrated tightly. The chat features in quip are barely used because they’re so anemic, and Slack is missing a document catalog UI, and, in a way, has gone to war with document catalogs because it wants chat to be the “center” of work. But this is often a mismatch for customers who view both as equally important.
As a salesforce user, this disturbs me, since salesforce has been a terrible experience. That said, perhaps our organization just doesn't have it configured effectively. We use both Slack and Teams though, so if this somehow makes it easier to get the whole org on Slack then it would be worth it.
That seems apt. Slack comes in with a strong brand of its own, like Heroku but moreso. The integration will probably be more of a bridge model than a consumption one.
I actually don't think Heroku has changed much at all since they were bought by Salesforce. That's partially a good thing (Salesforce isn't making them worse) but also a bad thing because Salesforce doesn't seem to be making them any better either. Pricing is the biggest thing, despite running on AWS and AWS prices dropping pretty steadily but Heroku's pricing seems to have held firm. Their offerings don't seem to have changed much over the years either, you don't hear about them in the news much, you don't hear a lot of customer stories or companies talking about using Heroku... it just seems stagnant, which in the world of cloud computing is not great.
It's hard to tell if Salesforce has been a positive for Heroku for keeping it alive, or a negative for mismanaging the company, since we don't know what they would have done if they stayed independent and had to actually compete. But I'm pretty sure if they were still independent and had to compete in the market with only the features they have right now, they would likely be out of business. There's very little reason to choose Heroku these days, and I say that as someone who has code running in production on Heroku's platform.
Pipelines was introduced 5 years ago, which also seems to be the last time they changed their prices. Their current model is based around the classic three-tier app (basically Ruby on Rails) no matter how much web applications have changed since then.
Heroku still doesn't have any data hosting options. You have to go to a third party for this.
Heroku doesn't have any static site hosting options. You have to go to a third party.
But the biggest problem I have with Heroku's model is how much I need to pay. I've been a Heroku customer for years and I'm still not exactly sure what a dyno is. And if I get it wrong, I can have auto-scaling... but only if I'm paying a minimum of $250 per month. Now that's not a lot to big companies, but for bootstrappers that's insane. And I only get 2.5GB of RAM for that $250/mo? And if I'm using microservices, every service costs me a minimum of $25/mo, $250/mo if I want auto-scaling on those services.
Like I said, Heroku is great and I use it in production and pay them money every month, but man if it's not stuck in 2015. Luckily so is my application so I don't have too many issues except for the ridiculous cost even as EC2 is dramatically cheaper now than it used to be (does Heroku support Graviton? I don't think it does), but PaaS in general is "the old way of doing cloud" and Heroku is becoming less relevant every day.
I worked with SF extensively. I agree the APIs are complex. Mule though is the worst. Mule is like Talend. It compiles everything in to Java. Mule’s Anypont studio is an Eclipse shell. Mule fools decision-makers with their Informatica wizard GUI. But you are forced into using Anypoint Studio if you want to do anything beyond beside a copy.
Salesforce is one of those companies that I know does a bunch of stuff but I don't understand most of what it's for or how those niches combine into a gigantic company. I get the sales lead tool, but everything else goes over my head. Don't understand how a sales lead tool became a "platform" either. Reminds me of SAP in this way.
Salesforce is not a sales lead tool, it's a way to codify your sales and marketing processes into a SaaS product. To me, it becomes obvious that it's a platform then, because users need integrations to properly codify their business processes. SFDC probably has more integrations than any other piece of technology that I can think of.
When you codify your business processes, actual code is going to be needed as well. Enter Apex and heroku.
Slack is a way for SFDC to codify another part of your business processes—communication.
That said, SFDC does a lot of things that fairly give it a bad rap. Their developer experience is really bad, their apps are not that great, and lightning is still not adopted at many companies years after its release.
> it's a way to codify your sales and marketing processes
Are there no better ways to automate sales and marketing?
Once you start using Salesforce, do all of your leads get stuck in the platform, or can you export them and do your own analytics queries? How deep is their lock-in?
> Slack is a way for SFDC to codify another part of your business processes—communication.
It feels too freeform to be automated. It's just chat with a so-so search interface.
I don't equate codify and automate. That's sometimes a piece of it (automating state changes), but more specifically I'm thinking about all of the validations, human processes, etc that go into customer and sales management. I'd need to think about how slack can "codify communications", but I'm sure there's some people that already have answers for this.
SFDC has one of the most robust APIs I've seen...you can export pretty much everything. I actually really enjoy working with the soql rest API, because it's simple, effective, and discoverable.
The lock-in is instead in their integrations. It is almost guaranteed that there won't be another platform that has all of the integrations you need, so you stick with SFDC. You add more integrations over time and the lock-in deepens.
>> Once you start using Salesforce, do all of your leads get stuck in the platform, or can you export them and do your own analytics queries? How deep is their lock-in?
To some extent, as a business owner or CRO, you want the data to be stuck in Salesforce. The price of Salesforce is small compared to the cost of salespeople maintaining their own relationships directly with clients -- and then potentially walking away.
Your points about codifying business process and integrations are spot-on.
The developer experience is sadistic, but Lightning is the worst. It takes forever to load basic information because it all has to cycle through JS callbacks. Try opening a link (or a bunch!) in a background tab: it doesn't load anything until you're actually looking at the tab.
> codify your sales and marketing processes into a SaaS product
I don't understand what this means at all. Let's say I make pies. My sales process is I go to grocery stores and try to get them to carry my pies. My marketing is I buy commercial time on the local tv station. How do I codify this into a SaaS product?
You have a sales team out talking to those grocery stores. You need to keep track of the relationships they have with those stores, the conversations they have, where those stores are along the journey to becoming customers. You want to understand how your marketing expenses influence that process. Further downstream, you’ll probably want to connect sales data to those stores over time to understand patterns and manage your operations. These are all pretty common use cases for something like Salesforce and there is a pretty widely accepted data model that most companies adopt to do these sorts of things which Salesforce out of the box is built around.
This is what I thought Salesforce was, and what I meant by a sales lead tool. I still don't get how this makes my pie making company a SaaS product though.
I see what you mean. I understood the parent comment to mean that Salesforce can be used to basically build a bespoke saas app that you use at the heart of your operations, but I’d agree that doesn’t change the nature of your business as a commercial baker in this example.
It doesn't turn your pie making company into a SaaS product. All of the back-office, sales, marketing, relations can be kept in SFDC (cloud SaaS) though.
The reason I don't call it a sales lead tool is that is about 10% of their use case now. They've expanded significantly and companies use them for just about everything.
Every time someone at your company uses your phone system to call a customer, it is auto-logged in Salesforce. Every email is logged. Every sale, every transaction, every interaction.
Now when "Bob the amazing Sales Guy" leaves you have a central repository of every contact he's made in every company he's worked with on your behalf. This means you build institutional knowledge instead of tribal knowledge.
So now lets say a couple years have gone by, and you want to publish a white paper on pie consumption, so you hand the project off to your research and analytics team. Thanks to Salesforce they have knowledge of every person your company has ever contacted about pies, and therefore have a great jumping off point to start with interviews for the whitepaper.
...and testcase_delta's reply is a pretty accurate & common outcome. Snake-oil salesmen masquerading as a high quality software service. At best it's just lies and taped together functionality, which the buyer has to deal with post-sale. Name a high quality tech company using salesforce...
This is how it's supposed to work. That's the promise that sold me on using it for my business for a couple of years. It never delivered. Huge waste of time and money. Never again.
Sales app -> Customizable Sales Process -> Arbitrary Customizable Process -> Platform.
Along they way they've bought a ton of companies that do various enterprisey things. Now they're a one stop shop to run everything a business might need.
Whenever I read about what Salesforce and SAP are for it really triggers the "this is fake. you're just making up words" part of my brain. At this point I'd rather not know what they do.
> As a salesforce user, this disturbs me, since salesforce has been a terrible experience. That said, perhaps our organization just doesn't have it configured effectively.
Suppose that we said that Salesforce (or JIRA) itself is fine, except for those sites that have implemented it poorly. Would that be an example of the One True Scotsman fallacy?
(I mean the question honestly. I'm not 100% I properly understand that fallacy's definition.)
Since you mentioned JIRA, it is basically there to support bloated Scrum teams. And one often hears No True Scotsman fallacies regarding Scrum. Salesforce has always seemed to me like something that, indeed, falls into this category of things that are never "done right". And likewise, I am sure there are Salesforce coaches, and maybe even some books that people try to sell.
I've been building an alternative around asynchronous audio, called heysync[0].
I can't stand being in long video meetings where everyone waits around smiling and one person talks forever. I also deeply miss the easy chats we used to have in the office, when we didn't have to schedule meetings just to talk. But I don't want to dedicate my time to sitting in a discord-like audio channel while I'm doing work.
So, heysync is the answer to my own problems. It has a similar feature set to IRC or to Slack, because I love those products, but it's built with asynchronous audio communication in mind, in a way a Slack app just couldn't provide.
You just talk, and heysync transcribes the message and stores the audio for easy playback. Your colleagues can either read or listen to what you just said. They can listen live, or later, so you can seamlessly talk even if the person you're talking to isn't there, or is multitasking.
(edit: I was downvoted pretty hard for contributing this -- if anyone wants to share why, here or via email at carss.w@gmail.com, I would love to learn how to do so better.)
Not sure about the downvotes either. Your comment doesn't read as being any more "spammy" than similar comments hocking self-made projects on HN as alternatives to existing things. This fits my use case - having a team lead that can code and speak fine but has difficulty writing intelligible sentences in English. Sounds useful for e.g. slightly-less distracting pair programming too.
I love these types of posts when they're clearly on-topic. With all respect to the author, this didn't seem close enough to the conversation at hand. A platform for asynchronous audio communication is not going to replace Slack, which is made for text messages.
If the GGP had said "I hate Zoom meetings where everyone waits around smiling and one person talks forever", the post would have made more sense to me. Or, if the GP's product can also function as a more basic Slack replacement, their post should have led with that.
Ah, interesting! I'm intrigued that it didn't come across, so thank you for the feedback. My app is fundamentally a text chat client like slack -- with markdown support, reactions, channels, DMs, and at some point threads and bots.
It just also allows you to speak via audio, and captures that audio inline with the chat, in both audio and text form, which is the key selling point. It is visually and in terms of day to day use very similar to Slack, or IRC. My desire to build heysync is literally borne out of frustration that this featureset is not possible within Slack itself, which I use daily.
Zulip. It's Open Source, you can either pay to have it hosted or host it yourself, it has mobile apps and a web interface, it has a good API for integrations, and the conversation model feels great.
Zulip is an excellent user experience, and when deployed self-hosted is also quite secure. The only thing it doesn't have is federation, which would involve rethinking security.
I've found it very effective after deploying a local version for our team.
One issue: Some users get confused over streams and topics, often posting anything in whatever was the last topic they accessed rather than going to the correct topic or starting a new one. These same users also say they can't find anything via search.
> One issue: Some users get confused over streams and topics, often posting anything in whatever was the last topic they accessed rather than going to the correct topic or starting a new one
This has been a problem ever since email: many people reply to the last mail they have from a list, sometimes changing the subject, and then get surprised when the mail is threaded under the mail they replied to.
I've seen this occasionally on Zulip instances, but a reminder and a suggestion that the topics are like email thread subjects or forum thread subjects tends to help.
Indeed, it's very much the same thing.
I have brought up the similarity to email, but it's been of limited help. I'm hoping that moving posts between topics will become possible at some point, which will allow me to clean things up.
It's already possible to move posts between topics. In the menu for a post, choose to edit the topic, and once you start changing it there's an option to move just the post or move later posts in the same topic.
Zulip's UI is pretty laggy in my experience (only used it on a big public server), can't seem to remember what I have already read sometimes and seems to only support threaded conversations (called topics by Zulip).
I haven't hosted it, so I don't know how much work is self-hosting it. Still seems like a better idea than sending all of your company discussions to e.g. Microsoft, especially when you're not from the US and can be the target of industrial espionage by the US government.
Can you share what server this was (here or in chat.zulip.org)? Essentially every bit of feedback we get on performance is that Zulip is much snappier than Slack.
Given that you mention a big public server, it's likely caused by an issue specifically related to that server's scale/usage patterns, and I'd like to make sure we investigate it.
Even if every of the 163,000 Microsoft employee got a company sponsored phone, that's still pretty much 2 orders of magnitude below the Lumia 520 sales figure alone.
I moved the past 3 companies I work with from GitHub to self-hosted gitlab after the Microsoft purchase.
When Microsoft bought GitHub, all of the "Developer Evangelist" / "Open Source" evangelist crowd made all of those noise about how "Microsoft is great for our community! They ARE an open source company! Everything is wine and roses!"
Anecdotal of course, but my code is no longer there. My profile still exists because I want to open issues with the tools I'm using and what not. And every once in a while, I stumble upon a project with a big disclaimer that the main repo is now on GitLab.
IRC. I'm serious. It's free and you realize how much of the slack feature set is not productive. Yes, some different administrative challenges and not a direct substitute.
If Matrix is good enough for the German Armed Forces [1], the French government [2], and the German education system [3], I can't think of any reason not to use it :)
Be honest now, there's no way you can honestly claim that Element is a good UI/UX. I'd love it to be the other way around but it's just plain and simply bad. At least on all MacOS combos I've tried - native client as well as web app (Chrome/FF/Safari). And Android. Oh and fuck not being to have different notification schemes for desktop/mobile. I end up having mobile notifications turned off altogether.
So many inconsistencies in the UI. Almost non-existent keyboard navigation. Typing notifications and read receipts on by default (supposed to be a privacy focused chat). Handling unread messages. Lack of threads. I could go on...
I don’t know about Mozilla or Fedora, but have you ever interviewed with Wikimedia? It’s a circus of insanity. The most bizarre corporate culture ever; and the most psychotic receuiter i’ve ever come across. Whatever they choose, I choose the opposite.
We use Zulip and I think it's amazing. I'm probably biased since I've been using zulip for 3 years and have always hated slack, but yes, it's a good tool.
As an aside just talking bout WORK performance during this huge shift to WFH, it's been wild to seem ZOOM go wild this pandemic, while WORK stagnated. I wouldn't have expected that.
>They're alternatives, but they are far from being usable alternatives.
It has to be comments like this that drove someone to create n-gate.
WebEx had 324,000,000 users running 73,000,000 meetings in March of this year [0]. As of April, Meet was adding 3,000,000 users per day with 100,000,000 users attending meets per day. [1]
You're obviously right though, they're clearly utterly unusable.
Those are pretty old dates considering how much has changed with the pandemic.
It’s also possible for something to have many users and have them casually brought up as unusable. The OP doesn’t literally mean unusable. They are exaggerating for effect.
To be fair, they said far from being usable. I would support a more tame comparison for dramatic effect, but this is verging on a literal claim which isn't supported by virtually anything.
Somehow Zoom made the jump to being a consumer brand because of the pandemic. I never expected it either, since I had only seen it used in the corporate world up to that point.
> Somehow Zoom made the jump to being a consumer brand because of the pandemic
Because of the same qualities that made it successful in the corporate world!
• Zoom is for one thing—it doesn't try to also sell you on a new service for managing documents, calendars, or VR bitcoins.
• Zoom is extremely easy for new users to set up and quickly enter a video call. It works even on very old hardware and operating systems.
• Zoom's audio quality is unmatched in calls with lots of participants. It's relatively adept at dealing with poor network quality and audio equipment.
I really think there's a lot of lessons here for other companies.
> Zoom is for one thing—it doesn't try to also sell you on a new service for managing documents, calendars, or VR bitcoins.
Ah, I see you haven't been following the recent updates (in which Zoom wants to gradually try to replace Slack and become your default client for your calendar and third-party integrations)
Zoom is general purpose software. My grandma was using it every day during lockdown. Their valuation is based on a lot more than the corporate use case, which Slack doesn't have.
Yeah that's what I figure too. Very quick to dash into a zoom chat with friends or random business connections.
I mean I think Slack uptake would benefit companies that have been forced into WFH, but shrug maybe that's not happening or doesn't seem like that's moved the needle on the stock price.
I think it is happening to some extent, but (1) they have a lot of competition from Microsoft Teams and (2) the total size of the workplace text-based group chat market is a lot smaller than...basically all human communication.
Salesforce and Atlassian are the two big cloud things I have experince with. Both feel like they just swallow up products and duct tape them to their behemoth in what results in a complete mess.
JIRA is a 22MB download any time I go to look at my tickets and the whole experience is grindy slow.
I'm still amazed that JIRA redesigned the UI and chose to relegate the date the ticket was created to a "secondary piece of information".
Every time I look at a ticket its like the 4th or 5th thing I check, its such useful information and they've allowed themselves to be so far removed from their principal use-cases its extraordinary.
Unless maybe it was my org that foolishly decided to configure it away?
Man, what happened to Atlassian? At some point in the not-so-distant past they were the gold standard, or at least I thought they were. Now they seem to be a cautionary tale.
My observation as a user is that it's still good if you are starting a new account from scratch. But if you have been using it for a decade and made lots of customizations and added plugins over the years, they get more clunky as they continue to update their product.
I don't even think Jira is specifically bad. If someone was only using it for basic project managment and ticketing, it'd be acceptable.
However, occupies the same niche as SAP or Oracle businessware.
First, Take a service that must be ergonomic because people rely on it all day to do their job. Next, make the primary requirement the ability for managment and finance to run reports. Then, outsource it to a company that wants to add custom web frameworks on top of a decades old project. Finally, graft on decades of customizations done by different generations of contractors.
If you can admin your own Jira instance and keep the fields and plugins to exactly what you need, it's pretty nice. I keep going back to it for the customizable workflows and fine-grained access control.
Unfortunately, every corporate Jira instance I've ever worked with has been overrun with every possible field possible, an unnecessary and constantly shifting mishmash of plugins and horribly slow access. You're paying the price for all of that cruft that you don't need and which can't be removed because "maybe someone wants it."
> every corporate Jira instance I've ever worked with has been overrun with every possible field possible
I've seen multiple different fields for the same value, each of them created for their specific team. The instance is slow AF most of the time due to the bloat and often I can't even assign a sprint to a JIRA because the field doesn't load anymore.
Agreed. Jira makes it easy to add a new field, plugin, or workflow step for a particular use case, but it is much more difficult to determine if an existing field/plugin/workflow step can be safely removed. As a result, everyone is afraid to touch it, projects accumulate cruft over the years, and it degrades the entire workflow. The problem is especially bad if there is shared ownership of JIRA, and therefore everyone feels empowered to add, but nobody feels responsible for the dirty work to clean up the mess from time to time.
My company had resisted the urge to bolt on additions more than most. We recently migrated from Cloud to on-prem Server as a result of being acquired, and it is amazing how much zippier our project is compared to some of the peer projects that have accumulated cruft.
Revenue was $1.6 billion in 2020, up 33% from $1.2 billion for 2019.
Growing at that rate at this point in your company's lifecycle is pretty extraordinary. So not sure why you would consider them to be a cautionary tale.
As for what has happened to them. They have been on an acquisition binge the last few years e.g. Trello, StatusPage, OpsGenie, Mindville etc. And as mentioned above they have been rewriting their UI in a new React framework called Atlaskit.
I also used to think Atlassian was a pretty poorly run company but then you look into it and actually the opposite is true. Although they did let Github, Gitlab, Slack dominate them.
Next few years will be interesting as Gitlab is moving very fast into their space.
Sales and Revenue do not always equate to quality and user experience. All these companies when they get to this size start to lean on M&A vs build it yourself. Look at the history of Oracle, Microsoft, IBM and you'll see the same pattern.
Slack is the new Sharepoint, everyone uses it but no one really wants to and it doesn't really fit the bill but everyone else is doing it so companies adopt it.
Slack's value is in selling the idea of async chat to managers and making it mainstream. I don't feel as nauseous using it as Sharepoint, but it does seem to be buggy and crashy in places.
Microsoft Teams Chat UI is garbage. It uses a lot of space, i can't just have a list of channels, no i need groups etc.
It even doesn't matter to me if its slack or hipchat or matrix or whatever. I don't know why we migrated to slack.
I don't get why Teams doesn't provide a lightweight chat typical UI. I would just switch to Teams. After all video calls are much better on Teams and more stable.
But then Slack integrated Teams and Zoom. They clearly don't want to compete in this area and i also don't get why.
I'm not sure that's actually the case at this point. Given it is not 10 years into the acquisition that is a pretty long time for it to still not have been engulfed in the mothership, but that time seems to mostly be up now.
Good thing we have competitive (and cheaper) options now including Digitalocean app platform and Render.com. I'm actually surprised it took this long to match Heroku (and beat them on costs).
True, but neither are really optimal for serious production use. I've looked at them both extensively as I would love to move off Heroku due to pricing. DO App Platform is still really immature and lacking in a ton of areas. Render is much more polished from a usability standpoint, but AFAIK they don't have any sort of High Availability offerings and have had significant downtime recently.
Heroku, on the other hand has been a hassle-free solution for my company over the past 7 years, and short of a few outages (which were actually the fault of AWS from what I remember), it has been absolutely reliable.
Just came across this comment (I work at Render). We did have 2 hours of downtime on 9/11 but it was the only big uptime incident in 2020, and we haven't had any major incidents since (even when AWS was down for 5+ hours).
We've worked hard to incorporate reliability lessons learned from building the platform at scale especially as we've grown [1], and I hope you'll give us another chance. If I can do anything else to help, my email is my HN handle at render.com.
I worked on that new Jira UI (codename Bento) and it was a constant source of embarrassment for me. I pushed hard to get the powers that be to focus more on performance and payload, but it was a Sisyphean task. It was perhaps the most demotivating job of my career because I disagreed with virtually every decision that was ever made with regards to that UI, from technology choices (the inane choice to use RxJS despite literally no valid use cases, the 5+ Redux stores in the same page, etc) to UI layout decisions (insane whitespace, the baffling choices about which things go in the right hand gutter...).
The components were mostly handed down to us from a company-wide UI team whose main design goals were to bring commonality across all Atlassian products. This is a worthwhile goal, no one thinks that it makes sense that Atlassian has different editors and even markup languages between (and even within) products. But the result was dog-slow overweight components like the Atlassian editor which tried to be everything to everyone. So when you need to bring in a monolithic highly-customisable 12mb+ component for every text edit field then things spiral out of control quickly. One cool thing, though, is that these components are open source[0]. And it looks like some performance/payload work has been done since I left, thank god.
In my new job I use Jira Server which hasn't been infected with the updated UI, and it's a shame because other than that terrible UI there have been big meaningful updates in Jira. But I'm dreading our inevitable migration to Cloud.
Sometimes with Jira updates, I have to ask myself “What WERE they thinking?” It’s good to hear that actually some people (well, at least one!) inside the org ask this too.
> I pushed hard to get the powers that be to focus more on performance and payload
If I was in Atlassian's situation this would be the last thing to focus on.
a) This is the biggest ever rewrite of their most important products. In this situation maintaining feature set compatibility is always going to be priority A, B to Z.
b) Their paying customers are mostly in the enterprise space who have very fast internet and stable environments i.e. payloads are quickly cached.
The key is jira and most atlassian products are feature mountains to be sold to upper management, but I can think of no end-user person that likes to deal with it on a daily basis. Then someone in the vein of slack or Asana comes around and eats atlassians lunch because they’ve neglected making the product good for anyone other than executives.
1) End users are not the buyer. It's the Head of Delivery, Iteration Managers, Agile Consultants etc that are. For them JIRA is great because it's heavily customisable and scales across the enterprise. It's actually quite hard to balance this with a great end user experience.
2) They are in the middle of a complete UI rewrite and I've only briefly used it but it's definitely much better than the previous versions. I imagine the Trello acquisition is also going to help them here.
I actually use Jira, Bitbucket and Confluence (all Server versiob) in a small team (maybe 5 people) and I really enjoy it. It‘s good in what it does, it does the things you want it to do and the 3 tools are good integrated.
For my other team members, they enjoy Confluence more than Jira, because Jira feels a bit difficult.
Well, they have succeeded in turning my entire team off JIRA. We basically don't use it anymore, mostly because their A B Z priorities didn't include making it not feel painful to use.
It's crazy to me when I can't type in JIRA... or when I drag a ticket to a new column, and it just doesn't go, and I reload and it's still in the old column. Or when I try to click a ticket and it just doesn't open.
The not being able to type fluidly has to be the worst though.
Our team has as well at least brought up the idea of potentially trying other products.
Some of it's probably me not really wanting to get involved with JIRA in the first place (who wants to manage tickets), but in the interest of being a better employee I've been trying to make sure I'm squaring out my work properly for tracking, etc.
And there's certain things, that I'm sure are there, but I just can't find sometimes. Like... how to add an epic easily. There's at least three different views for each ticket (when you create it, when you click it open into the modal, and the full screen view), and things are apparently in different places on those different views?
About that b). It‘s less about internet speed and more about your CPU not being fast enough to render everyhting in a useful time. With all that lazy loading, the browser is stuck with rendering for a couple of seconds - for each page...
This is why the browser isn't the best place for things like this. A Fat client is better. I still don't understand the push for webapps, when we have all this hp, storage is cheap, and we have modern installers that don't splat everywhere.
The browser is perfectly capable of stuff like project management workflow apps when you’re not shipping 22MB of useless abstraction layers in a runtime language.
c) Pushing folks to their cloud offering, partly by
d) doubling the cost of on-prem.
The surprise price bump really pissed off people here; that, combined with doubts about their long-term commitment to on-prem put evaluating alternatives on the list for next year.
Being a tool no one loves is a bad place to start changing a bunch of stuff at once.
We have a gigabit connection but that doesnt make the site any faster. Not sure how much is being cached or what the bottleneck is...but there is something seriously wrong with the site's performance. It has become so slow I honestly think performance is the cause of fewer and fewer Jira tickets at work (people used to make tickets for tiny isolated updates to track them finely, but now it all gets shoved into the commit-of-the-day) and fewer updates/comments. People seem to interact with it only on sprint ends when they must do.
I do enjoy the new Jira UI a lot more than the old one, but yes it is definitely slower and is missing some key features (hotkeys for editing specific ticket fields please!).
Things have been improved with the recent addition of pinned ticket fields, but they still have a long way to go.
>whose main design goals were to bring commonality across all Atlassian products. This is a worthwhile goal
the issue here isn't the goal itself, it is that such highly visible efforts - "common platform", "common UI", etc. which are very complex technically to do right - invariably bring up to the top and into the deciding positions those "drivers of cross-organizational/functional/etc. change" style people whom you'd really want to be staying far from such important and complex technical issues...
I worked with Jira in 2012-13, it was appallingly slow. Making it even slower is an achievement.
Good to hear that there’s at least one person involved with it that sees the problem with this. I imagine how the use of whitespace to organize the layout probably looked very simple and attractive in Sketch or Figma at some point. Then reality crept in, and that whitespace was gradually carved up into more and more incoherent pieces. And as that was the only indicator of hierarchy and relationships there was to start with, there’s now no organization left at all. Many screens are just a bunch of words, all imperceptibly different shades of dark gray, strewn out randomly over a solid white background.
To make things worse, they all seem to be implemented in slightly inconsistent ways (you can tell when an h1 is wrapped in ten (10) layers of nested divs, each just containing the next div) so things that should align are all off by a pixel and have slightly different behaviors.
Whitespace is good and functional in some contexts but it's detrimental in others. Imagine an Excel sheet with only 10 rows per screen, light gray text and no borders around cells. And yet this is the reality of many lists on many modern web sites. Less than 10 items per page when I could easily read 30 or 40 of them at once instead of scrolling, scrolling, scrolling.
Vanguard's new website is like this :-( used to be a medium dense table easy to compare records now on my 27" 4k monitor i can see only a handfull and its scroll city :-( https://www.vanguard.com.au/personal/products/en/overview
Can't help but think of Dieter Rams design principles. Do those principles apply for websites? I mean they are products in a way.
For this particular website I think the design is obstructing the functionality.
"Good design is unobtrusive - Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression."
That's absolutely spot on! Thanks for bringing that argument up. There's a fine line between aesthetically pleasing but functional and artistically inclined and obscure when it comes to this, and it should really be up to the users' preferences. E.g. GMail got it right from the start: let the user choose their way of doing things. If the user wants 100 rows per screen or 10 rows per screen, who are you to deny the user? :)
If someone could mockup a modern card-style design for excel incorporating the above, I think people will really get the inefficency of web sites today.
AWS did something similar in the new EC2 console. Too much whitespace, too little information. I'm glad they iterated and improved information density.
The whitespace craze is directly at odds with Tufte-ite principles on good information design - for knowledge workers there is a delicate balance between establishing hierarchy via whitespace and producing visualizations which are appropriately dense with information. My guess is that the root cause as usual comes from designers not being consumers of the product - if they were, this trade off would be obvious.
I think plenty of whitespace in general (I don't know the mentioned tools that much), when done well, is a good default, because I reckon the majority of users only handle a small number of things in such tools and whitespace can help readability and look better. But the more information you have to manage, the more it gets in the way up to uselessness. I just wish any tool would have some toggle or slider where one could adjust spacing on the fly
I'm normally not on the hate bandwagon for this sort of thing but the Jira UI has deteriorated to the point where it's an actual impediment to getting work done.
In the future, when cursing the developers who are responsible for this, I'll bear in mind that sometimes no matter how good the individuals in the team… it's sometimes impossible to salvage a good product.
API for Jira Server is not going anywhere. Of course the product itself will cease to exist in a little while, but most places where Jira is terrible are on datacenter anyway.
For one large web app I worked on, we had a setup where browser loading time would always print out in the dev tools console. We had no hard requirement for UI changes to stay under a certain threshold, but seeing that loading time with every refresh during development was enough to keep us mindful of payload.
I actually created a support ticket and also talked to someone in Atlassian through some user experience lab thing.
I didn't comprehend how someone thought it would be a good idea to move the button for a new ticket away from the main screen to that sidebar thing where it took an additional click to do so.
Yes lets add another click to the most used function in my workflow...
For what it's worth, I think a lot of people put misplaced blame on Jira for their own broken process.
Jira is a tractor trailer. It's big, it's powerful, it's a bit slow to get moving, but (1) it can carry just about anything (2) once it gets moving, it tends to stay moving. There's a lot of value in having a "do it all" project management system.
That being said, there's also value in alternatives that are more tailored towards specific needs.
We were avoiding creating issues because of how long it would take to do with JIRA. I had to stop and wait between sentences because the JIRA edit box couldn't keep up with my typing.
> the inane choice to use RxJS despite literally no valid use cases
We did the same at one company I worked for. It was a terrible decision.
RxJS is one of those things that is fun to play with until you look down and it's cutting off your legs before you even felt it. Instead of simple AJAX calls when needed in places that are logical, your app turns into this hydra of events flowing everywhere and never knowing why anything is happening or where it's happening. RxJS is what happens when a Jenga tower makes love with a Rube Goldberg machine.
And don't get me started on those damn marbles. We're writing goddamn CRUD webapps!!! We don't need marble diagrams for this. It's like that Mitch Hedberg joke about donut receipts. We don't need to introduce complexity into our simple life.
Isn't the idea that if you edit something I'm looking at it would be nice if my view could automatically update? (FWIW, I would totally accept that I don't need that on a bug tracker and I probably am actually happier without it, but I can at least see the premise being interesting... being able to see point changes or user votes or comments as they happen; I do appreciate the extent to which GitHub's issue tracker automatically updates).
Might be missing something, but how is this related? Is the assumption that this is what RxJS gives you? Because I mean...that's a websocket. And how you model the event, and handle it...is up to you. Don't need any library to help you unless you want one.
First of all, who does center alignment?? Looks tacky and amateurish. This isn't a flyer for your yard sale, it's a professional company's website.
Secondly, it's great that they're involved and passionate on social justice issues, however I wouldn't lead with that as the landing page gives no idea what the company actually does, offers, or makes.
Thirdly, when you click over to their team, it should identify their role instead of just letting you click to their socials.
You are describing a typical atmosphere in the frontend and node community in general. You might find this account from several conferences in 2018-2019 amusing [0]. RxJS is in no way an outlier in this regard.
Developers first introduced to RxJS hate the fact they have to think about the plumbing rather than the water... that is until they have to inner join 3 asynchronous sources of data and broadcast it out to their entire application.
Nothing wrong with Async/Await and zustand, the thing is that it doesn't maintain complexity as more sources are added, let me try to give you an example of the problem that Async/await solves versus what RxJS solves.
Say I'm installing a toilet, I need to go out and buy one from the hardware store, remove the old toilet, install the new one, and finally test that it works. It's a linear process that could easily be constructed via a series of async/awaits, and I wouldn't use RxJS to model the behavior.
Now, say I'm building a bathroom. You have a shower head, a sink, a toilet, light fixtures, power outlets, tiling, a door, and a window. You have a bunch of contractors. Now you're dealing with N number of sources, N number of tasks that can possibly done in parallel, and N number of possible things you could do in that bathroom depending on how much the bathroom is finished (for instance, if just the plumbing, floor and sink are complete, I can wash my hands)
This was always a hard problem, and not one that is especially appreciated, but I can tell you from experience that attempting to just use promises or async/await is not a scalable pattern.
Oh crude. Had one jQuery Developer be replaced with two 5 man teams so we could Use RXJS. Took a year for the first feature to be released. Not product, just a new page on the app.
Having used clubhouse extensively, I'd say the absolute opposite. It's missing basic features, reporting is a joke and while the trelloesque usability is nice that's the only thing really going for it. It's also more expensive than Jira, which is completely bananas.
I hate to be the "but it looks so easy" guy, but why are all these "behemoths" such a huge mass of things for essentially CRUD-y stuff with e-mailing bolted on?
(and yes, you could water, i dunno, facebook down to that, but still, these are... trouble ticket systems..? what am I missing? Scaling?)
JIRA offers an almost limitless amount of customization to fit any workflow. I think the custom attributes/fields/reporting part of it adds a lot of complexity.
Yeah... and once it comes down to a company's pm level, they all lock it down to what they think is the best, leaving teams using something that is guided towards PM and reporting, instead of getting job done.
Scaling is only half of it. There is a lot more to Jira than just CRUD over a few entities. It's trying to be issue tracking and project management rolled into one. For example:
- Workflows
- Access control over fields
- Custom fields
- Release management
- 3P plugins and integrations
- API access
I am far from being a fan of Jira but they do have a rather large set of features. Every time I evaluate the hottest new issue tracking and/or project management solution, there is something lacking as compared to Jira.
I've often half-joked that the road to JIRA is paved with other project management tools and ticketing systems.
I don't think anybody really sets out with the intent of using the one reputedly cumbersome tool that can do anything - but after growth and pivots and new requirements and new teams and special workflows... you end up needing a combination of features that is literally impossible to get with any other tool, and who wants to fracture into multiple tools?
So you get JIRA. And it just does it all, and even if nobody is overjoyed, nobody feels like they lost, either. There's value in that.
This is a fair question, you shouldn't be downvoted. Lean ticket trackers and productivity tools are perennially launched and invariably become as bloated as the incumbents.
This is because the information in these tools is business critical and needs to be consumed by almost everyone in the company. Moreover, different people need access to the same information in different forms of presentation, with aggregation and emphasis of different data. In contrast it's easy to make a work tracker just for developers - GitHub and GitLab have pretty much solved that problem. Making a ticket tracker which works as a single source of truth for all members of an organization who need access to the tickets is much more difficult.
Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate. You can't just target a single group here, because then you're trying to get the company to adopt separate repositories of work (it's already an additional complexity that work is split between e.g. GitHub and Jira, for example).
So to obtain the critical mass of adoption they need for product market fit and growth, these tools organically evolve to become everything to everyone in an organization. And suddenly your tracking tool is stuffed with metrics, integrations, feeds, dashboards, reports, etc.
The other thing is that these tools become especially bloated by integrations and plugins. A brand new instance of any tracker or project manager feels clean and fast. A few years in, it feels slower and more crowded by all the custom/third party additions rolled into it.
> Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate.
I realize this would be a lot of work, but I would be really interested to see some examples of "the ticket the developers want", "the ticket the VPs want", "the ticket the designers want", etc.
Yeah, that would be the modern solution. As far as I can tell even Salesforce has tried that with role-specific views that are customizable. But somehow it just converges back to everyone having everything all over again, but this time with 8 different frontend views to be maintained.
I've worked on these sort of problems, and I can guess why.
What happens is that a new field gets added, and whoever's adding it claims it's really "important" and needs to be seen by everyone. It'll invariably set as mandatory to be filled in too.
2 years later and some integration breaks because the integration doesn't set that field and you end up looking at that really important field and every single project has it set to exactly the same value.
Repeat ad nauseum.
The other thing I've seen a few times is when assessments or a bonus depends on some field so they make it visible to everyone. Then the bonus scheme changes, but they never hide the fields that no-one cares about any more.
> when assessments or a bonus depends on some field
Ugh, this reminds me of a mess I inadvertently participated in..
A certain employee, on an unrelated team to mine, decided to to go down the route of becoming an agile/scrum master/evangical and somehow got "reduce instances of X" as their personal KPI/development goal one year. Soon after this, they're pinging myself and other team leads on slack whenever X field is filled out on JIRA and demanding justification. Eventually because of this harassment I just stop filling out the field, leaving it as the default value and just verbally communicating the fact to whomever needed to know. Later on I find out that I wasn't the only one that took this route,And guess what happened next! The scrum master is promoted to a management position, in part due to their stellar KPIs! Excellent work all around!
Spot on. This also feels like a strategy that won’t age well. It’s tough if not impossible to deliver great UX from a bunch of acquired pieces. Slack’s relatively short path to wide adoption is evidence that the world is less and less tolerant of poor UX, even in the context of business software.
They need to absorb things so their sales team can say "oh we have X feature" regardless of its actual implementability and just leave it to the consultants to struggle and somehow implement a half baked solution that doesn't work in the end.
Oh but that's how they make money also. More products, more features, more crappy integrations = more service contracts, more consulting work, etc.
All a huge scam that enterprises are forced into because they don't want to be "left behind in the digital economy."
Also, these companies have MASSIVE sales forces (no pun intended). By acquiring a decent enterprise product and throwing teams of sales guys on it they can make a lot of money.
Returns aren’t as good if acquisition is high, like slack will be.
Note that Atlassian doesn't have an enterprise sales team.
They are a pretty notable company in startup history since they were the first to be hugely successful at using the self-service model for enterprise sales.
They do have a partner system however which is widely used, you need a number of staff who are atlassian certified on your staff then you become a <some level> partner, and get a cut of the sales you make.
A lot of small(ish) firms are making reasonable money doing this sort of thing; I'd count them as enterprise sales ;)
One central high quality HR Team can scale easily in a big org while the same amount in small companies need spend more on HR.
And its not just HR of course.
I wouldn't even trust small companies to build a modern and secure cloud product. While big companies have their own Security Teams and are able to afford a normal security audit, for a small company that means 1. much higher cost in relation and also binding of personal they might not have.
I have worked in a very small company which basically couldn't spell security. And i'm now working in a very big company. There are plenty of people who also can't do that but there are teams only for security.
I don't have to justify now that i'm doing things securely. Thats how it is. My manager will not sign the risk away; He actually can't and people are not keen of asking upper upper management for that.
Size scales in reverse order with security. The larger you are, the more difficult it is to make sure all the gaps are sealed - that's why the greatest of empires fall eventually - they get spread across so large a portfolio there are bound to be gaps, which are endlessly exploited, even on users of the large ERP companies.
If products were actually integrated well and deployed well all of what you say would be true. But that's just not the reality - trust me, I've been there. It's bad.
And that's a site without any etxernal tracking or ads. No images either.
But their horribly inconsistent UI and UX a big tell why it is this way. They simply serve you multiple versions of their website, each for different component. And together it's a giant mess.
Yeah, just checked a random ticket and got 223 requests and 37.6 MB of resources, DOM loaded in 19.48 seconds (granted I'm on a slow connection)...
> But their horribly inconsistent UI and UX a big tell why it is this way.
It's insane how the editor changes between creating a task description, to editing a task description, to writing a comment. Like three separate teams with loose guidelines created them. In reality it's probably more like 7 teams.
I hate Atlassian with a passion and the only reason I touch it is because I'm a corporate slave.
JIRA is the slowest website I use in current year. If it was a consumer site like Youtube or Twitter, I'd long stop visiting. You can feel the gears slowly turning whenever you click something. When I click the wrong button I get that pang of anxiety like you used to get when you accidentally opened Photoshop back in the day and had to wait the 20 seconds for it to load.
Creating a ticket in Jira is a pain I try to avoid. I've never seen a worse UX for something that simple. I hate it with passion, and my computer does too, always spinning up cooling fan. Then I create it, and of course the formatting us fucked up. Every single form has a different flavor. Preview shows something else to what will show after submit. You press edit and you see a completely different syntax. One couldn't make the experience so bad even if they tried.
I'm leading implementation of a software up at a remote arctic mine site (geostationary satellite internet) and have to manage our issues on the vendors Jira implementation. It takes about 5 minutes to load the site the first visit. It's dreadful.
What they have in common is that the people ordering it are not the people using it. These companies focus on the former, who want different things to the latter. Which sucks for the users but it makes sense for the vendors.
And yet at my last two startups, when we could literally pick any product on the market - there was tremendous pressure from product, project management, devs, and the business to use JIRA "because it worked just fine at the last place I worked and even if it didn't, at least I'm familiar with it". I'd love to see a killer Jira replacement that people don't say "in spite of how ugly and slow and barely useable it was, I still love Jira".
Work anecdote: Before I discovered “openssl speed”, I used JIRA to find race bugs in JS tests - loading up a JIRA ticket while running the test in a loop would spike the CPU for long enough to trigger the race. :)
Man, that UI is such a slow resource-hog of a bloat-ball.
Jira has some of the most staggeringly stupid design decisions I have ever seen.
I get so frustrated trying to do anything in their interface and it lags so badly on my outdated office hardware.
We got fed up with Salesforce's absusive behavior to smaller companies, or at least the behavior of the finance team we were assigned to, and left. We did an emergency Salesforcectomy in 30 days, switched to a new product, and honestly everyone who uses it is a lot happier. SF buying Slack worries me for the future of Slack.
Here's a fun exercise in technical debt. Navigate to the Salesforce Idea Exchange and upvote any idea. You will be redirected no less than 13 times and after which you will no longer be on the page you started on.
slack market cap 20b and at the time of their IPO only half the stock was listed
salesforce revenue 20b
are they really going to pay 40b for something that makes 400m a year? I get they're paying in stock but forgive me for not understanding the synergies here
Some possibilities: Slack revenue will increase on its own. Salesforce integrations and cross-sell will improve. An app discovery service that offers competitors can be brought in-house and managed.
slack projects 4b revenue w/in a few years so yeah, maybe SF is drinking the same kool aid?
even in the cross-sell case, 'slack doubles the value of salesforce' is a stretch
I suppose slack has way more customers so if even a few of them convert, salesforce grows tremendously? but the downside is this pushes SF into the freemium market.
'we're buying slack to help us grow our free tier' isn't ultra compelling.
if the future of salesforce is workflows, slack provides a lot of data for workflows (assuming they're allowed to use it).
if salesforce has a substantially more developed marketplace for plugins, SF can help slack get there too; not sure how rev-share works for slack plugins today.
Slack’s market cap is above $20B because of the news. It went up 35%. A majority of the premium to buy it is priced in now. Likely the acquisition will be around $25B.
Working with Salesforce for the one project that required it, was an absolute nightmare. Opaque APIs, needlessly complex implementation requirements, useless documentation.
It reeks of different services consolidated via acquisition (or one-off services kitbashed together), and adding slack to the mix will just add yet another variation to the existing APIs.
I commend those devs that work with Salesforce on a daily basis!
As a person that works a lot with Salesforce and not much with AWS, I have the same opinion but about AWS. Salesforce is not known for wonderful documentation, but experience and familiarity changes the perspective quite a bit.
API quality varies from product to product. Base APIs object retrieval are excellent because tons of people use them so they received incremental improvements even after launch. More niche APIs like Communities or Chatter unfortunately don’t get as much love or attention.
Documentation, on average, is great. Light on practical examples, perhaps, but Salesforce has made huge investments into education materials for the tech side of their products. If you think THEIR docs are bad, I urge you to share what big company (Netflix? FB?) with regular users as the dominant customer has docs that do are think are better.
Salesforce APIs are unintuitive and terribly documented by design, so that their ISV ecosystem (basically people who have spent years working and getting certified for it) becomes more valuable. If they made it easy a $250/hr "Salesforce consultant" role wouldn't exist.
I don’t believe this to be the case. The root cause is that company exposed the product’s internal workings to developers via APIs 20 years ago. Tons of companies built their whole business on it, and those APIs will never be deprecated. Most of those companies don’t employ any software engineers, so migrating isn’t viable. I’ve been in the room when complicated new APIs are developed, and we definitely weren’t making things hard on purpose. Every new feature needs to work with whatever our customers built out of what came before. We did our best given the constraints.
Of course these opinions are my own, I don’t currently work at Salesforce, and I can only tell a tiny part of the story from my own perspective, and it’s probably unfair to people who did a lot of good work.
I just read
https://news.ycombinator.com/item?id=20277115 "what is salesforce" (linked from elsewhere here) -- quite an impressive story, lots of talented people involved it seems to me
(Incl Steve Jobs just a little bit others might find it interesting to know)
I don't know a single enterprise application that isn't a "nightmare to work with". This is not an issue with the code/architecture but the level of complexity to operate at the scale that SFDC does.
> It reeks of different services consolidated via acquisition (or one-off services kitbashed together), and adding slack to the mix will just add yet another variation to the existing APIs.
That's not how this usually works. Heroku is still running just fine and isn't a messy bunch of APIs since they were acquired. SFDC will likely just sell Slack into their enterprise clients and let it be.
I don’t think it’s design by committee so much as it is sales needing more ammunition to close deals. That has for my whole career been the primary motivation of almost all features outside of the “base product.”
“Hey we got $so_many million dollar client who wants to use our product but they want to
auth with their AD and can’t use our three other SSO options.”
And thus was born the company’s pluggable directory over VPN connector and auth strategy.
> Compare any other CRM with salesforce and 80% of the time you'll find better API / UX.
You're right, if I'm using something as simple as Zoho, Streak, Insightly, Close, Pipedrive, etc.
But thats precisely my point - the greater the complexity of the application the more of the "nightmare of an API/UX". Have you ever worked with DynamnicsCRM? NetSuite CRM?
Looking forward to when salesforce gets acquired by an even bigger company.
It'll be so cool when literally everything I do in life is basically owned by one company. Get paid in company scrip, buy food at the company store, live in company housing, talk to my family and coworkers over the company intercom, genuflect to the picture of the CEO in the mornings and before bed.
LinkedIn fought extremely hard to end up with Microsoft when Salesforce REALLY wanted them. LinkedIn execs new Salesforce would be the end of the company.
Saying that companies are really bad, even dog shit (a sibling reply to my reply above), also seems popular -- implying that the poster could have created a better company himself? hmm
LinkedIn is a pile of dogshit, they didn't need any help to do it either. It's laggy, spammy and covered in dark patterns with a user base populated almost entirely by self-aggrandizing boomers jerking each other off.
Now please explain to me, how Salesforce would have ruined it?
Do people want to cash out and make billions of dollars? Or continue to fight in a competitive landscape and constantly work hard to innovate lest another company over takes them?
This is the end result of oligarchy capitalism, which is itself the end result of neoliberalism. The tech community is temporarily compensated enough to ignore the realities of our economy. It’s a shame, we are probably the most empowered to change its course.
Quick plug for the General Internet Unit podcast, they’re a good starting point for those wondering how things might be different.
Funny, just earlier today I was noticing that a friend of mine seems to have started working at Slack and was thinking "hm, that seems like the kind of company I'd consider applying to... smaller, but still serious, good quality product, but not bogged down in BigCorp politics etc."
I don't get it. Slack needs a productivity suite to fight off Microsoft eating their lunch with teams getting bundled for free with everything. Salesforce has no synergy with Slack that I can see. I guess you could deeply integrate with the CRM... but why would you want that abomination? The advantage of Slack is that it's centralized communication for the whole company. If it becomes bolted on to the CRM I guarantee other departments at companies will find a new tool.
Salesforce is building its own productivity suite - they have acquired Quip and continues to push it as a "live editing intelligent document linked with data"-type thing.
Quip is probably where they think the synergy is. Quip could provide the productivity suite features, and Slack could provide the chat features.
An integrated Slack and Quip product could be a decent competitor to Microsoft Teams, especially for the large amount of customers who already pay for either Salesforce, Quip, or Slack separately. It would probably be a lot easier for existing customers to add new features to what they are already paying for than it would be to switch to Microsoft Teams.
I don't get it either. Great exit for Slack though, which has done nothing in terms of its stock price since IPO. Slack doesn't really have a moat, and they're slowly getting eaten up by Teams and other companies like RingCentral who also have their own chat app. Wouldn't be surprised if Zoom came out with one.
Zoom has had a weak plain Slack copy cat for some time now. They bring it up in their change log a lot (Zoom Chat), but I only know of 1-2 people who use it.
Agreed. That would be the biggest. Would be insane and who knows what that could have led to for Zoom being the newest big tech company.
Before I thought Perhaps Atlassian and Slack would merge in a mostly stock deal. Was looking at their recent partnerships. Atlasssian’s market cap is 3x bigger. Only big enough if both were on board.
Not surprising. It's really hard to see how slack could survive as an independent company given that their product has been more or less stagnant while Teams has been eating their lunch on large accounts.
I don't think their corporate culture let their product make the leap from "cute chat app used by Silicon Valley startups because it has emojis" to Enterprise-level support and functionality.
This is the time to raise flags about anti-trust, not years later when the market is hurting. There is no reason for this acquisition other than to kill competition with gross incompetence and $$$ acquired via other sources.
While I've already kind of fallen out of love with Slack, I do appreciate that they are independent. I do understand why smaller companies do this, but generally it results in a crappier product. Skype is a perfect example of a good product left to rot on the corporate vine.
The software world would be so much richer if there were more difficult for bigger companies to suck them up and turn them into corporate goop. I'm not necessarily suggesting regulation here. Just wishful thinking.
Let's add in Mattermost. Have you used both? I remember trying Zulip briefly one evening and it just felt horribly confusing. Mattermost feels more at home but its threading model is weird, it's not really threading (at least like Slack) since all messages are echoed to the channel.
Zulip as a company is extremely different a massively-VC-funded-and-then-go-public company like Slack:
* 100% of the software we write is FOSS.
* We intentionally haven't taken VC funding despite plenty of opportunity to do so, to ensure we can remain an independent, values-focused company.
* Most features are built by our open source community, not fulltime employees.
* Zulip was a distributed company pre-pandemic (while we did have a SF coworking space walking distance from my home, I as the founder only went in about once every week or two, and essentially all collaboration was over Zulip or GitHub).
They acquired the original Zulip startup in 2014. Then they open-sourced the code, and Zulip since 2016 is backed by a new company which is the one tabbott is describing above.
365 comments
[ 8.8 ms ] story [ 512 ms ] threadSlack is missing doc management/creation. Quip is missing a good chat solution. It’s almost like PB&J.
Their chat api expects headers that they do not include in cors allowed headers, we had to write a proxy just for this.
Salesforce as a company is a terrible experience.
Had many incidents because of their bad practices or lack of knowledge or incompetency.
It's hard to tell if Salesforce has been a positive for Heroku for keeping it alive, or a negative for mismanaging the company, since we don't know what they would have done if they stayed independent and had to actually compete. But I'm pretty sure if they were still independent and had to compete in the market with only the features they have right now, they would likely be out of business. There's very little reason to choose Heroku these days, and I say that as someone who has code running in production on Heroku's platform.
The product is stable, there's a ton of new features (like pipelines), and can't imagine starting a serious project and not using Heroku.
Heroku still doesn't have any data hosting options. You have to go to a third party for this.
Heroku doesn't have any static site hosting options. You have to go to a third party.
But the biggest problem I have with Heroku's model is how much I need to pay. I've been a Heroku customer for years and I'm still not exactly sure what a dyno is. And if I get it wrong, I can have auto-scaling... but only if I'm paying a minimum of $250 per month. Now that's not a lot to big companies, but for bootstrappers that's insane. And I only get 2.5GB of RAM for that $250/mo? And if I'm using microservices, every service costs me a minimum of $25/mo, $250/mo if I want auto-scaling on those services.
Like I said, Heroku is great and I use it in production and pay them money every month, but man if it's not stuck in 2015. Luckily so is my application so I don't have too many issues except for the ridiculous cost even as EC2 is dramatically cheaper now than it used to be (does Heroku support Graviton? I don't think it does), but PaaS in general is "the old way of doing cloud" and Heroku is becoming less relevant every day.
https://www.heroku.com/postgres
https://www.heroku.com/redis
https://www.heroku.com/kafka
When you codify your business processes, actual code is going to be needed as well. Enter Apex and heroku.
Slack is a way for SFDC to codify another part of your business processes—communication.
That said, SFDC does a lot of things that fairly give it a bad rap. Their developer experience is really bad, their apps are not that great, and lightning is still not adopted at many companies years after its release.
Are there no better ways to automate sales and marketing?
Once you start using Salesforce, do all of your leads get stuck in the platform, or can you export them and do your own analytics queries? How deep is their lock-in?
> Slack is a way for SFDC to codify another part of your business processes—communication.
It feels too freeform to be automated. It's just chat with a so-so search interface.
SFDC has one of the most robust APIs I've seen...you can export pretty much everything. I actually really enjoy working with the soql rest API, because it's simple, effective, and discoverable.
The lock-in is instead in their integrations. It is almost guaranteed that there won't be another platform that has all of the integrations you need, so you stick with SFDC. You add more integrations over time and the lock-in deepens.
To some extent, as a business owner or CRO, you want the data to be stuck in Salesforce. The price of Salesforce is small compared to the cost of salespeople maintaining their own relationships directly with clients -- and then potentially walking away.
The developer experience is sadistic, but Lightning is the worst. It takes forever to load basic information because it all has to cycle through JS callbacks. Try opening a link (or a bunch!) in a background tab: it doesn't load anything until you're actually looking at the tab.
I don't understand what this means at all. Let's say I make pies. My sales process is I go to grocery stores and try to get them to carry my pies. My marketing is I buy commercial time on the local tv station. How do I codify this into a SaaS product?
Salesforce is a SaaS because it’s in the cloud. The first company to take a big het on the Cloud, in fact.
If you’re still confused, then spend an hour or so reading their marketing literature and kicking the tires in their free Developer Orgs. Simple as.
The reason I don't call it a sales lead tool is that is about 10% of their use case now. They've expanded significantly and companies use them for just about everything.
Every time someone at your company uses your phone system to call a customer, it is auto-logged in Salesforce. Every email is logged. Every sale, every transaction, every interaction.
Now when "Bob the amazing Sales Guy" leaves you have a central repository of every contact he's made in every company he's worked with on your behalf. This means you build institutional knowledge instead of tribal knowledge.
So now lets say a couple years have gone by, and you want to publish a white paper on pie consumption, so you hand the project off to your research and analytics team. Thanks to Salesforce they have knowledge of every person your company has ever contacted about pies, and therefore have a great jumping off point to start with interviews for the whitepaper.
Along they way they've bought a ton of companies that do various enterprisey things. Now they're a one stop shop to run everything a business might need.
Suppose that we said that Salesforce (or JIRA) itself is fine, except for those sites that have implemented it poorly. Would that be an example of the One True Scotsman fallacy?
(I mean the question honestly. I'm not 100% I properly understand that fallacy's definition.)
If there’s something missing all you need is either time or budget to have it built.
Rocketchat if you want full control (open source).
(Mattermost is great)
I can't stand being in long video meetings where everyone waits around smiling and one person talks forever. I also deeply miss the easy chats we used to have in the office, when we didn't have to schedule meetings just to talk. But I don't want to dedicate my time to sitting in a discord-like audio channel while I'm doing work.
So, heysync is the answer to my own problems. It has a similar feature set to IRC or to Slack, because I love those products, but it's built with asynchronous audio communication in mind, in a way a Slack app just couldn't provide.
You just talk, and heysync transcribes the message and stores the audio for easy playback. Your colleagues can either read or listen to what you just said. They can listen live, or later, so you can seamlessly talk even if the person you're talking to isn't there, or is multitasking.
0 - https://heysync.chat
(edit: I was downvoted pretty hard for contributing this -- if anyone wants to share why, here or via email at carss.w@gmail.com, I would love to learn how to do so better.)
If the GGP had said "I hate Zoom meetings where everyone waits around smiling and one person talks forever", the post would have made more sense to me. Or, if the GP's product can also function as a more basic Slack replacement, their post should have led with that.
It just also allows you to speak via audio, and captures that audio inline with the chat, in both audio and text form, which is the key selling point. It is visually and in terms of day to day use very similar to Slack, or IRC. My desire to build heysync is literally borne out of frustration that this featureset is not possible within Slack itself, which I use daily.
This has been a problem ever since email: many people reply to the last mail they have from a list, sometimes changing the subject, and then get surprised when the mail is threaded under the mail they replied to.
I've seen this occasionally on Zulip instances, but a reminder and a suggestion that the topics are like email thread subjects or forum thread subjects tends to help.
Given that you mention a big public server, it's likely caused by an issue specifically related to that server's scale/usage patterns, and I'd like to make sure we investigate it.
Google's erratic roadmap, less than stellar enterprise support, and shady privacy practices from their ad tech side just drive me away
Tell that to Windows phone owners...
Most of them were Microsoft employees
And MS paid for their phones
When Microsoft bought GitHub, all of the "Developer Evangelist" / "Open Source" evangelist crowd made all of those noise about how "Microsoft is great for our community! They ARE an open source company! Everything is wine and roses!"
Blech. I can't do business with evil companies.
[1] https://messenger.bwi.de/
[2] https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed...
[3] https://sifted.eu/articles/element-germany-deal/
...but those are among the three organizations I would trust the least with such a choice.
It would be like recommending a housing strategy implemented in San Francisco, or a public transportation strategy implemented in New York.
So many inconsistencies in the UI. Almost non-existent keyboard navigation. Typing notifications and read receipts on by default (supposed to be a privacy focused chat). Handling unread messages. Lack of threads. I could go on...
Slack has many alternatives including using email
They're alternatives, but they are far from being usable alternatives.
It has to be comments like this that drove someone to create n-gate.
WebEx had 324,000,000 users running 73,000,000 meetings in March of this year [0]. As of April, Meet was adding 3,000,000 users per day with 100,000,000 users attending meets per day. [1]
You're obviously right though, they're clearly utterly unusable.
[0] https://www.reuters.com/article/us-cisco-systems-webex-idUSK...
[1] https://www.theverge.com/2020/4/28/21240434/google-meet-thre...
It’s also possible for something to have many users and have them casually brought up as unusable. The OP doesn’t literally mean unusable. They are exaggerating for effect.
Because of the same qualities that made it successful in the corporate world!
• Zoom is for one thing—it doesn't try to also sell you on a new service for managing documents, calendars, or VR bitcoins.
• Zoom is extremely easy for new users to set up and quickly enter a video call. It works even on very old hardware and operating systems.
• Zoom's audio quality is unmatched in calls with lots of participants. It's relatively adept at dealing with poor network quality and audio equipment.
I really think there's a lot of lessons here for other companies.
Ah, I see you haven't been following the recent updates (in which Zoom wants to gradually try to replace Slack and become your default client for your calendar and third-party integrations)
I mean I think Slack uptake would benefit companies that have been forced into WFH, but shrug maybe that's not happening or doesn't seem like that's moved the needle on the stock price.
JIRA is a 22MB download any time I go to look at my tickets and the whole experience is grindy slow.
Every time I look at a ticket its like the 4th or 5th thing I check, its such useful information and they've allowed themselves to be so far removed from their principal use-cases its extraordinary.
Unless maybe it was my org that foolishly decided to configure it away?
I don't even think Jira is specifically bad. If someone was only using it for basic project managment and ticketing, it'd be acceptable.
However, occupies the same niche as SAP or Oracle businessware.
First, Take a service that must be ergonomic because people rely on it all day to do their job. Next, make the primary requirement the ability for managment and finance to run reports. Then, outsource it to a company that wants to add custom web frameworks on top of a decades old project. Finally, graft on decades of customizations done by different generations of contractors.
If you can admin your own Jira instance and keep the fields and plugins to exactly what you need, it's pretty nice. I keep going back to it for the customizable workflows and fine-grained access control.
Unfortunately, every corporate Jira instance I've ever worked with has been overrun with every possible field possible, an unnecessary and constantly shifting mishmash of plugins and horribly slow access. You're paying the price for all of that cruft that you don't need and which can't be removed because "maybe someone wants it."
I've seen multiple different fields for the same value, each of them created for their specific team. The instance is slow AF most of the time due to the bloat and often I can't even assign a sprint to a JIRA because the field doesn't load anymore.
My company had resisted the urge to bolt on additions more than most. We recently migrated from Cloud to on-prem Server as a result of being acquired, and it is amazing how much zippier our project is compared to some of the peer projects that have accumulated cruft.
Growing at that rate at this point in your company's lifecycle is pretty extraordinary. So not sure why you would consider them to be a cautionary tale.
As for what has happened to them. They have been on an acquisition binge the last few years e.g. Trello, StatusPage, OpsGenie, Mindville etc. And as mentioned above they have been rewriting their UI in a new React framework called Atlaskit.
I also used to think Atlassian was a pretty poorly run company but then you look into it and actually the opposite is true. Although they did let Github, Gitlab, Slack dominate them.
Next few years will be interesting as Gitlab is moving very fast into their space.
Slack is the new Sharepoint, everyone uses it but no one really wants to and it doesn't really fit the bill but everyone else is doing it so companies adopt it.
Microsoft Teams Chat UI is garbage. It uses a lot of space, i can't just have a list of channels, no i need groups etc.
It even doesn't matter to me if its slack or hipchat or matrix or whatever. I don't know why we migrated to slack.
I don't get why Teams doesn't provide a lightweight chat typical UI. I would just switch to Teams. After all video calls are much better on Teams and more stable.
But then Slack integrated Teams and Zoom. They clearly don't want to compete in this area and i also don't get why.
And yes, Atlassian did drop the ball. We'll see the fallout in five years, I don't see how they can save the company now.
Heroku, on the other hand has been a hassle-free solution for my company over the past 7 years, and short of a few outages (which were actually the fault of AWS from what I remember), it has been absolutely reliable.
We've worked hard to incorporate reliability lessons learned from building the platform at scale especially as we've grown [1], and I hope you'll give us another chance. If I can do anything else to help, my email is my HN handle at render.com.
[1] https://www.tfir.io/more-than-100000-services-created-on-zer...
The components were mostly handed down to us from a company-wide UI team whose main design goals were to bring commonality across all Atlassian products. This is a worthwhile goal, no one thinks that it makes sense that Atlassian has different editors and even markup languages between (and even within) products. But the result was dog-slow overweight components like the Atlassian editor which tried to be everything to everyone. So when you need to bring in a monolithic highly-customisable 12mb+ component for every text edit field then things spiral out of control quickly. One cool thing, though, is that these components are open source[0]. And it looks like some performance/payload work has been done since I left, thank god.
In my new job I use Jira Server which hasn't been infected with the updated UI, and it's a shame because other than that terrible UI there have been big meaningful updates in Jira. But I'm dreading our inevitable migration to Cloud.
[0] https://bitbucket.org/atlassian/atlaskit/src/master/
Sometimes with Jira updates, I have to ask myself “What WERE they thinking?” It’s good to hear that actually some people (well, at least one!) inside the org ask this too.
If I was in Atlassian's situation this would be the last thing to focus on.
a) This is the biggest ever rewrite of their most important products. In this situation maintaining feature set compatibility is always going to be priority A, B to Z.
b) Their paying customers are mostly in the enterprise space who have very fast internet and stable environments i.e. payloads are quickly cached.
2) They are in the middle of a complete UI rewrite and I've only briefly used it but it's definitely much better than the previous versions. I imagine the Trello acquisition is also going to help them here.
For my other team members, they enjoy Confluence more than Jira, because Jira feels a bit difficult.
The not being able to type fluidly has to be the worst though.
Our team has as well at least brought up the idea of potentially trying other products.
Some of it's probably me not really wanting to get involved with JIRA in the first place (who wants to manage tickets), but in the interest of being a better employee I've been trying to make sure I'm squaring out my work properly for tracking, etc.
And there's certain things, that I'm sure are there, but I just can't find sometimes. Like... how to add an epic easily. There's at least three different views for each ticket (when you create it, when you click it open into the modal, and the full screen view), and things are apparently in different places on those different views?
I'll take some of the blame, but it's a mess.
c) Pushing folks to their cloud offering, partly by
d) doubling the cost of on-prem.
The surprise price bump really pissed off people here; that, combined with doubts about their long-term commitment to on-prem put evaluating alternatives on the list for next year.
Being a tool no one loves is a bad place to start changing a bunch of stuff at once.
Things have been improved with the recent addition of pinned ticket fields, but they still have a long way to go.
the issue here isn't the goal itself, it is that such highly visible efforts - "common platform", "common UI", etc. which are very complex technically to do right - invariably bring up to the top and into the deciding positions those "drivers of cross-organizational/functional/etc. change" style people whom you'd really want to be staying far from such important and complex technical issues...
I worked with Jira in 2012-13, it was appallingly slow. Making it even slower is an achievement.
Good to hear that there’s at least one person involved with it that sees the problem with this. I imagine how the use of whitespace to organize the layout probably looked very simple and attractive in Sketch or Figma at some point. Then reality crept in, and that whitespace was gradually carved up into more and more incoherent pieces. And as that was the only indicator of hierarchy and relationships there was to start with, there’s now no organization left at all. Many screens are just a bunch of words, all imperceptibly different shades of dark gray, strewn out randomly over a solid white background.
To make things worse, they all seem to be implemented in slightly inconsistent ways (you can tell when an h1 is wrapped in ten (10) layers of nested divs, each just containing the next div) so things that should align are all off by a pixel and have slightly different behaviors.
I wonder if people like this stuff? I mean are there people who mindlessly scroll through this crap and like it?
For this particular website I think the design is obstructing the functionality. "Good design is unobtrusive - Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression."
In the future, when cursing the developers who are responsible for this, I'll bear in mind that sometimes no matter how good the individuals in the team… it's sometimes impossible to salvage a good product.
It's a shame they are killing off the server products to push everyone into the cloud.
as long handle being wholly dependent on a third party whose API access could be pulled anytime .
For one large web app I worked on, we had a setup where browser loading time would always print out in the dev tools console. We had no hard requirement for UI changes to stay under a certain threshold, but seeing that loading time with every refresh during development was enough to keep us mindful of payload.
I didn't comprehend how someone thought it would be a good idea to move the button for a new ticket away from the main screen to that sidebar thing where it took an additional click to do so.
Yes lets add another click to the most used function in my workflow...
THANK YOU (sorry for shouting). That's my biggest pet peeve with the new UI.
I feel like I'm using some mix of Mac OS X UI and a child's toy. Everything is so big and spread out, there's barely even space for longer text areas.
Don't even think about putting windows side-by-side with JIRA taking half a screen, it's unusable.
Jira is a tractor trailer. It's big, it's powerful, it's a bit slow to get moving, but (1) it can carry just about anything (2) once it gets moving, it tends to stay moving. There's a lot of value in having a "do it all" project management system.
That being said, there's also value in alternatives that are more tailored towards specific needs.
Way faster, way better design and the searchbar was amazing.
Look, Atlassian is a growth-by-acquisition operation, chaos is inevitable
We did the same at one company I worked for. It was a terrible decision.
RxJS is one of those things that is fun to play with until you look down and it's cutting off your legs before you even felt it. Instead of simple AJAX calls when needed in places that are logical, your app turns into this hydra of events flowing everywhere and never knowing why anything is happening or where it's happening. RxJS is what happens when a Jenga tower makes love with a Rube Goldberg machine.
And don't get me started on those damn marbles. We're writing goddamn CRUD webapps!!! We don't need marble diagrams for this. It's like that Mitch Hedberg joke about donut receipts. We don't need to introduce complexity into our simple life.
And the Award for Metaphor of the week goes to ...
[0] https://rxjs-dev.firebaseapp.com/
Secondly, it's great that they're involved and passionate on social justice issues, however I wouldn't lead with that as the landing page gives no idea what the company actually does, offers, or makes.
Thirdly, when you click over to their team, it should identify their role instead of just letting you click to their socials.
^ just my quick first impressions!
Some young woman was on stage demanding that all males need to apologize to women in tech. There were other incidents.
Not a community I want to be involved in.
[0] https://docs.google.com/document/d/1g4oh2GGZOsucZfT1YJ5wjDUS...
Say I'm installing a toilet, I need to go out and buy one from the hardware store, remove the old toilet, install the new one, and finally test that it works. It's a linear process that could easily be constructed via a series of async/awaits, and I wouldn't use RxJS to model the behavior.
Now, say I'm building a bathroom. You have a shower head, a sink, a toilet, light fixtures, power outlets, tiling, a door, and a window. You have a bunch of contractors. Now you're dealing with N number of sources, N number of tasks that can possibly done in parallel, and N number of possible things you could do in that bathroom depending on how much the bathroom is finished (for instance, if just the plumbing, floor and sink are complete, I can wash my hands)
This was always a hard problem, and not one that is especially appreciated, but I can tell you from experience that attempting to just use promises or async/await is not a scalable pattern.
I appreciate your expanation of th Atlassian dev process. I've always wondered how they managed to make JIRA so slow.
Except going to https://bitbucket.org/atlassian/atlaskit/src/master tells you to go to https://bitbucket.org/atlassian/atlaskit-mk-2/src/master/ which then tells you:
> Unfortunately, that code no longer resides here as it’s all been moved to a new closed source location.
The breadcrumb to get to it is a bit crazy, but https://bitbucket.org/atlassian/design-system-mirror/src/mas... is the old mirror, which has a link in the readme to the new mirror: https://bitbucket.org/atlassian/atlassian-frontend-mirror/sr...
That’s scary in a few ways I have a hard time imagining.
(and yes, you could water, i dunno, facebook down to that, but still, these are... trouble ticket systems..? what am I missing? Scaling?)
- Workflows
- Access control over fields
- Custom fields
- Release management
- 3P plugins and integrations
- API access
I am far from being a fan of Jira but they do have a rather large set of features. Every time I evaluate the hottest new issue tracking and/or project management solution, there is something lacking as compared to Jira.
I don't think anybody really sets out with the intent of using the one reputedly cumbersome tool that can do anything - but after growth and pivots and new requirements and new teams and special workflows... you end up needing a combination of features that is literally impossible to get with any other tool, and who wants to fracture into multiple tools?
So you get JIRA. And it just does it all, and even if nobody is overjoyed, nobody feels like they lost, either. There's value in that.
This is because the information in these tools is business critical and needs to be consumed by almost everyone in the company. Moreover, different people need access to the same information in different forms of presentation, with aggregation and emphasis of different data. In contrast it's easy to make a work tracker just for developers - GitHub and GitLab have pretty much solved that problem. Making a ticket tracker which works as a single source of truth for all members of an organization who need access to the tickets is much more difficult.
Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate. You can't just target a single group here, because then you're trying to get the company to adopt separate repositories of work (it's already an additional complexity that work is split between e.g. GitHub and Jira, for example).
So to obtain the critical mass of adoption they need for product market fit and growth, these tools organically evolve to become everything to everyone in an organization. And suddenly your tracking tool is stuffed with metrics, integrations, feeds, dashboards, reports, etc.
The other thing is that these tools become especially bloated by integrations and plugins. A brand new instance of any tracker or project manager feels clean and fast. A few years in, it feels slower and more crowded by all the custom/third party additions rolled into it.
I realize this would be a lot of work, but I would be really interested to see some examples of "the ticket the developers want", "the ticket the VPs want", "the ticket the designers want", etc.
What happens is that a new field gets added, and whoever's adding it claims it's really "important" and needs to be seen by everyone. It'll invariably set as mandatory to be filled in too.
2 years later and some integration breaks because the integration doesn't set that field and you end up looking at that really important field and every single project has it set to exactly the same value.
Repeat ad nauseum.
The other thing I've seen a few times is when assessments or a bonus depends on some field so they make it visible to everyone. Then the bonus scheme changes, but they never hide the fields that no-one cares about any more.
Ugh, this reminds me of a mess I inadvertently participated in..
A certain employee, on an unrelated team to mine, decided to to go down the route of becoming an agile/scrum master/evangical and somehow got "reduce instances of X" as their personal KPI/development goal one year. Soon after this, they're pinging myself and other team leads on slack whenever X field is filled out on JIRA and demanding justification. Eventually because of this harassment I just stop filling out the field, leaving it as the default value and just verbally communicating the fact to whomever needed to know. Later on I find out that I wasn't the only one that took this route,And guess what happened next! The scrum master is promoted to a management position, in part due to their stellar KPIs! Excellent work all around!
They need to absorb things so their sales team can say "oh we have X feature" regardless of its actual implementability and just leave it to the consultants to struggle and somehow implement a half baked solution that doesn't work in the end.
Oh but that's how they make money also. More products, more features, more crappy integrations = more service contracts, more consulting work, etc.
All a huge scam that enterprises are forced into because they don't want to be "left behind in the digital economy."
Returns aren’t as good if acquisition is high, like slack will be.
They are a pretty notable company in startup history since they were the first to be hugely successful at using the self-service model for enterprise sales.
A lot of small(ish) firms are making reasonable money doing this sort of thing; I'd count them as enterprise sales ;)
One central high quality HR Team can scale easily in a big org while the same amount in small companies need spend more on HR.
And its not just HR of course.
I wouldn't even trust small companies to build a modern and secure cloud product. While big companies have their own Security Teams and are able to afford a normal security audit, for a small company that means 1. much higher cost in relation and also binding of personal they might not have.
I have worked in a very small company which basically couldn't spell security. And i'm now working in a very big company. There are plenty of people who also can't do that but there are teams only for security.
I don't have to justify now that i'm doing things securely. Thats how it is. My manager will not sign the risk away; He actually can't and people are not keen of asking upper upper management for that.
That's the sales pitch, sure.
Size scales in reverse order with security. The larger you are, the more difficult it is to make sure all the gaps are sealed - that's why the greatest of empires fall eventually - they get spread across so large a portfolio there are bound to be gaps, which are endlessly exploited, even on users of the large ERP companies.
If products were actually integrated well and deployed well all of what you say would be true. But that's just not the reality - trust me, I've been there. It's bad.
I don't know where the sweat spot is, but i don't think it is at a 10 person company. I believe its more in the range of 500 or 1000 person company.
Oh my.
But their horribly inconsistent UI and UX a big tell why it is this way. They simply serve you multiple versions of their website, each for different component. And together it's a giant mess.
> But their horribly inconsistent UI and UX a big tell why it is this way.
It's insane how the editor changes between creating a task description, to editing a task description, to writing a comment. Like three separate teams with loose guidelines created them. In reality it's probably more like 7 teams.
I hate Atlassian with a passion and the only reason I touch it is because I'm a corporate slave.
(Two super-slow things combine to make the ultimate slow thing - looks like the aquisiton makes sense after all!)
Man, that UI is such a slow resource-hog of a bloat-ball.
There's just too many ways to "agile" in JIRA, every project/program manager I've worked with turns it into a Frankenstein immediately.
salesforce revenue 20b
are they really going to pay 40b for something that makes 400m a year? I get they're paying in stock but forgive me for not understanding the synergies here
It could certainly be a mistake, though.
even in the cross-sell case, 'slack doubles the value of salesforce' is a stretch
I suppose slack has way more customers so if even a few of them convert, salesforce grows tremendously? but the downside is this pushes SF into the freemium market.
'we're buying slack to help us grow our free tier' isn't ultra compelling.
if salesforce has a substantially more developed marketplace for plugins, SF can help slack get there too; not sure how rev-share works for slack plugins today.
Damn good exit though. Who woulda thought a chat utility could be worth billions
It reeks of different services consolidated via acquisition (or one-off services kitbashed together), and adding slack to the mix will just add yet another variation to the existing APIs.
I commend those devs that work with Salesforce on a daily basis!
I've heard decent ones are handsomely paid, so at least they have that going on for them.
Medium to large business will easily pay $200k-$400k for Salesforce implementation projects.
Still feel like the business sales industry is waiting for its iPhone disruptor.
Salesforce has listings of recommended Salesforce development and implementation companies. You’ll need to get training first and prove expertise.
You could look for companies that have job listings for Salesforce administrators and then see if they are open to contract work.
Attend Dreamforce to get a feel for everything is also a good idea.
API quality varies from product to product. Base APIs object retrieval are excellent because tons of people use them so they received incremental improvements even after launch. More niche APIs like Communities or Chatter unfortunately don’t get as much love or attention.
Documentation, on average, is great. Light on practical examples, perhaps, but Salesforce has made huge investments into education materials for the tech side of their products. If you think THEIR docs are bad, I urge you to share what big company (Netflix? FB?) with regular users as the dominant customer has docs that do are think are better.
I can not think of any other logical explanation for why it is so bad.
Of course these opinions are my own, I don’t currently work at Salesforce, and I can only tell a tiny part of the story from my own perspective, and it’s probably unfair to people who did a lot of good work.
(Incl Steve Jobs just a little bit others might find it interesting to know)
> It reeks of different services consolidated via acquisition (or one-off services kitbashed together), and adding slack to the mix will just add yet another variation to the existing APIs.
That's not how this usually works. Heroku is still running just fine and isn't a messy bunch of APIs since they were acquired. SFDC will likely just sell Slack into their enterprise clients and let it be.
It's my theory once a well-crafted enterprise application becomes very successful it bloats up until design-by-committee is necessary.
From that point on it becomes an unusable disaster.
“Hey we got $so_many million dollar client who wants to use our product but they want to auth with their AD and can’t use our three other SSO options.”
And thus was born the company’s pluggable directory over VPN connector and auth strategy.
Still, salesforce can sell and that's how it got where it is.
You're right, if I'm using something as simple as Zoho, Streak, Insightly, Close, Pipedrive, etc.
But thats precisely my point - the greater the complexity of the application the more of the "nightmare of an API/UX". Have you ever worked with DynamnicsCRM? NetSuite CRM?
It'll be so cool when literally everything I do in life is basically owned by one company. Get paid in company scrip, buy food at the company store, live in company housing, talk to my family and coworkers over the company intercom, genuflect to the picture of the CEO in the mornings and before bed.
Now please explain to me, how Salesforce would have ruined it?
We'll get there.
There's your answer.
Quick plug for the General Internet Unit podcast, they’re a good starting point for those wondering how things might be different.
Not anymore!
You must be using a different version of slack to me.
An integrated Slack and Quip product could be a decent competitor to Microsoft Teams, especially for the large amount of customers who already pay for either Salesforce, Quip, or Slack separately. It would probably be a lot easier for existing customers to add new features to what they are already paying for than it would be to switch to Microsoft Teams.
Before I thought Perhaps Atlassian and Slack would merge in a mostly stock deal. Was looking at their recent partnerships. Atlasssian’s market cap is 3x bigger. Only big enough if both were on board.
I don't think their corporate culture let their product make the leap from "cute chat app used by Silicon Valley startups because it has emojis" to Enterprise-level support and functionality.
One of the Quip founders is President and COO of SF too.
https://mattermost.com
We use it. Its great.
I was pretty impressed with mattermost in the brief time I used it. Shame it looks like their starter package is twice the price of Slack...
It has also an open source option you can self-host no?
It’s free for lots of use cases including basic commercial use and is open source.
While I've already kind of fallen out of love with Slack, I do appreciate that they are independent. I do understand why smaller companies do this, but generally it results in a crappier product. Skype is a perfect example of a good product left to rot on the corporate vine.
The software world would be so much richer if there were more difficult for bigger companies to suck them up and turn them into corporate goop. I'm not necessarily suggesting regulation here. Just wishful thinking.
[1] https://zulip.com/
https://mattermost.org/
What are reasons it's unlikely?
(I like Zulip btw)
The structural reason is that we're intentionally not taking VC funding, which does more or less inevitable lead to that outcome.
Less structural but just as important is that my personal priority is in creating great open source software for the world, not personal enrichment.
This thread may be useful: https://news.ycombinator.com/item?id=23105031.
* 100% of the software we write is FOSS.
* We intentionally haven't taken VC funding despite plenty of opportunity to do so, to ensure we can remain an independent, values-focused company.
* Most features are built by our open source community, not fulltime employees.
* Zulip was a distributed company pre-pandemic (while we did have a SF coworking space walking distance from my home, I as the founder only went in about once every week or two, and essentially all collaboration was over Zulip or GitHub).
They acquired the original Zulip startup in 2014. Then they open-sourced the code, and Zulip since 2016 is backed by a new company which is the one tabbott is describing above.