[Conference 2018] Making Open Source Work

I think a partnering program on the medium term, where you get more access to resources, and also pay for it. Models like odoo also depends on the referrals of partner to their enterprise version, more referrals, the further you go up the partnering level (silver, gold …etc.), and also get money. This would also motivate more partners to do referrals to ERPNext hosting instead of self hosting.

Maybe better for bigger projects, more hands on and support for the implementing partner for a price of course.

I think partnering and working on partnering programs that gives more incentive to bring enterprises and companies that work with ERPNext to work with the foundation would be a key discussion.

I still love this product :slight_smile:

Are you referring to something like this: Not Found

Yes, I know the resellers program, but it needs severe renovation. e.g. better representation of contributions and partners, better exposure of partners, better gamification engine, although this is more like enterprise more than a foundation.

I think we are looking at results of the problems and not the underlying problems. We need to fix some things to make the community healthy and help everything to grow in a more sustainable way.

I think there are problems the core team is feeling, and there are also problems from the user/community side as well. I think the conversation needs to dive deeper into the things plaguing us and not just focus 1 issue.

If we just set out to fix the core teams problems, you may end up making survival more difficult.

Core Team Problems:

Income

Need to have more funds to keep things going in terms of features and support.

Not enough help

Need contributors to help out more and funds to delegate if needed to outside teams. And probably need to spend less time on the big features and focus on platform stability.

Community Problems:

Core Contributions

If you need to improve a feature or build something new, you can build it and use it in 1-14 days. If you decide to build it for the core, it may take 3 weeks to 12 months before it is rolled out for usage. This means the vast majority of people who need a feature now just cant wait around for the code to be pulled in. And therefore most do the quick easy route when in fact they would love to get there code submitted for core usage.

Frappe / ERPnext Focus

Many people feel the core team is just working on new features that the community at large could care less about. Many people are concerned about the amount of resources that are going into new features. Many people also feel like great community ideas are dismissed or thin reasons are given as to why the core team does not want to do them. It does not feel like the core team and the community are collaborating effectively.

Bugs & Refactor

It feels like 70% of the core team effort goes into new features and not into supporting the platforms stability.

Income

How can the community exist without a path to make money just like the core team members? This one is obvious and need new ideas here to help allow all ships to rise without hurting what has allowed us to get this far.

Resulting Problems:

Losing value from community generated code.

+ Losing revenue from not having effective ways to build and maintain.
+ Losing momentum from bad communication and focus.
= Weak open source project and community

Conclusion

We need to work together to TRY things to address these issues. The core team needs a better way to survive and grow, so do great contributors in the community. The community needs support from the core team in order to contribute more effectively which allows the core team to make more money as the core product improves. The direction of Frappe and ERPnext needs more community oversight and the community needs to believe in the path we are on. Its one thing as a potential user to "like the software" its another to invest your company on it, you need to understand the leadership team and the path the company/project are on.

How do we maximize efforts of the Core Team?
Get them focused on product bugs, stability, usability to attract more paying users. Get the community to contribute more and also create ways for the frappe team and other teams to make money while users fund what they need. And allow the community at large to vote up apps and work done so the core devs and approvers.

How do we get the community to invest more into contributions?
Make it easy, make it fun, make it move faster with a path to consensus.

How do we make sure we the software is headed in the right direction?
Voting, Voting, Voting, and also paying to get things done faster.

IDEA: Roadmap + contribution voting system

  • Create voting system for apps and repos and even issues so the community can see all community projects/ideas and vote them up. Highest votes dictates what is on roadmap.

  • This will allow app repos to be converted by the core team while in use by anyone wanting to use it.

  • This will give oversight to the core team decisions. If the app repo being worked on is not voted up, it remains an app and is not put on the near term roadmap until voted up.

  • This would also work for general decisions or core direction shifts.

  • These app/project repos can also be funded just like kickstarter if there features are unfinished and need help one or more users can back it for development and one or more users can add development bids. If it gets funded and finished but not enough votes for Roadmap inclusion it will remain an app.

I really think an idea like this is doable and starts to address a lot of the issues and allows us to fully explore things like “partners” “bidding” and more that have been tried and have just not worked.

Let me know what you guys think of something like this. I can put together some more detailed thoughts if anyone thinks this would be a good project to fully explore and plan out how it would work. We might want to start a new thread if multiple people and core team support exploring this direction and presenting a plan.

11 Likes

When you say “core team”, who do you mean? My understanding was that most development (especially in the core) is still being done by Frappe. Frappe is a private company, and private companies are not expected to serve a community when they choose what features they work on or not. For that, the Foundation needs to be driving its own work.

That said, the relationship between the ERPNext foundation and Frappe is still very unclear (at least to me). If the Foundation is to pick up a leadership role in the coming years, it needs in my opinion a more clearly distinct identity, based on clearly articulated structures of operation and authority.

4 Likes

@joshreeder thanks for spelling this out! My comments:

Not sure where this idea comes from? Do you have any examples for this?

Why should anyone be concerned? Everyone in an open source project can contribute and “scratch their own itch”. If one team is delivering a set of features, why should anyone care. In fact the people who want these features are paid users on erpnext.com.

ERPNext is a platform that will have many built-in features, you can pick and choose what you like and ignore the rest.

Please call us out if you see such treads (but make specific references) If you see most of the threads, a few of them ever make it to a pull request. I agree we are learning here, and those who are following closely would have seen that we have been very helpful in merging / reviewing contributions of late. Either ways, no one is perfect, so we accept this needs improvement, but help us out.

How about, let’s raise $$$ to ensure bugs are fixed. Why should all investments be made by “core team”, while everyone are free to judge their efforts and choose to not pay anything. I don’t think community has any such kind of entitlement from the contributors. In fact if there is one thing that really really feels wrong about this, is the kind of entitlement the community has about the core team.

Community loves to dictate → Core team do this. Core team spend time fixings bugs. Core team, don’t add features (because we want to add them and make money). Core team be friendly. Core team, you don’t make money because you are stupid. Core team, we don’t make money either, so its still your fault.

Common. Don’t step on us and piss on us at the same time. If you want things done, take some responsibility and take leadership. There are tons of things you can do.

  1. Help review pull requests
  2. Help fix bugs
  3. Help fix UX issues
  4. Help with documentation.

I think its time the community either decides to take some responsibility or at least help in raising funds. Community can’t be demanding. I am sorry to come off as rude (and I do that for a purpose), but the core team can’t be taken for granted.

If we have to become a better community, all of us need to step in and improve.

  1. Accept that no one is perfect (specially the “core” team). We are willing to learn and engage. Things will only improve if we openly engage with each other with respect and the intention to help.
  2. Respect the time and effort and contributions that have already gone in. People have put in “years” of their lives into this and the work is truly open source. Edit: I hate to add this, but it’s a freaking gift. Have the humility / gratitude to accept and treat it as one. This is not just for the core team but everyone who has made non trivial contributions and there are dozens such people.
  3. There is no entitlement (for the core team either, I am learning this one too), so don’t expect others to “execute” what you want. Help. Criticise. But don’t demand. I have stopped demanding contributions these days, because there is no entitlement.
  4. Help is a 2 way street. Don’t expect help without either offering to help in return, or contribute. If you want help from us, then we will demand some form of contribution. Some help is truly free, but there are limits to everything, we don’t want to end up a community of doormats.

Community has only entitlement on the roadmap for money that is donated by the community. Earn your right to be on the table!

I am happy if you take leadership for this. But do both the things. The roadmap AND the funds or means to execute it. An empty roadmap makes no sense.

13 Likes

I agree strongly with the substance of your argument, but this sentence right here is where things get really complicated. It can’t always be just about adding. For bug fixes or new features, sure…the correct answer is to make or fund a pull request. But, what what about actual design choices?

Just as an example, consider the Payroll Entry doctype. In my opinion, Payroll Entry should work very differently than it currently does. This isn’t the place to get into specifics, but I believe that “fixing it” would involve replacing some of the current design choices with other ones. Likewise, the matter isn’t just a matter of making or funding a pull request. Rather, a choice needs to be made. This is a relatively trivial example in its own right, but it raises an important question: what is the process for making decisions about ERPNext?

Decision making is complicated enough for single doctypes…and only vastly more so for things like caching architectures, UX principles, and interface aesthetics. I strongly support the move to shift platform leadership into an non-profit foundation, but from the outside at least it appears that some very basic questions still need answering. That’s not a criticism in the slightest; these things take time. But, if the Foundation is to lead in any meaningful sense, it needs the authority and organizational structure necessary to make real, consequential decisions. Is the goal, following this period of transition, for it to have that? Or is the foundation intended more as a booster, designed to support fundraising and education for Frappe’s work? To me at least, none of that is yet clear.

2 Likes

The right approach is

  1. Identify the issues with the current implementation.
  2. Volunteer to fix it.
  3. Propose a solution.
  4. Send a PR (watch out for contribution guidelines).
  5. Make sure a maintainer is assigned if someone is not already engaging.
  6. Over time, build a reputation and then become a maintainer yourself!

The goal of the foundation is to become an independent, sustaining and functioning organisation by itself (separate from Frappe), support the contributors and maintainers financially and raise money from the community via donations and grants.

The goal for Frappe should be to be an independent service provider (like all service providers, welcome to the club) with its own goals to serve its paying customers with excellence and provide stable support to its employees, and like all service providers, contribute back to erpnext.

This is the separation we propose needs to happen, so there is no confusion about the roles. My guess is it will take 6-12 months for this to happen (unless someone gives the foundation a generous grant to get started!)

1 Like

As far as I can see item Multi Barcode seems not to be released, merged 10 months ago …

1 Like

Thanks for the response. I hear your concerns loud and clear and now have a better understanding of your view point.

Let’s keep the conversation going.

1 Like

This is exactly what I’m trying to understand, though. How are maintainers appointed, and by whom? Is there any particular philosophy or set of best practices that they are expected to keep to stay in that role? If Frappe and the Foundation disagree about an important decision, who decides whether or not to hit the commit button?

Decision making in private companies is easy, because there’s always somebody at the top. Communities are harder. If the answers to these questions aren’t explicit from the beginning, they will be a point of conflict.

3 Likes

The answer to this is thankfully easy and its a standard practice for large open source projects. The maintainer hierarchy does not belong to any organization. It is its own meritocracy based on an ever widening circle of trust.

Maintainers can be supported by foundation or by a private company. It does not really matter. There will be issues that multiple people will have opinion on and the best way to resolve them is by reasoning. The maintainers also have to over time come up with more explicit contribution guidelines and learn to enforce them. There would be weekly / monthly calls to discuss issues and design deliberations. Conferences and Events are a great way to build human to human contact and spirit of community, which can be supported by volunteers and foundation.

That brings us to our conference next month, and it would be awesome if many of you can attend. (https://erpnext.org/conf/2018) And maybe host events in your home cities.

We were fortunate to have Jordan Hubbard (co-creator of FreeBSD) to our 2015 conference and I had asked him this question. Its a fascinating talk if you have not heard it.

3 Likes

Thanks for posting that link. Jordan Hubbard is quite articulate, and I’m sorry I wasn’t at the conference to meet him. That said, I think we might be understanding his argument very differently.

The kind of foundation Jordan describes is very different from what we’re talking about here. A foundation, in Jordan’s opinion, is not there to provide leadership. To the contrary, the FreeBSD Foundation was formed only because the project was attracting so much money that they couldn’t handle it responsibly. It was designed as a trust, meant to be relatively passive and (to use Jordan’s word) “boring”. At its most ambitious, it serves as a communication channel sitting between developers and userland.

The real leadership in FreeBSD-land is the “Core Team”, which if I am understanding you correctly is more analogous to what you’re calling the hierarchy of maintainers. That’s a fine place for leadership too, but the same questions remain. There’s nothing easy or standard about FreeBSD’s core team, for example. It’s a complex system with a charter, goals, elections, roadmaps, dispute resolution mechanisms, communication channels, and well-documented best practices. It has a very particular and very explicit operational structure, and other large open source projects choose to organize themselves in very different ways.

In a way, this all comes back to the money. I don’t really have a sense of who uses ERPNext right know, but in my world at least nobody would flinch at dropping 5, 10, or 50k USD a year on business critical software, even and especially if it’s open source.

That brings me back to my original point: if companies, especially service providers, aren’t supporting ERPNext in the way that they should, I hope you’ll reach out to try to understand why they aren’t. I think the answers might be surprising.

I also think we must ponder open source and willingness to pay/support open source in developed economies vs developing economies. Frappe & Other SPs, it would be interesting to know which is revenue-wise ERPNext’s largest market(s). I only say this to prioritise resources accordingly. Let’s drive revenue and adoption and that can happen only when we go where the markets are. This is based on @anon-forker’s comment that people would drop 10-50k USD without blinking.

From a foundation and community standpoint, Governance structures will not be built overnight. However, based on what I have gleaned from the tone and tenor of the discussions here, some amount of formalization in process should at least be tried to see what works and what does not.

It’s a balance, though, too. What I was describing is squarely corporate world, but there are definite advantages and disadvantages to going after corporate money. Small businesses don’t have deep pockets, but small business owners are also usually much better evangelists for new and innovative tech.

2 Likes

Too new, but just in case if it makes sense.

Would data collection of transaction counts be allowed to quantify the usage from all installations. This will then allow to make a calculation of donation amount based on that usage. It would merely be a suggestion but at least would nudge the service provider/user to be conscious of the amount that could be donated. This should surely allow a more appropriate donation request and if agreed by the service provider/user make it’s way to the foundation.

1 Like

This is specifically because being new to the community and trying out the product that makes a lot of sense to promote, it would be better to give everyone an opportunity to donate an amount that aptly matches their usage.

If I am using it for testing and am doing 5 transactions a week then an amount could be calculated and yearly donation could be suggested.

Just my .02

1 Like

@rmehta this might be helpful.

2 Likes

I had known ERPnext till last year October, I began to dig deep about who actually founded ERPnext.
The reason was because i wanted to begin working with this great team begin giving back as long as my community embraces ERPs. I have loved the product and I don’t see any reason why I should not give back if they I have received from my clients.
I am coming for the conference in india actually for this reason, to make sure we make everything better and smarter, I will attend the developers meeting too before the actual conference.
Frappe will need companies like ours who deploy systems to actually be part of the foundation.
I will personally contribute to the foundation with my company am indebted to Frappe.

11 Likes

Point #3 is definitely a good idea to pull those self hosting users who rely upon PaaS/IaaS providers like DigitalOcean, AWS, etc. Minimal email support will definitely justify marginal increase of cost to the subscriber. This model definitely provides more flexibility on customization which is currently limited in the SaaS model.