Show HN: Openkoda – Open–source, private, Salesforce alternative
github.com
github.com
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'.
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/...
Not trying to be a downer, but I hope you're able to focus on improving docs in the near future.
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.
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.
Not is standard. You need to train your costumer in this interface you can simply contract employees who knows Salesforce.
[0] https://github.com/apache/ofbiz-framework / https://ofbiz.apache.org/index.html
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?
But yeah it is what most ERP tends to look like and then people make snazzy pages for specific sub flows for specific groups of users.
Odoo is doing quite well. It made Fabien Panckaers the youngest billionaire in Belgium.
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 :)
Is there something in particular that's flawed with Odoo's business?
Sad to hear about Odoo's disjointed approach to enterprise monetization.
Hopefully OpenKoda takes note.
It's kind of a tragedy of the commons.
In other words, community edition should work transparently to enterprise edition, so migration is simpler.
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.
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.
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.
Also custom integrations
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).
@dang, this person's spamming us with marketing links.
What's your approach to plugins, add-ons, and service partners?
This alone would be worth a blog post (assuming you don't have any non disparagements with CRM)
Openkoda Core is released under MIT license, so we have no means to stop you!
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.
When do you compete, and when do you cultivate?
Are some business sectors better at one versus the other?
I would leave corporations to work with corporations if they are really happy working together, but the world is much greater than that (them!).
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.
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.
We have a proposal review meeting with an Australian insurance company scheduled for this Thursday.
"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"
Understood, thank you for your answer and I wish you the best of luck!
It's just people taking memes seriously. Java is great and continuously improving.
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?
Here is a survey if you'd like to participate this year, but I don't think it will significantly alter the results.
https://survey.stackoverflow.co/2022#technology-most-loved-d...
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.
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 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.
Curious to know the motivations for choosing Java in this case.
We find modern Java to be ubiquitous, fast, and (still) super popular in enterprise environments.
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.
Also, Java programmers have the habit of using excessive abstractions that don't solve real problems.