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'.
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.
We use Odoo and love it. It would take moving mountains to get us off of it (short of predatory sales/pricing/licensing shenanigans anyway). It is fantastic and truly one of my favorite pieces of software. But man, does Odoo have a convoluted ecosystem. There’s no one place to learn about the product and if you self-host then the documentation might as well not exist for the small number of aggravatingly undocumented adjustments you might need to implement to get it working. They have weird and officially undocumented design decisions that can end up wasting a lot of your time if you don’t have the benefit of having read sometimes years-old public Github issues.
It’s not just self-hosting either. Their documentation covers the basics of key modules, and their video training material is great for functional insight. But it’s clear they don’t have anyone who is able or willing to effectively foster a coherent product-wide strategy around documentation, training, and similar enablement must-haves. Ironically, I think the fact that they run so much of their infrastructure on Odoo itself is part of the problem in terms of implementing a better strategy. If you buy an EMR, you won’t use it for HR just because it’s geared toward managing data relating to humans.
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.
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.
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.
> Salesforce is a generic application platform today
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.
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.
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.
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?
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 :)
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.
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.
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'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.
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.
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.
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.
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).
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 ?
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).
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!
> 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.
> 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?
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.
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!).
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).
> 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.
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!
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.
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.
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.
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.)
I initially disliked Go as well, but it's a language that can only be truly appreciated when you start using it. Many of its advantages come from from its simplicity, explicitness, fast compilation speed, single executable binary, and some opinionated choices made by its authors. Unless you're working with a legacy system, Go (or Rust) is the preferred choice nowadays for distributed systems and system softwares (Kubernestes, TiDB, traefik, to name a few). It's also the default choice for numerous internet companies like Uber, ByteDance, and Monzo.
Here is a survey if you'd like to participate this year, but I don't think it will significantly alter the results.
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.
I hear you, and if you're using anything other than PyCharm (or Eclipse with PyDev back in the day) then that's what you'll find. But try it with PyCharm, it works flawlessly with near perfect refractor on million line of code python code bases.
> 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.
Perhaps your experience with them was a long time ago. I agree that working with dynamic typing languages can be painful, but Python has had type hints since version 3.5, and JavaScript has Flow, or you can use TypeScript.
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).
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
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.
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.
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.
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.
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.
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'.