ERP implementer for the past 20 years. I'm an operations specialist rather than a manufacturing specialist, but do have manufacturing clients whose systems I have helped implement and continue to support alongside our manufacturing specialists.
I will preface this by saying that my initial thoughts are based solely on the website and documentation (which is fairly sparse and includes few screen shots or examples of how the software is actually used). I did not and probably will not* sign up or install this software to review further, so I'll fully admit that I'm probably missing a lot and likely not giving a completely fair review.
My first impression, looking at the documentation for the system and how some of the actual ERP-related functionality is described, is that barbinbrad is an expert in software development with a lot of experience writing software to support ERP systems, but has a fairly narrow understanding of how all of the functions of an ERP system are supposed to work. To use a tired old analogy: this can be likened to a highly-skilled heavy-duty mechanic and a veteran long-haul truck driver deciding to start their own trucking business. Between the two of them, they know a ton about the mechanics of driving and maintaining large tractor-trailors and may even know how to keep proper driving and service logs and how to train apprentice mechanics and new drivers. But their knowledge on all the other minutia of running a trucking business is just enough to give them false confidence that they know the industry. Without seeking outside help, many of these startups fail because of mistakes made on these details.
There is a lot of detail on how to set up the technical parts of the system (there are definitely two things that are abundantly clear: the database back-end is postgres and the software is open source), there is some good developer-related information on API calls and such. But the documentation on how it all works is very sparse and the functionality that is described appears very rudimentary. Accounting functionality is very simplistic (limited chart of accounts definition, unclear link between subledgers and the G/L, no apparent EFT functionality, limited multicurrency/revaluation capabilities). Similarly, inventory, purchasing, and sales appear to be similar in capability to a basic Quickbooks system. A couple of more advanced manufacturing-specific features like MRP and routing/scheduling seem to exist, but MRP will only "suggest" order - users still have to enter them manually in the system, and it is unclear whether there is any linkage with general inventory planning or sales forecasts. Basically, it looks like the software can build a BOM, and it can help run most of the assembly steps for that BOM, complete with some very strong traceability and visual cues, but all of the other business functions surrounding that BOM are very limited.
To be clear, this is not meant as a direct criticism of barbinbrad or the software itself. The software has potential, and barbinbrad appears to have a lot of experience working on manufacturing ERP systems. What is needed is more guidance from people with the expertise on the "other side of the keyboard". Preferably people who have worked in ERP systems across multiple manufacturing industries.
This a huge example of a classic problem that plagues many (if not most) "non-tech"* open source projects. Developers who are immersed in a specific type of software can see what it is they're developing and get a very good idea of what the software does and how it works (according to the specs that they've been working on). So they go about building what they see as the "better version" of what they've worked on before. In the process, they often do solve some of the glaring individual problems they've encountered in the past, but they do so without understanding the bigger picture of what the system as a whole needs to do. ERP software especially is hard, because it is very complicated, used in many different ways (even by companies in the same industry) and have to support so many different facets of a business. The experts are not developers. They are accountants, operations managers, procurement and warehouse managers, production managers, payroll managers, and the C-Level executives who consume the information that ERP systems spit out. The people guiding development have to have expertise in these areas, not the developers. And in the open source world, this is where the subject-matter expertise is often lacking.
(couple of footnotes):
I'm not prepared to enter my credit card number to try it out, don't have the time to install it in my own environment just for a review, and already am a bit annoyed that I had to enter my work e-mail address just to get to the point where I realized I'd have to do one of those two things to get anywhere.
*By "non-tech", I mean that the audience for which the project is intended is a non-technical audience - ERP systems, despite being very sophisticated software with a lot of server infrastructure involved, are systems meant to serve very non-technical people.
As a fellow ERP/MRP author/founder (PartsBox, specialized for electronics manufacturing), congratulations. These kinds of systems are very complex, much more so than it seems from the outside. Many people tend to think: "I could whip this up in a weekend." I also thought so 10 years ago when I started writing my own :-)
I do wonder about the value proposition of open sourcing the system, though. Apart from believing in open source and trying to do some good in the world, are there any practical reasons for you to maintain the system as open source? This is something that is very costly
founder here. extremely accurate comment. we had a customer send us this website recently. they said "we think you need a better website, we made this with claude"
Why would you be embarrassed? when bootstrap came out it took like 10 years for websites to start looking "not bootstrap". These people are just looking for something to complain, maybe GP is a designer and it's running out of work to do... As long as the product is solid...
I understand the need to make money, but hardly any open source software is free anymore even if you host it yourself. And this one doesn’t list the price which feels kinda cagey (get a license links to book a sales call).
It’s nice that it’s open source, thank you. I just wish that Mattermost et al didn’t open Pandora’s box with this one.
How do you handle the challenge of getting self-hosted customers to upgrade? I'm guessing a lot of self-hosted instances end up running fairly customized versions of your product.
Disclaimer: I'm the founder of Bonx (bonx.com). Genuinely curious — congrats on what you've built, and best of luck!
ERP implementer for the past 20 years. I'm an operations specialist rather than a manufacturing specialist, but do have manufacturing clients whose systems I have helped implement and continue to support alongside our manufacturing specialists.
I will preface this by saying that my initial thoughts are based solely on the website and documentation (which is fairly sparse and includes few screen shots or examples of how the software is actually used). I did not and probably will not* sign up or install this software to review further, so I'll fully admit that I'm probably missing a lot and likely not giving a completely fair review.
My first impression, looking at the documentation for the system and how some of the actual ERP-related functionality is described, is that barbinbrad is an expert in software development with a lot of experience writing software to support ERP systems, but has a fairly narrow understanding of how all of the functions of an ERP system are supposed to work. To use a tired old analogy: this can be likened to a highly-skilled heavy-duty mechanic and a veteran long-haul truck driver deciding to start their own trucking business. Between the two of them, they know a ton about the mechanics of driving and maintaining large tractor-trailors and may even know how to keep proper driving and service logs and how to train apprentice mechanics and new drivers. But their knowledge on all the other minutia of running a trucking business is just enough to give them false confidence that they know the industry. Without seeking outside help, many of these startups fail because of mistakes made on these details.
There is a lot of detail on how to set up the technical parts of the system (there are definitely two things that are abundantly clear: the database back-end is postgres and the software is open source), there is some good developer-related information on API calls and such. But the documentation on how it all works is very sparse and the functionality that is described appears very rudimentary. Accounting functionality is very simplistic (limited chart of accounts definition, unclear link between subledgers and the G/L, no apparent EFT functionality, limited multicurrency/revaluation capabilities). Similarly, inventory, purchasing, and sales appear to be similar in capability to a basic Quickbooks system. A couple of more advanced manufacturing-specific features like MRP and routing/scheduling seem to exist, but MRP will only "suggest" order - users still have to enter them manually in the system, and it is unclear whether there is any linkage with general inventory planning or sales forecasts. Basically, it looks like the software can build a BOM, and it can help run most of the assembly steps for that BOM, complete with some very strong traceability and visual cues, but all of the other business functions surrounding that BOM are very limited.
To be clear, this is not meant as a direct criticism of barbinbrad or the software itself. The software has potential, and barbinbrad appears to have a lot of experience working on manufacturing ERP systems. What is needed is more guidance from people with the expertise on the "other side of the keyboard". Preferably people who have worked in ERP systems across multiple manufacturing industries.
This a huge example of a classic problem that plagues many (if not most) "non-tech"* open source projects. Developers who are immersed in a specific type of software can see what it is they're developing and get a very good idea of what the software does and how it works (according to the specs that they've been working on). So they go about building what they see as the "better version" of what they've worked on before. In the process, they often do solve some of the glaring individual problems they've encountered in the past, but they do so without understanding the bigger picture of what the system as a whole needs to do. ERP software especially is hard, because it is very complicated, used in many different ways (even by companies in the same industry) and have to support so many different facets of a business. The experts are not developers. They are accountants, operations managers, procurement and warehouse managers, production managers, payroll managers, and the C-Level executives who consume the information that ERP systems spit out. The people guiding development have to have expertise in these areas, not the developers. And in the open source world, this is where the subject-matter expertise is often lacking.
(couple of footnotes): I'm not prepared to enter my credit card number to try it out, don't have the time to install it in my own environment just for a review, and already am a bit annoyed that I had to enter my work e-mail address just to get to the point where I realized I'd have to do one of those two things to get anywhere.
*By "non-tech", I mean that the audience for which the project is intended is a non-technical audience - ERP systems, despite being very sophisticated software with a lot of server infrastructure involved, are systems meant to serve very non-technical people.
As a fellow ERP/MRP author/founder (PartsBox, specialized for electronics manufacturing), congratulations. These kinds of systems are very complex, much more so than it seems from the outside. Many people tend to think: "I could whip this up in a weekend." I also thought so 10 years ago when I started writing my own :-)
I do wonder about the value proposition of open sourcing the system, though. Apart from believing in open source and trying to do some good in the world, are there any practical reasons for you to maintain the system as open source? This is something that is very costly
How does it compare to ERPNext? Feature-wise, tech stack-wise.
Should we just name this layout/theme "claude" from now on?
founder here. extremely accurate comment. we had a customer send us this website recently. they said "we think you need a better website, we made this with claude"
lol, wow. What else did they say?
they're awesome. we highly value their opinion. they were the ones who gave me the confidence to open source it
https://minimal.tech -- they build the whole stack from PCB to hardware to wiring to mechanical assembly to telematics software themselves
lol I had the same thought... embarrasing
embarrassed founder here. shipped an update to make it look less generic.
Why would you be embarrassed? when bootstrap came out it took like 10 years for websites to start looking "not bootstrap". These people are just looking for something to complain, maybe GP is a designer and it's running out of work to do... As long as the product is solid...
I understand the need to make money, but hardly any open source software is free anymore even if you host it yourself. And this one doesn’t list the price which feels kinda cagey (get a license links to book a sales call).
It’s nice that it’s open source, thank you. I just wish that Mattermost et al didn’t open Pandora’s box with this one.
you can run the community edition for free. there's enough in there to run a full manufacturing business.
How do you handle the challenge of getting self-hosted customers to upgrade? I'm guessing a lot of self-hosted instances end up running fairly customized versions of your product.
Disclaimer: I'm the founder of Bonx (bonx.com). Genuinely curious — congrats on what you've built, and best of luck!
most run on BYOC or managed hosting. but for the forks you can tell claude "merge upstream and fix the merge conflicts"
> merge upstream and fix the merge conflicts"
Is this software developed in that spirit - letting a probabilistic calculator randomly fix merge conflicts?
Sounds like a recipe for disaster. But then again, I’m not the manufacturer using this software.
But then again the original question seems strange as self-hosters have to manage their own upgrade by design.
Self-hosted upgrades can be tricky, indeed.
Looks good
One comment on the auto language translation: the french version is comically bad :)
I'd rather read it in english where the wording is (kinda, Claude is visible) more on point.
every ERP thread is a good thread!