[IMP] Code of Conduct regarding Open vs Closed Source

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.

This is where what I call “the problem with open source” begins. So categorically, “free software” is about freedom and not sustainability. Open Source cares about sustainability.

From the perspective of FrappeTech, we monetize because we own the ERPNext brand (we started it!). Would have loved it to be owned by a foundation and become a service provider like everyone else, but would need at least 500k in the foundation so we can fund development for the coming 2-3 years. As things stand right now, FrappeTech will monetize via ERPNext.com. I don’t think anyone should hold a grudge for this as whatever improvements we work on as FrappeTech are available to the entire community for free. While we have revenue on hosting and support, there is a lot money and value creation you can do as a service provider.

Here is what I recommend independent ERPNext service providers (ESP) should do:

  1. There is huge revenue in hosting / implementation / training / migration / customization / implementation. Maybe 5X of support. So focus on this market
  2. Create a good, high quality website (how many ESPs have that??) with good quality original content, videos etc
  3. Focus on the local market. Local presence is a big win. Build a mailing list, send newsletters, write blogs, case studies (again, how many do this??)
  4. Maybe partner with FrappeTech for branding + support so you can pitch to large enterprises. This is completely optional, but want to put it here since you also support the ongoing development of the product by doing this.

The “marketplace” revenue is a mirage. Under GPL, you can only charge for support and support revenue will always be small.

I really hope ESPs can up their game, so we can all win as an ecosystem. Anyone looking at ERPNext vs SalesForce or Odoo should find a high quality ecosystem in place.

1 Like

Thank you Chude for the clarification. I am happy to see you are not advocating a marketplace to sell apps.

I however disagree with your conclusion that most community members do not hold on to their apps/enhancements from a selfish motive. The sad fact is a significant majority do.

The above is me venting about a member trying to sell to me an enhancement to the HR module. This is not the only sales pitch I have received…I get several, this is however the most irritating from a pricing perspective hence the rant. Dude was trying to charge me a subscription fee that is practically higher than the fee paid for the entire ERPNext, just for creating and modifying a few doctypes.

You will be surprised the amazing amount of enhancements out there that people simply hold on to. It is their prerogative as you say, it is not compulsory to contribute , but it makes you a sad selfish free loader when you take such a huge product and refuse to give back the little you add to it.

And enough about the excuse that it takes too much of an effort to make pull requests. It is supposed to take an effort! DO you know how many crappy customizations I have paid for from renowned “contributors”? They turn me into a never ending tester for half baked products . If it is easy for such “customizations” to be pulled into the core “as is” then ERPNext will die a very fast death.

I agree that ERPNext team can do a better job on pull requests but we know they have resource constraints, let’s work together as a healthy community and not hang on convenient excuses.

Have a good Monday everyone.

3 Likes

The only obstacle to stepping up the game is the diminishing coding quality. It may make all efforts to go down the drain and the product staying local rather than international.
Latest examples:

  • InWords not showing content in Turkish
  • Installation bound to locale settings of the server
  • Lastest updates to Currency, Float scripts breaking the whole system for countries having , as decimal separator
  • Random customizations flowing into production branch like preset list query settings

You cannot pitch such errors to any customer let alone corporations.

3 Likes

Mmmm @Tufan_Kaynak2, I used to be a Premier Advisor for Intuit the parent company of Quickbooks some years ago.

Everytime, I repeat everytime a new QB release comes out it is full of bugs, and it is left to the customers to report it and wait for updates to fix it. Everytime.

And intuit is a multi billion dollar Company. I admit this used to drive me nuts cause I could not imagine a company of that size releasing a buggy software. But to their credit they always respond quickly with the fixes.

My point? It comes with the territory.

I worked both for Oracle and SAP. I have 20 years of Software Development/ERP/Project Management experience and official training.
Bugs are real and there but a version-12 product does not break its basic classes in such a way and is expected to handle merges in a better way.

While your summary of the market opportunities appears accurate, this particular statement is incorrect. You can charge for source code. You can charge for exceptions. Anyone who doesn’t make their code base available under GPL can be held liable to pay a fee. Not sure all devs will follow through but a reasonable number might.

I don’t think it’s a problem. I think the problem lies in not aligning the objective of sustainability with what we know to be human nature. People acquire these skills because they like the community and the idea. Ultimately though, if we can’t find a range of ways for them to benefit from these skills, things stall. I think this guy put it quite well in this tweet https://twitter.com/patio11/status/936629310785437696?s=19

I think you’ve done a very great thing with ERPNext and think that you should make a lot from it. So much so that I’d invest if that was an option. However, what I’m saying isn’t that Frappe shouldn’t make money, I’m saying that we should find every opportunity to spur a clear monetisation strategy for others who aren’t Frappe. I don’t think it’s a zero-sum between Frappe making money and the wider community doing so too. I’m also saying that we can’t say people aren’t forthcoming with code when we haven’t really put in place a platform to help them expose all the things they’ve built.

I don’t think any grudges are being held. This thread started by saying people don’t contribute. I don’t agree. I think we should propose practical steps to test this assertion and reverse it if true. The proposed site is a very cheap way to measure if this is indeed true. I’ve stated the reasons why I think it looks like people don’t contribute.

The proposed site is more about giving people and ideas more recognition and reducing the amount of repetitive work done by giving already done work more visibility. It is less about making big revenues. The recognition that innovators who post on this platform get might even be enough reward for some. The point I’ve been trying to make is that if we want better behaviour, we have to align objectives more closely to the self-interest of the parties of whom we demand this behaviour.

Great. It’s actually what community members are currently doing (personally, I think the partnership terms need to be improved to be attractive). But none of these really help to solve the problem of code not being shared.

1 Like

This is true in principle, but it’s not really true in practice. You can sell GPL software, but so can the person who bought it from you. Or, they can immediately post the code on github. There’s not really a commercial model here, at least not that I can think of.

1 Like

Well, if he’s selling it as a SAAS, the rules allow him to. I personally, wouldn’t buy it. However, if the market exists and enough people are willing to buy from him enough for him to continue in his current behaviour then, sadly, there’s nothing we can do about it.

I, on the other hand, can point to many people who have developed features and shared them as pull requests and links to their custom app repos. I’d like a centralized place to view all their work, compare with other work in the same category, give feedback and also support them.

I have a few good ones, if I say so myself. I can guarantee you that they are not shared because I and my team literally don’t have the time to package them for Frappe. Either that or they are very specific to the customer.

Again, this is what I say about looking at real vs idealized behaviour. If I have a series of jobs ongoing, I would rather dedicate a developer to spend time on those jobs than spend time packaging a bespoke PR or custom app. My feeling is that 9/10 people would also do this.

Probably the biggest selling point for why you need a site where people can share their contributions and other can rate them. That way, you might have been able to identify who to stay away from. You might have also been able to identify who could take a promising but raw PR/Custom App and likely deliver it to your expectations.

Well, yes there are resource constraints (personally, I feel it’s because of the monolithic approach that’s been taken to build ERPNext. A more modular approach would make the team less fearful of unintended consequences of adoption new functionality). The question is, if this resource constraint isn’t going to improve soon, then how do we solve the problem? I don’t think it’s by telling people how to or not to use the software outside of the licenses that have been adopted.

I have a few good ones, if I say so myself. I can guarantee you that they are not shared because I and my team literally don’t have the time to package them for Frappe. Either that or they are very specific to the customer.

Then simply put them on Github, start a thread on discuss linking to them. This way people can find them and if they are as good as you say they are, people will advocate for them to be included in the Core.

It is actually that simple Chude.

You do realise that quite a number of people have done it exactly this way?

And we have :slight_smile: Quite a few of our contributions have actually made it into core. I believe we gave Frappe the initial 2FA, improvements to HR Payroll, and the initial multi-currency tables and one or two other features that have made it into core. Also a few hanging PRs that haven’t made it into the core - and not for lack of quality. We’ve also paid for quite a few of the contributions made by others.

What’s not released is mixed up with customer-specific processes. No time to separate. When we do have the time though, I’m certain we will.

Archiving code in forum comments isn’t an efficient way to give it (or those who wrote it) visibility, allow for comparison or allow for it to be rated by a large number of people. I find it hard to believe that we think the two approaches are comparable. I’ve lost count of how many times I’ve looked for functionality, not found it and then only seen it referred to much later by accident because it’s under some obscure title and there’s no way I could have found it using the search terms that would normally come to mind.

I’m happy to take the responsibility to have this market place built and hosted if the foundation will adopt it and promote it. I think it needs to be tested first and compared to the alternative. Also note that designs are valid contributions too. The proposed market should also not discriminate against these.

5 Likes

This will be great. If this has to be an official listing, it will be hosted and moderated by the foundation.

Also lets start with a listing rather than a marketplace :wink:

Sure. Will share the specs and have someone build it. Hopefully, the foundation deploys and showcases it in a way that encourages adoption. I’m not certain what the differences between a listing and a marketplace are. However, the specs I share will definitely include:

  • the ability for people to rate shared code
  • the ability for a party to invite other parties to adapt or improve the shared code with the ability to indicate a fee that they’re willing to pay for this work to be done
  • the ability to call out unattributed code if it was copied from someone/somewhere else without saying so
  • the ability for users to propose that submitted code is related to other code that has been previously submitted (either because it is similar or because it is complementary)

Any other ideas for things to cater to are welcome.

4 Likes