Paul Boddie's Free Software-related blog
Paul's activities and perspectives around Free Software
Where Now for the Free Software Desktop?
May 31st, 2013
It is a recurring but tiresome joke: is this the year of the Linux desktop? In fact, the year I started using GNU/Linux on the desktop was 1995 when my university department installed the operating system as a boot option alongside Windows 3.1 on the machines in the “PC laboratory”, presumably starting the migration of Unix functionality away from expensive workstations supplied by Sun, DEC, HP and SGI and towards commodity hardware based on the Intel x86 architecture and supplied by companies who may not be around today either (albeit for reasons of competing with each other on razor-thin margins until the slightest downturn made their businesses non-viable). But on my own hardware, my own year of the Linux desktop was 1999 when I wiped Windows NT 4 from the laptop made available for my use at work (and subsequently acquired for my use at home) and installed Red Hat Linux 6.0 over an ISDN link, later installing Red Hat Linux 6.1 from the media included in the official boxed product bought at a local bookstore.
Back then, some people had noticed that GNU/Linux was offering a lot better reliability than the Windows range of products, and people using X11 had traditionally been happy enough (or perhaps knew not to ask for more) with a window manager, perhaps some helper utilities to launch applications, and some pop-up menus to offer shortcuts for common tasks. It wasn’t as if the territory beyond the likes of fvwm had not already been explored in the Unix scene: the first Unix workstations I used in 1992 had a product called X.desktop which sought to offer basic desktop functionality and file management, and other workstations offered such products as CDE or elements of Sun’s Open Look portfolio. But people could see the need for something rather more than just application launchers and file managers. At the very least, desktops also needed applications to be useful and those applications needed to look, act like, and work with the rest of the desktop to be credible. And the underlying technology needed to be freely available and usable so that anyone could get involved and so that the result could be distributed with all the other software in a GNU/Linux distribution.
It was this insight – that by giving that audience the tools and graphical experience that they needed or were accustomed to, the audience for Free Software would be broadened – that resulted first in KDE and then in GNOME; the latter being a reaction to the lack of openness of some of the software provided in the former as well as to certain aspects of the technologies involved (because not all C programmers want to be confronted with C++). I remember a conversation around the year 2000 with a systems administrator at a small company that happened to be a customer of my employer, where the topic somehow shifted to the adoption of GNU/Linux – maybe I noticed that the administrator was using KDE or maybe someone said something about how I had installed Red Hat – and the administrator noted how KDE, even at version 1.0, was at that time good enough and close enough to what people were already using for it to be rolled out to the company’s desktops. KDE 1.0 wasn’t necessarily the nicest environment in every regard – I switched to GNOME just to have a nicer terminal application and a more flexible panel – but one could see how it delivered a complete experience on a common technological platform rather than just bundling some programs and throwing them onto the screen when commanded via some apparently hastily-assembled gadget.
Of course, it is easy to become nostalgic and to forget the shortcomings of the Free Software desktop in the year 2000. Back then, despite the initial efforts in the KDE project to support HTML rendering that would ultimately produce Konqueror and lead to the WebKit family of browsers, the most credible Web browsing solution available to most people was, if one wishes to maintain nostalgia for a moment, the legendary Netscape Communicator. Indeed, despite its limitations, this application did much to keep the different desktop environments viable in certain kinds of workplaces, where as long as people could still access the Web and read their mail, and not cause problems for any administrators, people could pretty much get away with using whatever they wanted. However, the technological foundations for Netscape Communicator were crumbling by the month, and it became increasingly unsupported and unmaintained. Relying on a mostly proprietary stack of software as well as being proprietary itself, it was unmaintainable by any community.
Fortunately, the Free Software communities produced Web browsers that were, and are, not merely viable but also at the leading edge of their field in many ways. One might not choose to regard the years of Netscape Communicator’s demise as those of crisis, but we have much to be thankful for in this respect, not least that the Mozilla browser (in the form of SeaMonkey and Firefox) became a stable and usable product that did not demand too much of the hardware available to run it. And although there has never been a shortage of e-mail clients, it can be considered fortunate that projects such as KMail, Kontact and Evolution were established and have been able to provide years of solid service.
You Are Here
With such substantial investment made in the foundations of the Free Software desktop, and with its viability established many years ago (at least for certain groups of users), we might well expect to be celebrating now, fifteen years or so after people first started to see the need for such an endeavour, reaping the rewards of that investment and demonstrating a solution that is innovative and yet stable, usable and yet reliable: a safe choice that has few shortcomings and that offers more opportunities than the proprietary alternatives. It should therefore come as a shock that the position of the Free Software desktop has not been as troubled as it is now for quite some time.
As time passed by, KDE 1 was followed by KDE 2 and then KDE 3. I still use KDE 3, clinging onto the functionality while it still runs on a distribution that is still just about supported. When KDE 2 came out, I switched back from GNOME because the KDE project had a more coherent experience on offer than bundling Mozilla and Evolution with what we would now call the GNOME “shell”, and for a long time I used Konqueror as my main Web browser. Although things didn’t always work properly in KDE 3, and there are things that will never be fixed and polished, it perhaps remains the pinnacle of the project’s achievements.
On KDE 3, the panel responsible for organising and launching applications, showing running applications and the status of various things, just works; I may have spent some time moving icons around a few years ago, but it starts up and everything uses the right amount of space. The “K” (or “start”) menu is just a menu, leaving itself open to the organisational whims of the distribution, but on my near-obsolete Kubuntu version there’s not much in the way of bizarre menu entry and application duplication. Kontact lets me read mail and apply spam filters that are still effective, filter and organise my mail into folders; it shows HTML mail only when I ask it to, and it shows inline images only when I tell it to, which are both things that I have seen Thunderbird struggle with (amongst certain other things). Konqueror may not be a viable default for Web browsing any more, but it does a reasonable job for files on both local disks and remote systems via WebDAV and ssh, the former being seemingly impossible with Nautilus against the widely-deployed Free Software Web server that serves my files. Digikam lets me download, view and tag my pictures, occasionally also being used to fix the metadata; it only occasionally refuses to access my camera, mostly because the underlying mechanisms seem to take an unhealthy interest in how many files there are in the camera’s memory; Amarok plays my music from my local playlists, which is all I ask of it.
So when my distribution finally loses its support, or when I need to recommend a desktop environment to others, even though KDE 3 has served me very well, I cannot really recommend it because it has for the most part been abandoned. An attempt to continue development and maintenance does exist in the form of the Trinity Desktop Environment project, but the immensity of the task combined with the dissipation of the momentum behind KDE 3, and the effective discontinuation of the Qt 3 libraries that underpin the original software, means that its very viability must be questioned as its maintainers are stretched in every direction possible.
Why Can’t We All Get Along?
In an attempt to replicate what I would argue is the very successful environment that I enjoy, I tried to get Trinity working on a recent version of Ubuntu. The encouraging thing is that it managed to work, more or less, although there were some disturbing signs of instability: things would crash but then work when tried once more; the user administration panel wasn’t usable because it couldn’t find a shared library for the Python runtime environment that did, in fact, exist on the system. The “K” menu seemed to suffer from KDE 4 (or, rather, KDE Plasma Desktop) also being available on the same system because lots of duplicate menu entries were present. This may be an unfortunate coincidence, Trinity being overly helpful, or it may be a consequence of KDE 4 occupying the same configuration “namespace”. I sincerely hope that it is not the latter: any project that breaks compatibility and continuity in the fashion that KDE has done should not monopolise or corrupt a resource that actually contains the data of the user.
There probably isn’t any fundamental reason why Trinity could not return KDE 3 to some level of its former glory as a contemporary desktop environment, but getting there could certainly be made easier if everyone worked together a bit more. Having been obliged to do some user management tasks in another environment before returning to my exploration of Trinity, I attempted to set up a printer. Here, with the printer plugged in and me perusing the list of supported printers, there appeared to be no way of getting the system to recognise a three- or four-year-old printer that was just too recent for the list provided by Trinity. Returning to the other environment and trying there, a newer list was somehow obtained and the printer selected, although the exercise was still highly frustrating and didn’t really provide support for the exact model concerned.
But both environments presumably use the same print system, so why should one be better supplied than the other for printer definitions? Surely this is common infrastructure stuff that doesn’t specifically relate to any desktop environment or user interface. Is it easier to make such functionality for one environment than another, or just too convenient to take a short-cut and hack something up that covers the needs of one environment, or is it too much work to make a generic component to do the job and to package it correctly and to test it in more than a narrow configuration? Do the developers get worried about performance and start to consider complicated services that might propagate printer configuration details around the system in a high-performance manner before their manager or supervisor tells them to scale back their ambition?
I remember having to configure network printers in the previous century on Solaris using special script files. I am also sure that doing things at the lowest levels now would probably be just as frustrating, especially since the pain of Solaris would be replaced by the need to deal with things other than firing plain PostScript across the network, but there seems to be a wide gulf between this and the point-and-click tools between which some level of stability could exist and make sure that no matter how old and nostalgic a desktop environment may be perceived to be, at least it doesn’t need to dedicate effort towards tedious housekeeping or duplicating code that everyone needs and would otherwise need to write for themselves.
The Producers (and the Consumers)
One might be inclined to think that my complaints are largely formed through a bitter acceptance that things just don’t stay the same, although one can always turn this around and question why functioning software cannot go on functioning forever. Indeed, there is plenty of software on the planet that now goes about its business virtualised and still with the belief, if the operating assumptions of software can be considered in such a way, that it runs on the same range of hardware that it was written for, that hardware having been introduced (and even retired) decades ago. But for software that has to be run in a changing environment, handling new ways of doing things as well as repelling previously unimagined threats to its correct functioning and reliability, needing a community of people who are willing to maintain and develop the software further, one has to accept that there are practical obstacles to the sustained use of that software in the environments for which it was intended.
Particularly the matter of who is going to do all the hard work, and what incentives might exist to persuade them to do it if not for personal satisfaction or curiosity, is of crucial importance. This is where conflicts and misunderstandings emerge. If the informal contract between the users and developers were taking place with no historical context whatsoever, with each side having expectations of the other, one might be more inclined to sympathise with the complaints of developers that they do all the hard work and yet the users merely complain. Yet in practice, the interactions take place in the context of the users having invested in the software, too. Certainly, even if the experience has not been one of complete, uninterrupted enjoyment, the users may not have invested as much energy as the developers, but they will have played their own role in the success of the endeavour. Any radical change to the contract involves writing off the users’ investment as well as that of the developers, and without the users providing incentives and being able to direct the work, they become exposed to unpredictable risk.
One fair response to the supposed disempowerment of the user is that the user should indeed “pay their way”. I see no conflict between this and the sustainable development of Free Software at all. If people want things done, one way that society has thoroughly established throughout the ages is that people pay for it. This shouldn’t stop people freely sharing software (or not, if they so choose), because people should ultimately realise that for something to continue on a sustainable basis, they or some part of society has to provide for the people continuing that effort. But do desktop developers want the user to pay up and have a say in the direction of the product? There is something liberating about not taking money directly from your customers and being able to treat the exercise almost like art, telling the audience that they don’t have to watch the performance if they don’t like it.
This is where we encounter the matter of reputation: the oldest desktop environments have been established for long enough that they are widely accepted by distributions, even though the KDE project that produces KDE 4 has quite a different composition and delivers substantially different code from the KDE project that produced KDE 3. By keeping the KDE brand around, the project of today is able to trade on its long-standing reputation, reassure distributions that the necessary volunteers will be able to keep up with packaging obligations, and indeed attract such volunteers through widespread familiarity with the brand. That is the good side of having a recognised brand; the bad side is that people’s expectations are higher and that they expect the quality and continuity that the brand has always offered them.
What’s Wrong with Change?
In principle, nothing is essentially wrong with change. Change can complement the ways that things have always been done, and people can embrace new ways and come to realise that the old ways were just inferior. So what has changed on the Free Software desktop and how does it complement and improve on those trusted old ways of doing things?
It can be argued that KDE and GNOME started out with environments like CDE and Windows 95 acting as their inspiration at some level. As GNOME began to drift towards resembling the “classic” Mac OS environment in the GNOME 2 release series, having a menu bar at the top of the screen through which applications and system settings could be accessed, together with the current time and other status details, projects like XFCE gained momentum by appealing to the audience for whom the simple but configurable CDE paradigm was familiar and adequate. And now that Unity has reintroduced the Mac-style top menu bar as the place where application menus appear – a somewhat archaic interface even in the late 1980s – we can expect more users to discover other projects. In effect, the celebrated characteristics of the community around Free Software have let people go their own way in the company of developers who they felt shared the same vision or at least understood their needs best.
That people can indeed change their desktop environment and choose to run different software is a strength of Free Software and the platforms built on it, but the need for people to have to change – that those running GNOME, for example, feel that their needs are no longer being met and must therefore evaluate alternatives like XFCE – is a weakness brought about by projects that will happily enjoy the popularity delivered by the reputation of their “brand”, and who will happily enjoy having an audience delivered by previous versions of that software, but who then feel that they can change the nature of their product in ways that no longer meet that audience’s needs while pretending to be delivering the same product. If a user can no longer do something in a new release of a product, that should be acknowledged as a failing in that product. The user should not be compelled to find another product to use and be told that since a choice of software exists, he or she should be prepared to exercise that choice at the first opportunity. Such disregard for the user’s own investment in the software that has now abandoned him or her, not to mention the waste of the user’s time and energy in having to install alternative software just to be able to keep doing the same things, is just unacceptable.
“They are the 90%”
Sometimes attempts at justifying or excusing change are made by referring to the potential audience reached by a significantly modified product. Having a satisfied group of users numbering in the thousands is not always as exciting as one that numbers in the millions, and developers can be jealous of the success of others in reaching such numbers. One still sees labels like “10x” or “x10” being used and notions of ten-fold increases in audiences as being a necessary strategy phrased in a new and innovative way, mostly by people who perhaps missed such terminology and the accompanying strategic doctrine the first time round (or second, or third time) many years ago, and such order-of-magnitude increases are often dictated by the assumption that the 90% not currently in the audience for a product would find the product too complicated or too technologically focused and that the product must therefore discard features, or change the way it exposes its features, in order to appeal to that 90%.
Unfortunately, such initiatives to reach larger audiences risk alienating the group of users that are best understood in order to reach groups of users that are largely under-researched and thus barely understood at all. (The 90% is not a single monolithic block of identically-minded people, of course, so there is more than one group of users.) Now, one tempting way of avoiding the need to understand the untapped mass of potential users is to imitate those who are successfully reaching those users already or who at least aspire to do so. Thus, KDE 4 and Windows Vista had a certain similarity, presumably because various visual characteristics of Vista, such as its usage of desktop gadgets, were perceived to be useful features applicable to the wider marketplace and thus “must have” features that provide a way to appeal to people who don’t already use KDE or Windows. (Having a tiny picture frame on the desktop background might be a nice way of replicating the classic picture of one’s closest family on one’s physical desktop, but I doubt that it makes or breaks the adoption of a technology. Many people are still using their computer at a desk or at home where they still have those pictures in plain view; most people aren’t working from the beach where they desperately need them as a thumbnail carousel obscured by their application windows.)
However, it should be remembered that the products being imitated may also originate from organisations who also do not really understand their potential audience, either. Windows Vista was perceived to be a decisive response by Microsoft to the threat of alternative platforms but was regarded as a flop despite being forced on computer purchasers. And even if new users adopt such products, it doesn’t mean that they welcome or unconditionally approve of the supposed innovations introduced in their name, especially if Microsoft and its business partners forced those users to adopt such products when buying their current machine.
The Linux Palmtop and the Linux Desktop
With the success of Android – or more accurately, Android/Linux – claims may be made that radical departures from the traditional desktop software stacks and paradigms are clearly the necessary ingredient for success for GNU/Linux on the desktop, and it might be said that if only people had realised this earlier, the Free Software desktop would have become dominant. Moreover, it might also be argued that “desktop thinking” held back adoption of Linux on mobile devices, too, opening the door for a single vendor to define the payload that delivered Linux to the mobile-device-consuming masses. Certainly, the perceived need for a desktop on a mobile or PDA (personal digital assistant) is entrenched: go back a few years and the GNOME Palmtop Environment (GPE) was seen as the counterweight to Windows CE on something like a Compaq iPAQ. Even on the Golden Delicious GTA04 device, LXDE – a lightweight desktop environment – has been the default environment, admittedly more for verification purposes than for practical use as a telephone.
Naturally, a desktop environment is fairly impractical on a small screen with limited navigational controls. Although early desktop systems had fewer pixels than today’s smartphones, the increased screen size provided much greater navigational control and matched the desktop paradigm much better. It is interesting to note that the Xerox Star had a monochrome 1024×809 display, which is perhaps still larger than many smartphones, that (according to the Wikipedia entry) “…was meant to be able to display two 8.5×11 in pages side by side in actual size”. Even when we become able to show the equivalent amount of content on a smartphone screen at a resolution sufficient to permit its practical use, perhaps with very good eyesight or some additional assistance through magnification, it will remain a challenge to navigate that information precisely. Selecting text, for instance, will not be possible without a very precise pointing instrument.
Of course, one way of handling such challenges that is already prevalent is that of being able to zoom in and out of the content, with the focus in recent years on being able to do so through gestures, although the ability to zoom in on documents at arbitrary levels has been around for many years in the computer-aided design, illustration and desktop publishing fields amongst others, and the notion of general user interfaces permitting fluid scrolling and zooming over a surface showing content was already prominent before smartphones adopted and popularised it further. On the one hand, new and different “form factors” – kinds of device with different characteristics – offer improved methods of navigation, perhaps being more natural than the traditional mouse and keyboard attached to a desktop computer, but those methods may not lend themselves to use on a desktop computer with its proven ergonomics of sitting at a comfortable distance from a generously proportioned display and being able to enter textual input using a dedicated device with an efficiency that is difficult to match using, say, a virtual keyboard on a touchscreen.
Proclamations may occasionally be made that work at desks in offices will become obsolete in favour of the mobile workplace, but as that mobile workplace is apparently so often situated at the café table, the aircraft tray table, or once the lap or forearm is tired of supporting a device, some other horizontal surface, the desktop paradigm with its supporting cast of input devices and sophisticated applications will still be around in some form and cannot be convincingly phased out in favour of content consumption paradigms that refuse to tackle the most demanding of the desktop functionality we enjoy today.
The Real Obstacle
Up to this point, my pontification has limited itself to considering what has made the “Linux desktop” attractive in the past, what makes it attractive or unattractive today, and whether the directions currently being taken might make it more attractive to new audiences and to existing users, or instead fail to capture the interest of new audiences whilst alienating existing users. In an ideal world, with every option given equal attention, and with every individual able to exercise a completely free choice and adopt the product or solution that meets his or her own needs best, we could focus on the above topic and not have to worry about anything else. Unfortunately, we do not live in such an ideal world.
Most hardware sold in retail outlets visited by the majority of potential and current computer users is bundled with proprietary software in the form of Microsoft Windows. Indeed, in these outlets, accounting for the bulk of retail sales of computers to private customers, it is not possible to refuse the bundled software and to choose to buy only the hardware so that an alternative software system may be used with the computer instead (or at least not without needing to pursue vendors afterwards, possibly via legal avenues). In such an anticompetitive environment, many customers associate the bundled software with computer hardware in general and remain unaware of alternatives, leaving the struggle to educate those customers to motivated individuals, organisations like the FSF (and FSFE), and to independent retailers.
Unfortunately, individuals and organisations have to spend their own time and money (or their volunteers’ time and their donors’ money) righting the wrongs of the industry. Independent retailers offer hardware without bundled software, or offer Free Software pre-installed as a convenience but without cost, but the low margins on such “bare” or Free Software systems mean that they too are fixing the injustices of the system at their own expense. Once again, our considerations need to be broadened so as to not merely consider the merits of Free Software delivered as a desktop environment for the end-user, but also to the challenge of getting that software in front of the end-user in the first place. And further still: although we might (and should) consider encouraging regulatory bodies to investigate the dubious practices of product bundling, we also need to consider how we might support those who attempt to reach out and educate end-users without waiting for the regulators to act.
Putting the Pieces Together
One way we might support those getting Free Software onto hardware and into the hands of end-users – in this case, purchasers of new computer hardware – is to help them, the independent retailers, command a better price for their products. If all other things are equal, people generally will not pay more for something that they can get cheaper elsewhere. If they can be persuaded to believe that a product is better in certain ways, then paying a little more doesn’t seem so bad, and the extra cost can often be justified. Sadly, convincing people about the merits of Free Software can be a time-consuming process, and people may not see the significance of those merits straight away, and so other merits are also required to help build up a sustainable margin that can be fed into the Free Software ecosystem.
Some organisations advocate that bundling services is an acceptable way of appealing to end-users and making a bit of money that can fund Free Software development. However, such an approach risks bringing with it all that is undesirable about the illegitimately-bundled software that customers are obliged to accept on their new computer: advertising, compromised user experiences, and the feeling that they are not in control of their purchase. Moreover, seeking revenue from service providers or selling proprietary services to existing end-users fails to seriously tackle the market access issue that impacts Free Software the most.
A better and proven way of providing additional persuasion is, of course, to make a better product, which is why it is crucial to understand whether the different communities developing the “Linux desktop” are succeeding in doing so or not. If not, we need to understand what we need to do to help people offer viable products that people will buy and use, because the alternative is to continue our under-resourced campaign of only partly successful persuasion and education. And this may put our other activities at risk, too, affording us only desperate resistance to all the nasty anticompetitive measures, both political and technical, that well-resourced and industry-dominating corporations are able to initiate with relative ease.
In short, our activities need to fit together and to support each other so that the whole endeavour may be sustainable and be able to withstand the threats levelled against it and against us. We need to deliver a software experience that people will use and continue to use, we need to recognise that those who get that software in front of end-users need our support in running a viable business doing so (far more than large vendors who only court the Free Software communities when it suits them), and we need to acknowledge the threats to our communities and to be prepared to fight those threats or to support those who do so.
Once we have shown that we can work together and act on all of these simultaneously and continuously as a community, maybe then it will become clear that the year of the Linux desktop has at last arrived for good.
What do I think about the Fairphone?
May 26th, 2013
Thomas Koch asks what we think about the Fairphone.
I think that the Fairphone people are generally aware of Free Software and are in favour of it, but I also think that such matters are somewhat beyond their existing experiences, so that’s why the illustration on their site is a phone running something that might be Windows Phone (I wouldn’t really know, myself) showing Skype on the screen.
The rather awkward-to-navigate Web site mentions…
Root access: Install your preferred operating system and take control of your data.
Android OS (4.2 Jelly Bean): Special interface developed by Kwame Corporation (Also open!)
Of course, without a full familiarity with Free Software, it’s very easy for people to say “open” and not deliver what we expect when we consider openness and freedom. Moreover, without proper hardware support, promises of “root access” don’t go very far. It does seem to be the case that the “special interface” will be released as Free Software (more information available on the DroidCon site in a slightly more convenient form than the alternatives). But I haven’t seen much evidence of truly open support for the “Mediatek 6589 chipset” although it is theoretically possible that it could exist. That the MT6589 apparently employs PowerVR technology does not inspire a great deal of hope for Free Software drivers and firmware, however.
Certainly, those of us interested in Free Software should consider helping Fairphone to deliver the same kind of transparency in the software supply chain that they intend to deliver in the physical supply chains. Having software that can in its entirety be maintained independently of the hardware vendor means that the device can be viable indefinitely, and the result would be a product that promotes the sustainability aspirations of the Fairphone endeavour.
I’d be tempted to order one myself if we could realistically expect to bring about Free (and Fair) Software on a Freephone.
The Academic Challenge: Ideas, Patents, Openness and Knowledge
April 18th, 2013
I recently had reason to respond to an article posted by the head of my former employer, the Rector of the University of Oslo, about an initiative to persuade students to come up with ideas for commercialisation to solve the urban challenges of the city of Oslo. In the article, the Rector brought up an “inspiring example” of such academic commercialisation: a company selling a security solution to the finance industry, possibly based on “an idea” originating in a student project and patented as part of the subsequent commercialisation strategy leading to the founding of that company.
My response made the following points:
- Patents stand counter to the academic principle of the dissemination of unencumbered knowledge, where people may come and learn, then make use of their new knowledge, skills and expertise. Universities are there to teach people and to undertake research without restricting how people in their own organisations and in other organisations may use knowledge and thus perform those activities themselves. Patents also act against the independent discovery and use of knowledge in a startlingly unethical fashion: people can be prevented from taking advantage of their own discoveries by completely unknown and inscrutable “rights holders”.
- Where patents get baked into attempts at commercialisation, not only does the existence of such patents have a “chilling effect” on others working in a particular field, but even with such patents starting life in the custody of the most responsible and benign custodians, financial adversity or other circumstances could lead to those patents being used aggressively to stifle competition and to intimidate others working in the same field.
- It is all very well claiming to support Open Access (particularly when snobbery persists about which journals one publishes in, and when a single paper in a “big name” journal will change people’s attitudes to the very same work whose aspects were already exposed without such recognition in other less well-known publications), but encouraging people to patent research at the same time is like giving with one hand while taking with the other.
- Research, development and “innovation” happens more efficiently when people don’t have to negotiate to be able to access and make use of knowledge. For those of us in the Free Software community who have seen how real progress can be made when resources – in our case, software – are freely usable by others through explicit and generous licensing, this is not news. But for others, this is a complete change of perspective that requires them to question their assumptions about the way society currently rewards the production of new work and to question the optimality of the system that grants such rewards.
On the one hand, I am grateful for the Rector’s response, but I feel somewhat disappointed with its substance. I must admit that the Rector is not the first person to favour the term “innovation”, but by now the term has surely lost all meaning and is used by every party to mean what they want it to mean, to be as broad or as narrow as they wish it to be, to be equivalent to work associated with various incentives such as patents, or to be a softer and more photogenic term than “invention” whose own usage may be contentious and even more intertwined with patents and specific kinds of legal instruments.
But looking beyond my terminological grumble, I remain unsatisfied:
- The Rector insists that openness should be the basis of the university’s activities. I agree, but what about freedoms? Just as the term “open source” is widely misunderstood and misused, being taken to mean that “you can look inside the box if you want (but don’t touch)” or “we will tell you what we do (but don’t request the details or attempt to do the same yourself)”, there is a gulf between openly accessible knowledge and freely usable knowledge. Should we not commit to upholding freedoms as well?
- The assertion is made that in some cases, commercialisation may be the way innovations are made available to society. I don’t dispute that sometimes you need to find an interested and motivated organisation to drive adoption of new technology or new solutions, but I do dispute that society should grant monopolies on entire fields of endeavour to organisations wishing to invest in such opportunities. Monopolies, whether state-granted or produced by the market, can have a very high cost to society. Is it not right to acknowledge such costs and to seek more equitable ways of delivering research to a wider audience?
- Even if the Rector’s mention of an “inspiring example” had upheld the openness he espouses and had explicitly mentioned the existence of patents, is it ethical to erect a fence around a piece of research and to appoint someone as the gatekeeper even if you do bother to mention that this has been done?
Commercialisation in academia is nothing new. The university where I took my degree had a research park even when I started my studies there, and that was quite a few years ago, and the general topic has been under scrutiny for quite some time. When I applied for a university place, the politics of the era in question were dominated by notions of competition, competitiveness, market-driven reform, league tables and rankings, with schools and hospitals being rated and ranked in a misguided and/or divisive exercise to improve and/or demolish the supposedly worst-performing instances of each kind.
Metrics of “research excellence” are nothing new, either. It seemed to me that some university departments were obsessed with the idea of research rankings. I recall at least one occasion during the various tours of university departments of being asked which other universities us potential applicants were considering, only to have the appointed tour leaders consult the rankings and make an on-the-spot comparison, although I also recall that when the top-ranked universities were named such comparison exercises drew to a swift close. Naturally, the best research departments didn’t need to indulge in such exercises of arguable inadequacy.
The Real Challenge for Students
But does the quality of research have anything to do with the quality of an institution for the average student? Furthermore, does the scale of commercialisation of research in a teaching institution have anything to do with the quality of research? And anyway, why should students care about commercialisation at all?
My own experiences tell me that prospective students would do better to pay attention to reliable indicators of teaching quality than to research ratings. Many of them will end up having relatively little exposure to the research activities of an institution, and even if researchers actively attempt to engage students with “real world” examples from their own work, one can argue that this may not be completely desirable if such examples incorporate the kind of encumbered knowledge featured in the “inspiring example” provided by the Rector. It is, however, more likely that researchers would rather be doing research than teaching and will be less engaging, less available for consultation, and just less suited to providing high quality tuition than the teaching staff in a decent teaching institution. Who cares if a department is doing “cutting edge” research if all you see as a student is a bored and distracted lecturer having to be dragged out of the lab for an hour once or twice a week?
Even the idea that students will go on to do research after their undergraduate degree in the same institution, presumably by forging contacts with researchers in teaching positions, should be questioned. People are encouraged to move around in academia, arguably to an extent that most well-qualified people would find intolerable even in today’s celebrated/infamous “global economy”. That undergraduates would need to relate to the research of their current institution, let alone any commercialisation activity, is in many respects rather wishful thinking. In my entire undergraduate era I never once had any dealings or even awareness of what went on in the university research park: it was just a block of the campus on the map without any relevance and might have well been a large, empty car park for all the influence it had on my university education.
My advice to undergraduates is to seek out the institutions that care about high-quality teaching, whose educators are motivated and whose courses are recognised for providing the right kind of education for the career you want to pursue. Not having been a postgraduate as such, I don’t feel comfortable giving advice about which criteria might be more important than others, although I will say that you should seek out the institutions who provide a safe, supportive, properly-run and properly-supervised working environment for their researchers and all their employees.
The Circus of Commercialisation
Lots of money is being made in licensing and litigation around commercial and commercialised research, and with large sums being transferred as the result of legal rulings and settlements, it is not particularly difficult to see why universities want in on “the action”. In some countries, with private money and operational revenue ostensibly being the primary source of income for universities, one can almost understand the temptation of such institutions to nail down every piece of work and aggressively squeeze every last revenue-earning drop of potential each work may have, if only because a few bad years of ordinary revenue might lead to the demise of an institution or a substantial curtailment of its reputation and influence. For such institutions, perhaps the only barrier being broken voluntarily is an ethical one: whether they should be appointing themselves as the gatekeepers to knowledge and still calling themselves places of learning.
In other countries, public money props up the education sector, in some nations to the extent that students pay nominal fees and experience as close to a free higher education as one can reasonably expect. Although one might argue that this also puts universities at the mercy of an ungenerous public purse and that other sources of income should be secured to allow such institutions to enhance their offerings and maintain their facilities, such commercial activities deservedly attract accusations of a gradual privatisation of higher education (together with the threat of the introduction of significant fees for students and thus an increased inequality between rich and poor), of neglecting non-applied research and commercially unattractive areas of research, and of taking money from taxpayers whilst denying them the benefit of how it was spent.
Commercialisation is undoubtedly used to help universities appear “relevant” to the general public and to industry, especially if large numbers can be made to appear next to items such as “patents” and “spin-offs” in reports made available to the press and to policy makers and if everyone unquestioningly accepts those things and the large numbers of them as being good things (which is far from being a widely-accepted truth, despite the best efforts of self-serving, high-profile, semi-celebrity advocates of patent proliferation), but the influence of such exercises can be damaging to things like Free Software, not merely creating obstacles for the sharing of knowledge but also creating a culture that opposes the principles of sharing and genuine knowledge exchange that Free Software facilitates and encourages.
Indeed, the Free Software movement and its peers provide a fairer and more sustainable model for the widespread distribution and further development of research than the continuing drive for the commercialisation and monetisation of academia. Free Software developers give each other explicit rights to their work and do not demand that others constantly have to ask permission to do the most elementary things with it. In contrast, commercialisation imposes barriers between researchers and their natural collaborators in the form of obligations to an institution’s “intellectual property” or “technology transfer” office, demanding that every work be considered for licensing and revenue generation (by a group of people who may well be neither qualified nor legitimately entitled to decide). Where Free Software emphasises generosity, commercialisation emphasises control.
Universities, whose role it is to provide universal access to usable knowledge, particularly when funded with public money, should be looking to support and even emulate Free Software practitioners. Instead, by pursuing an agenda of pervasive commercialisation, they risk at the very least a stifling of collaboration and the sharing of knowledge; at worst, such an agenda may corrupt the academic activity completely.
Can universities resist the temptations and distractions of commercialisation and focus on delivering a high-quality experience for students and researchers? That is the real ethical challenge.
Why the Raspberry Pi isn’t the new BBC Micro (and perhaps shouldn’t be, either)
January 23rd, 2013
Having read a commentary on “rivals” to the increasingly well-known Raspberry Pi, and having previously read a commentary that criticised the product and the project for not upholding the claimed ideals of encouraging top-to-bottom experimentation in computing and recreating the environment of studying systems at every level from the hardware through the operating system to the applications, I find myself scrutinising both the advocacy as well as the criticism of the project to see how well it measures up to those ideals and whether the project objectives and how the way they are to be achieved can be seen as still being appropriate thirty years on from the introduction of microcomputers to the masses.
The latter, critical commentary is provocatively titled “Why Raspberry Pi Is Unsuitable for Education” because the Raspberry Pi product, or at least the hardware being sold, is supposedly aimed at education just as the BBC Microcomputer was in the early 1980s. A significant objective of the Computer Literacy Project in that era was to introduce microcomputers in the educational system (at many levels, not just in primary and secondary schools, although that is clearly by far the largest area in the educational sector) and to encourage learning using educational software tools as well as learning about computing itself. Indeed, the “folklore” around the Raspberry Pi is meant to evoke fond memories of that era, with Model A and B variants of the device, and with various well-known personalities being involved in the initiative in one way or another.
Now, if I were to criticise the Raspberry Pi initiative and to tread on toes in doing so, I would rather state something more specific than “education” because I don’t think that making low-cost hardware to education is a bad thing at all, even if it does leave various things to be desired with regard to the openness of the hardware. The former commentary mentioned above makes the point that cheap computers means fewer angry people when or if they get broken, and this is hard to disagree with, although I would caution people into thinking that it means we can treat these devices as disposable items to be treated carelessly. In fact, I would be as specific as to state that the Raspberry Pi is not the equivalent of the BBC Micro.
In the debate about openness, one focus is on the hardware and whether the users can understand and experiment with it. The BBC Micro used a number of commodity components, many of which are still available in some form today, with only perhaps one or two proprietary integrated circuits in the form of uncommitted logic arrays (ULAs), and the circuit diagram was published in various manuals. (My own experience with such matters is actually related to the Acorn Electron which is derived from the BBC Micro and which uses fewer components by merging the tasks of some of those omitted components into a more complicated ULA which also sacrifices some functionality.) In principle, apart from the ULAs for which only block diagrams and pin-outs were published, it was possible to understand the functioning of the hardware and thus make your own peripheral hardware without signing non-disclosure agreements (NDAs) or being best friends with the manufacturer.
Meanwhile, although things are known about the components used by the Raspberry Pi, most obviously the controversial choice of system-on-a-chip (SoC) solution, the information available to make your own is not readily available. Would it be possible to make a BBC Micro from the published information? In fact, there was a version of the BBC Micro made and sold under licence in India where the intention was to source only the ULAs from Acorn (the manufacturer of the BBC Micro) and to make everything else in India. Would it be desirable to replicate the Raspberry Pi exactly? For a number of reasons it would neither be necessary nor would it be desirable to focus so narrowly on one specific device, and I will return to this shortly.
But first, on the most controversial aspect of the Raspberry Pi, it has been criticised by a number of people for using a SoC that incorporates the CPU core alongside proprietary functionality including the display/graphics hardware. Indeed, the system can only boot through the use of proprietary firmware that runs on a not-publicly-documented processing core for which the source code may never be made available. This does raise concern about the sustainability of the device in terms of continued support from the manufacturer of the SoC – it is doubtful that Broadcom will stick with the component in question for very long given the competitive pressures in the market for such hardware – as well as the more general issues of transparency (what does that firmware really do?) and maintainability (can I fix bad hardware behaviour myself?). Many people play down these latter issues, but it is clear that many people also experience problems with proprietary graphics hardware, with its sudden unexplainable crashes, and proprietary BIOS firmware, with its weird behaviour (why does my BIOS sometimes not boot the machine and just sit there with a stupid Intel machine version message?) and lack of functionality.
One can always argue that the operating system on the BBC Micro was proprietary and the source code never officially published – books did apparently appear in print with disassembled code listings, clearly testing then-imprecisely-defined boundaries of copyright – and that the Raspberry Pi can run GNU/Linux (and the proprietary operating system, RISC OS, that is perhaps best left as a historical relic), and if anything I would argue that the exposure that Free Software gets from the Raspberry Pi is one of the initiative’s most welcome outcomes. Back in the microcomputer era, proprietary things were often regarded as being good things in the misguided sense that since they are only offered by one company to customers of that company, they would presumably offer exclusive features that not only act as selling points for that company’s products but also give customers some kind of “edge” over people buying the products of the competitors, if this mattered to you, of course, which is arguably most celebrated in recollections of playground/schoolyard arguments over who had the best computer.
The Computer Literacy Project, even though it did offer funding to buy hardware from many vendors, sadly favoured one vendor in particular. This might seem odd as a product of a government and an ideology that in most aspects of public life in the United Kingdom emphasised and enforced competition, even in areas where competition between private companies was a poor solution for a problem best solved by state governance, and so de-facto standards as opposed to genuine standards ruled the education sector (just as de-facto standards set by corporations, facilitated by dubious business practices, ruled other sectors from that era onwards). Thus, a substantial investment was made in equipment and knowledge tied to one vendor, and it would be that vendor the customers would need to return to if they wanted more of the same, either to continue providing education on the range of supported topics or related ones, or to leverage the knowledge gained for other purposes.
The first commentary mentioned above uses the term “the new Raspberry Pi” as if the choice is between holding firm to a specific device with its expanding but specific ecosystem of products and other offerings or discarding it and choosing something that offers more “bang for the buck”. Admittedly, the commentary also notes that there are other choices for other purposes. But just as the BBC Micro enjoyed a proliferation of peripheral hardware, software commissioned for the platform as well as software written as the market expanded, and even though this does mean that people will be able to do things that they never considered doing before, particularly with hardware and electronics, there is a huge risk that all of this will be done in a way that emphasises a specific device – a specific solution involving specific investments – that serves to fragment the educational community and reproduce the confusion and frustration of the microcomputer era where a program or device required a specific machine to work.
Although it appeals to people’s nostalgia, the educational materials that should be (and presumably are) the real deliverable of the Raspberry Pi initiative should not seek to recreate the Tower of Babel feeling brought about by opening a 1980s book like Computer Spacegames and having to make repeated corrections to programs so that they may have a chance of running on a particular system (even though this may in itself have inspired a curiosity in myself for the diversity seen in systems and both machine and natural languages). Nothing should be “the old Raspberry Pi” or “the new Raspberry Pi” or “the even newer Raspberry Pi” because dividing things up like this will mean that people will end up using the wrong instructions for the wrong thing and being frustrated and giving up. Just looking at the chaos in the periphery around the Arduino is surely enough of a warning.
In short, we should encourage diversity in the devices and solutions offered for people to learn about computing, and we should seek to support genuine standards and genuine openness so that everyone can learn from each other, work with each other’s kit, and work together on materials that support them all as easily and as well as possible. Otherwise, we will have learned nothing from the past and will repeat the major mistakes of the 1980s. That is why the Raspberry Pi should not be the new BBC Micro.
Norway and the Euro 2012 Final
July 1st, 2012
Here, I’m obviously not referring to the football championship but to the outcome of an interesting thought experiment: which countries are making the best progress in adopting and supporting Free Software? As a resident of Norway, I’d like to think that I’m keeping my finger on the pulse here in a country that has achieved a lot in recent years: mandatory use of open standards, funding of important Free Software projects in education, and the encouragement of responsible procurement practices in the public sector.
Norway’s Own Goals
However, things don’t always go in the right direction. Recently, it has become known that the government will withdraw all financial support for the Norwegian Open Source Competence Center, founded to encourage and promote Free Software adoption in government and the public sector. One may, of course, question the achievements of the centre, especially when considering how much funding it has had and whether “value for money” has been delivered, or as everyone knows where any measure of politics is present, whether the impression of “value for money” has been delivered. Certainly, the centre has rolled out a number of services which do not seem to have gained massive popularity: kunnskapsbazaren (the knowledge bazaar) and delingsbazaren (the sharing bazaar) do not seem to have amassed much activity and appear, at least on the surface, as mostly static collections of links to other places, some of which are where the real activity is taking place.
But aside from such “knowledge repository” services, the centre does seem to have managed to provide the foundations for the wider use of Free Software, in particular arguing for and justifying the collaborative nature of Free Software within the legal framework of public sector procurement, as well as organising a yearly conference where interested parties can discuss such matters, present their own activities, and presumably establish the basis for wider collaboration. My own experience tells me that even if one isn’t involved with the more practical aspects of setting up such an event, such as the details of getting a venue in order, organising catering and so on, the other aspects can consume a lot of organising time and could quite easily take over the schedule of a number of full-time employees. (People going to volunteer conferences possibly don’t realise how many extra full-time positions, or the effective equivalent of such positions, have been conjured up from hours scraped together from people’s spare time.)
And it has also been noted that the centre has worked hard to spread the message on the ground, touring, giving presentations, producing materials – all important and underrated activities. So, in contrast to those who think that the centre is merely a way of creating jobs for the sake of it, I’m certainly willing to give those who have invested their energy in the centre the benefit of the doubt, even if I cannot honestly say that my awareness of their work has been particularly great. (Those who are so eager to criticise the centre should really take a long hard look at some other, well-established institutions for evidence of waste, lack of “value of money”, and failure to act in the public interest. I’m sure the list is pretty long if one really starts to dig.)
In Politics the Short Term Always Wins
In many ways – too many to get into here – Norwegian society offers plenty of contradictions. A recent addition appears regularly on the front pages of the tabloids, asserting a different angle at different times: there may be a financial crisis, but it apparently doesn’t affect Norway… or maybe it does, but here’s how you, the consumer, can profit from it (your mortgage is even cheaper and you can expect your house to increase even further in value!). I was told by someone many years my junior the other day as he tried to sell me a gym membership that “we’re in a recession” and so the chain is offering a discount to new recruits. I somehow doubt that the chain is really suffering or that the seller really knows what a recession is like.
Nevertheless, the R-word is a great way to tighten the purse strings and move money around to support different priorities, not all of them noble or sensible. There are plenty of people who will claim that public IT spending should be frugal and that it is cheaper to buy solutions off the shelf than it is to develop sustainable solutions collaboratively. But when so many organisations need to operate very similar solutions, and when everybody knows that such off-the-shelf solutions will probably need to be customised, frequently at considerable expense, then to buy something that is ostensibly ready-made and inexpensive is a demonstration of short-term thinking, only outdone by the head of IT at the nation’s parliament boasting about only needing to rely on a single vendor. Since he appears to have presided over the introduction of the iPad in the parliament – a matter of concern to those skeptical about the security implications – one wonders how many vendors are really involved and how this somehow automatically precludes the use of Free Software, anyway.
(Another great example of public IT spending has to be the story of a local council buying iPads for councillors while local schools have 60-year-old maps featuring the Soviet Union, with the spending being justified on the basis that people will print and copy less. It will be interesting whether the predicted savings will materialise after people figure out how to print from their iPads, I’m sure.)
The Role of the Referee
The public sector always attracts vested interests who make very large sums of money from selling licences and services and who will gladly perpetrate myths and untruths about Free Software and open standards in order to maintain their position, leaving it to others to correct the resulting misconceptions of the impressionable observer. There needs to be someone to remind public institutions that they are obliged to act in the public interest, conduct sustainable operations, and that the taxpayer should not have to cover every expense of those operations because they have delegated control to a vendor who decides which technologies they may or may not use, which roadmaps are available to them, burdening them with arbitrary migration exercises, extra and needless expenditure, and so on. Moreover, such institutions should protect those who have to interact with them from interference: taxpayers should not suddenly be required to buy a particular vendor’s products in order to discharge their public obligations.
As we have already seen, there is a need for education around the issues of sustainable public sector computing as well as a need to hold those responsible for public expenditure to account. Holding them to account should be more considered than the knee-jerk response of splashing their organisation across the media when something goes wrong, even if this does provide opportunities for parody; it should involve discussion of matters such as whether such organisations have enough resources, whether they are sharing the burden with others who have similar goals instead of needlessly duplicating effort, and whether they are appropriately resourced so that they may operate sustainably.
I don’t expect a competence centre to perform the task of referee in ensuring a properly functioning, sustainable, interoperable, transparent public sector, but just as a referee cannot do without his linesmen, it is clear that public institutions and the society that pays for them and gives them their role cannot do without an agent that helps and informs those institutions, ensuring that they interact fairly with technology providers both small and large, and operate in a manner that benefits both society and themselves, through the genuine empowerment that Free Software has to offer.
Buying Hardware that Supports Free Software
February 4th, 2012
Have you ever wanted to buy a computer without paying a certain corporation for a product of theirs that you don’t want? Were you concerned that, regardless of whether you managed to buy a system without that unwanted operating system, the hardware might not support your favourite operating system distribution properly, leaving you unable to use some of the computer’s hardware (like the wireless network or some of the fancy graphical capabilities)? Were you worried that you might need to do extra work to support your favourite distribution and that people you know would end up blaming you for persuading them to try out something like GNU/Linux? Did you ever try to buy a “computer that runs Linux” from a major manufacturer only to find yourself navigating a labyrinth on their Web site (with every passage prominently marked with an advertisement for the unwanted proprietary product of a certain corporation), ending up either on a page telling you that they don’t sell that model any more, or on a “404 not found” page with all traces of that model erased from the record as if it never existed in the first place?
On the Fellowship Wiki, we are trying to put together an up-to-date list of vendors selling systems that at the very least don’t involve you paying the “Windows Tax“, and preferably involve the option of having a Free Software operating system distribution (like a GNU/Linux flavour such as Debian, Fedora or Ubuntu) pre-installed and ready to use. Although we don’t endorse any vendors – this is just research into those offering solutions that are friendly to Free Software – we hope that this resource will be useful for anyone looking to buy a new computer and act as an encouragement for other vendors to offer products that uphold healthy competition and appeal to an increasing group of people who care about things like Free Software, privacy, the right to control their own computer, the provenance of the software on their computer, the sustainability of their computing environment, and, of course, the proper functioning of the market for personal computers (where one company should not decide what everyone gets to use).
Go to the Hardware Vendors page to see what we’ve found so far, along with links to other resources that have provided good directions to friendly vendors, and feel free to contribute if you are an FSFE Fellow with some expertise of your own in this area. With the vast majority of ready-to-use computers sold via retail channels bundled with proprietary software, the market has been distorted to make the adoption of Free Software more difficult and to keep end-users ignorant of the benefits of Free Software and their right to control their own computer. Please consider helping us to level the playing field!
The FSFE Fellowship Events Calendar and GriCal
October 24th, 2011
Some time ago, I got involved with the FSFE Fellowship Wiki and implemented the theme code for MoinMoin that blends the Wiki together with the visual styling for the different Fellowship Web sites, along with an event calendar that shows what different Fellowship groups and individuals are doing – an activity which led to the release of the EventAggregator extension for MoinMoin.
Back then, a simple solution which let people add events by adding event pages to the Wiki, perhaps using the new event form, was sufficient and it seems that people did manage to publish their events after all. Having a solution already integrated with the Wiki was arguably preferable to installing yet more software and then thinking about theming and integration all over again, and nothing from the range of existing solutions – at least those known to the Wiki team – appeared to be particularly compelling. So, a bit of Wiki extension work got the job more or less done.
The form used to add new events to the Wiki
But now, some interesting work has become visible in the form of GriCal: a Free Software events service that not only carries details of numerous events related to Free Software, but is also a genuinely free solution whose code can be downloaded and deployed for those sufficiently motivated to do so. Some people prefer to publish events on GriCal and would rather see them appear automatically in the Fellowship events calendar. So why not aggregate events not only from the content on the Wiki but also from other sites?
EventAggregator has virtually always supported the iCalendar format as a way of downloading calendars, so that it is possible to view the Fellowship events calendar using your own calendar or organiser client, but could it not also support iCalendar as an input format? From the beginning, EventAggregator has used the fundamental information reminiscent of iCalendar to define events, albeit without all the BEGIN:VEVENT and DTSTART syntax, so surely a few adjustments were all that were necessary. Well, it did require a bit more work than that, necessitating some refactoring and the revisiting of assumptions that tends to happen when software evolves to do a bit more than it was originally intended to do, but now the distinction between events from remote sources and local pages is more and more blurred: the calendar doesn’t care where the events come from, although some caching within MoinMoin does attempt to stop those sites acting as event sources from being worried about having their events downloaded a bit too often.
So what does this mean for Wiki users? Well, defining calendars and creating events is still as straightforward as it used to be, especially if you use the “New event” link either below each calendar or in the menu when hovering over a day number in the calendar view. But if you know of some useful sources of high quality event information, you can also add an event source to the Wiki’s register of sources and then use those sources when showing your calendar.
The day view showing the timing of events within a particular day
Apart from all this new support for iCalendar aggregation, EventAggregator has also gained support for some other nice features over the past year or so. You can now view days individually and see the time information for events, and this can be useful when looking at things like conference schedules where lots of individually scheduled events are occurring within a short time-frame. You can also view events in any suitably prepared map, with events shown on a European map being perhaps the most obvious application for this feature in the Fellowship Wiki. Although the default map is not as fancy as something like OpenStreetMap or its proprietary competitors, the simple layering of active regions over a bitmap could be useful for customised maps, perhaps even things like building plans or anything that takes liberties with the concepts of latitude and longitude!
The map view using a map of Europe for Fellowship events
So I hope I’ve inspired you to at least take a look at the Fellowship events calendar. Remember that the Wiki is a collaborative resource: it doesn’t improve all by itself with only its increasing age to help it along. But with a bit of interest and even the most modest contributions, it has the potential to become a powerful tool and a medium to create greater and better things.
Finally, I’d like to thank Wolfgang for encouraging me to look into integrating EventAggregator with GriCal, opening up lots of new possibilities, and Ivan for telling me about GriCal and working hard to make the service work well with those of us who want to use its iCalendar output. I’d like to think that through such mutual encouragement and help, Free Software projects, products and services can only get better and better. The experience has certainly been a satisfying one for me, and I hope that Wiki users can now share in some of the benefits of this rewarding work.
EuroPython 2010: Talks Selected and Announced!
May 27th, 2010
I wrote earlier about EuroPython 2010, the Python community conference taking place in Birmingham, United Kingdom in July this year. Well, the list of talks has finally been made available. In addition, there’s a tentative schedule that will probably be adjusted over the time before the conference as people request different slots, change their travel plans, and generally try and avoid leaving for the airport right after taking questions.
What’s new about EuroPython this year is that there are four days of talks, not three, across four (and a bit) simultaneous tracks. Although Python conferences have tried as many, if not more, tracks on various occasions, rarely have they attempted to exceed three days. Certainly, the PyCon UK organisers behind this year’s conference are nothing if not ambitious!
Outside the Conservatoire, Birmingham
This year, I aim to give a talk about Python, Wiki solutions, MoinMoin and other collaborative tools, based somewhat on what I have learned from working on the FSFE Fellowship Wiki and on other community Web sites. It won’t be possible to cover absolutely everything about planning, implementing and maintaining these kinds of sites, especially with the broad range of Free Software applications and tools that can be brought into action, but I hope to cover some essential topics in the allocated time, and there will naturally be some resources made available that people can study afterwards.
Once again, why not take a trip to Birmingham and take advantage of four whole days of Python-related talks and events? Should that not be enough, there are another two whole days of tutorials (albeit at a modest extra cost) featuring everything from Web framework development, testing, game programming (featuring PyWeek‘s very own Richard Jones!) and even the somewhat peripheral topic of Arduino-based hardware hacking. And after the main conference programme, the usual sprinting begins (included in the main conference fee).
Suddenly, even the full-price fee starts to look like very reasonable value for money indeed. Register here!
EuroPython 2010: Registrations, Submissions, Organisation
March 5th, 2010
Every year, I seem to get involved with the organisation of the EuroPython conference, and this year doesn’t seem to be an exception. Like last year’s conference, EuroPython 2010 will take place in Birmingham, United Kingdom, and seeks to gather a respectable number of European Python users and developers under one roof by offering stimulating and engaging talks on the use of Python in various fields, the development of Python technologies (including the steadily increasing number of implementations), and other matters of a broader technological and cultural nature. As well as the talks, there will again be a number of tutorials, and after the main conference days (19th-22nd July) the sprinting begins: as most conference-going Free Software developers know, this is where people use the opportunity to collaborate with others to get some serious programming done on their favourite projects.
Birmingham's mercantile architecture
For some of us, it can often be quite hard to think a few months ahead and to consider signing up for a conference, not to mention the idea of submitting a talk proposal and then putting something together to present to a large number of other people, and especially this latter notion can seem overwhelming: when high-profile and/or successful projects are likely to appear in the schedule – after all, Python is almost everywhere now – one might question whether anyone would be interested in my software or my experiences with Python when there are supposedly so many important people presenting their important stuff. Well, in my experience at least, some of the most interesting talks and some of the most interesting discussion topics outside the talks frequently occur around people who aren’t minor community celebrities and whose issues aren’t announced with a fanfare. Discovering these hidden depths of Python usage is frequently what make conferences really worth attending. For an idea of the breadth of talks at EuroPython, take a look at those given at EuroPython 2008 and 2009: they aren’t all about big name projects or crucial decisions taken by Python’s core development team.
Geoffrey French presenting gSculpt: an interesting application that would probably go unnoticed by many
I wrote an article about organising EuroPython in 2008 for The Python Papers Vol 4 No 1 (2009), and if you don’t mind downloading a PDF, you can obtain it directly from the journal in question. In this article, I mention a number of talks that probably wouldn’t get the kind of promotion that one sees in the “blogosphere”, yet the topics (game development, code analysis, compilation, using “cloud computing” resources to solve real problems) are definitely things that would have many people returning home after the conference and taking a closer look at what the presenters have been doing. And frequently, the keynote speakers provide perspectives beyond those of software development and even inspiration for developers looking to solve problems which may be new to them, but which are very real to others: this truly makes a form of technology transfer possible in a way that those of us who support Free Software should approve, not based on parcelling out products but based on the transfer of expertise to where it’s most needed.
So if you’re interested in Python, as a beginner, a regular user, or as an expert, and you’re looking for a conference where there will be plenty of things to see, learn and do, and you’re also looking for a community-style experience instead of the more corporate-style conference events, and you would prefer a slant towards Free Software – and I think it isn’t unreasonable to claim that EuroPython encourages and emphasises Free (and open source) Software – then why not consider coming along to EuroPython 2010 this summer? And if you’re looking to make connections within the community, which is what many regard as the primary benefit of community conferences like EuroPython, why not join the organisers in putting the event together? That way, you’ll not only make connections with some fairly well-connected people, but you’ll also help shape the event into something that benefits you even more!
The Python implementations panel at EuroPython 2009
Helping to organise a conference can be hard work, but the end result can pay back this effort with interest. With this being my fifth year of being in some way involved with the running of EuroPython itself, I feel somewhat qualified to make this claim. Why not start your own investment with EuroPython 2010, or perhaps start one with your own favourite technology’s community conference? You might make connections and influence people, too.
Hacking the Fellowship Wiki
November 21st, 2009
(That’s hacking in the good sense of the word, of course.)
A while ago, Matthias Kirschner encouraged me to blog a bit about the FSFE Fellowship Wiki and some of the enhancements that have been introduced by the small group of volunteers and administrators, so in this post I’ll explain what I’ve been doing with the Wiki since I volunteered to help out a while back.
First of all, the Wiki needed to use the same visual style as all the other new FSFE pages. Since the Wiki is run by MoinMoin, and since I have some experience with making themes for MoinMoin, this was an opportunity to help out. Thus, my place as a volunteer was established: there didn’t seem to be anyone else amongst the existing volunteers familiar enough with Moin’s theming framework to do the job in a hurry.
Fortunately, the hard part of doing the visual styling had already been done, and all I really needed to do was to write a theme module which generates HTML that then uses the various CSS classes and rules already provided by the visual designers. In this way, the visual elements are plugged into Moin’s content generation system such that when a page is formatted, the right kind of HTML is generated, appropriately styled, that can then make the browser put the visual elements in all the right places.
Once the theme was done, other enhancements became desirable or essential. One aspect of the visual design was the presence of a green title bar at the top of the content area of each page – you can see this on all the FSFE sub-sites (home, blogs, planet) – and this didn’t fit in with the way Moin generates its pages. Ideally, one would dedicate all of the content area to Moin, and to allow the page author to put whichever title they like in such a prominent position, perhaps the first heading on the page. Ultimately, a compromise was reached (after numerous experiments): page authors would omit any initial heading, instead relying on the page name itself to appear in the title bar (which is what solutions like MediaWiki do), and the theme would make a “pretty” version of the page name for this uppermost title.
Another enhancement, given that FSFE is a European organisation where many languages may be in common use, was to support multiple languages and to allow users to find translations of pages. Although Moin already supports many languages, there isn’t a built-in feature to help users find the translation of the current page in their own language, preferably by providing a link to such a translation in a prominent place. Thus, it was decided that the theme would incorporate such a function, and the result is a sidebar menu which lists languages for which a page has been translated. More information on how this works can be found in the Wiki user guide, and the advocacy FAQ page should show this function in action.
One project that didn’t start as a Wiki project was the Fellowship calendar. It did appear that some Moin-based solutions were somewhat relevant, such as MonthCalendar and EventCalendar. Having written a Moin extension called CategoryMenu, dynamically building and showing navigation menus which present the Wiki’s categories, together with expanded lists of pages for those categories to which the current page belongs, and considering the likelihood that calendar events would most likely be written on a separate page in order to fully document the event, show likely participants, schedules, and so on (see the FSCONS page for an example), I thought it would be interesting to write a macro that would gather all event pages (belonging to a designated category) and to present them upon request in a calendar view.
The result of this effort is the EventAggregator extension, which started out just showing a simple list of events in each month, but then evolved to support a calendar view (which is arguably a necessity and was always planned), RSS and iCalendar feeds, and a number of conveniences to encourage people to add events, such as a “new event” form which can be prefilled with information, making the task of editing an event page less intimidating. I imagine that more enhancements will be made to this extension, possibly to make it more useful for applications beyond the Fellowship Wiki, but it has been an interesting exercise in learning more about Moin’s features, benefits and shortcomings. The result can be seen on the Wiki in the Fellowship Events page, although calendar views can be added to any page using the macro.
The work doesn’t end here, of course. There are always plenty of things that could be better, but here are some of the simpler ones for anyone wanting to help out but not to take on something that might be too demanding:
- Language translations for MoinMoin: the FSFE theme uses texts which do not have built-in translations provided by Moin, but it’s easy to add these texts for your own languages; see the English dictionary for all that’s required to make the Wiki friendlier to native speakers of your own languages.
- Templates for editing: templates for common types of pages, such as local Fellowship group pages, are required; such templates reduce the amount of boilerplate that authors have to reproduce and make editing easier, just as has been done for event pages with the Fellowship events template.
- Just using the Wiki makes it better! By adding content, there’s more of a reason to visit the Wiki, and by remembering to add events to the Fellowship Events calendar or by adding the right metadata to make events show up in the calendar, or by making more specific calendars (perhaps for your own local group), it becomes more interesting to use such resources.
Beyond the Wiki, there are many projects that can be tackled by anyone enthusiastic enough. It has been a rewarding experience to do all this work, and it has been a pleasure to work with the other volunteers. If you want to make the Fellowship infrastructure better, I can certainly recommend volunteering!