[Cython] funding (Re: sage.math problems?)

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Thu Mar 22 20:13:29 CET 2012


On 03/22/2012 11:39 AM, Robert Bradshaw wrote:
> On Thu, Mar 22, 2012 at 10:52 AM, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> Dag Sverre Seljebotn, 22.03.2012 17:58:
>>> On 03/22/2012 09:03 AM, Stefan Behnel wrote:
>>>> I would prefer copying the original installation over
>>>> (including the build history), rather than rebuilding it.
>>>
>>> I hope it doesn't come to this, but if it does, I think we should really
>>> look hard at ShiningPanda instead.
>>
>> We could set up an OSS test account to see what we'd get for our money,
>> i.e. how much of our build/test cycle we can put into one hour in their
>> environment.
>>
>>
>>> Honestly, my feeling is that if we can't rally up $240/month in funding
>>> among Cython users then we might as well give up.
>>
>> As long as we have sage.math, I can think of better things to do with 240$
>> per month. Didn't we want to organise another workshop at some point?
>
> +1, this would be a much more effective use of funding, though also
> easier to get funding for.
>
>> Regarding funding in general, maybe we should just start putting up one or
>> two of those sexy funding bars on our web site, like the PyPy devs do for
>> their funded projects. Assuming that goes well, it would also allow us to
>> put money on dedicated projects by paying basically ourselves for doing
>> tasks that we won't normally spend our precious spare time on (e.g. because
>> they appear too large for a weekend), but that we and our users deem
>> necessary for some reason.
>
> While that's a good idea in theory, I'm not sure how many additional
> hours would be freed up just because we could pay ourselves for it.
> Perhaps it would act primarily as an additional incentive to align our
> efforts with user request (though there are certainly already
> non-monetary incentives). A budget of a couple hundred a month is
> likely an order of magnitude too small to get as serious developer to
> attack "larger than can be done in a weekend" projects. Also, the
> monetization of Cython development changes the spirit of things a bit,
> and while I am a big fan of people being able to make money, or even a
> living, off of open source development, it complicates things a lot
> from a legal, financial, and political perspective.
>
> The current model of organization X is willing to pay developer Y for
> feature Z directly seems to work well enough for the moment. E.g. with
> GSoC, the bottleneck is finding good enough students and time to
> mentor them, not slots (=funding). Opening up funding to non-students
> could help a bit, but IMHO wouldn't change the balance that much (the
> gainfully employed cost a lot more and have less spare time).
>
>> Basically, any "real" CEP that we consider doable and that we'd have a
>> developer for could get a funding account where users could "vote" for it
>> by donating money.
>>
>> (and that's where the legal issues start ...)
>>
>>
>>> (And specifically, we
>>> could ask NumFOCUS first, and possibly share the queue with other open
>>> source projects on their lists, and possibly ask ShiningPanda for an OSS
>>> project rebate).
>>
>> Sure.
>>
>>
>>> I'm not primarily concerned with uptime, but with the time spent in
>>> maintaining the systems. The more that can be moved into the cloud the
>>> better for open source projects, if it means less maintenance, which is
>>> usually the case; see our move to GitHub.
>>
>> I don't know how much time the maintenance takes on UW side, but they're
>> using the machines for many other things, so I guess they'd have to invest
>> the time anyway. So they won't win much by us moving out.
>
> Yes. We add to the load a bit, but not much. And I don't see us saving
> administration time (the most lacking resource here) by moving to
> another service (if anything, it'd likely be more work).

OK. My comments were all predicated on the assumption saving 
administration time; and I totally trust yours and Stefan's judgement here.

Dag


More information about the cython-devel mailing list