March 27, 2009
freesoftware
3 Comments
Like Dries, I had the impression that OSBC was something of a parallel world to the type of conferences I usually attend. There were a lot of people from small VC funded companies created around niche enterprise markets (with all due respect to ERPs, electronic document/content management and business intelligence vendors), and the core assumptions that people work under aren’t the same as I’m used to.
For example, it was taken for granted that selling enterprise software implied owning all copyright, and thus getting JCAs signed for contributors outside your company. Also, the way people count the size of their community seems to be different for these company-driven projects – for some, the number of people who create accounts on a forge is their developer community, for others it’s the number of plug-in or extension developers. This isn’t deceitful, but when I think of the core GNOME developer community, I tend to think in terms of people who have access to Subversion, or people who write code for core GNOME components. If we counted the number of people working on GNOME-related projects, or GTK+ applications, then that number gets orders of magnitude bigger.
Why do companies do this? If you say “I have 10 guys working for me, and they write 95% of the code for our core product”, that doesn’t sound quite so impressive. The concern that you’re tring to allay by casting the net as wide as possible is”what will happen to your product if you go out of business?” In enterprise sales, the viability of your company is under scrutiny during risk analysis, and being able to say that you have a community of 9,000 people building your product goes right to that point. One person I spoke to this week said “open source is the ultimate escrow”.
The reality, however, is that for many of these projects, the company cutting funding for the project or going out of business is very bad indeed for the life of the project. Whether it be Mozilla being thrown a lifebelt by AOL, Novell cutting investment in Hula, or Wengo withdrawing from OpenWengo, the result has been that the project stays alive, perhaps (like Bongo and QuteCom) under a different name, but for several months or years, development slows down as an independent developer community grows to fill the void left by the disappearance of the core development team.
I’ve been trying to think of examples of successful community projects which have grown from the ashes of dead companies. A couple that come to mind are Abiword and Nautilus. Are there others that people can think of which went on to success? How about projects that went the other way? Code that went closed and was sold off by liquidators, or projects that have not had a release since the company went under? I’m interested in identifying patterns in the companies involved.
Update: Bassam from Blender pointed out in the comments that Blender and NaN is an example of a company that went out of business, the company founder started a non-profit, got the code released under the GPL (which it hadn’t been before) and built a successful user and developer community around the project post-liquidation. The personal investment of Ton Roosendaal through that difficult process was really the key point that made the transition so successful – he successfully reconciled business and community interests, and create a sense of community ownership of the project, through the selling of company assets to “the community” via a fundraising drive.
March 23, 2009
community, freesoftware, General, gimp, gnome, guadec, libre graphics meeting, maemo
2 Comments
For those who missed the next last week, the Gran Canaria Dasktop Summit website got updated last week – and with it, we opened registration for the conference. This is the organiser’s way of knowing who’s coming, and the way for attendees to reserve accommodation and request, if they need it, travel assistance.
We also concurrently opened the call for participation. Since we’re already a little late organising content this year, we’re going to have a pretty short call – please send abstracts for GNOME-related and cross-desktop content to guadec-papers at gnome.org before April 10th (midnight on the date line, I guess).
The procedure is going to be a little unusual this year because of the co-hosting of GUADEC with Akademy – a GNOME papers committee headed up by Behdad will be choosing GNOME-specific content, and a KDE equivalent will be choosing Akademy content, and we are co-ordinating on the invitation of keynote speakers and choice of cross-desktop content.
The thing that got me excited about this conference last yearn and the reason I was so enthusiastic about combining the conferences, is that cross-desktop content. The Gran Canaria Desktop Summit has the potential to be the meeting place for free software desktop application developers and platform developers, as well as embedded and mobile Linux application developers. We will have the people behind the two most popular free software development platforms coming together.
The conference is an opportunity to plan the future together for developers working on the kernel, X.org, alternative desktop environments like XFCE, application platforms like XUL, Eclipse’s SWT, desktop application developers and desktop-oriented distributions. I’m looking forward to seeing proposals for presentations from all over the mobile and desktop Linux (and Solaris) map.
So to your plumes! We’re not expecting abstracts to be works of art, but we are looking for thought to be given to your target audience and what you want them to get from your presentation. Compelling, entertaining and thought-provoking content will be preferred over “state of…” presentations, or other types of presentation better suited to blog posts. Knock yourselves out!
March 18, 2009
community, freesoftware, gimp, gnome, inkscape, libre graphics meeting, maemo, scribus
No Comments
With little fanfare, this year’s Libre Graphics Meeting fundraiser has been progressing nicely.
In the three weeks since the announcement of the launch of the campaign, we have raised almost $3,000 in community donation – mostly smaller than $50 – from 71 individual donors. Much of the credit for the campaign this year has to go to Jon Phillips of Creative Commons, Inkscape and OpenClipart fame.
The campaign has started earlier this year than last year, when we were really caught unawares by our difficulties in getting sponsors, and has lacked some of the frenzy of the last campaign, but Jon has been doing stellar work keeping the fire burning, and ensuring a regular stream of donations from supporters of projects related to Libre graphics.
It is hard to overstate the importance this conference has to the communities working on projects like Inkscape, GIMP and Scribus, among others, and to overstate the progress we have made because of these conferences in the past few years in the realm of graphics applications on Linux.
It’s useful to point out that in the Linux Foundation desktop linux surveys, the most popular applications which companies and individuals want for Linux are graphics applications – Adobe Photoshop, Illustrator, Premier, Autodesk AutoCAD, Adobe Dreamweaver and Microsoft Visio are the top 6 applications which people are missing on Linux. This conference is all about encouraging the development of applications destined to fulfil those needs. Also worth noting, when asked whether they wanted the applications above ported to Linux, or they wanted to use equivalent Linux applications where possible, a large majority want to use native equivalents, rather than ported commercial applications.
For any of you looking for a good cause which will go directly to supporting high quality applications that you use, I’d encourage you to contribute to the Libre Graphics Meeting. The conference is only as worthwhile as the people attending it, let’s ensure that we get a critical mass once again and provide energy and momentum to all of the participating projects for the coming year.
March 10, 2009
community, freesoftware, maemo
4 Comments
Never one to hold a grudge, I’d like to congratulate the FFmpeg developers on their recent release of FFmpeg 0.5.
I’ve been pretty hard on FFmpeg in the past for their lack of releases and their API policy – it’s made packaging their software hard for distributions, and developing using their libraries hard for third party developers. A release is great news, and I hope it is the first of many.
February 20, 2009
community, freesoftware, inkscape, maemo
2 Comments
Jono asked on the AOC blog for successful governance stories, and while I’m happy to comment on the blog, now that I’ve taken the time to write some down, I thought I might as well share them 🙂
Governance comes in many shapes & sizes of course. My favourite governance stories are about federating individuals, who manage to channel community efforts, maintain a meritocracy where code talks, and yet don’t come across as authoritarians.
Outside of Linus (who’s a good example), Ton Roosendaal of Blender has this kind of presence. Talking to Ton, it is easy to see that he cares about Blender and about the Blender Community. The care and attention that he brings to projects like “Elephants Dream” and “Big Buck Bunny”, or to the supporting documentation and conferences he organises for the community, illustrate the esteem in which he holds his users and his developer community. Even the way the Blender Foundation came into being was amazing.
One of my favourite communities is Inkscape. When they broke from Sodipodi, there was this acrimonious flame war, and something of a bitter taste in people’s mouth. So what Bryce Harrington, Nathan Hurst, MenTaLguY and Ted Gould did when they split was decide to throw open the doors, and accept code from all comers. They set a direction and some ambitious goals, but they were very clear from the start – come right in, you’re welcome. And this gave the project some great results, especially early on when it was still establishing itself. Bryce describes one of them in this article.
The success of the Inkscape project’s governance model is borne out by its ability to escape founder’s syndrome – Bryce, Nathan and Ted have now backed away from the project to some extent, they’re still there as wise heads, but they have passed off the direction of the project to other capable people.
I think the way that Drizzle was born bears some resemblance to this, and I really like the way they have consciously broken down the walls which were necessarily up around MySQL. Brian Aker’s been something of an inspiration on this. His mission statement at the announcement of the project was astounding.
Subversion‘s governance model is an exemplar of best practices too. Set a clear project scope (“Subversion is a compelling alternative to CVS”), clear goals, establish transparent and fair community processes, and open up the gates. Anything within the scope of the project is fair game. And once again, code talks. This story, from Karl Fogel’s “Producing OSS” illustrated the robustness of their governance, and the confidence the project’s leaders had in their ability to influence the project.
The Maemo Community Council has the potential to be a very good governance structure, I think. The idea of a governing body of the community, by the community, for the community, whose goal is to canalise the efforts of a disparate group into something coherent, and to provide a legitimate point of contact for technical decision-makers in Nokia, is a novel one, and hasn’t been tried, as far as I can tell, by other companies.
Counter-examples of good governance are all around, I won’t name any in particular to protect the guilty. But many of them stem from a misguided belief in absolute free speech, to the detriment of the quality of discourse and code in the project (“we are all created equal”) which results in very chatty, but unproductive, individuals taking senior positions in the community, or a sort of shyness of the founder or leader, who doesn’t believe that it’s his place to set a direction and tone.In company-run projects, excessive control or influence is an equally toxic characteristic. Companies who retain a veto on community decisions are companies who do not trust their communities.
February 12, 2009
freesoftware, marketing, work
2 Comments
In gathering material for my series on migrating to free software, one thing immediately jumps out at me.
If your server software uses industry standard protocols to communicate with your client software, then finding free replacement software is easy, painless and transparent for the user. Need a DNS service? Bind’ll do, thank you very much. SMTP? You’re spoiled for choice – there’s Qmail, Postfix, sendmail among others. IMAP, POP3 – try Dovecot, or the UWash IMAP server. SSH – OpenSSH. FTP – PureFTPd, VSFTPd, proftpd are all fine. HTTP – Apache os one of many web servers available.
Pretty much anything with an RFC has free software implementations that are complete, and compare well with commercial competitors. Often, as is the case of Bind or Apache, they are the leaders in their space.
In other words, by using only standard client-server protocols, you have freedom to leave.
However, if your server software “integrates” tightly with your client software, in the style of Notes and Domino from Lotus/IBM, or Exchange Server and Outlook, or Sharepoint and Office, or if it has its own proprietary wire protocol, then you may have a pain point.
So the first lesson, I think, is consider how replacable server elements of your infrastructure are at the acquisition, if you want to avoid lock-in later on. As hard as projects like Samba and Zimbra chase the tail-lights of proprietary wire protocols, the easiest way to avoid them is to rely, where possible, of standard, open protocols.
And that’s what I’m looking for more than anything. How do people get around their pain points? Have people had an Exchange or Sharepoint hang-over? Now that PostPath has gone away, are people looking to get rid of Exchange stuck with Zimbra? Has migrating from MS SQL to a free database server been a pain in the leg? What have people used to centralise authentication and share home directories across the network? Is Samba with LDAP a drop-in solution?
January 23, 2009
community, freesoftware, gnome, marketing
10 Comments
Bamboozled.
That’s what I am. Bamboozled.
For those who haven’t heard this story over the last week, a young woman in Wisconsin accidentally ordered an Ubuntu laptop from Dell and dropped some college classes because she couldn’t make her internet connection work, because when she put in the CD it didn’t launch, and she didn’t have Microsoft Office, which was a requirement for her online classes.
The story, for me, is the total ignorance that both the university and the ISP have of other operating systems. Instruction manuals have information for Windows, maybe Mac, and outside of that, you’re on your own. A newcomer to Linux can’t get by on their own.
Course requirements list specific commercial programs you need to have. And we have a long hard battle to fight for minds & hearts of the universities, hardware manufacturers, ISPs and everyone else who gives software to users, or who exchange files.
The news station story had a happy ending:
However, we think we’ve helped her get back to school.
Verizon says it will dispatch a technician to try to assist her accessing the internet without using the Windows-only installation disk. Verizon says its high-speed internet does indeed support Ubuntu, but some advanced features and installation disks clearly don’t work with Linux.
MATC also says it promises to accept any of Schubert’s papers or class documents using whatever software she has installed.
Schubert’s computer came with Open Office, a word processing software package that is compatible with Microsoft Word. She says she wasn’t aware it was compatible. MATC promised to show her how to save documents in compatible formats so she could enroll in online courses again.
So – happy ending, right? We’re helping win the hearts and minds, we’ve solved a new user’s problems, and we’ve got some nice press showing how Linux users are neglected by the industry.
Ummm… no. That’s what has me bamboozled.
The story quickly got spun as “news channel said Ubuntu sucks” on tech blogs looking for a big headline. And from there, all of a sudden, the reaction of “Ubuntu fans” becomes the story. The young woman in question got some abuse for not figuring out how to solve her problems – she was “lazy”, “a dumb girl”. The news channel gets lambasted for “unscrupulous reporting”.
We all get lumped in the same bucket. When I go to free software conferences and say I work with GNOME, I hear stories about rude behaviour of others in the GNOME community. Outside the free software world, people don’t make a distinction between the lunatic fringe and people like Mark Shuttleworth or anyone in between.
One of these days that’s going to change. The loony fringe will become the loony fringe, and the mainstream will go mainstream. It’s happened with every “movement” to come from off the radar, and it will happen to us. In the meantime we need to start controlling the story – reminding people what’s important, and generally drowning out the fringe.
December 20, 2008
community, freesoftware, General, gnome, marketing, work
5 Comments
Reposting from Neary Consulting: This is an article accompanying the presentation I gave at MAPOS 08 in London on December 9th 2008.
Moving the Mobile industry from purchasing to co-development in free software communities
Recently, Matt Aslett wrote an article about the way that attitudes to free software evolve over time within a company, using a graphic he got from the Eclipse Foundation, based on some Nortel funded research. Software sneaks in on the ground floor, going from simple use of components to a real understanding of community-driven development, resulting, long-term, in building free software projects and strategies.
Matt sees an evolution in attitudes as the software and its value is discovered at different levels of the organisation, before finally the business development side of the company picks up the ball and drives free software into the heart of the company’s product strategy.
I have also seen this learning process in action, but I would express it differently. People discover the value of the freedoms granted by free software one by one, more or less independently of their level in an organisation – exploring each freedom before discovering its limitations, and thus discovering the value of the next freedom, and qualifying for the next level.
The core freedoms in the Free Software Definition which are granted to the user of free software are:
- Freedom to use
- Freedom to modify
- Freedom to share, freedom to redistribute
- Freedom to participate
As companies start to integrate free software components into their products, they discover the value of these freedoms one by one.
Use
The first thing that people see about free software is FREE! As in zero cost. The days when companies reject a product out of hand because they don’t have to pay for it are gone – Linux, OpenOffice.org, Apache, Red Hat and a plethora of other “free” products have proven themselves in the marketplace, and companies are now prepared to allow free software components into their solutions, after appropriate consideration of the licences involved.
To quote one attendee at MAPOS 08, “why would I want to write a compression library, when I can download the best one in the world from zlib.org?” In the area of specialised components for secure communications, compression/decompression, a commodity kernel, and a bunch of other situations, it is appropriate to use free software components off-the-shelf. We expect them to work, and we don’t expect to ever need to talk to the maintainer.
Free software components are in use like this in thousands of systems solutions and commercial products, often without their authors even being aware of it. The main advantage of this for a systems or product company is a saving of time and money, through having a fully functional component without having to go through a purchasing process, and a reduced software bill of materials. An additional advantage is the simplification of your licensing due diligence, thanks to the relatively well-understood consequences of the various popular free software licences.
The difficulty arises when the software doesn’t meet your needs. In many cases, libraries are written by an individual to scratch an itch – it works for him, but is not quite up to your requirements. As one friend of mine put it: “Open Source: 80% as good as the last guy needed it to be”.
Perhaps it’s software that works on 32 bit platforms, but has never been tested for 64 bit. Perhaps it has not been ported to ARM or MIPS. Or perhaps the author simply never imagined that anyone would want the feature which you find indispensable.
In this situation, you can always ask the software author to write the feature or fix the bug for you – but since there is no client/supplier relationship between you, it is entirely reasonable for a volunteer to put your request on the long finger, or reject it outright.
At this point, you realise the value of having the source code – you can modify the software to meet your needs, or pay someone else to do it for you.
Modify
Being able to modify software that doesn’t quite meet your needs is amazing. This is the way things used to work by default, but the shrink-wrapped software revolution of the 1980s got everyone used to the idea that software was a valuable asset to be protected from public view at all costs. When I worked for Informix in the late ’90s, we used to refer to the source code of our leading product as “the crown jewels”.
With the widespread acceptance of free software as an alternative, developers are no longer surprised when they may see how a program works, and change its behaviour. This ability brings two important and immediate benefits – you have control of the behaviour of the software, and you can adapt it to suit exactly your needs. The old choice of build vs buy has become: build vs buy vs extend.
This situation is common in software services companies which provide vertically integrated “solutions” to corporate clients. You take components where you can find them to speed up initial development, stick everything together with duct-tape, hack whatever you need in whatever libraries you’re using to make everything pass the client’s integration tests, and then publish a set of .tar.gz files somewhere on the website of the company to fulfil any licensing requirements.
This control and ability to tailor a solution comes at a price, however. Over and above the cost of making the changes, your team is lumbered with a maintenance problem. Let’s say that implementing the features you need on top of a component the first time round takes a month. Fixing bugs in the features when it has been rolled out can take another few weeks. A few months later, the upstream product you’re based on goes and releases a shiny new version, with lots of compelling new features that you really want.
The cost of integrating your features into the newer version, and doing extensive regression testing before rolling out the new version, might take you another 6 weeks. It is not unusual for time spent integrating your work into later versions to quickly outweigh initial development time and investment. Inconveniently, this is typically effort which is not budgeted for beforehand.
After a company has run into this problem a couple of times, over the course of a year or two, someone will usually suggest that you propose that the features you have developed be sent upstream to the projects you work with – if the feature is accepted, you have solved your maintenance problem, it will be in all future releases of the project, and all of that tricky integration work and regression testing work will get done upstream, as part of normal maintenance.
Redistribute
And so you tell your star hacker Jack that he has two weeks to get your 5,000 line patch down to manageable size by getting your work integrated upstream. (when I said this at MAPOS, no-one laughed – so maybe this does not sound as ridiculous as I thought it did).
He diligently goes to work, cleaning up his code, getting rid of all the warnings, spliting up the big diff into small manageable chunks, creating accounts in 10 different bug trackers, signing up to a dozen mailing lists, creating 47 bugs with terse descriptions, attaching proposed bug fixes, and for major features he sends email telling people that the feature is there and asking for review.
By the end of a frantic month, two weeks more than he was given, he reckons that if everything he’s submitted is accepted, your 5,000 patch will be down to a more manageable 2,000 line patch.
What happens next is… underwhelming.
Major features and bug fixes lie unreviewed for weeks or months. Those that are reviewed need changes which take time and effort. Some patches are rejected outright because they’re too big and the feature is difficult to review.
A post mortem analysis of the project of “giving back to the community” might identify some of the following conclusions:
- Not enough time and resources were devoted to advocating your changes upstream
- Personal relationships between Jack and the project maintainers led to a much higher acceptance rate for patches and feature requests
- The projects were initially evaluated on technical grounds, no thought was given to the developer community underpinning it
- In some cases, maintainers priorities were ill-understood
There are two common conclusions that people make from this kind of analysis;
- It’s not worth it. They don’t want our work, and the time we’re spending is costing us more than maintaining out-of-tree patches
- Perhaps if you had engaged with the projects before modifying them heavily, or had been regularly sending contributions, that the maintainers would have been more encouraging, and might have been more prepared to consider your work. If someone from your company was a maintainer or committer already, you would have had a valuable short-cut to getting your agenda implemented in the upstream project.
If you choose door number 1, you will go no further in your quest to really understanding free software processes. This is a reasonable thing to do, but the costs involved are often miscalculated. In addition, the benefits of influencing upstream projects are often vastly underestimated.
If you choose door number 2, you have concluded, in short, that it is madness to include a component in one of your products and exert no influence with upstream projects.
Participate
To have influence, you must understand how the community around a project works. Someone within the team must become an active, trusted member of the community. Once they have gained the trust of the community through their contributions, there may be some procedure to follow for them to become a maintainer of the project, or to gain commit privileges.
These considerations are not technical, for the most part. Friendship and trust are fuzzy human concepts. And this more than anything else brings me to my final point.
Community is hard
For a start, every community is different. They all have different people, different behavioural norms, different dynamics, different forums for communication.
Taking GNOME Mobile as an example, there are 18 projects in the GNOME Mobile platform, with another 10 or so in incubation. Within that, we have a large number of projects housed on gnome.org, and governed by our rules, procedures and conventions. And yet each project has its own set of maintainers – GTK+ is maintained by a committee of around 10 people, EDS is maintained principally by Novell employees, gtkmm has one core maintainer, and so on.
On top of this are a number of freedesktop.org projects, and a couple more which are not under either of these umbrellas. To be an effective influencer of GNOME Mobile, you need to learn the culture of over 20 projects, of wildly varying sizes and baggage.
There are a number of issues to bear in mind when you approach a free software community for the first time. The main one is that while the vast majority of projects think that they are welcoming people with open arms and are very welcoming, if you are a stranger to their land, it is very likely that you will be getting exactly the opposite message.
In some cases, the extent of the welcome is “go and read wiki page telling people how to contribute to the project”. In other cases, no wiki page exists. Occasionally, you will be told that you’re asking your question on the wrong mailing list, or in the wrong way, or that you should read the relevant documentation first. It is not unusual for people to answer questions with a very terse answer – perhaps a link to a mailing list discussion or web-page where the answer can be found.
In general, all of these things are intended to fulfil a simple goal – get you the information you want as quickly as possible, in a way that wastes the time of people already in the project as little as possible. An admirable goal indeed, but as a newcomer, this is not how people are used to being welcomed. Eric Raymond wrote extensively about this in his essay “How to ask questions the smart way”.
Indeed, one of the hardest things to do as an outsider looking in is to evaluate when a community is healthy and viable, and when it has problems which will prevent you from working effectively in partnership. Few resources which talk about healthy free software community projects exist – “Producing Open Source Software”, by Karl Fogel, is something of a bible on the subject, and should be required reading for anyone considering investing in free software. I have also found some presentations, including Simon Phipps’s 2006 OSCon keynote “The Zen of Free” and “How Open Source Projects Survive Poisonous People” by Ben Collins-Sussman and Brian Fitzpatrick, to be excellent resources in helping identify traits of what makes up a healthy community. Two other useful papers which include metrics on measuring the openness of a community, including its governance model, are Pia Waugh’s “The Foundations of Openness” and François Druel’s Ph.D. Thesis (in French) “Évaluation de la valeur à l’ère du Web ” (PDF – rough translation: “Measuring value in the era of the Web”).
Some of the considerations when evaluating a community are whether there is clear leadership, whether that leadership is an individual, a group, or a company, how the leaders are chosen (if they are chosen), what technological and social barriers to participating in the project exist, whether the community processes are documented and transparent, what recourse one has if one feels badly treated, what the behavioural norms of the community are (and whether they are documented) – the list goes on. Pia’s paper in particular gives a great overview in the section “Open Governance”.
Call to arms
And so I close with a call to arms to both free software communities, and companies planning on developing an “open source strategy”.
First, developers, document your communities. Think of yourselves as guides, explaining the cultural quirks of your country to a newly arrived immigrant. Be explicit. In addition to explaining where and how your community works, document how one gains trust and responsibility. Ensure that a newcomer can learn quickly what he needs to do to become a citizen and from there a project maintainer. I am not saying that it should be easy for someone to become a maintainer. What I am suggesting is that it should be easy to see how one becomes a maintainer before doing it
Next, project managers, software developers, company leaders: please, please, please – save yourself time and money and, when you reach the point where you will be building products which depend on good free software components, let the second thing that you do, right after a technical evaluation, be to evaluate the health of the community. A community where you can earn influence and guide the project to better meet your needs is a better long-term investment than betting on a slightly technically superior solution with an unhealthy governance model.
You are building products that you will be selling, supporting, and hopefully profiting from. In this situation, does it really make sense not to have the developer’s ear?
December 4, 2008
community, freesoftware, General, gnome, guadec, home, marketing, running
3 Comments
I’m going to have a busy busy month of December.
La Fête des Lumières
I’ve written about the Festival of Light in Lyon before, and it’s coming around again. I’m going to bring the boys into Lyon with over 1 million other people to walk around cold streets looking at light shows on some of Lyon’s best known landmarks. This year will be bigger than ever, with a €2 000 000 budget, and I have had a sneak preview of some of the installations from training runs on the riverbanks of the Rhône and in Parc de la Tête d’Or. The light shows are always interesting, sometimes a little arty, often spectacular. This year, I would like to bring everyone up to the top of Fourvière to have a view of the entire city.
MAPOS 08
First up, next week I’ll be in London to give a presentation at MAPOS (nothing to do with cartography), the Mobile Application Platforms in Open Source conference. My presentation is titled “Increasing Ecosystem Cooperation”, and will be at 15:30 on Tuesday afternoon.
I will talk about the need for companies building on free software to make mobile application platforms to work actively to develop that platform. I hope to get the message across that building on free software is not a client-supplier relationship, but is more like a research grant or R&D function.
Companies in this space are used to surveying the market, choosing the best solution, and then paying for it, so that some third party will keep improving it. The integrator model which many distributions use, of modifying the basic building blocks according to your needs, and sending changes up-stream after they have been developed, is an intermediate model, which has both positive and negative sides. But what we really need is an active co-development, with companies building on our platform investing R&D dollars into targeted co-operation across multiple companies, to address coherently a problem space (such as the needs of mobile platforms).
GNOME Foundation members are entitled to a 15% discount on registration, for those thinking of going.
Bibliothèque Municipal de Lyon
On the evening of the 12th, I will be participating with a panel including some people from Handicap International’s Centre icom which I visited a few weeks ago. I will be presenting GNOME’s accessibility capabilities to a seminar on Information Technology and Handicap both to show its power and also to advertise its freedom (philosophical and financial) compared to proprietary programs like Jaws.
Christmas run
On the 14th, I’ll be in Aix les Bains, running in the Corrida des Lumières with a bunch of my club-mates from the AAAL – since running 39’10 last month in a 10k, I’ve been hyped about running another competition. I’ve been training well, and Christmas runs are always fun with mulled wine & dinner afterwards.
GUADEC co-ordination
Along with Vincent Untz, I’ll be flying out to Las Palmas on the 15th (oh how life is hard) to meet with Alberto Ruiz (for GNOME), the Gran Canaria Cabildo (the local government), and the KDE eV board members co-ordinating the conference from their end. We’ll be testing out the cheaper hotel accommodation option for the conference (I hope there will also be a “very low budget” option like a youth hostel or a campsite), meeting with local volunteers, and resolving the major issues we need to work out before we ramp up the next phase of the organisation – gathering and scheduling conference content.
Judo
Thomas started Judo this year, and he loves it. I have stayed around after bringing him a couple of times, and the warm-up they do is certainly fun, but challenging. On the 17th of December, Thomas will be having his end-of-year competition, the first time he’ll be in a Judo competition. It’s a bit of fun, really – and yet I hope that introducing an aspect of competition into the activity doesn’t in some way ruin it for him.
Christmas skiing
As usual, Christmas will be on the 25th of December this year. Last year we were in Ireland, but this year we’re going to celebrate with just the family, and the kids will get to wake up in their own beds. On the 27th, Anne, the kids and myself are going to go into the Alps to meet up with the rest of her family for a week. We’re hopefully going to get in some skiing, go walking in the woods, eat too much, drink too much, and be very merry indeed. It’ll be my second time celebrating the new year in the mountains, and with the cold & the snow it feels like Christmas in the films. I love it.
Go
When Lefty wrote about trying to get a particular type of brush in Japan,the intricacy of the detail of the story made me think of Go. Go is an ancient game with a small number of simple rules, which result in a game of deep complexity and beauty, and a handicap system which allows unevenly matched players to play competitive games.
It is a game steeped in the kind of tradition that Lefty talks about – professional Go tournaments are played on goban cut from a particular type of rare wood, with white stones made from the carved and polished shells of a specific type of clam, gathered on a single beach in Japan, and the black stones being made from slate mined in a single mine. The Go board is elongated, just enough to make it appear square when you are sitting in front of it, and the size of the black and white stones are slightly different, to compensate the visual impression of white stones appearing larger.
I’m back playing regularly (mostly, unfortunately, with GNU Go, who is more than a match for me on bigger boards) and have taught Thomas the basics. He’s caught on surprisingly rapidly – he’s up to the stage where he can beat me in a 9×9 game with 4 stones. Go is a very intuitive, rather than analytical, game, and some of the key concepts like influence, “good shape”, life and death are quite abstract, making it a game that children can “get” quicker than adults.
I’ve also found parallels between the ebb and flow of a Go game and free market economics. The core principle that the goal is not to kill your enemy, but simply to reduce his territory while protecting yours through strategically placing your stones to create influence and strength, matches closely my ideas of how markets work.
Phew! That’s a lot of “stuff”.
November 28, 2008
community, freesoftware, gnome
1 Comment
Friday afternoon I went along to Handicap International’s Centre icom’ here in Lyon, to see what they do first hand, to talk to the people there, and to figure out if there was any way that GNOME could be working better with people like them.
Handicap International, like all of the other groups I have talked to involved in bringing IT to people with disabilities – or indeed to anyone who doesn’t know computing very well – have a natural affinity with Free Software. First, for its price – equivalent proprietary software is expensive. But also for the philosophy of Universal Access that is so important to the GNOME project – that everyone should be able to access IT, regardless of their culture, or their physical or technical ability.
Handicap International Centre icom
We had a great afternoon, including role-playing. I played a deaf person who could lip-read, it was eye-opening to see how long it took for people to realise what my handicap was, when a few extra minutes taken at the start of the session would have helped a lot. We got to try lots of AT, including a golf-cap with a metal tip for controlling the mouse with head movements, and a software face-tracker that worked with an ordinary webcam, both of which brought home just how hard using a computer is if you can’t use a mouse (we used both with dwell-clicking enabled).
It was surprising to see how little specific AT hardware there was – all the PCs were normal, and 90% of what the Centre does is set up preferences, and where necessary use specialised software.
One other thing was surprising – in spite of being aware of Dasher, there is no-one in the center that uses it – they prefer the on-screen keyboard. I wonder if there isn’t room for a dialogue there – and I would definitely like to hear from people using Dasher for actual data entry, to see in what situations it’s adopted.
« Previous Entries Next Entries »
