Negative Community Reaction Development

I’ve been thinking about what it is that cultivates a negative reaction from people who use your software and who are invested in it’s success. This line of thinking has obviously been brought about by the new Ubuntu Unity interface and the strong reactions to both technical implementation and implementation method.

Firstly I want to separate out the general masses and the competition (no offence Jeff), there are plenty of people on the internet who just love to troll and there are plenty of people in other distro that talk nonsense based on tribal affiliation. Ignore them, I’m talking about negative reactions from people who make up the fixtures and fittings in the community, for Ubuntu, this would be Ubuntu Members (but not MOTU).

I’m sure we’ve all seen comments such as:

I really liked Maverick, but now with this new Unity thing that Mark has dictated will will all be using, I guess I’ll stick around for 11.04 but then move when 11.10 comes out and we have no choice but to use Unity.

The user in the quote is frustrated that development on Unity has seemingly come out of nowhere to crush all the familiarity they used to have and in order to continue to use the latest and greatest Firefox and OpenOffice they’ll be forced to put up with design decisions that will be against their own personal internal aesthetic. They’re not wrong in their concern, but of course this is a risky move that their distribution is attempting; a massive coarse correction which delves deep into the bowls of the ship we’re all sailing in and is tinkering with the engine and reshaping the hull to see if it’ll make the thing go faster.

Much like someone below deck messing about, we can’t see what the hell is going on, all we can see is the speed of the boat. So for a while the ship starts to slow down and we start to wonder if our friendly hacker is down there hitting the engine with a wrench and drilling holes in the hull. Of course the truth is that they’re risking everything on thought out designs will the same goals as most on deck, that part needs trust.

Alternatively we read official messages like:

Unity is a new interface to attract new users to Ubuntu and to attempt to jump the chasm, not everyone will be happy with the design direction; but we can’t hold back developing a user friendly desktop operating system waiting for a consensus that will never arrive.

And this too is true, but again is missing bits of the puzzle. Nothing about this kind of press release calms the fears of users, in fact it may only work with casual users and those that really trust where the ideas are coming from. It’s just as nutty to ask everyone in a committed community to trust you while you ignore the majority of what they say in order to get on with the herculean job before you as it is for users to suggest developers are deliberately planning to remove functionally just to hear the sweet screams of users.

The key is probably trust. The community members can trust the corporate development because we’re all in the same boat and they’re hardly likely to throw us overboard and corporates need to trust their community more, they’re not as design blind as we like to think, sometimes they’re just really bad at describing why they’re having trouble. This is especially true when a community member looks after lots of ubuntu user’s computers. We as developers just need to be better at reading/translating them.

I drew this graph to try and illustrate what it is about the development method that annoys people and provokes them into irrational opposition or productive support for any given project:

What are your thoughts?

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.

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?

Gnome Icons: What the Devels are up to

My friend leftyfb over on his blog has highlighted an issue with gnome that I always thought was a genuine oversight. i didn’t think that the gnome developers were seriously and deliberately removing the icons from certain menus. For the past few months, every time I went into the System menu, I thought the missing icons were because some bug that no one could find the time to fix, had crept in.

Apparently not. according to records it was a discussion by developers to remove visual queues and make Ubuntu harder to use for dyslexics like myself. Forcing us to read words which we can very easily misread and not letting us use icons in which a combination of shape and colour can act as reinforcing cues for the noun of these menus.

I know dyslexia isn’t a fun disability like blindness and deafness, but a little consideration would have been nice.

The exact regression aside, Mike points out in his blog another worrying facet that I’ve seen myself all too often in the gnome developer community. A community of disagreeableness. As I was saying yesterday in my blog post about disagreeable filtering: Being nasty and obnoxious is a poor man’s user contribution filter compared to being patient, understanding and using dialectical tools to work out problems so they can achieve as many wishes as is possible.

I don’t expect devels to say they’re good at design when they are only good at systematics. If you’ve worked out some of the science or some basic principles of design, it doesn’t make you a designer. It’s not always parcelled into simple rules and regulations. Sure, sometimes they help, but they’re at best guidelines and a good starting point and you’re not expected to use them as iron clad regulation. Of course this is an obvious warning sign that the coders have taken to design before learning anything about servitude let alone elegance.

I’m not pleased with gnome developer’s attitudes. Yes, sure, users are annoying, but why aren’t you asking them for money in exchange for listening to them? Instead you’re pretending that you’re an open community that welcomes contributions from unskilled users, but in fact want to cut yourself off from all users. A sort of Unenlightened self interest, the bastard brother of Enlightened self interest who is responsible for cutting ties between developers as users and pure users.

This is why I protest that we MUST start being honest about how progress is funded. You only have to listen to the people that control the purse strings, listening to anyone else is charity and is not guaranteed in any way. If we want to have users making a real difference in the community and ultimately getting the software that they want to have, then we MUST make sure those users have a way to pay for such services.

If we want to have users making a real difference in the community and ultimately getting the software that they want to have and not the software that we think they ort to have, then we have to listen to them and be able to ask them to pay for the time of developers.

Wishlist Ubuntu

I was on the Ubuntu forums yesterday checking out a couple of threads and it struck me that we still haven’t managed to get out of a weird feeling that the amorphous developer community surrounding Ubuntu somehow owes the users who post wishlist threads a free ride.

For instance in one thread there is a general complaint that developers are not doing enough new things for lucid, or not enough testing, or enough stabilisation. When in fact the developers are doing exactly the right amount of development and exactly the right amount of work, based upon what their own needs and feelings are.

Of course this part is hard to understand for users that have been told that Ubuntu is a free lunch. Developers are under no obligation to do anything unless paid to do so. It doesn’t matter how many wishlist threads there are, few developers are ever going these things for ideas and I wonder if it’s actually a cry for help that these users don’t know how to get involved. I’m reminded of this phrase:

“Too many Chefs and not enough Cooks”

Yes FOSS gives you the power to be your own Chef, to say what you like and don’t like, to use what you find useful and to dismiss anything you don’t. But along with that it gives you the responsibility to be your own cook too. You have to work at what you need and it’s only useful to complain when your hoping to strike up a decent and productive discussion.

Perhaps this is why the Opportunistic Developer project is important, to try and convince more Chefs to get down and do some of the grunt work in solving their problems. I just wish there was an Opportunistic Payment project that allows people who can’t contribute time, to at least be able to push development forward with good old fashioned money.


Launchpad and Gtk weaving

I’ve making a generic gtk class which will allow me to set up threading for a nautilus python extension, the idea is to set off a new gtk main loop with a window (using gtk builder) and set off a thread. To bind them together I’m using gobject timers with stacks of calls which cross the boundaries.

So far it works and has improved the load speed and usability of the ground control project. The generic classes mean I can expand it and reduce code complexity.

What are your thoughts on this problem? Is this the right pattern to use?