[IMP] Code of Conduct regarding Open vs Closed Source

Dear all,

There was a great discussion on Open Source vs Commercialization debate at the conference, specifically on extensions to ERPNext that are non-open.


ERPNext code is licensed as GNU GPL V3 which is a “copy left” license that applies to all derivative works. Broadly the license grants the freedom to use, study, modify and redistribute to any user.

In the context of ERPNext community, most of the code is donated free by Frappe (and its customers and partners) and contributors who fund the project directly or indirectly. But there are many people in the ecosystem who have built useful extensions on ERPNext that are also useful to the community, but not shared.

This leads to a lot of conflict within those who chose to contribute back useful things and those who don’t and yet benefit from the contributors.

The Rules

To resolve this, at the conference most in the community have agreed this code of conduct / honour code. This specifically applies to those who commercialize ERPNext:

  1. If the extension to ERPNext is for end use / single use and not redistributed to more than one user, then it is not required to share the source with the community.
  2. If the extension is generic and is used by more than one customer, then the code must be made available to the community on GitHub / alternatives with adequate documentation.

These rules may or may not be compliant with GPL and people are independently liable to comply to GPL, but these are the rules that will apply within this community. That includes, ERPNext events, chapters, conference, and this forum.

To put it in context, if you are sharing screenshots, marketing something or asking questions on the forum regarding something that is generic and redistributed to more than one customer, you must share the source and docs on the forum.

This will also help you comply with the copyleft license and protect the freedom of your customers. For this community, this will also create a more “contributing” community, compared to many other communities that are over commercialized.


That’s great, eventually it may give birth to an ERPNext AppStore and App certification


+1 for the approach and it’s fair enough.

I read somewhere one of the finding of conference 2019 that every one resolves same issue in silos. I have initiated an approach that can be extended already in the forum, like a knowledge base where any community member can share learned lessons with enough details so if any one later face same issue can search in the forum by key words. I am sure information exists on each laptop, let’s make it public and anyone can get benefit. With KB(knowledge Base) we will not replace documentation which valuable resources but extend it.

for me still I have doubts, with the first post using new approach things will be more clear.


I suggest the ERPNext foundation provides a platform where people can register these custom apps with meta data on what they do, what area they cater to and other classification data along with a link to the repo where the app can be found. This will immediately bring visibility to duplicate efforts and also serve as a way for partners building innovative tools to distinguish themselves (they are in this for profit as well as their love for open source and opportunities should go around or else we’ll just keep grooming freeloaders).

However, my understanding is that a custom app can be licenced as non-GPL and the creator is under no compulsion to share if not so minded - especially if their client does not want this. Please clarify.

Also, as I’ve said on other comments, quick appraisal and acceptance (or rejection with clear reasons) of direct PRs to ERPNext will encourage the desired behaviour. It is sometimes the perception that Frappe Tech prioritises things that are immediately advantageous to them over things that might not be thereby forcing partners to retreat to custom apps. Can we talk about this?


This is indeed an issue. For example, I have two PR for Frappe docs hanging since July without any feedback and I’m not sure that the devs even saw them. Another example is that I have applied for a verifier position for the new translation portal in August. I got a prompt reply saying that my application is being considered and not a word more three months later.

While I understand and don’t blame the developers for not having time to pay attention to every single little thing happening around the Frappe and ERPNext, but if the devs want to urge contributions, they will have to do somthing about the contribution review process, since the current one directly discourages contributions and forces, as Chude said, to retreat to custom apps.


Not just partners but anyone in the community.


This can easily be done by a GitHub Repo and Discuss post to start with.

At this point we have a PR review bottleneck and in most cases, the PRs are incomplete, lacking test coverage, not updated after feedback and not as per the contribution guidelines. It is not ideal to merge these PRs.

However it still makes sense to share a repo / code on discuss so it is searchable by future users.

Harder to compare and contrast options with this approach. A simple site with the following:

  • Domain (Accounting, Buying, Selling, etc)
  • Subdomain (General Ledger, Accounts Payable, etc)
  • Description
  • Name of Developer
  • Email of Developer
  • Link to GitHub Repo

Would probably increase the efficiency of looking for solutions and help Frappe Tech easily identify features with promise that can easily be adopted into the core.

Having to search through the discuss forum is unorganised and defeats your stated aims.


Good post. It is important that we clarify the conduct regarding the project, and that we ensure the integrity of the project as an open source system is maintained and defended.

I found the easiest way to explain the question of what must be shared is by explaining the following.

“You were granted certain rights and benefits with this project. You should not deny those rights and benefits to others.”


Big thumbs up on your comment and I share the same experience and feeling.

No other words needed.


Suggest this rule change be communicated via mass-email campaign. Not everyone lives on the forums. Even those that do, they sometimes only pay attention to New & Unread posts.

An email blast improves the chances of people learning about official rule changes.

Otherwise it could be months+ before everyone discovers this. Some might never notice the sticky post and click on it.


Yes that seems to be the case and a reasonable one, until such time that the Foundation and maintainers can merit and share in that responsibility.

In my several years of being actively involved with ERPNext, I think I can say with some level of confidence that many members of this community have no problems whatsoever with sharing their code… just a quick browse through this forum will reveal a large number of active users happy to openly share what they’ve developed

The major issue is with the ease of contribution and lack of a simple, organised way to share the code. I believe the simple website suggested by @Chude_Osiegbu would be a good place to start

Also, we need to work out a system of making selected custom code in the aforementioned website contribution-ready. Most times when people develop stuff, it’s to solve immediate problems… either for themselves or for a client. The extra effort to make this code contribution-ready according to Frappe guidelines is quite significant. Expecting everyone who develops extensions or patches to go through this rigour whether in terms of development efforts or financing (or both) is quite unrealistic. There are however loads of community members who would be happy to finance such solutions getting into the core

There needs to be a system that helps make generic solutions contribution-ready, with oversight (and guarantee of getting merged) from the core Frappe team, and sponsorship (cash and/or development efforts) from the community

Kind regards,


I agree with @wale. Also may I add we need a simple way of tracking what everybody including Frappe are working on so that we don’t end up with multiple people working on the same things?


I agree, we definitely could benefit from a process for tracking projects/work.

I’ve previously raised this suggestion, and been directed to write a “Proposal” on GitHub. Which is not a tracking solution. And isn’t useful anyway, unless Frappe agrees to participate.


Exactly. And more importantly, sponsorship to the community. We have to build a proper economy around the monetisation of ERPNext development skills. There’s clearly a gap between the development of user-specific apps and their generic, frappe-ready equivalent that can be deployed into ERPNext. Let’s create a market where people can create branches of these solutions that are cleaned up to scale the necessarily high vetting process and let sponsors who really want to see that functionality get into Frappe, pay for that cleaning up. Let’s add a rating mechanism to that site so that Frappe can prioritize their adoption of these functionalities based on how many likes they get relative to others in their category. Basically, let’s create a market place for custom apps with a route to adoption into the core. Of course, Frappe Tech would also need to respect the licenses on these apps.


I believe the difficulty of: contributing to ERPNext on the community side and approving the contributions on Frappe/Maintainers side is linked to ERPNext philosophy of everything in core. Obviously, when something breaks, everyone is affected

While it has a lot of merits, I think it has been taken to the extreme to the point that it is becoming a bottleneck. There are a lot of things that should be in the core and many others which should not. A school should not need to update when the hotel room booking feature is updated. Expecially that they may need to pay someone to do it.

To me a middle ground approach would easy contribution: the core which has features everyone needs and where contributions are very strict and domain specific apps/domain more accessible to the community.


Does anyone here use Drupal? Its architecture and history remind me a lot of Frappe/ERPNext, and I wonder if it wouldn’t provide some ideas for how the community here might move forward.

Over the last ten years, they’ve had many very similar conversations about monolithic design, and they’ve found some innovative ways to strike a good balance between coherent design and flexibility. They have a similar organizational history as well, combining a diverse community with an active founder corp. The revenue models are also very similar.

Their approach to modules, in particular, seems to navigate a lot of the very real dilemmas described in this thread. A lot, I think, could be applied here.

Custom apps, here we go.

I would also like to pay for available apps, in-case you guys make the Marketplace open to that :slight_smile:

1 Like