The biggest mistake a competitor can make is thinking Salesforce is a CRM. They may sell themselves as one, but that is just to get a foothold in a company's sales system. Salesforce actually sells (1) an ecosystem that lets your company connect to any other software out there and (2) a platform on which you can build...basically anything. These two together ensure that every one of their customers is 100% locked in and will continue to pay whatever Salesforce asks for all eternity. The actual CRM part (basically tables of data with a UI) is trivial, and not really their "special sauce" that you can disrupt with something shinier.
100% agree. And we are not there yet. But I feel like open source is the best answer to 1 (building an ecosystem of integrations), and that it will also allow us to build a better platform for developers (2): why learn Aura components/Apex when you already know and can use Typescript/React?
An open-source core is only part of it, because different users will need different data models for different business domains. One of the biggest challenges here will be: how can you allow tenants to run arbitrary plugins that (a) execute arbitrary sandboxed server-side code, and (b) can store arbitrary new data models and custom fields within your instance's centralized storage alongside the canonical model types, in a way that allows for indices, foreign key constraints, and derived materialized fields?
If you solve this and provide a great developer experience, including free sandbox accounts and a payments stack so that developers can sell plugins without needing to ever operate their own infrastructure, with namespacing to avoid compatibility problems between apps, then the ecosystem will come.
That's a very good point. In the early stage, we were thinking about a single tenant architecture which would make this questions way easier. However, I am a strong believer in multi-tenant architectures as they allow to scale while mutualizing the resources (I personally think it's single tenant at scale is non-sense in term of ecology) and we will invest into maintaining a multi-tenant architecture.
So, as we go through the multi-tenant path, what you say is very relevant and will be challenging.
Regarding custom entities and custom fields, we plan to introduce a flexible data table backed by a meta-data, quite close to what salesforce is doing ; this article is gold about how they built it: https://architect.salesforce.com/fundamentals/platform-multi.... In short, you have a data table (uuid, objectid, tenantid, field1, ..., fiel500) where fields are VARCHARs and you build your own engine on top of that. This comes with a lot of challenges such as performances (indexation), typing (we lose Typescript/GraphQL power obviously as we deal with flexible data modeling)
Regarding plugins that we want users to be able to create and to activate on the marketplace without vetting, here is the way we see it right now:
1) Front-end: serve a dedicated JS depending on what workspace you are on. Rebuild this JS when you activate / update a plugin
2) Back-end: we will need to execute the code in a separate environment. We were thinking about serverless lambdas for the cloud version and keep it local on the main server for self-hosting ; kind of allowing two drivers (lambdas + local) to execute plugin code in the codebase but using lambdas only on the the cloud).
Would love to chat a bit more about it. We will likely open a Github discussion thread in the upcoming weeks about this specific topic) so we can get the feedback from anyone interested into it
>However, I am a strong believer in multi-tenant architectures as they allow to scale while mutualizing the resources (I personally think it's single tenant at scale is non-sense in term of ecology) and we will invest into maintaining a multi-tenant architecture.
Our products use multi-tenant architecture in the form of 1 database file per company, and a single database server for everyone (by default). It's great for data isolation, as we can't accidentally leak sensitive corporate data from one company's account to another (say, a missing WHERE). It's also great for indexing, as DB queries only touch small subsets of data. And it works well for most businesses (10-100 employees). For large companies (not that many of them), if we detect a lot of activity which stresses the main database server, we have infrastructure in place to migrate them to dedicated servers, transparently to users. It's worked pretty well so far.
Very interesting, this makes sense, it is definitely a direction we could go into. We are using Postgres and were also considering using 1 schema per tenant.
We built a version of this which goes far further.
- Monaco (embedded VScode inside the target app/platform)
- Typescript
- NPM modules
- Linting/autocomplete including custom fields/objects, so you basically know it's going to work before you even run it
- breakpoint debugging
- Version control with diff view
- Magic utilities to call the platform's own APIs in an easy typesafe way
The breakpoint debugging provides an amazing experience for the embedding app. It's pretty magic. But because the runtimes like Lambda don't ship the Inspector API we had to create a custom compiler to make it work.
We are actively looking to license this stack to other SaaS looking to build platforms.
If you want a demo leave your email and I'll reach out.
The ecosystem is really not about Aura/Apex. I think the API is a bigger piece. Pretty much everything in Salesforce can be controlled via the API.
That isn't even the big challenge though. The biggest challenge is getting people to build for your platform. If a sales team uses 10+ integrations (it's honestly probably 20-50), then they will pick a platform that supports 9-10 of their integrations.
A "real" development stack might enable users to build actually good experiences. The custom (proprietary) stacks I've seen so far have always been pretty "meh", lacking features, community and tooling, resulting in not-great DX and making building some features something between very hacky and impossible.
Accurate. The licensing (and the "kill switch") at a previous job were controlled entirely via Salesforce. Our app would "phone home" regularly to check which features are being paid for and we'd toggle them on and off in our app accordingly.
I had, at the same company, been asked to evaluate building Salesforce apps (using the custom programming language they provide) and contrasting that with building new apps on our own metadata-driven platform.
Developers hate it, business people love it. It won't be going away for lack of paying customers, that's for sure.
I'm really eager to get to the point where we can work on CRM extensibility and developer experience. We're hoping to bring traditional web development workflows and not re-invent anything.
We opted for a multi-tenant infrastructure for the cloud hosted version so there will be some additional challenges to make it work in that context!
If you wanna see what that might look like, take a look at servicenow, I do basically all my coding in vscode, and ctrl+s saves to the dev server. they have one of the more robust developer environments I've used.
> The actual CRM part (basically tables of data with a UI) is trivial
Although I agree with the general sentiment, I disagree with this.
I've tried out over 100 low-code ui builder over the past year (including creatio,Corteza,ERPNext,Baserow,tadabase,appsmith,nocodb,mathesar,bubble, etc.) and so far none of them have perfected "excel like ease with the power of a database".
2 competitors which I think are getting things right on the UI front are Attio [1] and Folk [2]. It's not as powerful as Salesforce and the data structure is very loose, but they have done a good job with the user-experience. They are not open source though.
You seem to be missing Coda ( https://coda.io ) which (in my experience) comes remarkably close to “Excel with data powers”. Think of Notion’s document editing and tables, but with _much_ more power, a proper formula language, UI widgets, etc. The Coda team have churned out a ton of amazing features in remarkably short time.
The main drawback I’ve encountered: no obvious way to separate code and data. I can’t find a way to version/clone one without the other while keeping the data in Coda. However there are plenty of integrations with external data sources, so keeping a chunk of the data external may be the best way.
EDIT: Oops, forgot to thank you for creating this amazingly comprehensive sheet. I’m looking for a similar thing myself: a self-hostable CRM for a small team that wants some flexibility around custom fields and automation but doesn’t need most of the other common CRM features. My current plan is to try AppSmith, but there are a bunch of entries in your sheet that I haven’t seen before. Thanks again!
Replace Salesforce and CRM with ServiceNow and ITSM and it's a similar story. They call it "Land and Expand". There's a reason they have a 99% or so renewal rate.
I think of Salesforce like an octopus that puts immovable tentacles into the organisation that are almost never removed. It provides as much opportunity to be misused as possible!
The basic answer is that when an certain type of organization gets to a certain size, they hire professional full-time sales people, and those sales people have been trained their whole career on Salesforce, so that's what they're familiar with and that's what they're going to want to use.
I've tried twice to buck this trend at small startups. I was successful in getting the companies to use a lightweight, elegant, user-friendly, not-Salesforce CRM system when they were small (<10 people). And everyone was happy. And in both cases, as soon as the organization got large enough that the professional sales people came on board, they said "what is this garbage where is my Salesforce", and that was that.
This is a VERY hard pattern to break, unfortunately.
I did the same thing. Then the lightweight, elegant, user-friendly, not-Salesforce CRM system that I had convinced the company to depend on (Highrise CRM) was mothballed by 37 Signals. Yes it's possible to export data, but there are usually things that we couldn't export (like notes and files/attachments) and it was a nightmare I will forever avoid at all costs.
After another client found that their Batchbook CRM solution was also being EOL'd, I started to feel like going for the biggest most well-known market-leading CRMs ends up being a good choice just from the point-of-view of data longevity and peace of mind.
I really wish 37 Signals open-sourced Highrise, or that CiviCRM or any of the other open source CRMs managed to get to a level of polish and ease of use so that I could ditch Salesforce, but I've yet to find anything that could justify such a move away from the Salesforce behemoth.
> I have never used nor worked at an organization that is built on top of Salesforce.
You probably do. Salesforce has all kinds of different products from Slack to Mulesoft and Tableau. Salesforce starts their pipeline by solving one problem, making that work well from a business ROI perspective, and then they pitch you on another and another and another with package pricing. This is basically the Oracle model and how Larry got his blood money.
Benioff started his career at Oracle and was a prodigy there - becoming the youngest ever VP or something like that. It's not surprising if his playbook is inspired by Larry's.
Same thing, as is servicenow, they're all cloud platforms angling to be the "Company OS" all coming at it from different angles. Salesforce comes in at the sales side of things, SAP invades as a finance app, and ServiceNow begins their encroachment as an IT ticketing system, but they all wanna be THE only cloud platform your company needs.
Sure but Microsoft isn’t really offering a coherent solution for general company data and processes. They have the power platform, but because there’s no happy path, best practices, laid out it requires a lot more buy in from actual engineers who don’t have a lot of love for nocode platforms.
It’s totally feasible to build a IT ticketing system in power platform. And then to build a sales/CRM solution and then also build a bunch of analytics and compliance and such for finance, but because Microsoft doesn’t have the barebones platforms there it’s a lot more work to stand up, and you end up maintaining a very custom product that is totally dependent on Microsoft not suddenly changing their pricing or deciding to kill the platform due to lack of revenue. At that point you may as well just build your own thing in actual cloud products instead of depending on the “baby proofed cloud”.
> Sure but Microsoft isn’t really offering a coherent solution for general company data and processes.
Do you have a moment to talk about our Lord and Savior Dynamics 365?
> Microsoft Dynamics 365 is a product line of enterprise resource planning (ERP) and customer relationship management (CRM) intelligent business applications
What? Microsoft is one of the biggest players in the market in this space with Dynamics 365!
I don’t have any data to back it up officially, but working in the space it seems like dynamics is taking customers from their competitors (eg SAP) fast too…
Yeah, lots of botched React integrations, misuse of Serviced Workers, nightmare security roles, just to name a few daily problems you will run into when choosing Dynamics 365!
It seems like a good solution would have clean interfaces between various pieces so they can be easily replaced. Sales, purchasing, payroll, HR, and IT stand out to me, but there may well be others.
You can say the same thing (lock in) about any product that has migration costs. If everybody thought that way nothing would get built. I say to Felix: just do it, but think about these problems.
Fortunately there is a whole field of business devoted to this problem: go-to-market strategy. Target a niche, offer a compatible product, offer a significantly better product, offer a different product, offer a cheaper product ... the options are endless.
> You can say the same thing (lock in) about any product that has migration costs. If everybody thought that way nothing would get built.
Not all "migration costs" are the same: to quote General Turgidson, "It is necessary now to make a choice, to choose between two admittedly regrettable, but nevertheless distinguishable, postwar environments: one where you got twenty million people killed, and the other where you got a hundred and fifty million people killed."
In the case of software migration costs, the cost of migrating away from a proprietary application-platform with zero-to-little code and data portability, will be orders of magnitude higher than the cost of migrating away from a proprietary infrastructure-as-a-service platform.
This isn't anything new: while Cloud-y platforms like SalesForce present even higher barriers to exercising our rights to data-sovereignty than what we had previously with SAP (because at least with SAP you can defenestrate the machines), it's all too similar to the 4GL vs. SQL wars of the 1990s. I honestly can't think of any orgs from then that regrets betting on a SQL-based RDBMS, while there are still companies out there depending on FoxPro, Progress, or worse...
This is also why I flat-out refuse to use Firebase.
Another hidden-cost of 4GL-like systems is that eventually they run-out-of-steam: hype fades and the vendor becomes stagnant and/or can't attract the best minds in the industry to design and build the platforms they expect others to use, so they lose whatever advantages they might have had which justified their proprietary nature - or an even more insidious version, whereby too many slow-moving companies become dependent on a particular platform that the platform's vendors have to intentionally hold-back the platform to avoid imposing too many fast-moving potentially breaking-changes (Java comes to mind...).
Right, but the bigger the organization, the larger those costs. Think of a city of Los Angeles switching to a new system for tracking their public works department versus a township of 3,000 people. Smaller orgs are much more tolerant to this. New orgs start small and don't need something huge like Salesforce immediately; they need something usable.
There’s a lot of introspection tools within the UI, pointing you to implementations. The code management is happening “within the system”, so to speak. There’s just a lot of “everything is within this system and is inspectable”
It's more than that. If you look around the market at any sort of data, BI marketing automation, payments or a dozen other verticals and every single one of them will have a first-class integration with Salesforce extolled on their homepage. A business running Salesforce is like a business that speaks English.
