I'm not a fan of Elon-style "pitch FSD or promise things that you don't have" either. But we had to find the right balance between expressing our vision and expressing where we are which you can see through screenshots/product demos.
The vision is definitely to have something extensible and more powerful than force.com ; we aren't there yet because we need to build strong foundations before that. We already try to separate our business apps from the core engine in the code base to learn what will be the right api and get ready for that next step when it's time.
If that's the case I'd encourage you to take away a few lessons from Salesforce:
1. IT is not your customer. The business is, and they don't know how to write code. Based on what I saw thus far; this is your biggest weakness. The only way to extend the platform at the moment is to self-host and write code.
2. Avoid baking crazy logic into the system now that you'll be unable to fix later *cough* SF 'standard' objects *cough* that will behave in very weird ways.
2(a). Person Accounts look like a good idea. But, they aren't; and never will be. They just create a lot of complications later when someone gets married or starts a business.
Hey, just seeing this thread now. Agreed!
We've started a year ago and have done probably just 10% of what is needed to really get to Salesforce.
We need (1) a flexible data model, (2) a flexible layout, (3) code execution.
We've done (1) but have yet to do (2) and (3) this year.
Next step of the plan is to let people build and share apps that leverage those 3 blocks, that's where open source will really shine!
Can you elaborate on what "a flexible layout" means in this context? Is this data layout, i.e. serialization format(s)? UI layouts for displaying values in the data model? Something else?
(We too are in the "let people execute their code on our servers" space; providing a flexible data model seemed to have been key)
Oh nice that you saw this (even though the post was flagged only a couple minutes after launch, not sure why). Thanks for your reply!
We have a model with 1-schema per tenant + we can create a dedicated Postgres user, so we don't have the same security risk multi-tenant apps would have. And I felt like passing SQL was the right long-term direction with text-to-sql LLMs. But I get your point.
I guess what we're looking for is more "open source frontend lib for embedded analytics" than just a query builder then. This does not exist but seems like a lot of work to build.
The shift to commercial open source with a hybrid financing model is what's driving the trend. It makes it possible to get enough funding to build high-quality software while bringing the costs down for everyone.
We're doing just that with our own CRM [1]. It couldn't have been a side-project as you need thousands of engineering hours to build something decent. But with only a few millions in engineering spend, we'll have something that is genuinely as good as the products from billion dollar behemoths.
Open Source software will never be able to monetize as well as closed-source. We might only capture 10% of the value we create. But being open source inherently creates strong network effects that tends to push towards a limited number of winners, and the addressable market in CRM is so big that it's still possible to build a multi-billion dollar company while massively driving the costs down for everyone.
It's kind of like the Prisoner's Dilemma: If every company keep their software proprietary, they can all make moderate growth/profit. But if one goes open-source, they could attract a large community, drive innovation, and potentially reap long-term profits while reducing the overall market size.
Yes that’s why we created this. For my previous company I couldn’t find anything I liked. I wanted something built with modern technologies and by people who care about design.
There are still a lot of things we need to develop to be at feature parity with big players but we are shipping fast and we will get there!
It’s already a good CRM for basic tasks like tracking contacts and opportunities. It’s stable and mostly bug-free. Next month we will ship custom objects and the API, then email integration. And next step is to make it truly extensible (right now your best option to do something truly custom is to fork it which obviously isn’t great).
I like that you signed up just to comment on this. It probably means we're doing something that matters even if you think we don't do it well :)
We'll work on a real demo environment with a lot of records, we just haven't prioritized it yet. Right now it's not really a demo environment, but a real account that happens to be provisioned with a few example records. Putting more records wouldn't really make sense (you have to delete those records manually to start using the CRM).
> Putting more records wouldn't really make sense (you have to delete those records manually to start using the CRM).
I would assume that their point is that this would demonstrate that the system doesn't break down if you fill it with more than a handful of entries. Would be a shame if it grinds to a halt after using it for a few years.
The vision is definitely to have something extensible and more powerful than force.com ; we aren't there yet because we need to build strong foundations before that. We already try to separate our business apps from the core engine in the code base to learn what will be the right api and get ready for that next step when it's time.