In a bid to understand the ERPNext ecosystem better, we did a casual survey of what the current ecosystem looks like and what are the key areas and feedback that we need to understand. For a domain like ERP, the ecosystem is a key enabler of the product. Most end users will use the product through a service provider. Small businesses in manufacturing, small services and retails are still not “cloud friendly”.
Read the full post here:
Would love feedback as usual!
Thanks for taking the time to make the surveys.
The data driven big takeaways from the survey: (PS: coundn;t access the file"
(1) a significant group either feel ERPNext does not have the features (>37%) or the necessary ability to talk to existing system aka integrations (>31%) as the reasons to close deals.
(2) Only 7% feel that being free / open source is a barrier. So to say or conclude that people don’t understand open source model (yes my grandma wouldnt, doesnt…but she didnt take the survey and you cant conclude that from here) 
(3) Further, almost majority 48% think no training is a barrier to contributing back.
(4) A whopping 56% are asking for a “stable product” which is contradictory to the Need more features. So what does that mean? How can one ask want more features AND stability? The answer to that is in getting integrations. Let software that are great at doing something do what they do best (such as open cart, Magento …) and ERPNext communicates (integrates) to them & works WITH them and does what it does best.
These are THE big pointers/take-aways something that might be worth focusing on as a community.
The following observations I felt the need commenting upon.
[Another observation here is that users always feel “our business is unique” and there is a perception that unless you have feature X, this system is not useful to me. Sometimes, this is just an indication that the customer is not really “ready” for an ERP system.]
Yes, that is also their perception of ERPNext. And their “Preception is (their) Reality”, whether or not someone agrees. It is wrong to think that “they are not ready for an ERP system”. The current conclusion is saying between the lines “GROW UP! When you are old enough you can have ERP!”. 
Might be it is better said ERPNext is not ready for them. This conclusion will help us grow ERPNext. They dont need to be ready for us. We need to be ready for them. They “adopt” a system, system needs to “adapt” to them.
I am a firm proponent of putting responsibility for developing integrations in the realm of system integrators - integrations should be community developed and ideally contributed. And ideally, integrations would be apps, rather than part of core.
The foundation should work on stabilizing ERPNext and furthering features in the product itself.
There question was not who does what but about what is the barrier to… That is my interpretation.
We can debate the who. The answer we know. It is the community, and the foundation is part of that community.
Nor was i debating the architecture (app or core or where/how in general)
I think it’s important to note that integrations and features are separate things to discuss. Integrating with other apps doesn’t replace adding features to the core of ERPNext. I think the fact that so many users are calling for stability is because of historical issues that arise when new versions come out. There are often ‘teething issues’ when moving between new releases. These often get resolved in a day or two (sometimes much less), but that is significant downtime for a customer and if it happens at the wrong time, it can be devastating. ERPNext is moving in the right direction by adding a the UI tests, but I think that the demand for a stable product is a warning that ERPNext needs to do more to ensure that upgrades from previous releases to present go smoothly.
Here are some suggestions for making that happen:
I think what Rushabh is trying to say here is that there needs to be more education to these potential customers about the benefits of an ERP system. Just because a feature is missing doesn’t mean that an ERP system can’t add value until that feature is developed. My company started using ERPNext just for our timesheets and started implementing more of it’s functionality into our processes as they were developed (in the case of RFQ, which allowed us to really use the entire procurement system), and as we had the manpower to implement them. This education is the responsibility of the service provider.
Great suggestions and insights Ben.
By the way : my interpretation was from the data.
Further : It might be very well right that integrations and features are 2 different things. The survey asked the question and we got the answer. For >30% of the respondents : No integrations is a barrier. Maybe it was a wrong question. It got asked, and we got the answer. We might not like the answer but we cant argue with the data.
Maybe there needs to be another survey on integrations and one more on features separately and ask what is important to the community. Maybe that is the next step.
@Deepak_Pai This is a Foundation topic and a fair one for members, community and customers to be concerned about; but it is pretty nuanced, which seems to be something that you and Ben (and Jay in the comments to the post) are agreeing with. I do too. Rushaba is a stickler for the ‘right word’ and I think this is an example where we can in the community can do better to be more explicit.
That said, I think the ‘doesn’t have feature X’ crowd, is more of a ‘it’s not what I’m used to’ complaint. To some, an integration is a feature they can’t do without. There are some who have said that “without a QuickBooks integration, ERPNext isn’t worth it,” as an example. It’s also a benchmark in the ease-of-transition that can provide some comfort: I can try this new thing out without committing to it and go back to the old thing when I decide I don’t like it. It’s harder to get those people interested in investing manpower without the affirmation of some other brandnametrust that they recognize.
I think the kind of path that Ben described is really prescient and I’d advocate that it’s something to take up as a marketing strategy for service providers as appropriate. This seems like a great way to focus adoption on features that are native and tested as such, rather than integrations that are difficult to build and maintain.
Thanks for that. So the suggesting i am hearing is: the community should focus on an issue of marketing that probably 3-4% of the think is the problem. (Refer pie chart pls, what should be the goal?..) And ignore >32%? 
Again. I am not giving my opinion. Its the data that speaks.
Lack of features is a great indicator. Like i said before, Magento, OC… are so well built already. People are invested in it. Now, they want accounting. Letx say there are 2 competitors bidding for the job. XYZ vs ERPNext. The former has integrations and later does not. Who wins? Now let’s compare that to the survey results 30% of the people said its a deal breaker. That might have been 70% of the opportunity they got. Pretty significant.
End customers are not nuanced. They compare. They are black and white. They see others have it. We don’t. They want these to work together. All the other ERPs have realised it and building integrations. At the moment there are plenty of choices.
Erpnext could lose out. And the survey says 30% people actually can’t close deals. So we are losing out already.
PS : this survey was not “voice of customer” as much as" voice of integrators who also use ERPNext". While for the integrators, ERPNext is their bread and butter, for customers ERPNext is just an option. And they were not surveyed.
Anyway. I let go of the bone.
Most parters say that “don’t add features”. I think they say this because they want to monetise, its a perverse incentive. The biggest antidote to this is that we must keep pushing features at a frantic pace so that custom features keep breaking. That will be the only reason parters start contributing
Just posted this on another thread. This is relevant here too. I would love to see more people step up contributions. Right now 90+% of all custom development never comes back to the community. If majority of new features come at contribution, core devs can focus on stability. I think this is very much possible, and some devs like @Ben_Cornwell_Mott and @Chude_Osiegbu are already leading the way. I am pretty hopeful this day will come soon as this creates its own flywheel effect.
This is an interesting concept. I’ve seen a lot of similar “upgrade” issues everytime WooCommerce releases a major update. They’ve taken the step of basically screaming “BACKUP BACKUP BACKUP” before upgrades. Almost everyone is using a VM these days, and taking a snapshot is just so simple. The main issue I see with integrating a backup process inside the upgrade process is that updates of larger databases will take a lot of time as the backup script will need to be run.
Another area with broken upgrades I’ve seen is if users upgrade from let’s say version 7.1 to 8.4 - things break. Other systems have recommended upgrade paths. 7.1->7.2->8.0->8.4 (just a random example) which would make things go smoother. This would require an ability to upgrade to a specific point in time though (ex: bench update --frappe 7.2.3 --erpnext 7.2.4 or something like that).
We tried to implement this. @bomsy can share his experience doing this when he has some time. If I remember well, we can move forward easily but not always as easily if trying to “roll-back” from a more recent version to an older version. Issues were with with downgrading versions of package dependencies in pip etc. I think it’s worth looking at again though. The ability to choose the exact version of frappe, erpnext you wan’t to install is something important to have in my opinion.
This might be very helpful. Some implementations get underway and are in full use for several months when something happens that would cause them to want to re-install their system and restore a backup. This could be bad hardware, or any number of things. Right now, you are stuck with what ever latest version is available. That means their database restore will likely fail and they would have no way to get back to their previous running state. I don’t see “rollback” as necessary if they can select the version they want to install.
Hmm… I somewhat disagree. I am an implementer myself. Projects I have cooking in the custom area are being done to contribute back (mainly through MN Technique). However, the frustration of constantly having to keep up with “features” that are added only to find others now broken really makes it hard to get a stable version to call home. I believe their argument may be more related to the “Stability” issue. Yes, they will want to make some money on custom work they do, but it is hard to hit a constantly moving target core system with a custom app or feature.
Here is where the attention really needs to be placed. This had a majority vote, so it must be important. However, a “Stable” version is not mutually exclusive from “adding more features.” You just have to look at them both in perspective. If there were “stable” release points that could stay in place and supported by the “paid self-hosted support” then there would be no reason for people to be constantly chasing the next release. BTW, I am a subscriber to the paid self hosted service. I find it most helpful when I cant figure out something in the system that may not be well documented. I paid my $$ and I love the support. This would also solve the request to be able to install older versions because “stable” releases could be archived for install at any time.
Once you have something like that in place, then you can focus the next daily release candidate to have the new features you want to play with until you get them stable enough for then next “stable” release point.
This scenario gives you the ability to have very happy users because they can install and use a known release and see all of the know issues with that release. It makes the fear of failure subside for the prospective user and adoption of the system is less of a hurdle. It also leave the developer field wide open for contributions and testing.
The only thing the foundation would need to have ready, are SAFE and painless instructions to upgrade from one “stable release” to the next “stable” release with no down time. This of course would have to be in PRODUCTION mode and not developer mode. Real users are going to be using production implementations anyway.
Anyone wanting to start from a developer mode of a previously stable release would likely know they are creating another fork that they intend to support for their client. Those users would not be concerned about the upgrade ability to other stable core versions any longer and would be moving that direction knowing the risks.
These people are true end users and are likely to have little or no contact with developers, implementation contractors, or service providers. These people are most likely your small business owners. The family bakery, the corner barber shop, or the guy with the kiosk cart in the mall selling cell phone covers and chargers. It is true that they would need some sort of instruction, but it does not have to be in the form of one on one training. Just good documentation would fill that gap.
This documentation might even be “contributed” by other users that are already on s stable release version that they know is not going to change next week. The current lack of documentation coming from the community is because it is hard to hit a moving target. However, if users of stable versions were encouraged to add to a wiki documentation set for their favorite stable release, you might be surprised at how soon your stable versions could settle the ranting of agitated users. Maybe offer them some free hosting time for their own implementation if they add useful content to your documentation wiki.
At this point I believe you cannot look at your data and claim that it is contradictory. It really just needs to be put in perspective. If the majority of the survey participants claim they want stability, then you start there and see what other issues might be managed if you had a stable set of releases. That is kind of what I was trying to show you here. None of the complaints are cause for alarm, they can actually be woven together in the correct sequence to make the end product stronger if you can see how they are all related. Finding the common thread is the hard part, and everything else can be fixed from there. So if stability of the #1 issue, then work out your plan to offer stable releases and see what foundation that gives you for solving the other things in order of their ranking in the survey.
Similar to what I tried to do here, you will soon find the stepping stones from one issue to the next and they become easier to put to rest. Don’t take a hard line on all of them or any of them. Just focus on the worst issue first and work from there with an open mind and make your own path through them to get to a happier user base. Product adoption will surely accelerate once there is something to begin calming the user base. It just may not be adoption of the latest bleeding edge versions at first.
Hope this helps - BKM
I don’t believe you thought this through all the way. The people that are looking at the features that get added to ERPNext are coming to this system BECUASE of that very thing. Many are already using some sort of mess of daisy chained integrated 3rd party software to make a client happy. The more of these integrated pieces of software you have strung together, the more headaches you give yourself when one hiccup starts in one of the integrated links.
If the foundation feels they can take on a feature that would negate the need for a 3rd party integration, then by all means they should try to make that work. It is the complete harmonious system that users want. Those that follow the rough road of 3rd party integrating will be the FIRST to want that feature to be already built into the core system. Those kinds of clients are the ones calling me all the time looking for something to get them out of the finger pointing that goes with 3rd party bolt on software when problems arise.
Plus, for every integration you add to a core system, you take on a separate license with a separate fee each month or year. That alone drives them nuts. The less the core system does, the more it costs a user each month for the added headache of 3rd party stuff. The more the core system does, the better they would feel about annual hosting fees. I have to turn away clients that have huge spider webs of 3rd party stuff strung together. The time it takes to streamline those nasty systems is almost not worth the effort. Every now and again though they have had enough of the headache and they decide to pay for the labor to untangle their mess. It is never pretty, and it always cost more than if they had done it with a better system in the first place.
As it stands right now, the majority of my clients use a core erp system of some sort and pay to interface quickbooks. The only other interface they ever get is one to a barcode label printing package so they can label whatever they manufacture themselves. Having those two integrations is already stretching the patience of some users, but they put up with it because quickbooks is usually the standard bearer for their accountants, and labels are something they have to do to track what ever they make.
Anyway, just thought it might help to know that users of multiple integration links are not as happy with their systems as you may think.
BKM
Make that better system ERPNext 
Your observations match exactly with my own client base. For quite some time now I have take the word FREE out of my vocabulary. Even if it may be free to use a system like ERPNext, they would never be able to implement it on their own so the potential free aspect is never realized.
So my clients are invoiced for start-up costs, and annual (or monthly) support license fees. The only thing they know is that the total cost of ownership is probably much less than one of the commercial (proprietary) vendors and they get all of the customizations they asked for in the beginning. Most of the commercial vendors cannot provide that level of service and custom stuff as well.
Don’t say FREE, just say customized to your needs for this much money!
BKM