As ERPNext becomes more complex and as the number of users, community and team grows, we need to find new ways to manage this growth. ERPNext is a pretty un-orthodox company. We are usually loathe to define "rules" and it is even harder for us to follow them. We prize independence and flexibility and value the need for "inspiration" to drive work. But as the scope of our work grows, the problem is two-fold. How to set priorities for the team and each member and how to make sure that the division of work is clear and allows each team member to perform to their best. In terms of priorities, fire-fighting usually takes the center stage. Right now we have fires raging on too many fronts, and most of them are self inflicted.

Support

Bulk of the operation is driven from feedback from paid users. These users are the core pillars of the ERPNext ecosystem and the reason why we are able to support the product. Hence, issues from paid users get the top priority. Often, the reply is a helpful link from the documentation, but many times it involves trying to replicate a complex scenario and then trying to understand if there needs to be a fix. Sometimes its a feature request, which is mostly created from an "edge case" scenario, probably involving multiple currencies, taxation, custom print layouts and pricing rules!

Deployments

The second part of our operations is deploying new versions on our servers. Currently we host around 4000 databases on three sets of servers. Deploying a new version across all of them is fraught with a lot of complexity and uncertainty. A patch may fail on a particular set of databases, old and new versions running simultaneously may cause issues. In the middle of a deploy, we may discover that a hot fix needs to be pushed immediately, forcing us to abort the current deploy and push the fix.

Release

Release management is merging contributions from the team and community in the product. A merge may involve code review, manual testing, extensive back and forth communication and adding a few finishing touches. We aggressively try and push new features and fixes in the product. The speed at which we do this sometimes causes a lot of friction and bad experiences at the user-end. There are two conflicting goals, to improve the product as quickly as possible and to keep it extremely stable. Of late we have been guilty of pushing for improvement too hard against stability and we need to assess and slow down our release cycles.

Usability

Our goal for ERPNext is to "Make ERP simple" and we also try pushing that goal forward aggressively. To make ERP simple, we realize that ERPNext is used differently by each user. We need to work on better default settings, fewer fields on each form and making the communication simpler and more consistent. Most of our in-office discussions hover around what can we do to make ERPNext simpler without disturbing our existing users.

Community

The ERPNext community is a source of a lot of help and also takes away a lot of our time. Answering issues from developers and users is complex, tiring and time-consuming. Since ERPNext is an upstart, we need to focus on the community too. The community is also a source of strength for the product and in the long run we hope to build an organization that is truly representative of the user and developer community.

Communication

In between all of this there is a lot of communication between the team members, users and community. Email that need to be answered. Bills that need to be paid, services that need to be renewed etc.

Priorities?

Coming back to our original question about priority and division of work, I think it is important to set a clear vision and goal. Our goal as of now is to be useful to 10,000 companies. That is a 10-fold increase in the number of users. We believe that the best bet to reach that stage is to make ERPNext even simpler to use, specially for new users. Most users walk away from ERPNext because they find it too overwhelming and complex to start. If we have to be geared towards that goal, we need to make sure that our operations are very smooth and managed well. Right now we have walked away from diving operations, design and development into separate groups, but maybe its time to look into that again. This means we will need many more leaders so that each person can take control and responsibility for their work. This is something we have been avoiding, but the push is inevitable.