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