That’s a very cynical way of looking at it. I’ve been working with open source software for 30 odd years now, and I’ve never paid a single cent for linux, ubuntu, nginx, mariadb, python, nodejs, redis, git, etc. Does that mean I don’t value them? Maybe, but it sure doesn’t feel that way. Does Frappe measure how much it values these software platforms by the amount of money it pays to its publishers?
If open source has a single lesson, it’s that valuing something and paying for it are two completely different things. That doesn’t mean there’s no way to make a living from open source, however. It just means that nobody’s going to make a living simply by fact of being a publisher. Instead, it’s about finding the intersection of a venn diagram, between (1) the people who want open source software to be good, and (2) the people with resources to do something about it.
I agree, and let me add a potential point of reference.
Again, there are more than one ‘class’ of open source software.
the ‘tool’ class like python, etc.
and the ‘public production’ class like Ubuntu, Mozilla Firefox, and ERPNext
If you spent much of your life as a developer of ‘tool’ class software, you may not be as broad minded as the people that specifically set out to create ‘public production’ class applications.
Developers of ‘tool’ class software tend to see the end products value in how efficiently they can use it to perform other interesting tasks. Hopefully they have a monetary goal in mind with whatever they are using their new and improved tool to create. My observation is that most do not have that goal in mind. They are more interested in the creation process, and when they get to the point of having something ready to launch, they struggle with how to ‘monetize’ it. In many cases they flounder into the ‘open core’ concept and expect to have everyone suddenly start adding dependent applications to their core as a way to ‘sell’ software that originated as open source.
Developers of specifically ‘public production’ class software (like ERPNext) are usually developing with a monetary goal in mind from the start. In the case of ERPNext, I had always assumed it was to be able to sell the supporting service with cloud servers and an active user base that will always need questions answered or help setting up some function. Maybe also training the endless supply of new users. If they do not have a way to sell that constant support stream, then they are relegated to selling advertisements (think Android Apps).
It appears (at least on the surface to me) that the ERPNext/Frappe development teams either did not have their monetary goal fixed at the beginning of their project, or they have had so much turn over in the core developers that they are now dominated by the ‘tool’ class mentality and have lost their way toward a monetization plan.
Will they venture down the road of ‘open core’ and try to start selling bolt-on application functions? Or will they find their footing in the support service end of the spectrum?
Sadly, if you start looking at the history of open source (in the public production class) that has tried to convert their project to an ‘open core’ format, you will see that is also the time they lost their momentum and allowed other software to pass them by in creativity. This is a sign of desperation (IMHO) from folks at higher levels of the developer team that have never thought through the business end and jump on open core because it seems easy. However it appears to be a move that begins to alienate their base users and usually turns them into long term ‘liabilities’ as they interact with the rest of the user community.
I really believe that in order to keep an open source project on track toward a monetization goal, the team must build that discussion into every aspect of their work and keep it in every meeting agenda or else it gets lost along the way. Sometimes, once it is lost, it never gets back on track because too many new large personalities joined the team during the time when money was NOT being discussed.
If you want an open source project to eventually make money, then you must make that the FIRST priority and plan everything else from that perspective with a definite plan in mind. Unfortunately, many developers do not also get majors from business schools.
I agree with a lot of what you’ve said, and I definitely get what you’re arguing here. I’m not sure that I’d go quite so far, though. A lot of projects figure this stuff as they go, and there’s nothing inherently wrong with that. The risk, of course, is that the core team burns out along the way.
My biggest gripe about SAP/NetSuite/etc has always been the design: it’s software that seems to have been written by the sales department. ERPNext has a vastly superior architecture and API. Unfortunately, very few CEOs care about technical design, even if they should.
That may be where your “tool vs. public production” distinction comes in. My company recently shifted all of our processes from Apache to Nginx, for example. It was a sizable project, but probably fewer than 5% of our employees even know it happened. We’re still just exploring ERPNext at this point, but in that regard you’re right: ERPNext probably has a lot less in common with Nginx and a lot more in common with integrated platforms like Drupal.
A great example of open source project of similar complexity level to ERPNext which is also able to monetize it is Jenkins. Which started as Hudson - Continuous Integration framework under Sun Microsystems and forked out to be an independent project as soon as Oracle acquired Sun. So by analogy to Frappe org there is a company called CloudBees which contributes code and provides Jenkins related services. And they are doing great. I doubt that Kohsuke (the creator of Jenkins) had monitization in mind from the beginning, but, if I remember it right, as soon as Jenkins (Hudson at that time) became hugely popular, there wasn’t a question of how to monetize it due to high demand for services and customizations.
One last point… (and the reason I believe ERPNext/Frappe are dominated by ‘tool’ class developers)
If it were truly a public production mentality, then one of the first things they would have developed several versions ago would have been a user friendly GUI report builder that did not require developer knowledge to use it.
There are several other clues you can find as you learn the application, but ultimately ERPNext is still the ‘technical perfection’ dream of it’s developers and not really a great user application yet.
See this topic for how they probably got there:
When the team gets serious about making this a user centric product, you will be able to tell by the quality of the releases that users regard with praise.
Maybe similar in complexity, but still a ‘tool’ class project. It it was not designed for the general public to use, it was designed as a tool for developers to use to develop even better stuff. Not really the same, but it is a good point about how even tool class projects can get to a monetization model.
You will be demanded to fix your software. You will be shouted. Sometimes, the line may be crossed, and you will be abused. “How dare you not (use your free time to) fix this ultra high priority bug that is affecting me?” or “This is an absolutely basic feature! How is it not implemented yet (by you on your free time)?!” or even “You made me move to Software Y, and you need to win me back” are going to be realities you will have to face.
I think maintainers have to have a thick skin. While I have been an active contributor to this forum, this demand on how I should spend my free time does not makes sense, and drains out my energy. So maybe I am stepping back a bit.
Every project has its own culture. We have kept the code and documentation around the project 100% free its upto the others to follow.
I don’t think these kinds of statements are helpful. The core maintainers allocate their resources according to their sense of what priorities should be. You have different priorities. There’s nothing wrong that, of course, but it’s unreasonable to expect that other people should necessarily share your view about the future of the platform.
When you talk about being “serious about making this a user centric product”, for example, you’ve got a very particular kind of user in mind. The users I work with, meanwhile, have literally zero interest in GUI-based report builders. These are not development questions, in other words, but strategic ones, tied up in much larger debates who and what this software is for. Untangling that particular ball of wax is what a governance structure is for, and over the last year in particular the maintainers seem to be taking bigger steps in that direction.
In the meantime, if you consider a GUI-based report builder essential, I’m sure there are others who agree with you. It sounds like great opportunity for a community-led app.
Not sure what you mean by calling it tool class project. It helps software development companies reduce burocracy and streamline processes eventually releasing more resources towards reaching main organization goals. It has a transformative impact onto adopting organization. Same potentially is true for ERPNext but for more general target audience. Don’t see the point in separating tools/public production classes on the basis of knowing or not knowing in advance how to monetize service/product either. IMHO said distinction just depends on whether there are already similar products/services on the market which you can draw monetization parallels with or not, otherwise you have to find/create a way to monetize. Which in fact may change over time like for instance in case of Mozilla, first from selling CDs and support then from search engine partnerships.
The main difference I see between open source project for general public as opposed to the project targeted at developers is that developer community can contribute more to the the core of the system.
Ahh… now we come back around to the actual topic of this thread. Hopefully everyone can follow the logic here.
Why does it not make enough money?
It is true that my views are just that… mine.
However, if you take time to look at all of the ‘self advertising’ the ERPNext team publishes, you will see that they are marketing their product to accountants, warehouse managers, and small to medium manufacturers among many others. I just picked out the first three.
The average college educated CPA did not also take website design, programming with json, html, or xml. Yet accountants are the developers chosen market. They construct their ads directed to those individuals. However, it is impossible for an international software to be able to create the standard reports required for every location on earth. So unless you happen to find the one or two reports you need on a regular basis already built in ERPNext, you would have to hire a developer or programmer to do the rest of the work. This is where a simplified report builder would dramatically increase your user base and therefore your monetary returns.
To me that indicates the developers are either lying to the public about their package, or they never had the general public as their intended target in the first place. Or I guess there is a third possibility. Maybe they are so stuck in their ‘tool’ mentality that they truly cannot see that they are missing their mark. Yet they expect to be able to make money with this software.
So, if they really want to monetize this, they need to make sure they can hit their target market. Clearly they are concerned that the project is not generating enough funds to allow it to grow. So instead of looking at what monetary model to use to get the ROI to look better, they might want to be looking at why their user base is not growing at the pace they would need to achieve their goals.
The same is true when it comes to a small manufacturer. There is much self created praise in the advertising for the ability to handle manufacturing businesses. Manufacturing businesses have grown in huge percentages over the past few years and yet, ERPNext is fairly stagnant in it’s ability to attract new manufacturers to it’s user ranks. This would be a huge potential for monetization. The problem is when any manufacturing manager worth their paycheck actually tries to use ERPNext to run their manufacturing module, they almost immediately stumble into the Scrap Management hole. A very sore spot with manufacturing users since at least mid 2015. Just check the forum yourself to see this. There are even some developer posts in the advertising indicating there is a scrap management module. The reality is you are expected to be a proficient programmer in python, json, etc. and write your own fix for this otherwise simple function. Again, another indicator that the developer team is either completely ignorant of the problem (because they can program their own way out of it when they need it), or they really are not targeting the software toward the users the originally claimed to be concerned about. They are targeting other programmers and not actual users. So, they should NOT really be surprised that the monetization model is not producing the revenue they were hoping to achieve.
I could go on with many more examples, but it should be fairly easy to see the diachotpmy here. The way the developers and the foundation talk about their software does NOT match up with the user experience. In the few cases where it does, you will find the ‘users’ have either their own IT group to fill in the missing parts, or they are developers themselves.
How can you expect to grow your monetary goals with this software if you never go back and make it user freindly enough to grow the installed base.
The only thing they are accomplishing at this point is discouraging many of the very users they claim to be helping because of issues like the 2 I described above.
You must understand… I am a LOUD voice of PRAISE for this software because I use it in my own business and set it up for so many other businesses. I seek out those potential users that have the money to pay for the development of the pieces they need in order to complete the package and I pair tha with 3rd party developers to make everyone happy. I love it!
My only point here it so try to shine a light on where the monetary opportunities are being lost. You cannot hype a product and then NOT have it live up to the description.
Why pour tons of resources into adding new domain types and more complicated permission structures if you cannot even fix the important parts of your core product? You cannot keep playing in the ‘developer perfection dream’ zone and expect that just because you put all this effort in the dream that you should also be making more money with it. The way to grow and make more money is to meet customer needs, not ignoring their concerns.
Can you think of any company in the world that made money by ignoring their users needs?
That is how the ‘tool’ class developer mindset is different from the ‘public production’ devloper’s actions. One only ‘thinks’ they are doing what is needed to make money, and the other is actually making money.
I am sorry that some of you take offense to my characterization. I am trying to provide a view point of the general public user that is evidently being missed in this project. Once you run out of developer users to buy into your project, you have to start looking for regular general public users in order to grow it into the money maker you wanted. You cannot get them unless you start paying attention to them.
Simply put, a ‘tool’ class developer is generating software that only applies to other developers and assumes they have the base knowledge to make use of it. Whereas a ‘public production’ class development team is writing software directly aimed at end users that are NOT expected to have developer knowledge in order to be successful in using their product.
Quite honestly, ERPNext looks like a package put together by a ‘tool’ class development team that was trying to target a user they were unfamalier with (i.e. general public users). Otherwise the missing pieces to make it user friendly would already be in place with a project of this age.
Final example of why the ERPNext/Frappe team is not able to grow their user base.
The Frappe cloud groups is now supporting v11.
However, there are still so many fixes to be made to v11, that they are constantly making updates to it. Some of those updates break previously working functions.
The Frappe cloud team then inflict those changes on their installed clients and cause them further harm.
This is NOT the actions of a ‘public production’ class team.
This is the actions of a developer team that is more then happy to have a group of ‘paying’ users at their disposal to use a guinea pigs for their patches!
Is it any wonder that you cannot grow the Frappe cloud model as fast as you wanted?!?
If you really wanted to have a viable and stable user base that would be happy to pay for the service, you should only be deploying a version to the Frappe cloud that doesn’t change every week. Maybe the last v10, or maybe a v11 that never updates. Regardless of how you look at it, you are doing more harm to your future growth by continuing with this model.
But you cannot question WHY the project does not meet your monetary goals and at the same time complain that it is eating up your ‘free time’.
If you want to have the conversations about monetization, you must then also look back at the factors that are affecting that goal.
You cannot have it both ways.
It is either a project for the love of it, or it is a project to make money.
The first allows you to have that step back you espouse. The second demands that you pay attention to the causes of slow growth.
You must pick one.
After all, you posed the question at the top of this thread. You cannot be wishy-washy now. You are either concerned about the revenue stream or you re not. You need to choose the path for your project and be prepared to deal with everything related to the decided goals. But you cannot straddle the fence. This project is far to mature to be trying to have it both ways.
Once you start talking about bigger monetization goals, you have left the ‘for the love of it’ part of your project behind and the conversation shifts to why it is not making money. So you will need that thick skin.
I don’t think ERPNext is just a ‘tool class’ project, it has lot of functionality and if you are willing to adopt certain workarounds, you can handle scenarios like scrap etc. This is true of not just ERPNext but any ERP. Every ERP has it’s genesis and for ERPNext it is make to order.
Open source in it’s pure form never starts with the motivation to make money but eventually I think good open source projects end up making money either for themselves or for the community around them or both.
I agree on stability being compromised for adding features sometimes but again the community always wants more features
I’m afraid you’ve misunderstood the meaning of my post in a fundamental way. You’ve written a lot of words here about why you’re right and I’m wrong about this particular thing, but none of it’s important. It’s not important because, at the end of it all, neither your opinion nor my opinion are the ones that count.
That’s why I phrased my response to you as I did. When talking about your earlier statements, I didn’t say that they weren’t (at least from your perspective) factually true; I said they weren’t helpful. That’s an important difference. When people get invested in open source platforms, the particular set of problems they face often feel very urgent. That’s a great thing, in a way, but it often leads to situations where people who don’t write the code tell the people who do what they “must” decide.
That’s not helpful. It’s not a matter of “taking offense”, as you say, but something more fundamental about the nature of open source. It isn’t a democracy. Instead, you vote with what you create.
This whole thread was started on the premise that the project may not be meeting it’s monetary goals.
Open Source projects are usually started because of a love for the topic and the concept (regardless of the projects end goal).
However, when the ‘project’ then starts moaning about not making enough money in the intended revenue streams, the developer team has at that point turned their attention away from ‘the love of the project’ focus and begun to ask hard questions about WHY it doesn’t make enough money.
At that point ALL interest is no longer on what makes the developer happy from a working or contributing perspective. It has now turned the corner on what to do to make money.
If you want to make money, then you MUST take a hard look at the things that are LIMITING your potential to make money.
At that point everything is on the table and sometimes what might seem blunt or harsh, is just the truth that might be missing.
So, yes, my points are helpful as well as others that attempt to look at this from a business perspective and offer their thoughts.
After all, this has now become a business issue, and not a feel good issue and not by my doing, but by the developers new interest.
When the perspective changes, so does the advice needed to succeed.
At the very beginning of this thread, the author tries to paint the monetization of opensource software with a political brush. I refused to bite on the politicization of the topic and instead address the core reasons for the premise of the topic…
Making money with your project.
For example, the author proposes the following:
In this, the author ‘assumes’ that everyone reading has the same progressive concept of how the world works and that capitalism cannot help them find a solution.
The author presumes to imply that:
“You cannot make a living making music.”
Yet there are more millionaires in the music industry than you can count.
“… or art.”
Yet we have thousands of famous architects designing the most beautiful buildings in the world, bringing them to reality and filling them with equally beautiful paintings. photographs, and sculptures from their local populations.
“You can’t even make a living taking care of children.”
Yet there are tens of thousands of very profitable daycare centers around the world. There are even daycare centers for senior citizens that are not only profitable but enriching the lives of the people they serve.
Because of these flawed assumptions, I tended to focus on the facts and realities of making money with a project.
Here the author starts by almost asking the question of “why can’t I make money with this?”
The author then slides into politicizing it with a biased set of assumptions as detailed above.
The CORE of the issues is that the author and the developer team needs to drop the pessimistic, defeatist, progressive attitude in order to focus on the right path to monetizing the project and keep it going. There are business answers to the situation but you have to be open to them.
Everything I have commented on here is about how to get to their money goals. However if you start out the thread with a progressive defeatist tone, then it becomes difficult to properly frame the issue.
when the ‘project’ then starts moaning about not making enough money
I’m sure you have a lot to contribute to these conversations, but when you start writing things like this, I have a very hard time taking your words as intended in good faith. Nobody’s “moaning” here, and I wish you would try to find more constructive ways of making your points.
The dichotomy you’re creating between the developer perspective and the business perspective is a false one. I work with mid-sized companies. That typically means 200-1000 employees, and at least $250M a year in revenue. Maintainer-led open source is very much alive and well in that world. Likewise, when I say that the creators are supposed to make the decisions on design priorities, there’s absolutely nothing idealistic about it. It’s a very well established strategy of governance, and even the corporate boards I’ve reported to (composed of people who have never written a line of code in their lives) increasingly understand that.
The ERPNext maintainers are still in the process of figuring out their long term governance structures, and they’ve still got a lot of work to do on that front. Nobody’s doubting that, I suspect least of all them. Maybe they’ll figure it out, and maybe they won’t. Either way, the jabs and insults don’t help anyone.
