Whoa! Where’s it going?

After good healthy interest in yesterday’s video I decided to post the code in a repository (GPLv3 and CC-BY-SA) and as a second act to deliver Mark Shuttleworth’s feature request which I show off in the new video:

View Video on Blip

This is particularly cool since it means desktops will converge and look the same at certain dates as well as diverge and look different at all other times. What are your thoughts?

Ubuntu Made Art in August 2010

It’s time once again to show off some of the great art being made using Ubuntu and the wonderful tools we have available to us:

Also check out the Cartoon TV show made using ubuntu and blender: Pirates vs. Ninjas vs. Robots vs. Cowboys (in Portuguese)

This is my top 10 for August, if you want to see more of the amazing art being done using Ubuntu, check out the full gallery.

LinuxCon Kernel Panel Discussion

I wanted to post this to the planet because we rarely get to think about the kernel in the Ubuntu world, and when we do get kernel related posts they’re usually fairly dry and require some background skill to read.

This is a commentary piece.

Getting the community involved in testing

There is not enough testing of RC kernels. Most people who attended thought the level of testing in Linux was bad.

Testing would be much easier if there was the possibility of safely testing a kernel by selecting installed RC kernels on boot in Ubuntu and letting it run through an automated set of regression tests which could automate a potential report for time and regression and then perhaps reset (if possible). Such a test suite could expand the number of users who would be willing and able to test the kernel without background skill in kernel development.

I feel that not enough time has been spent on coding the boring part (tests) and too much emphasis is put on the exciting features development. Of course the rationale is that users will just test out the bugs. But if the user-base is shifting then users won’t be able to carry the burden of testing for all regressions forever.

Increasing invisibility of the Kernel

The kernel ecosystem is concerned with the lack of visibility and the unattractive nature of working on the Linux Kernel. The pressure is to increase the visibility to end users to make the brand glamorous to work with. The licensing of the kernel doesn’t require any sort of attribution upon the distribution of a product using the Linux kernel, it’s not well known that the Linux kernel (with busybox in toe) runs the majority of embeded consumer devices as well as some of the most popular phones but isn’t well known.

Perhaps another problem with the Linux kernel is that it fails to control it’s brand in such a way as to make it clear that you are not working on Linux _unless_ you are working on the kernel project. This is a failure of the project to correctly market itself as a kernel and not a whole operating system stack which seems to be the current problem. The attempt of the kernel project to hijack the branding of the standard distro space has caused a lot of confusion and head scratching.

Ubuntu is not Linux, in the same way that an Ice cream isn’t a waffle cone.

Playing with Branches, New Version?

Does strict release cycles put new developers off from playing with the Linux kernel code base. Perhaps it’s due to the fact that we should be having a play-with branch set which doesn’t need to be versioned as 2.6.7 or 2.6.9 in such a way that it could potentially lead contributors to believe that they are working on code which is the future of a Linux release. Which is not the intent of a highly experimental space. For a play branch it just needs some educational type of person to manage a playground kernel branch specifically for the weird and wacky as well as perhaps educating new users. Perhaps some educational grants could be put towards paying someone to run such a program.

Getting Patches Into Linux

Security is a fairly hard area of kernel development where scrutiny over patches is very high. If there is a developer that is finding it hard to get patches into the Linux Kernel mainline then it’s advisable for the to separate their changes into manageable chunks. From these chunks it’s possible that some chunks would be acceptable and merged in on their own merits, while other chunks/patches would remain in discussion.

For google to get their wait lock Android patches in, they’ve basically got a small team which is trying very hard to upstream the code. Of course the technical solution chosen isn’t quite good enough yet for the kernel team to accept just yet and the solution does need the costly and extensive discussion for the appropriate way forward to be selected. This of course does create a cost barrier to google and the team that works on this functionality has found that it needs to work in non-work hours in order to both fulfil the requirements of releasing a solid Android release and at the same time attempt this much more idealistic technical feat of getting the right solution unto the mainline kernel.

I don’t have any thoughts on this issue, it seems like everyone is one the same page.

Fla Extract

Quick note, those interested in the very start of extracting binary fla files can start here:

Python Scripts – GPLv3 don’t forget.

This is part of the way and yes I’m well aware of using Flash CS5 to convert these binary files into their friendlier XML cousins. But we should be able to rip these apart as well. I think having some xml and binary forms of the same data sources would be most helpful.

I’ve put out a call to artists to get some of these source files. If your reading this much later then perhaps I’ve had an update since which has better scripts or more information.

DebConf Next Week

I’m starting to get ready to go to DebConf in New York next week and I’m certainly excited to be given the opportunity to meet more of the Debian community. Because I don’t do much packaging I’ve not managed to get to know enough Debian people and I feel like projects such as http://art.debian.org/ are interesting and I would love to find others who are involved in similar things in that section of our extended community.

Anyone have any suggestions of what I should keep my eyes open for next week?

What Happens

I wanted to play with brush lines and I was thinking back to a chat I had with my good friend David about Free Software and lack of User attachment to sticking with Free products when their only desire is practicality. This of course can make a very transient user base who will leave at the first sign of trouble.

Of course any time spent with a particular piece of machinery like software will develop an educational and brand familiarity attachment. I want to put those to one side because I believe they are useful over long time periods but not the short term.

Contributors (and if you reading this then your more than likely a contributor) are of course different, they’re invested in time, philosophically and socially and so are much more likely to stick it out and may actually know how to not only work around problems but we hope through training programs like UDW and UW that we can train people to know how to deal with problems in a more sustainable way. Treating bugs as problems for everyone and not just the individual.

Of course what the mainstream pattern looks like is different, they don’t have contributors or contributing developers, everyone is locked into working around problems. The key difference is that because users are customers, they’re invested in the product. They feel like they own it (even when they don’t) and feel like they ort to stick out problems so that they can get their money’s worth. Of course what do you do in both this and the above case when you have a major headache that you don’t know how to work around or even if you manage to work around? You complain like crazy on your blog, to your friends and to anyone that will hear your pain.

Your complaining is a direct reflection of your ties to a particular product, even to it’s defects.

In the most ideal case and one I was trying to make the case for a few days ago, we’d be able to either turn users into contributors or if that’s not possible then into paying customers that pay for real solutions and code patches, not just work-arounds.

The training that’s going on is a great start, but with better training materials in the community we could be making more contributors aware of the ability of solving problems more permanently and thus improve their input into progress (blogs showing you how to work around a problem are not progress in code terms).

Software isn’t perfect and we need to get lots of people with lots of energy (or money) to invest that energy into the community and to the community collaboration that so effectively benefits everyone. And in my mind the best way to get people quickly attached to FOSS and Ubuntu is to get them to invest into it sooner rather than later, then we have time to get people familiar with the brand and educate them.

Your thoughts?

How to Ask for Translations

Thanks to seven translators who were able to write po based translations and some new heavily artillery svg building scripts to manage it all, I’m pleased to blog about the French, Czech, Serbian and Thai language translations of the short “How to Ask Smart Questions” guide.

Update: Added German, Polish and Hebrew.

This should open it up to more readers. More translations are welcome, but only if you can edit po text file, if you’d like to learn then please do get in touch.

Translators get in touch!

Free at the Point of Download

Yesterday I posted an entry about how I felt that commercial economics should be more widely employed in the FOSS world and that it’s our failure as a community to engaged appropriately with non-material-contributing users in such a way as to make our material contributions more economically sustainable.

Some took this to mean that I was a dangerous capitalist (ironic for those who know my as the dangerous socialist).

OK let’s make one thing clear, I do _not_ advocate for the sale of something that is already paid for. And by that I mean that someone else already put the money or time into making something FOSS and has graciously licensed it for download.

If you need to spend full time on a project to make it a success then you have no choice but to find a way to make money. My proposals so far have been more about promoting the idea of paying for the _creation_ of software than about the rather more impossible _distribution_ of software. To do that would be to make something artificially scarce.

There must be a way to see users in different lights, they are: users, potential contributors, potential inverters and a source of problems. If you can turn every Ubuntu user into a contributor then that’s great, it’s healthy for the ecosystem and it’s growth and I know it’s great for the education of the contributors. On the other hand if you don’t have time to contribute then the next best thing to invest is damned money. Paying for someone else’s time can get you that contribution and it can even be more meaningful since the people who your paying can be highly skilled and your simply saving them from a life of non-foss development.

I’ve not yet given up the hope that we _can_ find a way to have fair Free Software development that pays the bills and delivers freedom.