[Proposal] Public Betas

1

Community,

Over the last few days, I have been observing that a lot of users want similar features and are ready to pay but are unable to come to a common platform to make this happen. Bounties are not so good because there is no guarantee of goals and what will exactly go in the bounty. Currently the best way is to depend on a service provider to make this happen.

We were brainstorming on a new idea, we like to call this “Public Betas”

Public Betas are intense feature development sprints that can go on from 4-12 weeks. Users can participate in the beta by paying an entry fee, say $500

Some public betas we can start are

  1. Extension of E-Commerce Features
  2. Amazon MWS Connector
  3. Quickbooks Connector
  4. Magento Connector
  5. Woocommerce Connector
  6. Manufacturing Module Extension
  7. ERPNext for Agriculture
  8. Projects Module Extension

Once we announce a public-beta, we can invite developers and users to come in and build features together. Users will provide test data and will involve in testing, developers can pick features and build. The number of developers can depend on the number of users that sign up for the beta. We can fix a pay of $1000 per month for a developer willing to work on a public beta (or we can ask foundation supported devs to participate in this)

For example if we have 10 users, $5000, we can have 5 developers for a month.

The foundation (or Frappé) will guarantee that 1 developer will work on a beta for full time.

The benefit for users is that they can give active feedback on the feature they want and they will also be sharing the development cost with other users who want similar features.

We will scrap the bounty system and move to this instead.

Let us know your thoughts!

24 Likes
3

I fully support this…With bounties there is no garantee that the code will be added to the OS code base…Quality is an other issue…With this the experts do the job (Frappe) and adding to OS codebase is garanteed, Robert

2 Likes
4

Ok. I sort of like the idea. The bounty system didn’t ever seem viable for my client base. However, the system you propose would only work if there were a consensus on the projects to put on the list and the priority of the list order.

In other words… lets take your initial list as an example.

If there were an overwhelming number of people willing to jump into the Quickbooks connector, then they would probably ‘sit out’ the 2 projects you have lined up ahead of it (Extension of E-Commerce, and Amazon MWS connector). If you do not have them in the order of popularity, you might loose the attention of he crowd that pays for the projects.

This may alter the overall opinion of the process held by the developers. If you really want everyone to be excited and then use that excitement to drive the new feature process, then it would probably be best to run periodic surveys to determine the potential support for any given project. Using the data from that, you can line up the projects likely to generate the most support and hopefully start your new feature development ideas with a lot of excitement because the ones everybody seems to want most would be the first in line.

I believe this could be a success. The attention to details is where you may run into trouble. Open Source developers are not know for their ability or desire to follow a fixed plan. Yet, the users funding the projects would really want to see a punch list of design and functional goals. They will want to know they are helping to fund something that will not leave them without important functional pieces they need in any given project. It is this part of the developer/user equation that has been driving the work to eager contractors all along. I also believe this will not interfere much with the developer contractors. They will still need to be ready to take on the projects that might never have enough consensus to make it to the list, or those projects that someone simply cannot wait very long to get done.

So, as long as you think you can handle the backend process of keeping a disciplined developer group to actually meet their design goals, then you will have very happy users that will continue to add funding to the projects they also want for their systems.

The survey and data collection process would probably have to happen at least quarterly in order to keep the developer system active and current with users needs. The forum then would need a section to promote and sing the praises of the accomplishments of the developer community and the users involved in the support funding.

While the “Bounty” system was fairly self running, this new idea will actually take work on someones part to keep it in line and running smoothly.

Do you have the resources for keeping an idea like this going?

If so, then this idea you have proposed has the potential to create a logarithmic growth curve for ERPNext. I look forward to see how this progresses.

BKM

3 Likes
5

this system was in place some 3 years back…However without a financing option…

6

This seems to be a good way to engage Foundation developers on developing features, which are in demand. A way to go!

1 Like
7

I believe it is a good idea to have these public betas, baked with the foundation. I simply wanted to make a little warning about the current list : I see many connectors. I know there are regularly asked and in the end, customers must decide.

But, in my opinion, connectors can be problematic : for closed source solutions, it is about open source philosophy and user rights. Technically, it is also huge work to get dual sync functional connector initially, but in the long term, maintaining it too.

Moreover, I feel that this time and money may be better spent on core ERPNext, improving feature to compete to desired solutions. For me, the ERP promise is to have one database and one interface for users and 80% of their needs. An ERP will never be better than specialized products of course, but may fill a good coverage of standards features. That’s why I found ERPNext feature extensions more profitable to the community.

3 Likes
8

This sounds like a well thought through idea. I support the concept in principle. However like suggested above it is better to focus on improving the core features of ERPNEXT rather than spending resources on connectors.

1 Like
9

Let that be for the community/market to decide. If there are a group of members who want to finance a connector, then so be it.

The market will win in the end. If a connector to a closed-source solution is what is required vs a fully in-erpnext solution, then that will win.

I agree that having everything in ERPNext would be ideal. But that simply will not be possible unless there are literally hundreds of developers working on various features full-time.

1 Like
10

I agree with @Yakulu the focus on 3rd-party integrations must be approached with caution. What comes to my mind is the question what is the GOAL of ERPNext and do we all as a community agree or buy into the same.

Is it for instance

ERP for Everybody Do-It-Yourself Business Management System that will help you stay in control
100% Open Source

Let’s spend our money, time, skill and effort towards what works for us that is under our control and serves our interests. Customers may pay (or they always do) but what will this product always be about?

Open Source is the means of developing software for the foreseeable future but for this community it is also the end product as well so I see no benefit in allocating resources to try and “mainstream” ERPNext by connecting to 3rd-party proprietary software.

11

This sounds to be a good idea and way to engage both foundation developers and community to certain extent. Platform will bring both industry expert and developer together to ensure thing works better.

We may need see it as two different types of wish list one is extensions, enhancements and self sustained features and others are integrations and connectors. Second wish list may sound problematic as it has been pointed out by many and I too agree being part of that journey when working on QuickBook connector (still on).

Some of the challenges were,

  1. First was third party application keeps coming out with enhancements and new feature and even our own been enhanced. So, managing the balances and updates becomes a challenge. And If we work focusing one version then we left out of the version league. Then implementation and maintenance both becomes a overkill.
  2. Second development and implementation (where you need to address various practical scenarios based on business cases and varies from practice to practice.) troubles a lot and takes into too much of specialisation. In that way it becomes wider problem to address and match up with each and every feature set even talking a one way sync up (but keeping one system upto date.)
  3. Third, there will be always smaller GAP at certain extent one need to live with. Some accepts and some doesn’t.

But first type of wish list certainly will have some results and benefits to add to platform.

Moreover any “beta” will have that thought in first place before it’s getting public. So, time and money will be spend in right direction. Bonus one Frappe core member always be at disposal to address any scenarios to curtail general ground level failures.

This will definitely benefit in a way as we keep addressing the expectations from platform to certain extent.

2 Likes
12

I feel this is a great idea. Fully support.

I prefer to contribute 200-300$ per month for these kinds of things…which in the end it will pay back.

In the end, that is equivalent to 10hrs. of paid work, I would need to buy on the market which may / may not make it to the main branch because I don’t know how to give away code.

I prefer to give away money to projects. Second best to giving away code. :slight_smile:

1 Like
13

You are right Felix, let the community decide.

I am part of the community and I just put down my own position/decision.

The sum of the part makes the whole.

Sum of decisions/positions like mine will end up becoming the community’s decision.

14

This is a good idea, but it is not clear how it will be implemented. The main issue is selection of features for proposed ‘Public Betas’.

wouldn’t it make decisions far more easier if we have an easy way of finding what those features are and what is the interest from community/market for each one of them? We had a related discussion earlier regarding this as part of long term roadmap discussion(ERPNext Roadmap Document [Long Term Goal] - #13 by spoojary). If we have a list of prioritized road map items($ + Dev time), selecting what should go to ‘Public Beta’ becomes a non-issue. That way even a core feature like ‘upgrade stability’ might show up above all other features if there are enough people considering it as an issue and are ready to pay for making it better.

1 Like
15

Thanks for sharing that thought. I am pretty excited about this too. I have not seen any other open source project experiment with an idea like this. Let us see how it goes!

I agree. A quarterly survey of features is a good idea. So are upvotes on the GitHub issues!

Yes will start with a list. I am thinking of kicking off with the e-commerce features. Instead of pre-deciding on features, we often realize when we work the read scenarios that our initial planning was not optimal. So a process where there is high engagement with the developer. For example there could be a call every 2 days for a beta where all users / developers can discuss, so we enter a quick feedback loop.

I used to be ambivalent about connectors too, but many users are asking for this. One thought that I am evolving here is that instead of doing a full 2-way sync we should cover the transaction and not the master data, for example:

  1. In Quickbooks, just push invoices and payments from ERPNext
  2. In MWS / shopping carts, just pull the order info

Only the master data relevant to an order or invoice should be pushed.

100% agree!

3rd party marketplaces like Amazon are a reality and we are talking about hundreds of thousands of small businesses that transact via these portals. I think its a fair requirement.

I agree we should just go for core data, just pushing invoices and payments in case of Quickbooks like I said

I think $500 is a good entry point, but am open to more ideas. Don’t want to make it complex by adding levels though.

Developing blindly is not much fun. By getting users to pay for the public betas, we will ensure they have “skin in the game” and be involved in giving active feedback and testing!

4 Likes
16

I sincerely think that public beta’s proposal its good.
as it will add more flavors to the ERPnext and to exacerbate the growth of more specialized ERPnext for Industrial and Agricultural Use.

Also we should make a set of rule for engagement in the public beta about the feature list. As we each of us will have different needs and might not all be covered in the public beta’s (non generic feature that only applicable to us but not others.). So its kinda win-win solution for all to enjoy.

Just my one cent comment.

1 Like
17

Then i do it once every 2 months. Averages out the same!
Best

18

I am fully for this idea!

19

  1. So it will be like 3rd extensions or like plugins for wordpress? Why not such a marketplace / extensions directory inside ERPnext? Make the core strong and add-on features added as per needed. No bloat to the core. :slight_smile:

  2. People get to vote on features? So what is the development priority?
    E.g. 2 feature requests : 500 votes on one beta vs 5 votes by paying voters on another feature beta.

  3. What about after-support for these new development? Once merged to core, core team will support or the developers that wrote them?