Approach to Achieve Significant Enhancements on ERPNext - A Proposal

Hi all,

This is just a proposal, but it is better to put something in front of people and get them to react than not. So, everything in this document is up for discussions.

What it covers:

Significant Enhancements: Like Manufacturing Module, Accounting Module, Country Specific Localizations (significant ones of course), Primary (Online) Server and Secondary (Intermittently Online) Server(s), etc.


A bunch of ERPNext enthusiasts get together and decide that the Roadmap is too slow for them and want to hasten significantly enhancing ERPNext.

This is relevant where such enthusiasts are willing to make significant investments in time, development or money. Or all three. Or any two!


  1. A proposal needs to be made to the ERPNext Foundation Governing Body and in-principle approval obtained. A proposer and two people expressing their commitment is required along with the proposal.
  2. After approval, the team of three (proposer and two supporters) prepare a scope document and scope out the features, and the effort involved to make the enhancement.
  3. Special focus will need to be paid to ensure that the enhancement does not alter existing features or make existing features unnecessarily complicated.This proposal document then gets published in a public forum of the foundation and needs to be live for at least 2 weeks.
  4. A Project Steering committee will be formed with as many members that are willing to fund the project based on the formula: Lower of USD 1,000.00 or “Total estimated cost of Project/Number of People Interested in being on the committee”. Meaning if a Project is expected to cost $10K and there are 12 People interested in being on the committee, then each seat on the committee is available for $833.33. If a project is expected to cost USD 6K and there are only 3 people available, each committee seat is still available for $1K. Individuals or companies can choose to pay more than the required amount, but everybody on the committee still gets only one vote per member.
  5. It is mandatory for the proposer and the supporters to “buy” into the Project Steering Committee.
  6. The committee is formed and the committee decides to execute the project. The committee has the leeway to decide who (or which company) should execute the project, but the project needs to take ownership of the costs to push the code back to ERPNext codebase.
  7. The committee has the leeway to decide the scope, the stages and everything else. The committee will decide on a simple majority. Where there are a even number of people voting and the votes are tied, the following will break the tie: 1. The Voting pattern of the Proposer and the two supporters, and where that is tied (because one of them could or did not vote), 2. the voting pattern of the proposer.
  8. The Committee has the leeway to appoint other Development Contributors to the Committee so long as such contributions are not charged and the total imputed contributions are greater than the minimum amount each committee member paid to be on the committee.
  9. The project committee will disband after the Foundation Governing body accepts the code, though it is expected that the committee members will be part of the Sub-Committee that covers this enhancement. Where such sub-committees don’t exist it is encouraged for the project committee to morph into the sub-committee as defined by the Foundation Governance body.
  10. Where a Project becomes unsustainable or unsupported because of cost/time overruns or poor design or execution, or incompetence of the person, people or team(s) involved, the codebase becomes automatically part of the Foundation and the Foundation Council body can decide to reuse, discard integrate code without assigning any recognition to the committee or the contributors.
  11. It is expected (though not required) that the project will examine all relevant GitHub issues on the enhancement and will roll all practical and possible issues into the Enhancement Road Map.
  12. Where the enhancement is complex and needs to be broken off into phases, it is required that this process be adhered to for each phase or milestone.
  13. Where the project does not get completely funded as covered in #4, and the Project Committee decides to address only a subset of the deliverables, the committee is required to peg the committee membership as per the revised cost and allow for people to sign on the lower cost for an additional 1 week. Let’s say a project is initially priced at $10K. And receives committee member funding from 8 members contributing $1K each totaling to $8K. So, the project committee decides not to abandon the project but decides to reduce scope to $8K. Now let’s say two more people want to be on the committee, the cost of membership on the committee in such cases stays at $8K/(8+2) = $800 and not $1K. Please note that committee members can decide to contribute more than the minimum contribution, but still get only one vote on the committee.
  14. It is expected and is mandatory for committee members to recuse themselves from voting when making decisions that involve conflicts of interest. Like a committee member also runs an organization that does development on ERPNext and the organization is in the running for the execution of the project and the committee is deciding to go with this organization and another organization, this rule states, that such a committee member shall not vote and even if s/he does, the vote shall not count.

A very good proposal @JayRam.

When I first read it, it looked little complex. Looking at it in detail, I understand why it is hard to make it simple :slight_smile: Anyways, my 2 cents looking it from a slightly different angle.

  1. A proposer comes up with a draft requirements/scope document. ERPNext foundation provides a framework to publish that and get the attention of the forum, gather support and fine tune the requirements/scope document and estimate. This helps in making the scope more generic rather than just solving proposers specific usecase.
  2. When the proposer gets the tentative support for execution(base on community interest), he puts forward the proposal to ‘ERPNext Foundation Governing Body’ for execution of the project with stake holder list and their respective contribution(execution effort and/or money).
  3. Governing body reviews the document, discussions and updates it with expert inputs (considering impact to existing features, usability, review etc)
  4. It forms a ‘Project Steering committee’ consisting of stake holders and ‘ERPNext Foundation’ experts. The role of foundation experts is to make sure that the project abides with the general guidelines of ERPNext, so that contributing the feature back to community will be hassle free. So this should comprise of usability, design,process etc. The expert suggestion should be advisory, but ignoring that might make contributing it back to community difficult.
  5. Governing Body decides the minimum contribution as ‘sprint-contribution’(30 Engineering days or equivalent amount-$500?). This stake-holder contribution is used to determine the feature priority for execution. For example Project X gets 4 stake-holders with contribution of 5,2,2,1 sprints. They shortlist 10 features for implementation with various sprints ranging from 4 to 1. They use their contributed sprint-cost to vote for the feature priority. The high priority feature gets selected first and also ‘consumes’ the sprint-contribution, so it can’t be used for other features. Perhaps I haven’t explained it well, but this is basically using bounty to implement a feature.
  6. Once the feature is selected for execution, they decide a feature-lead(highest votes) for execution of that feature. They will have the freedom to decide the detailed scope, design etc, but share all the details in community public forum and get it reviewed by the foundation experts.
  7. Foundation will provide a guideline to accept the code like 0 critical issues, x issues, y% automation, documentation etc. Foundation experts will review that and give the go-ahead for merging the feature.

In summary, if someone wants to implement/enhance a feature, they need to
a)Contribute time or
b)Contribute money
The Foundation will enable them by providing expert suggestions/reviews to merge it back to the mainline code.


Great summary and suggestions, @spoojary. I will run the draft versions of all my posts past you, get your perspectives and then post on the forum. :slight_smile:

But yeah, the idea is to foster collaboration across acquaintances in a structured, supported and assisted environment.