I received an interesting email from Debian developer Raphael Hertzog who has happily allowed me to blog about the ideas we were talking about. His email centers around the funding of infrastructure projects in the Debian distribution and ways to think about funding that avoid socio-political problems.
We’re not talking about vast sums, but more enablement funding. Not profits, not stipends, commissionary funding.
Background: Raphael has written a book which he is hoping to get translated into English and which he hopes to make money from.
First thing is to distinguish between direct funding and proxy funding. For instance money from Raphael’s book enables him to write code and that’s proxy funding. But if someone paid him directly to write that code, then that’s direct funding.
Direct funding is in my opinion, more stable and shows a more healthy relationship between programmer and user. In order to achieve direct funding there is one fundamental question:
Who are you serving?
Who is it that takes the most benefit from your work? For the infrastructure work on developer tools, it’s other Debian developers and they I think should be the people who should fund Raphael’s work on Debian’s infrastructure.
For work on dpkg and other system code that gets shipped into Debian, then the answer is the users. People who use Debian should be involved in helping to pay for it. If Debian’s users are too poor, then Debian is not directly economically viable (though I don’t think this is the case).
Your other option is charity, people paying the project to do coding, even though it would never benefit them. There are plenty of projects that ask for money from anyone who’s passing by. But if the user uses the project then it’s not a donation, it’s an investment into the project.
Getting money from a property like a book is simple, it might not be as stable, but it’ll certainly be easier. Getting money from one area to feed one’s own self interested needs in another is a simple idea, you’d be self funding in that case. If your doing work for others, then your being a self driven charity full of compassion for your community.
Not all work can be economic, sometimes it’s because there will never be enough users and sometimes it’s because the users just don’t have the time/money to fund it. But lots of infrastructure programming can look uneconomic on the surface, but is in actuality unexplainable to users and thus is difficult at attracting funding directly. Those cases are normally most attractive to fund by proxy and all traditional businesses count such things as business expenses (things like office space).
There is a social stigma in Debian that now exists around internal project funding thanks to the Dunk Tank experiment which I think should be corrected. There is nothing wrong with money, it just needs to be handled completely transparently and ownership must be fairly explicit… which in the case of Dunc Tank it wasn’t. It’s not “Debian” funding things, it never was, it’s SPI or a board council or some other mechanism which exercises rights over the properties and to what they would be invested in.
Anyone who doesn’t like it, can go take it up with the owners of the money. Although when you don’t own the money, it’s a bit hard to argue that you should have been given a choice into where it went. This is perhaps why Canonical exists, so Mark didn’t have to fight through hoards of community well wishers to actually lay money down to get things moving… not that I agree with everything Canonical has done, but I see the reason for it’s existence, it provides a very definitive boundary about who’s money it is and those with the money get to decide what they want developed.
Personally what I would have done in Debian is done a slight dancing fork, splintered the money out into a project/organisation called “Debian Infrastructure” and then given voting rights/tokens to each approved deb dev. They can then ask for what they need from the infrastructure devs and the money can be spent without argument. Not enough money or free time to get a job done, then it can’t be done. What ever the end result, it needs to have very definitive property boundaries.
