> > 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.
I would tend to disagree, but only on the grounds that people with money and resources have a nasty tendency to demand to know how their money is used in a regularized and formal manner, and (at least here in the US) they may be required to report that through other channels as part of their compliance regime in their industries. Most commercial entities would expect to have a formal audit report for how funds were spent, and how the choices are made. As a person, I don't think anyone has problems with you being honest and trustworthy. Corporations are a whole different kind of rat. My day employer probably would not allow contributing to the project without a formalized public method of dealing with the transparancy and accounting issues. Even my evening consulting business would probably be more likely to contribute if that process was in place. > > 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. I would just observe that you should start out as you mean to continue. If you plan to hold people accountable for delivering what you provide them resources to do, then that's your model and you should stick to it. "Ask Kern" doesn't scale very well, and you *really* want this to scale. > 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". Resources allocated by the foundation would not necessarily be monetary. Access to equipment and development tools could also be part of a "grant". For example, I've got development machines I personally own for about a dozen different OS and CPU architectures, and some tape changer hardware that's mine to play with. What I had considered doing was making access to that development lab for a autobuild farm and testing lab my contribution to the foundation. No money involved, but we would need to coordinate who's using it, and I'd like to know how it's being used (there are some tax advantages in the US to lending hardware to non-profit projects). > 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. All of which really require some kind of coordination to keep the code stable and clean. I'll think about it a bit more. I still think there needs to be a clearly defined mechanism for how that problem list gets tackled, but it bears some skull sweat to think this through. > 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 get good turnout when *I* talk about it -- 50-75 people in sessions. As the author, you're likely to get a much better turnout...8-) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
