[IMP] Code of Conduct regarding Open vs Closed Source

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.

13 Likes

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

2 Likes

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

No other words needed.

2 Likes

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.

3 Likes

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,

11 Likes

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?

2 Likes

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.

3 Likes

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.

4 Likes

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.

7 Likes

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

I could not agree more with @rmehta’s post. We all need to contribute to the community. And commercial providers must do it. There cannot be a tolerance for exceptions in my opinion. Wanna highlight this article again, that Rushab posted some time ago:

4 Likes

Some excellent points in here. My two cents:

  1. While a website as suggested by @Chude_Osiegbu sounds like a great resource, I have found such efforts wane over time. A simpler list similar to the many awesome-x Github lists might sustain better (e.g. awesome-iot).
  2. @rmehta, would the Foundation be open to selling exceptions to the copyleft license? This is compatible with the GPL.

If the site becomes a marketplace - as I expect it would - then I wouldn’t be worried about it waning. What I think is missing from the ERPNext picture is a clear platform and strategy to allow 3rd parties outside Frappe Tech who have invested time in learning the framework an avenue to monetise those skills while remaining true to open source ideals. I think the suggested site would be a step in the right direction.

@Chude_Osiegbu I usually agree with you on most things, but this time I need some clarification.

ERPNext is an open source product. The team provided this product for use by anyone for free, and they still commit energy and effort into releasing new version on an annual basis basically.

Some Community members have also developed enhancement to the core product. Some of this enhancements have been merged into the core while others simply publish it on Github …also to be used by anyone who desires… for free.

Some Community members however hold on to their enhancement for personal use alone and do not contribute to the core or publish on Github. It looks like your solution to this is to give this category of people a market place to monetize their enhancement? Is that what you are saying? This looks like a way of rewarding what to me sounds like bad behavior. How much have THEY paid for using ERPNext and the other enhancement contributed by other members who also invested resources in learning Frappe and ERPNext?

Kindly clarify for me please Chude

1 Like

True. Just to clarify, I’m not saying that people should be paid to share their custom code. I’m saying, people should share their custom code which will perhaps trigger an opportunity for them (or others) to be paid to spend time in enhancing it in a way that it can them be absorbed into core if it turns out to be something the community (AKA market) really wants in the core.

It seems more and more these days that the propensity for things to get into the core is slim - and only when it aligns with immediate goals of Frappe Tech (I stand to be corrected). Which is why a market place that gives these contributions visibility (adopted or not) is key.

I don’t think many community members hold on to their solutions because they don’t want others to benefit. They don’t go out of their way to publish them because they are more focused on solving their client’s problems than packaging a PR that might wait forever to make it into the core. This is where I think my suggestion would be useful. Rather than keeping silos of features and functionality effectively hidden in individuals’ repos, provide a site where one can at least classify and link to the repo so that other parties can use it and possibly even pay yet other so-motivated parties to clean it up to meet the rigorous standards of the Frappe PR acceptance process. The biggest beneficiary of this would likely then be Frappe themselves as they can have a central place to see what’s getting attention and bringing new things they haven’t covered.

We really have to be realistic about people’s priorities and motivations. Ultimately, those motivations are economic. I will always prioritise implementing my client’s needs in a dedicated app over waiting to have it merged into core and likely will move on to the next challenge after that. The least the foundation can do is make it easy for me to share (and for others to find) what’s been done without waiting for me to perfect it to Frappe’s standards for PR. The interesting thing is that, once it’s shared, you create a whole new market for people who might be interested in it enough to pay someone else to round out the rough edges and get it to the point where it’s okay to get into the core. Then we wait for Frappe to accept.

Finally, we have to be pragmatic. It’s good manners, even nice, to share code. But not compulsory - as long as one is not distributing to a 3rd party. I don’t think we should get stuck on this. The respective license rules are clear and we should be guided by them without emotions. Any extra rules are not binding. In my experience people will share if they find that what they share is well received.

3 Likes

more than agree on this statement.

more than agree with this also. I personal don’t have any custom code in ERP Next. only customer Doctyp for my POS solution. Manny time I considered sharing my project in open source however I have code my solution that would breach third party libraries licenses agreement provide by client or other integrated partner. However, am always ready and open to help anyone with their project.