So a CRM that replicates Salesforce APIs? Sales people don’t want a Salesforce FOSS version, that’s why they green light salesforce. It’s about trend not practical software. Only dev teams that have been implementing Salesforce for 5 years want a FOSS version.
In true enterprise fashion, they went with Java. Enterprise, confirmed.
Honest question, what's wrong with Java? It's performant, has mature libraries, good documentation, and supported pretty much everywhere.
There's plenty I'd like to improve but it's honestly in a very good shape. There's a reason enterprise picks Java - it's battle tested and there are enough quality developers around. Frameworks like Spring for webdev are top notch. Unless you've got a very specific reason to pick something else (python or rust or whatever) Java is the safe bet (along with c# but Java is an order of magnitude bigger I think).
It's just people taking memes seriously. Java is great and continuously improving.
It's not just a meme. The developer experience in Java is worse compared to some other popular programming languages like JavaScript, Go, Python, etc. The language is a bit verbose, and the compiling speed is slow, hence the development speed is slower. Java developers tend to overly abstract things, so the code tends to be unnecessarily complicated. The JVM also has a high memory footprint, the startup speed is slow, and it requires warming up the JIT. Some popular libraries and frameworks overuse reflection and annotation, they are nice to use but are nightmares to debug when issues happen. This is why GraalVM and Kotlin have been gaining popularity recently, as they aim to address several issues with the JVM and Java. The biggest strengths of Java are its ecosystem and community.
It is a meme.
I'm not sure if any of this is true and you seem to be contradicting yourself. Java is far less verbose than Go, and the compiler is leagues faster than kotlin's, graal's native compiler, probably most other languages, and I'm sure its faster than Babel. Javac doesn't do any optimizations, just emits bytecode. Why is it acceptable for Go to be verbose and kotlinc to be slow?
I'm not saying that Go or Kotlin is better than Java in all of those aspects. I'm just saying that Kotlin, GraalVM exists because Java, JVM have certain issues or limitation. For Golang, I'm just saying that the developer experience in Go is better. It's not just my personal experience, you can find the same result in any developer survey.
I clearly wasn’t surveyed. I don’t even like Java but I would need a an extender to my ten foot pole before touching Go. (Unless we are talking microcontroller embedded software, and I only could choose between Java and Go.)
The developer experience when trying to maintain a Python codebase the size of an average enterprise Java codebase is pretty...abysmal.
A python codebase never gets to the size of a Java one for the equivalent functionality. There's a reason the other ongoing mocking of Java is about its abundance of IAbstractGeneratorFactoryFactory classes.
This is true but Python codebases never reaches the feature parity of large Java code bases. I like Python up to about 10 kLOC or so, after that I tend to forget what is going on where, but in Java the IDE just knows what is going on where.
The developer experience in Java is worse compared to some other popular programming languages like JavaScript, Go, Python,
Wait, what?
Go, maybe.
But the dev experience in languages that are only able to catch errors at runtime, like Javascript and Python, are painful!
Looking at existing Python/Node.js codebases, half the automated tests are there simply to catch errors that statically typed languages catch for free, and even those tests aren't a match for a statically-typed language anyway.
I hate, hate, hate, HATE working on languages where my only options are:
1. Pray that no future code calls this function I just wrote with the wrong parameter types.
2. Write tests for all the callers of that function, to defend against some caller getting called with some combination of arguments that result in the function being called with the wrong types, while knowing full well I can't cover all possible cases like I would in a statically typed language.
Honestly, the first step in writing software is modelling the data types and structures[1]. In Node.js and Python you can model all you want but enforcement is left to developer discretion.
At this point in time, having done a few Node.js and Python backends, the dev experience in c11 is superior.
In order of least painful to most painful, in my experience of writing backends:
1. Go 2. Java 3. C# 4. C 5. C++ 6. PHP, Python, Node, Ruby, etc.
Those languages in #6 above are popular because they allow you to hodge-podge your system together.
[1] The second step is modelling the data flow, of course.
You can’t be serious comparing ASP.NET Core and EF Core to the abomination that is writing full back-end including DB access in Go or Java (assuming Spring Boot and Hibernate).
Should have been C# with ASP.NET Core and EF Core instead. Hibernate is extremely dreadful to work with and no one in their sane mind should even have the gall to ask users to touch it when better options exist. Spring Boot also performs very poorly against ASP.NET Core.
Also the kinds of people who know how to solve the kinds of problems that this sort of software deals with are likely to be Java programmers.
The biggest strike against Java at this point (IMO) is that you don't know what Oracle are going to do to make your life harder in the future.
There is nothing inherently wrong with Java, people just love to joke about it. To some extent, justifiably so. Not necessarily because of the language, more because of the common patterns in established there
There's nothing wrong with Java. It's old and boring, but most good tech is.
Anybody have recommendations for similar projects written in Python?
Curious to know the motivations for choosing Java in this case.
Python is significantly more resource heavy than Java. This is not a notebook or quick script. What would Python offer here?
Objectively, very little probably. Non-java shops tend to avoid it because java codebases have a reputation for being relatively complicated. Java is a great language though and it may very well be the best cultural fit for the type of org that _actually likes_ salesforce. They also seem to be publishing a docker image, so it shouldn't be difficult for non-java orgs to integrate.
Python is more resource heavy than Java for CPU, but not for memory. I am pretty sure that Java is more resource heavy for memory.
Also, Java programmers have the habit of using excessive abstractions that don't solve real problems.
Salesforce is customized in something called Apex, which is a dialect of Java. Would make migration/integration more convenient
Its like Java 5 mashed with some C# and then they've added their own syntax changes on top for custom salesforce things.
I would guess java was chosen for its high quality libraries, efficient runtime and its static typing, which enables easy and safe refactoring.
Exactly this.
We find modern Java to be ubiquitous, fast, and (still) super popular in enterprise environments.
[Odoo is Python based](https://github.com/odoo/odoo) and the 'core' modules are open -
Not providing any endorsement of the software nor can I say how the Odoo CRM/CMS compares to Salesforce. I've tried migrating a non Salesforce business to Odoo twice and haven't had success yet.
Yes, I haven't used this myself yet but I have been keeping my eye on this project for a while now, https://erpnext.com/ The Frappe framework that is the foundation of ERP Next can be used to extend the ERP platform or build standalone apps.
probably because java owns the enterprise space.
I can recommend https://github.com/frappe/frappe as a general engine, https://github.com/frappe/erpnext is a full blown CRM/ERP built on top of it
Salesforce's biggest value proposition is the partner ecosystem, which Salesforce has cultivated for like 20+ years. Some platform companies (Shopify comes to mind) cannibalize their plugin ecosystem by adding similar functionality to the core platform, but Salesforce deliberately avoids competing with software/services in the partner ecosystem. It's such a safe bet to build on top of Salesforce, because there's basically 0 platform risk and the technology is ubiquitous.
What's your approach to plugins, add-ons, and service partners?
I am not sure I'd agree with that - at one point Salesforce tried to buy my company, which was a best-of-the-AppExchange partner, and their justification for their (very) low offer was "that's what it would cost us to copy you". We sold the company 2 years later for 10x their offer, without a ton in the way of new revenue (our AppExchange ranking mysteriously tanked after we turned down their offer).
AppExchange ranking mysteriously tanked after we turned down their offer
This alone would be worth a blog post (assuming you don't have any non disparagements with CRM)
This was over a decade ago, so happily not something I'm feeling too sharply nowadays. It all worked out better in the end.
We actively look for service/technology partners, so if you want to build an application or extension on top of Openkoda for you or your clients we would be more than happy.
Openkoda Core is released under MIT license, so we have no means to stop you!
Should chat with the folks at https://news.ycombinator.com/item?id=40469773, your system could be a potential integration target.
Some platform companies (Shopify comes to mind) cannibalize their plugin ecosystem by adding similar functionality to the core platform, but Salesforce deliberately avoids competing with software/services in the partner ecosystem
When do you compete, and when do you cultivate?
Are some business sectors better at one versus the other?
Also insert the standard HN comment of “I can’t believe it’s [CURRENT_YEAR] and this functionality isn’t part of the core platform itself”
but Salesforce deliberately avoids competing with software/services in the partner ecosystem
It helps that Salesforce takes a huge slice from sales in the AppExchange.
This isn't entirely true, though. Salesforce does, at times, position itself against its own ecosystem. Their recent attempt at devops, no matter how feeble it is, directly competes against major players like Copado and Gearset. Mulesoft and some other ventures over the years should have theoretically relegated a huge multitude of sync apps to irrelevancy, if Salesforce had been able to execute better on them. They launched a payment system a couple of years ago that competes with some other top marketplace options. There are dozens of examples like this.
Last commit is 2 months ago? Are you still building it?
Yes, absolutely - the next release is scheduled for June, our current development cycle (which may not be ideal) is based on internal builds and testing before public release. The main reason is that there are e.g. insurance companies out there and whilst well, it's still open-source, we would not like to break anything for them.
Could you merge consistently and just cut stable releases on a scheduled cadence?
Yes, that's a good point - actually we were discussing this option (again!) just last week as we are cautious of not-that-frequent public releases.
Without it any contribution will probably be a pain to handle (and it's usually already not trivial to handle correctly ;).
Curious what testing is covered that you don't have automated as part of the CI?
These are mainly either integration tests with hard-to-automate third-party platforms and tests in more complex multi-tenant deployment scenarios.
There is also the Enterprise version which is developed in parallel with the open-source Core edition. Being a small team we just found it was easier to phase the release schedule.
Looks cool, but honestly what companies need a Salesforce like too but can't afford Salesforce force ?
I'm still have to host this thing somewhere, if I'm bootstraping a startup I might as well rely on Excel until I can afford Salesforce.
I like the project though. Best of luck.
That's a great question and we have great answers from actual clients - the repeating pattern goes as follows:
"We invested three years building this app, it's a booming success, but their user-based pricing is killing us"
"We can't run complex queries"
"It's too slow"
"We feel our data is stuck there"
"I want to own my code and my application"
"Why do I need to use APEX where we use Java and JS everywhere else in the company"
Okay so this isn't really for end users, it's not for Billy Bob's shop which needs to use Salesforce to track cupcake orders, but rather a vendor who would sell Salesforce like software to Billy Bob with some light customization on top.
Understood, thank you for your answer and I wish you the best of luck!
Honestly, I don't think there are many (revenue speaking) Billy Bob's shops using Salesforce to track their cupcake orders out there.
Bad example, but generally this is more of a framework for building Sales tracking software vs a direct Salesforce competitor, right?
Looks cool, but honestly what companies need a Salesforce like too but can't afford Salesforce force ?
Consider the example of APRA-regulated entities (banks and super funds who do business in Australia, for example): APRA's CPS230, which describes the requirements for business continuity, requires that you not lock yourself into a single vendor for a variety of critical functions, which means you need to explain how you'll keep your bank running if the relationship with that vendor is severed.
Depending on the function - for example, if it's considered "country-sustaining" or "bank-sustaining" - APRA may require you can do that in a matter of minutes through to hours. You may be very happy running Salesforce as your primary vendor - but if you want to be able to explain how you can run critical functions in the event of SF deleting your account a la Google, or a commercial breakdown, or whatever, having something that you could hydrate your data into, repoint your systems to their APIs, and keep basic functionality going is a very useful BCP to be able to demonstrate.
That's spot-on.
We have a proposal review meeting with an Australian insurance company scheduled for this Thursday.
Is this meant to be a drop-in replacement for Salesforce or just another CRM? There's a built-in advantage to choosing the tool that everybody uses and that's compatibility. If you look at 1000 data integration or marketing automation tools on the market, 1000 of them will have OOTB integration with Salesforce as a selling feature. Just to be realistic, building a better CRM won't be enough to replace Salesforce.
Nothing can be a drop-in replacement for Salesforce as it is designed almost exclusively to lock-in customers.
Salesforce is a case study in how rich dark patterns can make you.
Standardization can be good, but when the entire industry standardizes on the same processes how can anyone differentiate themselves?
Salesforce nowadays is more a universal, business application platform. Closed, proprietary, with user-based pricing model.
You already posted a Show HN like 10 days ago. Why are you posting again?
A post get more than 100 upvotes within one hour with no real source code and very few commits. I really doubt where the votes come from.
More than that: https://hn.algolia.com/?q=openkoda
@dang, this person's spamming us with marketing links.
Sadly, I doubt anybody's going to beat Salesforce and other crap such as Workday unless it's the same crap selling under a different name. Corporate people want their featurez.
The good news here is that they are many businesses out of there which a) need an enterprise solution (data protection, dedicated cloud, multi-tenancy), b) have complex data processing patterns (think: underwriting a property policy with cyclone/flood coverage), and c) don't have an unlimited budget.
I would leave corporations to work with corporations if they are really happy working together, but the world is much greater than that (them!).
While I agree with you, you're missing my point :) I was talking about procurement practices.
Maybe I'm missing it, but I don't see any links to any documentation beyond the surface level. The closest seems to be the technology page at https://openkoda.com/technology/ which seems to be aiming to sell to budget owners. Nothing wrong with marketing to budget owners, but if the selling point vs Odoo is 'it's easier to build your app on OpenKoda, then deep and detailed developer docs are a must.
Documentation is where a lot of the 'new' ERP efforts fall flat and the established players get right. As a purchasing manager, I want to be able to send the landing page to a lead dev and be able to ask them 'Do you think this will work better for upcoming new program XYZ?'. Without stellar documentation, the answer is inevitably going to be 'not sure'.
Thank you for your interest!
You may want to share the following docs as a good starter:
Short video: https://www.youtube.com/watch?v=gob4j072Isg
5-min guide: https://github.com/openkoda/openkoda/blob/main/openkoda/doc/...
Installation: https://github.com/openkoda/openkoda/blob/main/openkoda/doc/...
Thanks for the links. While they are great to get started with, it only highlights my point about comprehensive docs. The starter links are not enough to be able to answer any of the questions that need to be answered before making a bet on a new platform.
Not trying to be a downer, but I hope you're able to focus on improving docs in the near future.
How would this compare with something like goHighLevel?
Thanks for this question. I understand that goHighLevel is a closed marketing application platform, whilst Openkoda is an open-source enterprise application platform with pre-built application templates for a quick start in specific industries (now: insurance and realestate, more to come).
I was just complaining to my partner about the OG Salesforce… I feel extra inspired to check this out!
Thanks, I really appreciate your words!
When talking to our users (and clients - as we customize Openkoda for enterprise companies building their bespoke applications as well) so many of them are tired of Salesforce being: a) slow, b) limited, c) expensive (probably in this order).
Unless I hit governer limits immediately and have to pay thousands per megabyte of storage I wont consider this a viable replacement for Salesforce.
Are there any similar projects written in NextJS ?
Thank you for such an overwhelming reception, we truly appreciate your comments and been sharing your feedback back and forth on our Slack channels today.
If you have a strong enterprise use case, I would be super happy to schedule a quick Openkoda demo for you, including all the bells and whistles. Just share a short description and ping me at: mglomba@openkoda.com
We are still actively watching this thread and will try to address as many questions as possible.
Considering the tag line "Ready-to-use development platform that accelerates the process of building business applications and internal tools", I would think OpenKoda would compete with Retool more than Salesforce, no ?
Where can one find the breakdown of features on the free vs enterprise versions?
Well, there is Odoo. Which is pretty much exactly what OpenKoda is (FOSS ERP).
Odoo is doing quite well. It made Fabien Panckaers the youngest billionaire in Belgium.
Odoo's quest for monetization from open source has been a bit off-putting. I stopped using it a few quarters back due to that. Community and Enterprise are becoming too disjointed.
Thanks for the feedback. I've never used Odoo or OpenKoda, just read a lot about both and was impressed.
Sad to hear about Odoo's disjointed approach to enterprise monetization.
Hopefully OpenKoda takes note.
Point taken.
What would be a better approach?
Developers livings as monks and coding away in a dark delapidated castle surviving on their 4 donated cups of coffee a month while addressing 43,000 GitHub issues a month created by enterprise users who are working on commodifying the FOSS product into their cloud solution.
I can't speak specifically for Odoo's quest for monetization because I'm not a user; it very well may not be a healthy one. But in general I think FOSS monetization should be celebrated. Successful open source software businesses are generally good for everyone except for closed source software businesses.
Is there something in particular that's flawed with Odoo's business?
You are correct that monetization need to celebrated in OSS software. This being said, when your open-source version is but a shadow version of the enterprise version, then you're doing something wrong. That's what op was hinting at. I'd add if you want people to use and promote your software, you also want to make sure the documentation is usable. Though regarding Odoo, I would say the situation is somehow better in this regard than it used to be a 5~7 years ago.
Odoo is very open core, only a thin core is open source, whereas the vast majority of features are closed source.
That's not true. The enterprise part is much smaller than the open source part.
I'm not sure how you are measuring "size", but I was going on features.
Though I haven't done a formal review of which features are open and closed, and the xompany doesn't appear to document it anywhere, so I may be wrong. It seems like when I have looked into it in the past mostly it is a core framework with a few open source apps and whole bucnh of closed ones and the marketing doesn't clearly state what is open and closed.
Why would you make a definitive statement about a product without doing the research to make sure you know what you're talking about?
If you expect every comment on this site to be backed by a massive amount of reasearch, then you are in the wrong place. I have looked into Odoo several times, I was expressing my impressions of the product. Sorry if that wasn't clear in my initial comment.
Yes, I think you could compare Openkoda with Odoo, but well... we are nowhere near being billionaires ;)
Assuming you are apart of the team, I'm sure you know Odoo is 20 years old. So, I can't see why in time there couldn't be real competition.
OpenKoda and Odoo actually have sparked interesting questions for me about what an Open source ERP market would look like.
One conclusion I came to is as opposed to vendor lock-in as most ERP/CRM products try to enforce, it would actually be better to go the opposite direction (high compatibility with existing alternatives).
That said, have you guys considered allowing imports from Odoo into OpenKoda or other deep integrations?
In theory, I feel like you can run Odoo apps in OpenKoda, or even vice versa. The experience would be suboptimal but being split between two ERP systems is too.
We meet a lot of companies who are not happy with software solutions which are hard to modify.
It's not even about the cost, but about the limitations and poor development velocity.
These companies strive to build something innovative, they just find these closed platforms really cumbersome and slow to deliver.
When you start investing millions of dollars into a bespoke solution you really want to truly own it at some point. And this is impossible with closed and proprietary application platforms.
Where do you meet such companies?
Hey! As a Odoo dev, it’s really cool to see Odoo mentioned here. I was thinking the same thing regarding its similarities. I’ve always regarded Odoo as the “batteries included” ERP framework.
Here in Australia, Odoo is finally starting to hit some strides. We’re seeing more jobs in the market requesting Odoo experience, at our work we’re onboarding more customers than we have before. All said, I’m definitely going to fire up OpenKoda and brush up on my Java :)
Just want to say a friendly "hello" - great to see Odoo team here!
Salesforce is a generic application platform today, and this is how see it. Openkoda is not a drop-in replacement for Salesforce CRM, it is a useful replacement when you want to build your core business application a) retaining full source code ownership and ability to get any Java/JS team to work on it and run anywhere you want, b) without becoming dependent on technology and commercial limitations of working with big S.
Not is standard. You need to train your costumer in this interface you can simply contract employees who knows Salesforce.
I don't know much about salesforce, but if it is anything like every other "enterprise" grade software every installation is a special unique snowflake and you have to train the people on it anyway... Or more realistically you give them a 5 minute overview and let them flounder away a few weeks hating the infernal thing while they try and figure it out.
People don’t build applications on Salesforce because it’s a generic platform, they build on it because they need to integrate with the sales/crm process/data/etc.
Edit: To be clear, I’m not saying your idea isn’t good. There is tons of room for this stuff, but be careful in assuming the reason devs use Salesforce platform is because of the features. It’s usually not.
Source: I ran dev tools at Salesforce.
Indeed. So, if one is going to customize the hell out of it anyway, with most of the functionality being extensions, then why not just use a free software core ? Vertical solutions providers might find profitable to serve their customers and not pay the Salesforce tax.
There are people building for decades on things like Ofbiz[0] because it's flexible and it's truly open source. There are open and closed projects built on top of it, because it's a flexible business system which allow you to quickly model and built anything. I know a few companies myself that replaced Salesforce with a custom Ofbiz implementations and local companies that do the implementations.
[0] https://github.com/apache/ofbiz-framework / https://ofbiz.apache.org/index.html
That looks very interesting. I'm on the lookout for software for a bootstrapped biz.
A problem I can see my mugg^H^H^H^Hcolleagues flinching at that UI and thinking "this can't be very good" just based on the UI; like it or not, looks matter.
The themes I saw are basically color schemes. Has anyone done a more "modern" UI/UX?
Maybe some plugins could work with both.
Also custom integrations
Free Sales software is quite an oxymoron