This mostly didn't work out for them back in the day but in more recent times as more and more low quality middle level managers and execs get hired they manage to get approvals.
In my org a new VP demanded Jira instance within a month of joining the company and that it be used for technical project reporting.
Of course all the developers said fuck no to that so for a while some managers were trying to do two way sync between Jira and Buganizer. When I left it was mostly abandoned and full of tumbleweed...
That's when you're supposed to pull the smooth-talking people that are usually in those roles and ask them a very simple question:
"Do you want this tool more than you want to be employed?"
But in software, like all industries, the best salespeople are also domain experts, and domain experts in software are rare before you add the need to be able to sell.
* Inspiring client confidence and enthusiasm in our solutions
* Motivating engineering teams to tackle ambitious challenges
* Delivering high-impact results within accelerated timelines
Maybe if the devs hadn't been slacking beforehand, they wouldn't have had to rush to catch up.
* Your sales team passionately championing solutions tailored to my needs
* Them securing the resources and commitments needed to accelerate delivery
* Them inspiring the engineering team to rise to ambitious deadlines, ensuring my project stays on track and delivers real value
Maybe if the devs shared their dedication to meeting my goals head-on, they'd be able to ensure my business objectives would be achieved without having to crunch.
> "Do you want this tool more than you want to be employed?"
will be harmful to wellbeing of developers rather than sales guys.
Just wait until you hear what salespeople get up to and what they make off of it.
It's true you need working software, but without sales and operations doing their part, the software will be scraped when the company folds.
Sales and operations get away with everything because they're the beating heart of any successful organization.
But that thing is slow as a snail. Even if it's an on-prem installation. I want nimble tools.
I know it's a very unpopular opinion, but I'll take a fast Redmine over a slow Jira all day, every day.
P.S.: Another slow tool like this is OpenStack. Every CLI command, every web UI click means a ping-pong of 20 REST requests. At least, when it works, it works, which is 100% of the time if it's configured correctly.
I think that it’s been diverted from its original purpose,and is now indeed horribly complicated since it’s supposed to be all in one package.
I’ve also noted that in large companies the quality of the product for end users, as long as it’s not a massive drag on productivity or on recruitment and is not core business, is irrelevant and that other factors are more important ( costs, contracts , easy to install integrate and maintain, quality of support, breadth of use within the company etc ). This makes atlassian a natural superpower.
The problem is that the workflow you officially have and wish you used is almost never the actual workflow, so it becomes horribly confused and insane.
Even for internal projects, a lot of money is thrown at software because the corporation has decided (rightly or wrongly) that it's easier than changing process, culture, personnel, or internal incentives.
For example, salespeople on commission were closing not-very-profitable deals. The response was to layer in a complicated project feasibility/profitability estimation logic, configuration features for an "approval" org-chart hierarchy between users, and various new triggers to block the workflow at particular steps and e-mail people to come click and approval button... I still feel it would have (should have?) been better to change how the sales commissions worked.
To my great consternation, I have not found this to be true in the cloud version:
https://jira.atlassian.com/browse/JRACLOUD-72631
Special thanks to Matt Lachman for keeping up the good fight every (business) day.
I just checked and https://github.com/mozilla/jira-bugzilla-integration is alive and well.
Bugzilla is a Mozilla product so you’d hope they’d use it themselves (it’s often referred to as “dogfooding”). But Jira is everywhere so I’m sure some project managers argued that it was needed.
And once you have Jira then the same people push for Confluence too. But MediaWiki was the de facto standard before everyone jumped on proprietary solutions like Confluence and Notion. In fact I seem to recall that very early versions of Confluence was just a 3rd party Wiki that Atlassian bought. Or at least there was a Java-based Wiki in their early portfolio.
You also have to bear in mind that organising docs is an endless and thankless job which nobody wants to do. So these things tend to multiply like vermin once someone starts creating docs on another platform. One startup I worked for somehow managed to have stuff scattered between Confluence, Notion and Google Docs despite only employing 50 people. It was crazy.
Another client I recently worked for had Sharepoint, Notion and Confluence as their official tools for documentation.
As for IRC and Slack, every company I’ve worked at in the last 5 years had two of either MS Teams, Zoom or Slack. Literally every company. And that’s in addition to email. Go back further and there was Skype, WebEx, and so on and so forth too.
It’s almost a meme these days to hear the sentence “how would you prefer to be contacted” because so many solutions are competing against each other with overlapping functionality.
Then you have developer-focused tools like GitHub with their own docs and issue tracking too
At this point in time, it’s easier to just accept that each org is going to end up with multiple overlapping solutions because you’ll get new people join the team and they’ll want to use their preferred tool because that’s what they’re productive in and so the spiral continues.
So if Mozilla managed to keep the options down to just 2 for each product category, then I’d say they were doing better than most other organisations.
Bugzilla was fine to hack a few extra fields into, but I wouldn't want to build anything around it. Buganizer was actually pretty nice, but suffered from too many competing tools built around it, most of which were just somebody's 20% project, so they kept getting abandoned. Jira wouldn't be so bad if it weren't so slow and annoying to use; only our TPM can keep track of how everything is set up.
The internal system I built was very specialized to our use-cases; it started out as a simple task list and eventually grew into a huge beast. By far the worst part of the system was the manual-test-management system, but that was just a mess due to its very nature. We were able to be very efficient with some of the custom functionality we made.
But you’re right, calling it a “product” does somewhat oversell the significance of the project within Mozilla.
And for making it a product: It's a quite competed market, with Salesforce, SAP, Google, Microsoft, ... and it doesn't fit to Google's "you're on your own" approach, but requires consulting and integration services, as introducing a CRM to a company involves analysing the existing processes and then adapting processes to software capabilities and adapting software to processes. (Which both often fails ...)
I don't know if they every built a proper replacement, but for at least half a decade the Baggins Roster UI (internal backend for things like Google Groups and such) appeared to have been an abandoned summer intern project.
>The attackers impersonate IT support personnel, requesting the target employee accept a connection to Salesforce Data Loader, a client application...
"The application supports OAuth and allows for direct "app" integration via the "connected apps" functionality in Salesforce," explains the researchers.
"Threat actors abuse this by persuading a victim over the phone to open the Salesforce connect setup page and enter a "connection code," thereby linking the actor-controlled Data Loader to the victim's environment.
... app is used to export data stored in Salesforce instances and then used the access to move laterally through connected platforms such as Okta, Microsoft 365, and Workplace.
Accessing these additional cloud platforms allows the threat actors to access more sensitive information stored on those platforms, including sensitive communications, authorization tokens, documents, and more.
> The instance was used to store contact information and related notes for small and medium businesses. Analysis revealed that data was retrieved by the threat actor during a small window of time before the access was cut off. The data retrieved by the threat actor was confined to basic and largely publicly available business information, such as business names and contact details.
Which is to say, they took public _and_ private data and the private data is something we don't wish to publicly admit so probably not good.
Most likely translation: it affected the Google SMB sales team's Salesforce instance
That's a pretty nonchalant way to say "they totally stole stuff before we knew what was going on or could stop them".
https://krebsonsecurity.com/2025/07/phishers-target-aviation...
Could totally see someone sending a message like "Hey, your TAM asked me to talk to you about $IMPORTANT_FEATURE_REQUEST, can you grant me read access in the account where you're developing $UPCOMING_SECRET_PROJECT so I can get some additional color?" It might even be enough to get someone on a conference call and pump them for MNPI about $UPCOMING_SECRET_PROJECT under the guise of ensuring that the feature request is helpful.
> [...]
> In June, one of Google's corporate Salesforce instances was impacted by similar UNC6040 activity described in this post
Nope. Good old fashion social engineering.
Uh, it's the users that suffer.
You Suffer https://www.youtube.com/watch?v=_-ywSPWu3K8
UNC6040: lool.
shadowgovt•20h ago
On the other hand, the past decade-ish has seen them grow very rapidly via acquisition, so perhaps this DB was grandfathered in via an acquired company and hadn't yet been replaced by anything internal.
(For Salesforce in particular though, I'd be willing to believe Google doesn't have an in-house alternative... People asked for a Salesforce-like in Google Workspace for years and the company had no interest. I have a hunch that most Googlers find the idea of creating a new CRM to be a profoundly boring intellectual exercise).
mc32•20h ago
That said, you can hire people for any purpose (specific roles) and you can build what you want. It’s more a question of whether it’s worth it to build such solutions, after all you have a main line of business to tend to. That’s to say even Google and Apple have so called “boring “ roles and there are lots of people who don’t see it that way and want to work doing those things.
shadowgovt•20h ago
But even with their, what, 180,000 people these days, I think it's entirely possible nobody is as excited about CRM as Paul Buchheit was about email services.
progbits•20h ago
But yes your point stands, sometimes it just makes more sense to use an existing product.
eitally•20h ago
You might be surprised how much of what runs Google (Anaplan, for example, for XWS) is fairly industry standard.
scottyah•15h ago
bpodgursky•20h ago
Easy to hire experienced salespeople and have them hit the ground fast if they use standard Salesforce conversion flows.
bombcar•17h ago
dilyevsky•20h ago
eitally•20h ago
This led to consolidation of a number of back office IT teams that ultimately ended up with far more enforcement clout than they'd historically had. By the time Ruth changed roles, most of the "normal" business processes had been fairly standardized. Fwiw, the Cloud instance of SFDC, which is by far the most complex & customized, has been in full use for almost five years now and is the canonical source of truth for sales data.
coredog64•19h ago
ssk42•16h ago
shadowgovt•19h ago
I feel you about the ROI. In hindsight, it's a little funny to me that Salesforce is doing revenue numbers a little under half of Google Cloud; you'd think that would be large enough value to get Google interested in biting into that pie.
loeg•19h ago
Of all the things to NIH, this is one of the most defensible -- lots of bugtracker options just aren't very good.
cjpearson•18h ago
8n4vidtmkvmk•16h ago
kevincox•14h ago
...and it still wasn't great.
surajrmal•7h ago