Want to go to UDS Narwhal?

UDS is only a month and a half away and there was again a very tight selection for places for Canonical to sponsor us community folk. I’m interested in finding people who didn’t get sponsored this time but may still have some means to go or would still like to go.

The first goal I want to see if a number of people clubbing together can reduce the cost for rooms, travel and anything else in order to make UDS less stressful on the budget. If you’re interested, I’d like you to email me at [email protected] and let me know what your means are. So far I’ve discovered rooms and resorts near by which are very cheap when sharing.

The second idea is to make a Kitckstarter funding drive to sponsor community members who would be able to give valuable input at UDS. I’m sure there are lots of Ubuntu users who would like their thoughts carried to UDS and for them I was thinking of making a to get some of the more important community people flights and accommodation. With this you could each give $20 and have your per peeves and notes of consideration brought in. For a higher donation the person could attend a session on your behalf with your notes and try to get your thoughts brought into the discussion live.

Would you sponsor someone to go to UDS?

The Debian Pennybox

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.

Funding Model: Miro Adoption

From the folks that are brining us a compiled online video program comes an interesting funding model. Adopt a Line of Code.

You get to pick a line of code to adopt and pay $4 per month for looking after it. The cute graphics really made me laugh though, as if code is really that pretty1. These charitable donations count towards your tax return and of course help to make development possible.

I’m wondering if anyone has had any ideas on Adopt a bug or Adopt a feature. Something to tie users into the programming and code support for Ubuntu would be really useful. although I have heard that lots of people don’t really want to pay for software, which is sad to hear, because software development costs are not zero, even if distribution costs are2.

Like my Software Concert idea, it has boasting extras such as tags you can put on your blog or website and it ties the product it’s self into what your buying so your not just buying a token heart felt thanks like you are with typical donation buttons.

I’m interested to hear how successful this project is for Miro and I’m also interested to hear of other unique and interesting funding models for Free and Open Source Software, the more we experiment, the more likely we’ll be able to invent something that will be able to drive FOSS development economically out of the enterprise and student bedroom production houses and into a more professional and well paying development that seeks to serve real end users in homes and small businesses.

1 Depends on the language of course
2 Well, close to zero.

FOSS: First Generation is Costly

There is so much new stuff being brought out right now, everything from Google Wave to some very interesting ubunet ubuntu karmic integrations.

What is interesting is how costly the first iteration of any idea is, it seems that before an idea is really solid or cohesive you need to spend a lot of time just thinking about what your trying to achieve. This includes a lot of pondering, staring into blank spaces and coding stuff that may never be used, over and over again.

Once you’ve got the idea nailed down, seemingly any programmer and her dog can recreate it with a fraction of the effort and even start evolving it using ideas from other spaces. Perhaps it’s similar to how some artists can take other people’s works and redraw them, but would always claim never to be able to draw.

It’s interesting because we may have to try and work out the economics of “first to market” projects, ideas and what essentially boils down to software research. Currently it’s kind of expected that projects that are first to market will be able to recoup their costs from that advantage, selling licenses and such.

But this is FOSS not proprietary closed source, it’s possible but not really very efficient to sell GPL licenses. So exactly how are we going to fund software research and unique projects that may have a high failure rate? Can we expect normal users to invest time and money into these kinds of projects using previously proposed methods for funding features and bug fixes? Would that really work if we knew it was very risky and the users are even less likely to understand what the result is really going to deliver?

Or perhaps it’s more likely that the developers will work for free on new ideas with the hope that one day people will be paying them to keep them active as successful projects. It seems like an enormous investment for volunteers, but they would be best placed to recoup from their experience.

Perhaps it’s best to leave this kind of thing to Universities like other industries do? Get government subsidised labour to do all the ground work and then be ready to jump into the successful projects later on, perhaps this might even get the students jobs later on based on their work.

An alternative thought might be to dismiss any kind of dedicated research and be contented with purely evolutionary work. No need to test new ideas or research user interaction, just follow user demands and what ever else is currently in the market.

I don’t really have any answers, I just figured I’d throw this out there. Maybe all of the above works, I obviously want lots of new cool stuff in Ubuntu.

FOSS can work in the Free Market

This is in response to LeafStorm’s excelent post about the market economics of software and FOSS caleed FOSS and the Free Market.

He goes into explaining the difference between rivalrous and excludable and does a good job at explaining why it’s not possible per say to sell software as if it were a traditional product (like sandwiches), I’m going to selectively quote the passages for the benefit of the reader:

If a good is excludable, it is possible to stop people who have not paid for the good from using it or enjoying its benefits. For example, computers are excludable – if you sell computers, people can’t use your computers for themselves without buying one from you first (the mostly applies to physical goods). An example of a non-excludable good is a fireworks show – anyone within a few miles can watch and enjoy the fireworks.

If a good is rival in consumption (“rivalrous”), one person using the good impairs or prevents others from using it simultaneously. For example, food is rival in consumption. If I eat a sandwich, you can’t eat the sandwich, and if you can, it will be in a form that you will not want to eat it in. FM radio is not rival in consumption. Everyone in an eight-mile radius could be listening to the same station, and they would all listen to it the exact same as if they were the only one.

He goes on to show how software is neither excludable or rivalrous and how efforts to make it excludable are attempts to defy the basics of market economics.

There is however one omission with the article and that’s with the assessment of Free and Open Source software as being condemned to always be produced by volunteers for free or by incidental funding such as support services.

What I would suggest is that we are looking at the problem the wrong way. While software is not rivalrous or excludable, software development as a service is excludable (although not quite rivalrous) and this is important. If your view of software is always on the visible finished product then your not going to be able to make any money in FOSS. Not directly from development anyway because you are fighting the economics.

On the other hand if you consider the service of development to be your product, then you are following the economics in the most direct way and can make quite a nice living from it, so long as you are able to get the people who demand the service to pay a fair price in a stable and predictable way. The people who pay for the service are the people who get to decide what will be developed and in what manner.

That is why non technical users should be involved with FOSS funding, they can’t direct development through their own skills, but they should be able to direct development (even if just slightly) through their purchase of developer time.

I was thinking today about a project to sell developer blocks, some made up certificate of value which would be sold at $120/€100 and which would entitle the barer to enter into development tracks and bug fast tracking. One alone wouldn’t be much, but if a bug or project can get a number of developer blocks from users then they can happily pay for development and build better projects with more stable developer time.

I’m sure many of us would love to be able to prioritise our bug with some lovely money, or add into a pot that would get us features and developments that we really need. This product would be sold and money would be taken up front, the company or organisation would act as escrow. The blocks would be both excludable and rivalrous as mentioned above.

I think it’s important to get Ubuntu and FOSS mainstream, but I also think it’s vital that we get user funded development into the mainstream as well. So far I’ve seen very poor support from my fellow Ubuntu community contributors to be involved or support such a system, I really need your help to spread the philosophy of user funded software development.