the island of eleusis

[preface: I originally wrote this on the 25th, thus the introduction.]

It’s the eve of Australia day and it seems to be that time of the year when some citizens feel entitled to air their opinions about the inappropriateness of Australia’s national day. A week ago, Prince William came down on a visit to Australasia and opened up New Zealand’s new Supreme Court building. He ended up spending a few days in Australia, where he was quite warmly welcome, causing a few to anxiously reflect on that old chestnut - the question of Australia’s ties to the British monarchy, and reviving discussions of an Australian republic. Closer to the 26th of January, others decide to ruminate about everything from changing the Australian flag to changing the national anthem to changing the date of the national day itself.

As I tweeted, “only in Australia is the national day so fraught with an outpouring of sickening political correctness”. This was quite predictably met with responses about the ‘slaughtering’ of indigenous Australians by British colonialists. No, obviously it wasn’t the case that on a January 26th during the 18th century that a bunch of British admirals rocked up to these shores and masterminded a cheerful and coordinated slaughtering of the natives to clear the way for a bunch of settlers and convicts and so on. Rather, the idea is that January 26th is symbolic of the pain endured by indigenous Australians - as a whole, one might surmise - at the hands of colonial forces.

Yes, it is true that the general attitude towards indigenous Australians is rather quite dreadful. This is especially when compared to the more harmonious character of New Zealand’s Maori and Pakeha population. Indeed, the roots of New Zealand as a nation come from the Treaty of Waitangi, between the Maori and the Pakeha, back in 1840 - nothing even remotely compares to this in Australia. On the other hand, whereas the Maori people were composed of inter-related tribes in a relatively well structured society, indigenous Australians were dispersed over a much more vast area, with no central authority. This meant that colonialists could not effectively deal with a single group that was somewhat representative of the peoples of the land - much less be able to compose a treaty with them.

The denigration of Australia day by certain citizens annoys me for several reasons. This is not to say that I wish to see them forcefully silenced. It’s rather more about me being sad that they do not share my perspective. It is regrettable that some were murdered in the course of Australia’s history - I think that is something most can agree on. From where we stand, however - centuries after some of these events - what good comes from lamenting what happened, and demanding that justice be served? What kind of justice can be served to people who had their land removed from them, other than giving them a fair opportunity in participating in the thriving society that was subsequently built? What do some stand to gain or benefit from, to continuously lament about this, when they themselves are either descendants of those who perpetrated crimes against the indigenous population, or migrated to this land following the creation of colonies that supplanted the indigenous? What is the solution to their dilemma - to leave this land and to never return; to wish themselves out of existence?

On the question of changing the date of the national day, especially due to the pain and suffering that it symbolises to some, what day of the year could be picked that would be completely unblemished? I can guarantee that, given there’s only 365 days in a year, every single one of them has born witness to some degree of human tragedy, pain, suffering or bloodshed at some point during the past few thousand years. Given that fact, any day chosen to be the national day of any country is bound to be arbitrary and despised by at least a fraction of the population for one reason or another. That should not be sufficient cause for moving the national day.

January 26th was chosen as the national day because it was the date that the First Fleet arrived in Sydney Cove and proclaimed British sovereignty over the territory. The settlement established by the fleet became the first of many other colonies around the continent - most of which became established over another half century. Sydney became, and still is, one of the most important gateways between the Australian heartland and the rest of the world - as such, the date of its founding has national significance. The date of proclamation of British sovereignty is also especially relevant as it denotes the beginning of an era in the history of this land where the dominant society has been one with significant cultural, political and economic ties to Britain. While Australia has progressively weaned itself from Britain’s influence and found its own place within the world, no other nation has contributed so significantly to Australian society, so far. Perhaps it might be appropriate to revisit the date of the national day if such an event were to occur.

I find myself in an odd position, being rather defensive about Australia and its national emblems and events, particularly since I was not born here, and have not even spent most of my life here yet. To me, Australia currently feels like home. Home in the sense that, I know this place, I know the people, I know how to live here. I may never fully resolve the question of where I really belong - whether it’s here in Australia, or back in Mauritius. Back in Mauritius, where most of my extended family still is, where the word ‘motherland’ still holds an emotional appeal, yet so limited by its tiny, tiny shores. Contrasted with Australia, a land so vast that I may never see all of it; a land so full of mystery and potential adventures.

I came to the realisation recently that, despite having lived in two different countries and visited cities many thousands of kilometres apart, I have never ever been anywhere that hasn’t been part of the British Empire. This includes my recent trip to Wellington, New Zealand - which even has prominent landmarks named after a British monarch, such as Victoria Street and Mount Victoria. The fact that I was born in Mauritius itself owes to the fact that the British moved thousands of people from India (presumably from the east coast) to work on sugarcane plantations in Mauritius. To my mind, I have a choice between seeing myself as a victim of this imperial behemoth - a descendant of peasants who moved across an ocean to live on a tiny rock, or as a citizen of a mighty empire (or what used to be an empire) stretching to practically every part of the planet.

Who I am today is in large part thanks to the institutions whose foundations were laid by the British as they colonised the world. There were those who opposed the colonisers for whatever reason, and perished against the sheer military might of the empire. From where I am, however, it seems disingenuous to be ungrateful for what the empire built, despite what it destroyed.

IEEE Software recently published an opinion piece from Tom DeMarco titled ‘Software Engineering: An Idea Whose Time Has Come and Gone?’ in which DeMarco appears to declare the death of ‘Software Engineering’ as a discipline. Unsurprisingly, this is generating some waves in the tech blogging community, with pieces such as ‘Software Engineering: Dead?’ from Jeff Atwood’s Coding Horror, and Myles Eftos’s ‘Yep, Software Engineering is dead’.

From reading DeMarco’s article, it is apparent that what he is addressing is the emphasis placed on ‘control’ on software projects - that ‘software engineering’ is often taken to mean that it’s a means of controlling the outcomes of developing a software project. It should be obvious that DeMarco’s stance is one of reflecting upon his previous work and making some comments about how his work has been perceived in the software industry over the years. Aside from some “Aw shucks, I wish my younger self had been wiser” style reflection, DeMarco laments the fact that his work has been used over the years to justify the creeping bureaucratisation of the software development process. From that point, DeMarco goes on to prescribe that, rather than controlling minutiae, those in charge of software development should be treating their projects (by way of analogy) as unruly teenagers - by attempting to instil a sense of moral values and principles, rather than by being overbearing and all-controlling.

Unfortunately, Jeff & Myles appear to either be sensationalising, or reacting to a rather superficial reading of DeMarco’s opinion. Straight off the bat, Jeff points out DeMarco’s gravitas in his field, to hammer home the point that ‘yes, this is a big deal’. From there, however, Jeff switches to his usual agenda of elevating the romantic notion of ‘software craftsmanship’. Not that I’m averse to this position - au contraire, I’m a big fan of Jeff’s frequent expounding on matters of software development principles. What I disagree with, however, is the utter sensationalism with which this is being made here. At least, I am heartened that Jeff appears to have grasped the main point of DeMarco’s analogy: “If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.”

I have no idea what has been said about either DeMarco’s piece or Jeff’s blog post on the 220 mailing list, though reading through Myles’ blog post left me slightly incensed at certain points. The analogy between building a bridge and building software is somewhat tired. Compared to building bridges, building ‘software’ encompasses a vastly larger scope. That much we agree on. You might as well be comparing building software with building anything made of materials sourced from the ground. From here, however, it seems that Myles launches into a tirade about his least favourite academic subjects, or at least the ones that he found ‘stupid’. What I fail to grasp at this point is the relevance to DeMarco’s piece… But I’ll play along anyway.

Yes, formal proofs are arduous, and can be rather silly for trivial programming tasks, but it should be obvious that such techniques aren’t applicable to all software development contexts. Would you apply formal proof methods to a small dynamic website you’ve just built? Hell no. Would you apply formal proof methods to mission-critical software that could potentially lead to injuries, fatalities or serious damage to the environment or property, if anything were to go wrong? Hell yes. (Well, some variant of a formal method, anyway) It’s a simple cost-benefit (or risk analysis) scenario: which costs less - the development process, or the consequences of something going seriously wrong? I’d further argue that formal proof exercises done in an undergraduate academic setting would be more geared towards teaching and learning the process of doing the proofs than anything else. This is undergrad CS that we’re talking about, with its endless assortment of silly assignments that require students to produce little of value beyond the end of their courses. I might also add that, even with a ‘simple’ program having 9 lines of code, this degree of simplicity may be afforded by a myriad of much more complex underlying supporting systems - the degree of simplicity of a program may simply be a matter of perspective, or from where you’re standing to look at the code.

What I find most troubling about Myles’ post, however, is the complete denigration of UML. Yes, I’ll admit that I’m a big proponent of UML. There may be a point about UML working really well with the waterfall model of software development, but to then imply that UML is almost completely useless - by association with the inadequacy of the waterfall model to address ‘real’ problems - seems a lot like missing the point of what UML is actually about. Yes, UML may superficially look like ‘architectural drawings or flow diagrams or something’. More importantly, UML is a standard notation to communicate about elements of software design. Beyond the ability of expensive software to create specky, neat and professional looking UML diagrams, UML itself is a tool for software developers to use when thinking about, crafting and communicating about the systems they’re building. By analogy, I would say that an ability to work with UML is like an ability to work with words and sentences and paragraphs. That is probably the reason why IT recruitment agents started using ‘Object Oriented Analysis & Design Skills’ and ‘Sound understanding of UML’ in their job ads - those *are* fundamentally useful skills to have.

As a programmer, I can have a conception of something that is a ‘class’ or an ‘object’ and be able to express the idea in a diagram, say on a whiteboard, while talking with fellow programmers, and still be able to more or less directly translate this concept into code using Java or Python. Using UML, I can model relationships between such classes and talk about such relationships - beyond mere representation, UML can be a valuable tool for solving software design problems, especially in team environments. [And the good news is that there are tools nowadays to automate parts of the translation between UML and code, so you don’t have to ‘go and update hundreds of UML documents every time a minor change was required’] None of this is really dependent upon the specific project management methodology being used. The real problem, as far as IT recruitment is concerned - at least in this region anyway - is that there is often a disconnect between what software development shops need and what their recruitment agents end up publishing. Given that IT recruitment agents are often more experienced in HR and marketing, they end up developing formulas for easily pushing job ads out there seemingly without much consideration for what is really required. That is how you end up with a litany of job ads that look like the same stuff rehashed over and over again. Thanks to all this, graduates who do have such skills end up in jobs which are advertised as requiring their skillset, yet never use them in any useful capacity.

Getting back to the main article, however - the point that DeMarco is trying to make here is rather subtle, one which can best be understood in the very context of his analogy. Developing software, in general, applies to a vast field of human knowledge and applications. As such, decisions about how software should be developed necessarily need to vary based upon the context and constraints within which such development is occurring. By way of analogy, humans, as they grow into adults, cannot be robotically programmed to gracefully handle every possible situation they might encounter. (Or, at least, one could imagine that this approach could fail rather disastrously if tried) Given these limitations, it is far better to learn about core principles and knowing how and when to apply them to produce generally favourable results. DeMarco’s point is that, as this applies to humans, that may be the real way forward for software development.

p.s. Some interesting and relevant articles relating to this topic:
- “Is Software Engineering Engineering?” - Peter J. Denning, Richard D. Riehle
- “Software Engineering ≠ Computer Science” - Chuck Connell

So the WAEC published the results of the referendum at http://www.waec.wa.gov.au/elections/state_referendums/2009_Daylight_Saving_Referendum/

I overlaid the data on a map of electoral boundaries of the Perth metro area (http://www.boundarieswa.com/2007/Final-Boundaries/Quick-Links-2007/):

Red: No
Blue: Yes

If you spot any mistakes, let me know!

I’ve been reading Alain de Botton’s ‘The Architecture of Happiness’ recently. A particular passage in part II of the book seems to do to design & architectural beauty what Pirsig’s ‘Zen and the Art of Motorcycle Maintenance’ did to quality - that is, defining such ethereal idealistic concepts vis-a-vis man:

In essence, what works of design and architecture talk to us about is the kind of life that would most appropriately unfold within and around them. They tell us of certain moods that they seek to encourage and sustain in their inhabitants. While keeping us warm and helping us in mechanical ways, they simultaneously hold out an invitation for us to be specific sorts of people. They speak of visions of happiness.

To describe a building as beautiful therefore suggests more than a mere aesthetic fondness; it implies an attraction to the particular way of life this structure is promoting through its roof, door handles, window frames, staircase and furnishings. A feeling of beauty is a sign that we have come upon a material articulation of certain of our ideas of a good life.

Similarly, buildings will strike us as offensive not because they violate a private and mysterious visual preference but because they conflict with our understanding of the rightful sense of existence - which helps to explain the seriousness and viciousness with which disputes about fitting architecture tend to unfold.

The advantage of shifting the focus of discussion away from the strictly visual towards the values promoted by buildings is that we become able to handle talk about the appearance of works of architecture rather as we do wider debates about people, ideas and political agendas.

Arguments about what is beautiful emerge as no easier to resolve, but then again no harder, than disputes about what is wise or right. We can learn to defend or attack a concept of beauty in the same way we might defend or attack a legal position or an ethical stance. We can understand, and publically explain, why we believe a building to be desirable or offensive on the basis of the things it talks to us about.

The notion of buildings that speak helps us to place at the very centre of our architectural conundrums the question of the values we want to live by - rather than merely of how we want things to look.

– Alain de Botton, ‘The Architecture of Happiness’

I have lately been embroiled in a debate about the importance of commenting in code. While I don’t yet believe that comments are completely unnecessary, I tend to think that they are largely unnecessary. Almost two years ago, I wrote ‘Software development without maps’ in which I extolled the virtues of ‘documentation’. While it can be easy to confuse ‘documentation’ with ‘commenting’ and jump to the conclusion that I’m now contradicting myself, I’d like to draw the distinction between the two. Commenting is only a specific type of documentation - a kind of documentation that is so narrow in scope that it only applies to code. [Sidenote: In general, commenting will end up covering the ‘mechanisms’ expressed by code, and very little of the ‘policies’ and justifications - which would be best covered by higher level documentation anyway.]

In essence, I see programming as an activity where one devises and manipulates abstract models. Writing code is merely a process of expression of such models. What I was trying to get at, in my previous blog post, was that the same models can be viewed at different levels of abstraction. The ‘documents’ encompass knowledge about the models at a higher abstraction level than the code. Documents, being UML diagrams, specifications, or other suitable representations. Comments, on the other hand, are at the same level as code. While it may be useful to sketch out a program using comments before the real code is written, I believe that such ‘scaffolding’ should eventually fade away. Like faint construction lines in a technical drawing, such comments are there to provide an initial framework for laying out the real lines and curves. Like faint and rough sketches on canvas, or a block of stone or wood, the comments become unnecessary as the system is painted, or moulded into shape.

As a software system takes shape and matures, the most reliable indicator of what it is doing is the code itself, not any superfluous comments. Indeed, there are various dangers associated with using and maintaining comments beyond the initial stages of coding:

• comment maintenance overhead
  As code is modified for various reasons - bug fixes, feature additions, refactoring for reuse - extra time is required to verify not only the proper operation of the code (which can be automated), but also to review existing comments and rewriting the ‘comment narrative’ in a way that fits the reshaped code. I consider this to be a special case of duplication of logic - in the presence of comments that attempt to explain the program logic, one needs to maintain not only the actual program logic expressed in the code, but also those comments that ‘pretend’ to be saying what’s happening. Such a task becomes especially daunting in a team of non-trivial size, as various people end up writing and rewriting chunks of this narrative - which all ends up devolving into an incoherent and unreliable mess. There are ways of managing, verifying and testing program code - and enforcing program coding style conventions - written in a diverse environment, but there is no reliable way of getting people to write a natural language in a consistent, non-monotonous way. The best we can do is introduce the editor model - should we then have a ‘comment editor’ on every programming team, to ensure that all the comments flow clearly and adopt the right style and tone?
• matching comments with code
  On the other hand, if programmers do not take the required amount of time to fully review and rewrite comments as they implement changes, we end up in a situation where the comments do not accurately reflect the sequence of events expressed in the code. As this compounds, over time, programmers who are introduced to the system later on bear the considerable risk of being lead astray while attempting to trace defects. The end result is code of poor quality, at the significant expense of time - time wasted following misleading comments.

Looking at the issue from another perspective, what about the usefulness of comments? The machine does not care about comments in the code. Comments do not affect the compiler. Comments do not affect whatever is going to be interpreting the code, or some processed version of the code. That is, indeed, the point of comments. Comments won’t make programs run faster, or in a more stable manner. Comments won’t eliminate bugs. If guns don’t kill people and people kill people, then comments don’t eliminate bugs - people eliminate bugs.

As far as I can tell, the importance of commenting code is 1) seemingly over-emphasised by Computer Science departments, and 2) an unfounded myth perpetuated in programming shops. OK, after a quick trip through IEEEXplore, I found several papers seemingly extolling the virtues of code commenting. However, they all seem to cite the same paper when doing so. A paper written in 1988. A paper about a study based on PL/I and Pascal. Enough said. Clearly, there has been some research done on the topic, but a lot of it seems outdated, especially in the face of more modern concepts such as Object Oriented languages, etc. I shall delve more into this and possibly post a follow-up to this.

In any case, even I was to assume that comments are useful and will bring about world peace, I cannot find any qualitative documentation on the subject. It’s all well and good to say things like “Your code should be 20% commented” or “You need to have comments describing each function” or “Comment about why, not necessarily what, the code is doing”, but no one ever seems to have good examples of such. Such vagueness simply serves to exacerbate the problem - anyone can write practically anything they like in comment blocks and get away with it. “Whaddya mean, I wrote comments! See!” A more practical way of posing this question would be: Given that I have a programming task, how do I write good quality comments that will remain useful to future programmers, given what I know about the problem domain, and how I anticipate it to change? Is there an example of this story and how it pans out?

Taking a step back, let’s look at the real problem that commenting pretends to solve.

As I mentioned earlier, programming involves the manipulation of abstract models and expressing them in code. It therefore follows that one gains more by learning how to more effectively express programming code than by decorating code with comments. Programming code is the ultimate middle ground - it is something understandable both by the programmer and by the machine (at some level). The programmer who can write prose in comments does not hold a candle to the programmer who can get the machine to execute exactly what he wants to get done. There are two main reasons for the existence of comments in code: 1) making up for the lack of higher level documentation, and 2) attempting to mask complexity by ‘explaining it in english’.

The first case is symptomatic of a poor development process, where intentions articulated at the business level aren’t properly captured and architected into solutions at various levels of abstraction. In the absence of UML and other such higher level program models, developers are supposed to resort to code comments to explain ‘why’ certain things are being done, even though higher level descriptions would be more accessible to various stakeholders. (This is a variant of the “explain why you’re doing this” style of commenting) Comments used in such a manner simply mask a lack of traceability between what a particular client wants, what possible solutions are presented and approved, and what ends up getting implemented. The valuable historical record of the back-and-forth discussions detailing what happened and when particular decisions were made, is simply lost. Coupled with an environment where developers are added to and removed from a project in a piecemeal fashion, this is simply a recipe for a fragmented disaster, as few of those involved have a complete memory of the sequence of events.

On the other hand, masking complexity by ‘explaining in english’ is plainly disproven by decades of development on programming languages. Concepts such as functions, classes, methods, packages and libraries were developed for the specific purpose of managing complexity by breaking down code into smaller, safer, more tractable and more manageable chunks. Those allow for the implementation of layerable and composable solution patterns, as well as enabling reuse - all techniques well known to help improve the long term reliability and maintainability of software systems. If it weren’t for those, we’d still be writing long epics in FORTRAN.. if we could even get that far.. The fact that classes and methods can be given meaningful names dispels a lot of the reason for using inline comments. Got a function doing lots of things? Break it up into smaller functions that have descriptive names. The code is then easier to follow at a higher abstraction level. Want to zoom in on a specific step? Just go into that function. Easy. Up and down the abstraction ladder.

Despite the various reasons for writing comments, it all boils down to managing complexity: the complexity of stakeholders’ requirements, the complexity of the solution at hand. What I’ve been trying to say is that all of this relates to the management of the development process. By building maps and models of stakeholders’ requirements, a better understanding of the problem domain can be achieved. The process of building such maps and models also helps in the discovery and resolution of conflicting requirements and essential priorities. From there, developers can devise subsystems that - when coupled together - should aim to meet the set of requirements. Such subsystems can then be defined in terms of their interfaces and interactions with each other - all at a higher abstraction level. From there, the team can then zoom in further into each subsystem and attempt to refine the implementation further. This same process can be repeated down to applications, services, packages, classes and methods. The whole ‘stack’ describes the abstraction ladder in a consistent manner, and moving up and down this stack constitutes the ‘zooming’ action. Explaining the process in such a way presents a simple concept that can be applied by various people involved in the process. Stakeholders talk to architects and account managers to produce documents and customer-facing models, while architects present the same documents and models to developers for further refinement and evaluation. The end product of this process is a whole collection of inter-related artifacts that document the history of the project and its various aspects from different perspectives - all of which is much more useful and accessible then comments buried deep in the code.

Another way of looking at the commenting problem is one of situational awareness. Piles of comments (or code, for that matter) are essentially worthless to a programmer until he reads them. (And when he does read them, the code will provide a more accurate picture of what’s happening, rather than the comments) A programmer (A) who writes some code has implicit knowledge of what the code does and why it’s doing what it does. A programmer (B) who simply reads comments written by someone else has explicit knowledge of what the code is doing, but not necessarily any implicit knowledge. A programmer (C) who reads some code written by someone else internalises a more accurate mental model of what the code is doing. Simply put, programmer A devises a mental model and expresses it in code, while programmer C is doing the reverse process by reading the code and building a mental model. While programmer B has some chance of success at building a model, he might end up doing so ‘faster’ than programmer C, but at the expense of an inaccurate - possibly even out of date - model. This whole construction and deconstruction of mental models is exactly why the ‘abstraction ladder’ development process is powerful - it provides models of varying detail at various levels to enable almost anyone to more easily conceptualise any part of the solution and work with it.

Earth Hour was on again last night. As I wrote about last year’s event, I figured it was time to post again, though this post won’t be about me re-iterating my previous points. I’ve just read an article on NYT titled The Civil Heretic, about Freeman Dyson and his ‘controversial’ views about climate change. This particular excerpt reminded me about something I wrote nearly two months ago, which I’ll post below:

The film continued with Gore predicting violent hurricanes, typhoons and tornados. “How in God’s name could that happen here?” Gore said, talking about Hurricane Katrina. “Nature’s been going crazy.”

“That is of course just nonsense,” Dyson said calmly. “With Katrina, all the damage was due to the fact that nobody had taken the trouble to build adequate dikes. To point to Katrina and make any clear connection to global warming is very misleading.”

February 9th, 2009: Bangkok is sinking

This article made me realise just how much the global warming alarmists sometimes contradict themselves. There is a subset of alarmists who whine about how urgent action is needed to prevent sea levels from rising. The rationale being that rising sea levels would not only cause small islands to disappear or coastlines to shrink, but mostly that some of the world’s largest cities are located on the coast, and would thus ‘sink’ under the rising waters.

Yeah, and?

If we assume that sea levels have been variable over the centuries (which doesn’t seem unreasonable), how were people previously affected? Is it not reasonable to say that, as sea levels rose, hundreds of years ago, people from coastal cities and other settlements simply moved to higher ground? They didn’t organise global action against climate change or sea level change, simply because they didn’t have the capability to do so. Alarmism was contained to coastal areas that were actually affected by the environmental changes. Humanity wasn’t just drowned out.

To say that humans are arrogant, selfish and destructive just because they decide to not subscribe to geo-engineering on a massive scale is simply disingenuous. What of the arrogance of those who wish to preserve monuments of unsustainability (i.e. strips of poorly engineered coastal urban strips) by performing large scale experiments in trying to influence the global climate?

Keep it simple - architect a more sustainable future civilisation that can weather extremes rather than playing global climate bingo.

–

While natural disasters strike more and more populated areas these days, the media seize the opportunity to dramatise the situation and attempt to link global climate change to ‘more extreme weather’. While that may be true, why doesn’t anyone pick up on the fact that people have been building cities in downright stupid places over the centuries - New Orleans anyone? What has changed is not the climate (which has always been variable), but people’s growing stubbornness in living on their little piece of land, no matter what the environmental cost - until disaster strikes. Nowadays, instead of properly learning from such disasters, it’s more fashionable to call for ludicrous large scale action to be taken to protect everyone’s little piece of coastline from the growing evils of nature.

I think it’s a great thing for people to finally be stepping up to think of a way forward for XMMS2, especially after a period of relative stagnation. However, I have a few bones to pick with the current shape of things.

Given the direction that the ‘XMMS2 Vision’ is taking, I I’ll say this: I think software freedom is overrated. We’re in 2009, an era where Open Source is practically mainstream - computer manufacturers such as Dell and ASUS are selling desktop and laptop computers with Linux (typically Ubuntu, or some other Debian derivative) pre-installed. ASUS’s Linux-powered eee PC helped launch the netbook revolution, with many observing that the netbook was an ideal application of the low cost benefits of a Linux-based OS. After a decade of people wishing to see Linux as a relatively mainstream desktop OS, it is practically there - any moderately computer literate average Joe can easily grab an Ubuntu Live CD and be on his way.

That’s not to say that freedom is not important, but simply chanting ‘freedom, freedom, freedom’ does not build a thriving community of passionate users. Well, actually, it does, but that’s a kind of community that borders on blind faith, religious dogma and rabid zealotry when it comes to ‘freedom’ - e.g. the cult of GNU. Passionate, indeed, but is this what you see for the future of the XMMS2 project?

When I think about the XMMS2 project, I tend to take the ‘freedom’ aspect for granted, given that XMMS2 has been an open source project for most of its time in existence. It’s a given that XMMS2 is released under an open source licence, and that the small community of loyal developers, users and other fans has been built upon this foundation - I don’t think that is likely to change. When looking for a future vision for the XMMS2 project, I’d say that it would be more useful to search for more practical goals than to get lost in navel gazing about freedom. In the end, what people care about is code that works.

I recognise that putting together this vision is a good opportunity to examine the values that are important to the XMMS2 project. More importantly, however, I think what’s needed is a sharper focus on achieving certain goals. Without a drive towards such goals, we’re pretty much left where we currently are, simply nibbling at ideas that we think are good at the time, without making much progress towards something more coherent.

I’d like to present my own vision for XMMS2 - by no means a definitive attempt, but merely my opinion - and comment on what has been said/written so far.

First of all: XMMS2, what is it? We use the term ‘XMMS2’ in many contexts, with multiple meanings. I feel that, without a clear idea of how to define the term, we’re likely to be left floundering, especially since this is at the very core of what we’re trying to do. XMMS2 is many things:

• A music player. (Or ‘audio’ player? We’ll get back to this..)
• A framework for building custom ‘jukeboxes’?
• A community of people who study, use, develop or otherwise contribute to a common codebase.
• A project - to produce a music player - encompassing the community effort.

Personally, over the years I’ve been involved with XMMS2, it has been all this and more:

• An opportunity to participate in an Open Source project and understand what it’s about - especially the ability to do so from firsthand experience rather than being an outsider looking in.
• An opportunity to put my software development skills into practice - and learn more about development in multiple languages, algorithms, software development processes.
• An opportunity to discover more interesting kinds of music than I knew of - music that’s almost non-existent on local radio stations and music shops.
• An opportunity to virtually meet and interact with strange people from all over the globe.

When I was first introduced to the XMMS2 project, I was merely a university student tinkering with something I found interesting at the time. What I learned from the subsequent experience, however, tremendously increased my development skills and practical knowledge of how software can be developed. I can say with some amount of gratefulness that being involved with the XMMS2 project is one of the major things that has shaped my career as a software developer so far - what I learned from Anders’ engineering skills is still something that has an influence on how I build software today.

Perhaps, then, one might consider ‘education’ as one of the values of the XMMS2 project. Indeed, XMMS2 has been a mentoring organisation in Google’s Summer of Code program for a number of years now - something which I believe has been quite instructive for both the students and the mentors involved. I’d like to think that there are others who might be interested in learning a thing or two about ‘real’ software development to join the community. Granted that code produced by the XMMS2 project is far from perfect, and far from being an academic example of great software engineering, I believe that there is much one can learn by being involved in the community and studying the code. (And no, the XMMS2 project isn’t unique in this respect - many other open source projects also fit the bill)

Beyond what XMMS2 means to each community member, we need to look at where the project is headed. The way I see it, there are two main points to make about this: 1) building the code (or system, or framework - technical excellence), and 2) building the community (community excellence). In this process, we must bear in mind that we’re trying to appeal to certain relatively distinct groups of people:

• Users
• Developers

Both groups view technical and community excellence differently.

In general, as far as users are concerned, if the product works, they’re (mostly) happy. (If they’re really happy, they might even tell their friends) As far as community is concerned, users are happy to occasionally rely on the community for support when things go wrong (Why can’t I play my music, etc). A user’s experience in both respects will dictate how long the user will remain loyal. For example, if XMMS2 can’t easily play a particular file, the user will seek an alternative solution and likely switch to a different player. If the user cannot get the community to resolve a particular problem, or finds the community relatively unfriendly, he will likely gravitate towards a more friendly community.

As far as developers are concerned, technical excellence is about producing interesting code in particular ways - a more efficient algorithm, a more flexible plugin system, a library with a clean API, a seriously cool feature that’s not available anywhere else. The cornerstone, however, is the existing developer community around the project - these existing developers are the gatekeepers to the existing codebase, the ones with inside-out knowledge of how the existing system works, the ones who share the history of the project and dictate where it is going. The interface between contributing developers and core developers is exactly where the value of ‘open source’ comes into play. On one hand, contributing developers are attracted by how easy it is for them to modify existing code to introduce new features or fix defects, and on the other hand, core developers must have processes in place to ensure that code of relatively high quality is accepted - while encouraging the better contributors to remain interested.

Somewhere in the middle, there’s an intersection between the set of users and the set of developers. This typically takes the form of passionate users with certain skills moving towards becoming developers by contributing code to the project. In general, I think that this should be encouraged, as it grows the base of community members available to support users and induct new developers.

OK, so I’ve talked a bit about what I think is important for XMMS2 as a community. I’ll post some more later about users, developers and XMMS2 as the product.

Yes, there’s actually a film titled ‘Paris’. It’s yet another one of those ‘multi threaded’ plot films, a la Syriana or Babel. It starts off rather confusingly - rather than picking a single starting point, and then branching out, it begins by showing glimpses of all the various little subplots first. Predictably, the subtle links between the various microcosms become apparent, later on.

The film is very much a romantic snapshot of life in Paris, in particular the life of Pierre, as he tries to deal with the news that he might not have much longer to live, due to a heart condition. From there, the film tries to link in the lives of the cute girl who lives across the road from Pierre, her history professor and his brother, Pierre’s sister - Elise - and a bunch of African immigrants with a brother from Cameroon trying to make his way to the very city, a group of produce vendors from the market where Elise often shops for groceries.

There appears to be no greater purpose to the story other than “this is Paris”, presented in a way reminiscent of how the history professor attempts to characterise Paris’ colourful, multifaceted and ‘fragmented’ history and personality. Indeed, there are points in the film where you feel that the city itself is a character that unwittingly influences the lives of the human characters that live within it, whether it’s by drawing them in from far-away places, frustrating them about their various day to day problems, presenting them with awkward romantic opportunities or offering them hope and joy.

I didn’t turn off any lights during the so-called Earth Hour 2008. There were 3 or 4 lights on at the time, each rated around 15-25W - yes, those hazardous, mercury-vapour-containing compact fluorescent bulbs. My UPS monitor logged approximately 300W usage while I was playing Call of Duty 4 online. (That’s including various network equipment - modem, switch, wifi AP - a low power file server, a 22” LCD monitor and a PC with an Nvidia 7600GT GPU.. plus a macbook charger) I didn’t replace any lights with ‘calming’ oxygen-sucking candlelight, nor did I use any phenol-producing plastic glowsticks.

I’m glad that others did, however, turn off their electrical conveniences and replaced them with alternative pollutants, if only for an hour - all in the name of raising global awareness of .. what was it exactly? Energy efficiency? Pollution reduction? The minimisation of resource depletion? Carbon Dioxide emissions reduction? Oh yes, that’s right.. ‘global warming’. And, while they did so, coal-powered baseload power plants kept on belching their millions of tons of Carbon Dioxide, soot and other air pollutants.

Here’s an idea for Earth Hour 2009: How about getting the power producers involved? Instead of just switching off your lights, which does nothing to slow the actual power generation process, why not get power companies to also switch off their power plants? Think about it: instead of then having estimated savings of:

• ~10% energy usage per city
• ~40000-60000 car-usage-hours

you’d be safe in the knowledge that you actually did help STOP Carbon Dioxide (and power) production for a while, and not just flipped a few switches and buried your head in the sand long enough to delude yourself into thinking you actually made a real impact, in terms of resource consumption.

But then it’d take a few days for those baseload plants to cycle back up to full production capacity.. that should be fun - let’s call it Earth Week, instead of Earth Hour!

Real progress in energy usage and efficiency don’t happen overnight, and they certainly don’t happen with people just ‘thinking about their energy usage for an hour’. Real progress in energy usage happens in the form of:

• More energy efficient light bulbs like those from Luxim, that convert more electricity to light, rather than heat
• More efficient power generation methods, like experimental panels that convert nuclear radiation directly to electricity
• Smart devices that switch to low power mode when not being used
• People turning off unused lights every single night, instead of one hour per year
• Designing, building and buying more energy-efficient devices in the first place

So pull your head out of the sand and look at the big picture. It’s a big, energy-hungry world out there. The only way we’re going to make it is not by going backwards to the days where electricity production didn’t exist, but forwards, where electricity is produced and used in a more efficient manner.