[Discussion] Open Source does not make money by design

1

Would love to get the community’s view on this:

http://www.ianbicking.org/blog/2019/03/open-source-doesnt-make-money-by-design.html

"I see an implicit assumption that makes it harder to think about this: the idea that if something is useful, it should be profitable. It’s an unspoken and morally-infused expectation, a kind of Just World hypothesis: if something has utility, if it helps people, if it’s something the world needs, if it empowers other people, then there should be a revenue opportunity. It should be possible for the thing to be your day job, to make money, to see some remuneration for your successful effort in creating or doing this thing.

That’s what we think the world should be like, but we all know it isn’t. You can’t make a living making music. Or art. You can’t even make a living taking care of children. I think this underlies many of this moment’s critiques of capitalism: there’s too many things that are important, even needed, or that fulfil us more than any profitable item, and yet are economically unsustainable."

1 Like
2

Not all good things make money - Strongly Agree. The world is far more complicated than what your or I feel should or should not happen in a given set of circumstances. People “should” take care of their health, care for the environment, be honest yadda yadda but not everyone behaves that way. However, from time to time, a bunch of circumstances can come together and result in creating something very unlikely or unexpected. Any large scale success has it’s share of luck and “right people at the right place at the right time” associated with it and ERPNext will be no different.

This is not a good or bad thing, it just IS. Accepting the reality one lives in is the first step to figuring out how to deal with it.

Points 3 and 4 in the essay in the “What can you get paid to do?” section seem to be most logical ways in which Frappe / service providers can monetize ERPNext while keeping the product open source.

4 Likes
3

Hi,
Open Source does not make money by design → is not true according to me.
Depends on your business model, ERPNext is an opensource, the question is how to monetize it right? you are not spending money getting contributions and feedback, feature requests, testing, security issues, documentation etc… are you able to pay 170 community member participated in the last release (11), here the value of opensource.

Money come from service usage, here ERPNext usage or SAAS model, not from the product it self, product is an enabler only, like Telecom companies they are selling calls minutes and not the infrastructure right (it’s an investment to sell call minutes later)?

Have a nice day
Nofal.

4 Likes
4

There were some good discussions at Linux Expo this month related to this. Steve WallI from Microsoft gave a nice presentation based on this article discussing the difference between projects vs products, community vs customers, the engineering economics of open source and some other interesting topics.

5 Likes
5

I do not believe that ERPnext fits into the group of open source apps that developers “roll their own” as a solution to something considered “only their problem” or to make their lives easier in their day to day work.

Even if it may have started that way years ago, it seems to have grown into something much more appropriate to fixing real world issues that goes well beyond the scope of only being useful to the developer group. I believe that makes the ERPNext project something more akin to Mozilla’s Firefox. It is a set of applications that provide real world value to every day people simply by using it. It is almost utilitarian, yet far more valuable to the end users than the connotation of the utilitarian moniker.

ERPNext, in my humble opinion, is something that does not really belong in the same conversation as projects like compilers or photo image compressors that might be used exclusively by developers in the first place. ERPNext applies more to a huge business audience. My feeling is it belongs in a very different conversation.

It has the potential to generate significant revenue for the developers foundation if they continue to survey their current ‘paid’ users on their cloud service and prioritize those client wishes slightly over the wishes of the rest of the user base.

Helpful Note of Full Disclosure: I am not a client of the developers cloud service because I disagree with how they manage their services pertaining to software updates. However I fully support their business decision to offer cloud services as a way to finance their growing project because I want to see the project grow into something better. I believe in this enough to take an opinion on this matter that probably goes against my own business interests.

Thank you to the dev team for being interested enough to ask the hard questions. Even if philosophy is not their strong point :blush:

BKM

5 Likes
6

This article is built on false oppositions from the ground up.

And so I remain pessimistic that open source can find commercial success. But also frustrated: so much software is open source except any commercial product.

Commercial success for open source software is not some hypothetical that the idealists in the world are still trying to achieve. It’s already happened in vast, vast ways. The business model is robust and well established. You don’t sell open source software. You sell the things open source software lets you do.

1 Like
7

Examples ??

8

I think this question is directed at me, but apologies if not.

It’s always hard to tally this stuff (since open source profits tend to be more distributed than in closed source profits), but this report suggests that the open source services market will grow to more than $32 billion over the next three years.

If you’re looking for individual examples, Confluent, Elastic, and RStudio all strike me as interesting case studies. (And of course there’s always the Red Hats, Ubuntus, etc., not to mention big consulting forms like IBM and Oracle who do a lot of high-end consulting work with complex open source involvement).

9

Many of the examples are not pure open source other than RedHat and Canonical. (consider the millions of Linux Cos that tried)

The argument is that the publishers don’t make money unless they go open-core with a community / enterprise editions. Core argument is people don’t value someone else’s work unless they are compelled to pay in some way.

10

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.

6 Likes
11

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. :open_mouth:

Just my observation… :sunglasses:

BKM

6 Likes
12

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.

13

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.

14

May I site Gitlab? They are possibly one of the best examples erpnext can learn from when it comes to monetizing open source software.

15

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.

BKM

16

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.

BKM

17

Here is another relevant post that was trending on HN a few days ago: On Being a Free Software Maintainer – feaneron

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.

6 Likes
18

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.

9 Likes
19

I wish I could like this comment 10 times.

20

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.

1 Like