Re: [Bacula-devel] Re: Open Source Funding Idea (Problems and Strategies in Financing Voluntary Free Software Projects)

[Kern S. <ke...@si...>]

On Wednesday 31 August 2005 20:29, David Boyes wrote:
> > Yes, indeed. This is a very interesting article.  I was aware
> > of the problems of funding especially bad feelings that can
> > develop when certain developers are paid and others not, but
> > I had never considered it from an angle of "crowing-out" of
> > volunteer programmers.  This "crowding-out" of volunteers is
> > clearly something that I don't want to happen as I want
> > Bacula to remain free and open rather than commercial or
> > semi-commercial.
>
> I think another aspect that we haven't seen a lot of discussion on is
> transparency and accountability, which is often the big catch with
> commercial donors.

I don't think this is a really big problem. First, I am someone very open. I 
have no problem with keeping things transparent.  The few conversations I 
have off-list, for example, are typically private or items that would 
interest very few persons such as release packaging problems (bugs), ...
Concerning accountability, in general, that won't be a problem either as I 
must have been an accountant in a former life because I have no problem doing 
the bookkeeping for a number of corporations that ran in the past.

>
> One idea I've been toying with proposing is the idea of having a formally
> reviewed proposal process (similar to applying for a grant) for projects to
> be funded by the foundation. The formal review would include estimates of
> time, level of effort, timelines, and formal requirements for documentation
> and code standards. Asking someone to think about these things in advance
> tends to sort the serious contributors from the kibitzers. I believe the
> Apache and Samba folks have adopted this approach for this very reason.

Yes, this is a good idea, but it is probably a bit early for this simply 
because we don't have sufficient numbers of contributors.  If we had 10 
programmers submitting code, this would be critical, but when it is one or 
two as it is now, there isn't much need.

>
> The review of the proposal would be conducted by Kern and a technical
> review body selected by him for technical relevance, usefulness, and
> furthering the general good. The proposals could then be ranked based on
> that technical review, and funded from the foundation accordingly. Some
> risk management controls would need to be implemented (along with a legal
> obligation to repay the foundation if you receive money and don't complete
> the project). Proposals would be open to anyone, and repeat proposals would
> be encouraged -- if you have a track record of doing good work, that should
> be a plus in your favor.
>
> Perhaps that idea could be combined with the "authorized providers" idea in
> that they could become part of that technical review body -- if you
> contribute resources/money, your opinion of what should be prioritized
> should (IMHO) count a little bit more than the random community at large
> (the "put up or shut up" model). Contributions of time should count as well
> as funding.
>
> >  What I would like to encourage is
> > a few more long time contributors that work in the core code.
>
> See above. While most of us do this for the love of it, a little money
> coming back in makes it a lot easier to convince the PTBs of the importance
> of the work. Even a token amount goes a long way to making that case, and
> if there's a clear audit trail, I think a lot of organizations would be
> interested.

I'm thinking about transitioning into something like Debian does, where a 
certain funding is really important, but they don't actually pay programmers.  
Paying programmers is what seems to create the conflicts or "crowding out".  

What I can imagine, and what I had already planned, is to make a list of 
projects.  Then rather than say that I will implement those projects for the 
next release, I step back, select one or two smaller things for me, and ask 
people to step forward for those projects.  If no one steps forward, then we 
will simply not implement those features.

As for funding those projects, I'm thinking that Bacula, at least in the near 
future, will not fund them.  However, something that has worked in the past 
is that if one or more corporations want a particular feature that is on this 
project list, then they will have several options of getting it done:
1. supply programmers to do it under Bacula supervision.
2. submit a patch (not really recommended -- not so long ago,
    I rejected a pretty big patch).
3. provide funding incentives for programmers.

For item 3, in the past, I have simply put qualified programmers in touch with 
the corporate sponsors, and they worked out the funding between them. This 
was the case, for example, for Landon, who wanted the funding to go to EFF.  
However, other programmers may want to receive the funding themselves.  In 
any case, Bacula would not be directly involved with the funding.

This is probably not the best long term solution, but it is a solution for the 
short term (I think) that avoids getting Bacula into the "crowding out" of 
volunteers.

>
> >  This is the major area that is lacking in Bacula.  Perhaps
> > this will happen over time, perhaps it will improve if I
> > start making a few public appearances next year in free
> > software meetings.
> > Any suggestions from anyone along this line would be welcome.
>
> I'd also start hitting the bigger storage management conferences. The IBM
> zSeries Expo in EMEA would be a good place to reach a lot of the
> enterprise-level customers, as would Guide/SHARE Europe (usually colocated
> with above).

Well, I don't know if Bacula is really ready for the bigger storage management 
conferences, but they would be well worth attending so that I can get a good 
feeling of what is necessary in the longer run.

I remember in 1984 (I think) I went to a DataQuest conference with all the big 
CAD vendors.  It was a bit like I imagine Bacula today in the world of EMEA 
and Guide/SHARE.  

My presentation was a flop -- they didn't want to hear about AutoCAD and said 
that at best, it could *only* be used for training CAD operators.  After all, 
at the time, those guys couldn't even imagine doing CAD much less design on a 
PC!  Well, today, Autodesk (the company that produces AutoCAD) is a 1.5 
billion dollar enterprise with a large range of computer aided design 
products.

-- 
Best regards,

Kern

  (">
  /\
  V_V