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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux