Fedora as an crowd founded project an additional funding source to our sponsor

["Jóhann B. Guðmundsson"]

On 07/24/2013 01:23 PM, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/24/2013 08:31 AM, "Jóhann B. Guðmundsson" wrote:
>> On 07/24/2013 11:35 AM, Stephen Gallagher wrote:
>>> While I *am* pleased that you've given some real thought to this,
>>> I think you may have missed the real point I was trying to make
>>> there, which also ties back to the original purpose of that
>>> thread.
>>>
>>> Fedora is hemorrhaging users to other distributions (and to
>>> closed-source platforms). I tried to note that the people
>>> maintaining the vast majority of the pieces that correspond to an
>>> "operating system" in Fedora (loosely the Ring 0-2 pieces in that
>>> design) are almost entirely Red Hatters. This information is
>>> based on admittedly imperfect metrics (mostly dist-git commits),
>>> but even if it's off by a 15% margin of error, the contributions
>>> still have Red Hat in the vast majority.
>> Hmm not following
>>
>> On numerous occasion it has been stated that Red Hat employees are
>> just like any other member of the Fedora community and should be
>> treated as such with the only difference being that on their
>> paycheck says Red Hat instead of <insert some other company ( so
>> are you saying that is not the case?
>>
> Sorry, maybe I was unclear. I meant that if Red Hat pulled out its
> contributions in favor of croudfunding, you'd lose an enormous amount
> of the active contributors' time. Working for bug bounties vs. working
> as a full-time job is a huge difference. The point I was really trying
> to make here was that if we went full-crowdsourcing, the effect would
> be basically the same as it is now because Red Hat would remain the
> primary (likely only) contributor to funding.
We already feel in QA when Red Hat re-tracks it's resource from Fedora 
to focus appending RHEL release.

My subject clearly states "an additional" which is required until we 
have successfully implemented that model and

>
>> And as such their in the case of the "bounty" donations would just
>> be "bonus" to the existing salary as it might be for anyone else if
>> that's what you are wondering.
>>
>>
>>
>>> The problem with crowdsourcing is that you have to have someone
>>> who wants your product enough to pay money to see it happen.
>> That would be ourselves and user base as in our community and it's
>> users but for something like this to work we cannot just copy/paste
>> the concept as is and blindly apply to the project we need to adapt
>> and adjust it to us.
>>
> Right, and what I'm saying is that if you took away Red Hat's
> contributions, there's absolutely no way that the remaining community
> could afford to keep the lights on, let alone continue to innovate.

Which is what worries me.

>
>
>> Here to me it's seems again that you implies that Red Hatters are
>> "different" from other community members so it would be good if we
>> can establish if that is the case or not.
>>
> Well, in this instance they are. Red Hatters have a vested interest in
> doing their work in Fedora. Application developers as a general rule
> will do their development on whichever distro makes it easiest for
> them. They tend to be more fickle (and in my view, if they were
> suddenly asked to pay for the privilege of working on Fedora, they'd
> jump to Arch or Ubuntu or Debian or $DISTRO).

By my experience only on the early stages once they mature ( as a 
programmers ) they choose the OS that least get's in their way and has 
the least hazzle to setup their development environment basically what 
OS get's them quickly to coding


>
>
>>> In other words, if we switched to a crowdfunded model, the
>>> primary contributions would *still* be coming directly or
>>> indirectly from Red Hat. The only difference here is that now it
>>> would look like Red Hat was taking a stealth role in Fedora's
>>> governance instead of standing tall as its primary benefactor
>>> (and beneficiary).
>> I dont see how or why that has to be the case.
>>
>> Are you implying in a such model we should keep our sponsor hidden
>> instead of having something like a page with Platinum,
>> Gold,Silver,Bronze for companies as is being done on flock and
>> something similar as is being done on lwn as in "*✭ supporter ✭"
>> *displayed next to our community members name everywhere where it's
>> displayed in our infrastructure/web?
>>
> Well, right now that's basically what we are doing already. Fedora is
> an independent entity (on paper) that just happens to have funding
> provided almost exclusively from a single source.

Thas because it has consistently been stated in the past that the you 
cant so can we or cant we?


> Perhaps I
> misunderstood how you were planning to display that information based
> on your earlier comments about Red Hat. It seemed to me that you were
> looking to reduce Red Hat's visibility in the project. If that was not
> the case, I apologize.

I have no interest in reducing Red Hat visibility in the project nor do 
I see how or if doing so would be somehow beneficial to the project 
quite the opposite advertising "platinum" sponsor everywhere possible, 
might attract other companies to to become platium sponsors for the project.

>
>>> Also, you mention later in the thread about moving Fedora's name
>>> out of the USA. Given the current US climate around
>>> "outsourcing", this could be a significant legal hurdle and is
>>> probably not a fight worth having right at this moment.
>> It has been mentioned to me privately in a mail and a on this
>> thread that the us legal and tax system would be a stopper at least
>> while Fedora was under the trademark.
>>
>>>
>>> tl;dr version: If we switched to a crowdfunding model, Red Hat
>>> would still be the primary contributor and little would change.
>> Other for the fact that this would allow everyone to contribute to
>> the project not just Red Hat which in turn would make us less
>> depended on it ( or they spending money on us from their point of
>> view ).
>>
> My understanding is that Fedora is registered as a non-profit
> organization in the United States which I believe allows for anyone to
> donate to it *today* if they so chose. The fact that the only
> donations we see are *time* rather than *money* is an interesting fact
> (and given Red Hat's sponsorship covering most things anyway, I think
> that's a better expenditure from our community members).

If that's the case why has it always been claimed that you cant?

>
>
>>> I strongly support opening up a donation program to support
>>> bug/rfe/design bounties. I'd like to see that pool of money
>>> managed by FESCo.
>> Agreed although I'm unsure if FESCO should handle that process
>> beside the obvious points of there might be conflicts of interest,
>> they have enough on their plate as it seems so a special Financial
>> SIG with representative from each sub-community ( with perhaps the
>> exception of the service sub-communities which would just fall
>> under whomever is in charge of the finance for the project )  might
>> better fit.
>>
> Well, most of the time, FESCo members are pretty good about abstaining
> from votes when they have a conflict of interest, but I'm sure we
> could work out the governance of such a system in a reasonable fashion
> if this is an approach we end up taking. One might argue as well that
> the Board is essentially already the Financial SIG.

I personally would want us to form a special sig for this task.

>
>
>>> If people want to donate to bounties for individual upstream
>>> projects, it's probably better for them to do that directly.
>> I disagree we need to increase the number of contributors here
>> within the project and sorry to say that but we cant do that if we
>> forward everybody upstream ( which is one of the reason I have been
>> so reluctant forward our QA community members directly upstream
>> always ).
>>
>> We also want to be the downstream distribution of chose for
>> upstreams so we need to somehow make it attractive for them
>> participate in the project and this could be one of those factors.
>>
>> Bounty hunters they themselves could donate a portions of their
>> bounty upstream themselves if they wanted to.
>>
>> Ofcourse no bounty would be paid out until it has been accepted by
>> upstream
>>
> Perhaps the aforementioned "Financial SIG" could also be responsible
> for contacting upstreams about proposed bounties before they go live
> publicly to confirm that the upstream would accept a (properly
> designed and compatible) contribution. That way we can simply reject
> bounty submissions if upstream plans to refuse the fix.

I dont think that is necessary upstream could just close the bug with 
"WONTFIX" and the bounty be refuted and the bounty offerer offered to 
donate it somewhere else, set that bounty on another bug or a refund ( 
with the exception of the infra tax we always collect the infra tax :) )

>
> Also, we'd need to work out when exactly to collect the money for the
> bounty (and when to refund it)
I think it would be best that we collect the bounty offer when it's set 
to prevent the donator from re-tracting the bounty offer but offer him 
to set the "time" limit ( in months ) the bounty offer stands.

> . I'd suggest that in order to ensure
> that no one gets screwed out of it, the bounty should go into an
> escrow account for one year. If no one has accepted the task in that
> time, it should be refunded to the bounty poster unless they opt to
> extend it another year.

Bounty offerer select the time the offer stands from a list ( like 
1month, 3month 6month an year )


>   Similarly, after a bug has been accepted, they
> should have a year to complete it (or request extension) or else it
> gets refunded to the bounty poster. Seem reasonable?
>

I think the above would take all the coding fun out of it so we should 
not tie it to acceptance nor an specific time to complete it since I 
might decide to hunt that bounty and you might as well so we have a 
coding contest , which results we have to deliver before the bounty 
offer runs out ( the time the donor set on the bounty ) and the fastest 
coder wins or the better coder depending on what upstream accepts.
Basically bug bounty's are open for all including upstream.

We might need some code reviewing committee in the cases where upstream 
itself participates in a bounty hunt to prevent upstream just disregard 
the submission from everybody but themselves instead have the best 
implementation ( best written code ) to win even if upstream refuse to 
commit it.

JBG