Sponsoring features

Organisation
1

From time to time, we (B2CK) are requested to make a proposal for a new feature. Or we have an idea for a new feature.
But frequently we (or our customer) do not have enough budget to implement it. So we would like to group the effort between many customers. But for that we need to advise and communicate about such plan.

I would like to propose to add a “Sponsoring” category on discuss where companies or individuals could post a request to share development effort.
The idea is to link to a feature topic, have an global cost estimation with a progress bar.
People may pledge to sponsor a part of the cost with a comment (or a private message).
A timer could be set on the topic to close it if it did not succeed to reach the goal on time.

After that it will be up to who is requesting sponsor to manage itself the invoicing and payment collection.

13 Likes
2

I created Sponsoring - Tryton Discussion

1 Like
3

The workflow is clear when there is some implementator (usually B2CK) that wants to share the cost of implementing a feature with other community members but we are missing a way to some community members to raise their hand if they may contribute some money for some feature but do not want to fully implement that by themselves.

AFAIK @herrdeh was interested on this workflow, so if we organize it others may join.

I’m wondering if just creating the sponsoring request on the same topic will be a good idea, or we need to organize in another way.

4

Without implementer there is no point to raise money.

5

Of course, the primary objective will be to get some implementor, even maybe several offers can be raised for the same topic. People offering their sponsor should organize to find the best implementator.

Once an implementator is found, they money can be raised.

1 Like
6

Thank you for bringing up this topic. I think such sharing of burden and effort is crucial for the success of OpenSource and way too little used until now.

To achieve optimal results, IMHO the concept should incorporate:

  • the chance to contribute different sums per supporter
  • competition in providing the solution
  • quality control in regards of code quality
  • quality control in regards of usability

So I think we should have these steps:

  1. a discussion about the features in request
  2. a kind of “tender” where the task is described
  3. applications of different implementers with their offerings (1)
  4. acceptance of the best bid (2)
  5. actual coding work
  6. creation of documentation
  7. QC of code. (3)
  8. QC of documentation (4)
  9. QC of usability (5)
  10. payment to implementors

(1) As we have the big “me2”-scandal in Tryton, often there will already be solutions in existence, which only need some update/upgrade. Even this reason alone IMHO requires to open the market for various biders. And there are many other good reasons for competition.
(2) Obviously, the concept of the “best bid” is a very critical one. But to begin with, “lowest price” may be good enough, as the implementer has to pass QC steps #6-8.
(3) This IMHO should be done by a committee of 3 understanding people, as a matter of fact Cédric should be one of them. Code reviewers need to get a decent share of the project money.
(4) This can be done by supporters or a distinguished “docu committee”.
(5) This IMHO should be done by the supporters (in case of discord, their votes could be weighted by their contribution).

This sketch is not regarded to be a bullet-proof blueprint, but may serve as a starting point.

Cheers,
Wolf

Special greetings to @htgoebel, @rmartin , @jsiero (;

1 Like
7

This is up to the choice of the one who is proposing his services.

This is not in the Tryton way to put people in competition. We always try to achieve consensus.

This is already enforced with the review process.

This is also part of the review process.

This is already done in https://discuss.tryton.org/c/feature/5

This is described in https://discuss.tryton.org/c/feature/5

The sponsoring topics allow to have multiple proposition.

I can not see by whom and on which basis.
For me the sponsors will choose with their money.

2 Likes
8

I’m giving up here. My believe, that within structures of the foundations substantial improvements are possible, is eaten up. I’ll see what the “contrib area” process will do.

W

9

I do not think “contrib” should change in contrib. The same sponsoring process should be avialble for any contribution.

10

I don’t see this as a shortcoming of FOSS in general. Many projects perform general fundraising and the project leaders/foundation decides how to spend the funds (e.g. development of specific features, bug fixing / bug bounties, etc.). Several times recently @ced has proposed a feature to the community and asked for financial contributions to compensate development. A non-developer could act as a middle-person, propose a feature and ask for community members to pledge financial support or quote the development.

Treat this with appropriate skepticism. Similar to asking a sales person what product features are important, you find out what is immediately important to close a sale, but not much about long-term strategy.

1 Like
11

@dalers

Thank you for your thoughts.

Yes, there are “watering pot” methods for funding. But they are not able to direct money (=ressources) into a specific issue. If I do not really know where my money goes to, I’m not so keen in funding.

But I do not see that in general FOSS projects do have a section in their user forums, where issues and funding of their solution is organized. There are things like bountysource, but those are not attached to the user forums. So if I open an issue at bountysource, it’s a matter of good luck if other fellows will find it - or go to other funding platforms, and the funding effort is dissipated. If I do open an issue at the project’s bug tracker, I do not have the opportunity to fund it.

Well. Luckily, we do not have to deal with the needs of salesmen, but those of users (in Tryton: mainly developers, which is a problem of it’s own). And I cannot see that long-term strategic issues cannot be discussed in a wider public.

12

We are all Tryton salesmen :wink: . I was making the observation that the features community members want to pay for now are not necessarily the features that that will help Tryton succeed in the long term (I will readily acknowledge the circular argument that without solving immediate issues there may not be a long term, to which I would respond there must still be an appropriate balance, and it must be the project leaders and developers who determine it, for it is their project).

I agree with you in concept regarding

and

but IMHO think you may be over-estimating the time and budget the Foundation has available to manage a formal process such as you propose, even if it were to be supportive of one.

While I do not fully agree with @ced

because it could also be argued that without money there will be no implementer, I also take @ced’s reply to mean developer’s time is a scarce commodity, and unless there is agreement first on the value of a proposed feature, it is unlikely an implementer will be interested in the work. Further, I believe the comment was made wrt collaborative development by the project community, and not from the perspective of a Tryton Services Provider (e.g. B2CK), who I expect would have had clients who funded development of features unique to their own needs, and expect you could do the same.

Since the Tryton project governance is a federation of contributing members with no central authority, development must be determined by consensus (@ced said as much above “We always try to achieve consensus.”), and management by consensus is always challenging. The alternative is to hire a team and do the work yourself, which to some degree is the approach taken by Coopengo (see the “How we used Tryton to build an insurance ERP” presentation at TUB 2016, and the Coopengo Tryton Tutorials, which I believe you may already be familiar with).

I do not understand why not. Unless I am missing something, it seems one is free to simply post to the Sponsoring channel in Discuss with a link to the issue in the bug tracker, state they are interested in sponsoring the resolution (or some portion of it), and invite developers to propose a cost.

Respectfully,
Dale

P.S. IMHO language such as this

does not help your cause. “Scandal” is a loaded word (evokes a strong emotional response instead of a considered rational response), and the lack of description implies readers should be familiar with the issue, and those who are not are hence inferior to the writer.

4 Likes