Mark Shuttleworth | here be dragons

One of the big debates we are having at the moment in the Foundation is all about how to design a curriculum to stimulate the development of analytical skills. The thing I care most about is that we focus not on the specific set of tools, but on the ability to “learn and apply a current tool set”.

The truth is that we constantly acquire and discard sets of tools. So we should not be fixated on one specific set of tools for all of life. Society, technology and the times change so fast that any fact, process or algorithm we learn at school is by definition not going to be useful for any length of time. The real skills that serve us are the ability to adapt, learn, apply the products of that learning, and participate in the discussions and challenges of the day. Tht doesn’t mean that facts are useless, nor that specific tools don’t matter. Unless you can demonstrate an ability to absorb and apply both, fast, you haven’t actually gained the knack of becoming effective in a given environment.
I was thinking about the toolsets I’ve had to acquire over the past fifteen years since I left school.

In university you are solving the problem-du-jour as set by lecturers and tutors. Each year you learn a new set of theorems, axioms, rules, laws, analytical techniques, best practices, algorithms, formulae etc. And you have to learn how to make them dance for you so that you can do well in that year. Then, by and large, you file those away never to be used again, and learn new tools for the next year of study. Sometimes, the tools and laws and rules are additive, you build new knowledge on the old stuff. Sometimes, however, you just learn the tools because you need them to get through the year, and that strikes me as being makework. See my rant on the study of economics below.
In work, you’ll have to learn the tools of the trade or the company and how to get things done. If you’re a nutcase like me, you change your toolset entirely every few years – I spent two years consulting and training (late university and early Thawte), two years writing database-driven web applications for crypto and PKI services (later Thawte), a year studying ballistics and space vehicle operations (Star City and the ISS), two years learning cooking, dancing, and the intricate details of playboyhood, and now two years learning about how to build a distribution (Ubuntu), and how to build *big* web applications (Launchpad.net). In each of those phases the tools have been different. Its hard to know what kind of schooling could have made a meaningful impression on my ability to be a better cosmonaut – or a better programmer – or a better man of leisure.

And I’ve no idea what set of tools I’ll have to learn next.

My experience might be extreme, but for ALL of us life consists of a constant process of reinvention, learning and discovery. You are not doing the same job today that you were five years ago – the world is changing around you. the most successful people learn how to spot the best tools and trends and to take advantage of them. They also learn to LET THEM GO when the time is right. Rather than being convinced your tools are the One True Way, recognise that they are rocking good tools right now and will also certainly be obsolete within five years. That gives you an incentive to keep an eye out for the things you need to learn next.

Not everything that gets offered to you is likely to be of use. I hated economics at university because it epitomised the disposability of old knowledge. The problem was that first-year economics was basically a history lesson disguised as a science lesson. We learned one classical set of ways of looking at the world, and how to apply them to assess an economy. This was a bit like learning science circa 1252 and being told that you need to be able to draw up an alchemical recipe for lead-to-gold conversions that could pass for authentic in that era.

Then in second year they said “luckily, the world has since decided that those ideas are utter crap, you can’t really manage an economy using them, but here’s a new set of ideas about economics”. So we set about learning economics circa 1910, and being expected to reproduce the thinking of the Alan Greenspan’s of that era. The same people who orchestrated 1929-1935 and all the economic joy that brought the world. We knew when we were studying it that the knowledge was obsolete. And of course, when I looked into the things we were supposed to study in third year, fourth year and masters economics programs the pattern repeated itself.
There is some value in disposable knowledge. I like to hire guys who set out to learn a new programming language every year, as long as they are smart enough to stick to core tools for large scale productive work, and not to try and rewrite their worlds in the new language every year. The exercise of learning new API’s, new syntactical approaches, new styles is like jogging, it keeps you fit and energised. It’s useful even if aren’t a marathon runner by profession. But it should be kept in balance with everything else you have to do.

So, back to the topic of curriculum.

We want to create a curriculum that can:

• be self taught, peer mentored, and effectively evaluated without expert supervision
• provide tools for analysis that will be general useful across the range of disciplines being taught at any given age
• be an exercise machine for analysis, process and synthesis

The idea is not that kids learn tools they use for the rest of their lives. That’s not realistic. I don’t use any specific theorems or other mathematics constructs from school today. They should learn tools which they use AT SCHOOL to develop a general ability to learn tools. That general ability – to break a complex problem into pieces, identify familiar patterns in the pieces, solve them using existing tools, and synthesise the results into a view or answer… that’s the skill of analysis, and that’s what we need to ensure kids graduate with.

I’ve had the huge privilege over the past two days to be on the panel helping select this year’s Rolex Awards for Enterprise.

It’s inspiring to see the diversity of amazing projects that were shortlisted – on the one hand that made the debate all the more difficult, on the other hand I felt that each project had much to recommend itself. You’ll have to wait till October to find out the winners! Anyhow, for the record, it’s fantastic to see individuals with courage and vision getting the chance to pursue their dreams with the support of an award like that. If you know someone – anyone – doing original and visionary things with whatever time and resources they have to hand in the fields of exploration, heritage, the environment… urge them to apply for the next round.

Perhaps the best bit for me was the panel itself. Most often when I have the pleasure of meeting someone I really admire the meeting is necessarily short – we’ve both got to run to the next meeting, and the next time we’re likely to be able to coordinate a meeting in person is months away. Here we had long, intense discussions about the projects, which become a proxy for the challenges facing the world at large. And so you really get to see what people think are important, and why. A great two days. Tomorrow, I’m off to San Fran for the MySQL user conference, then NYC for the weekend and on home to London to get ready for The Drake.

Lloyd pointed out that I never blogged about…

The Edgy Eft

We now have quite a lot of infrastructure in place to track feature ideas through to implementation, so this is a call for folks who want to drive features in Edgy to document those in the wiki, and register them in the Ubuntu Blueprint. I should say that there’s a real art to getting a feature into Ubuntu. If you can hack it yourself, then join MOTU and get cracking! If not, you might want to read a little about managing the community process and building a team around your idea that CAN turn it into reality.

Enjoy!

I’m all fired up after two days of the most amazing work bringing together some very remarkable people to talk about a TSF strategy to ensure that we can give the next generation excellent analytical skills despite the global collapse in the supply of maths teaching capacity.

The headliners were:

Alan Kay of the Squeak project and Squeakland educational software platform,
Guido van Rossum of Python fame,
James Dalziel of the LAMS project, IMO the “next big thing” in the e-education space,
Zelda Holtzman, CEO of the Shuttleworth Foundation

There were about 15 of us, covering several programming environments (scheme, smalltalk/squeak, python, logo) and a variety of educational frameworks (UK, South Africa, participants from France, Switzerland, Netherlands, USA…). The idea was to bring together people who potentially have the ability to shape up a framework that can take off like wildfire. The risk was that, with so many strong opinions from different backgrounds, we would not be able to make progress.

Suffice it to say that after two days in the bunker, I think we did brilliantly! I saw real bridges being built between Alan and Guido, two great men who’s collaboration might give us the tools to teach logic from the earliest days of education (think of 5 year-olds writing code visually) through to high level instruction (we all know how effective Python is for university type problems, right?). Instead of fighting over turf or syntax, I sensed a genuine willingness to synthesize the best work from both camps into something that could have both Python’s pop-culture widespread appeal, and pedagogical foundations that build on years of Alan’s experience in the Squeak world. The mouse might yet become the snake’s strongest ally.

We also heard from people who help to shape educatonal policy in the UK, South Africa and elsewhere, and I was even more convinced that the problems we want to solve through this initiative are universal, even though the crisis is most evident in countries like South Africa. So I hope we can mobilise a global response, and if you have access to global agencies interested in education then please put them in touch with Helen King, who coordinates the international work of TSF.

What’s this all about? The big picture is that I believe we should be building an analytical skills curriculum that is post-mathematical. Mathematics is a beautiful but abstract art, that has traditionall been the vehicle for the development of analytical capacity in young minds, but has equally traditionally been seen as dry and difficult. We need to teach mathematics NOT because people should become mathematicians (I could not pass my first year maths exam tomorrow though I did reasonably well at the time) but rather people we want society in general to have the ability to apply known tools and patterns to solve the problems it encounters. That’s what learning maths gives us during our formative years.

So what could replace traditional mathematics instruction? Why, software engineering – but not the way it is taught today. We don’t want to produce a society of software engineers any more than we used to want to produce a society of mathematicians. We want to produce a society that knows how to:

1. Learn a set of tools quickly and efficiently. In life, the set of tools we apply to the problems we face changes every few years. So it’s not the specific SET of tools you learn, its the ability to grok a new toolset, figure out when to use, and do so efficiently that counts.
2. Break problems into simpler pieces, solve them using familiar tools. The whole process of analysis is about taking a big hairy problem that is new and unfamiliar, and teasing it into pieces that look solvable based on tools that you already know.
3. Put those simpler answers back together to make an answer to the big problem. This is the synthesis part – taking the results of your analysis and making them meaningful in the real world.

Anyway, the traditional way to teach these life skills has been to drill kids in mathematics. That was always quite a tough sell. Nowadays, its a tough sell in the face of even tougher competition for learner mental bandwidth from cell phones, MTV, instant messaging and the myriad other bling-bling commercials desperate to get your attention when you are 12 and about to get your first credit card. So we need something that is sexy, exciting, challenging, and interesting. I’m pretty convinced that basic technology is becoming pervasive, so by the time our R&D here bears fruit it’s reasonable to expect that most kids even in developing countries have access to technology, whether that looks like a $100 laptop or a TuxLab (another awesome TSF project). And kids LOVE technology. They love the games, they love the puzzles, they love figuring out how to make those darn machines do what they want. This initiative, then, is about figuring out how to build a curriculum that will produce generations that can do the 1, 2, 3 above NOT because they learned mathematics, but because they explored the world of technology.

You can read more about this specific project on the TSF wiki.

I realised that Blueprint has very little in the way of documentation to help people figure it out. Despite this, usage of Blueprint seems to be taking off, with nearly 700 specifications in the system and quite a lot of Launchpad karma getting dished out daily. But documentation will help, especially since Blueprint is starting to take shape and will be at the heart of our planning for Dapper+1.

So without further ado, I give you:

Official Blueprint Docs (v0.1)

Enjoy, and comments, updates and clarifications welcome! Note, some of those features discussed have landed in the code but not yet moved to production, so you can find them at http://staging.ubuntu.com/ rather than http://launchpad.net/ for the moment.

Phew, big Blueprint landing just went in to LP, I guess it will be in production some time this week. This gets the spec tracker into roughly the right shape for us to get Dapper+1 smoothly planned and executed. It also involved quite a lot of groundwork for the 1.0 UI I am driving towards for Launchpad. So perhaps I should blog about those plans and solicit some feedback.

The high-level story is this:

• Applications on subdomains. We will move the functionality of the different facets of Launchpad into subdomains. So rosetta.launchpad.net will be where you will find translation pages, malone.launchpad.net will have bugs, blueprint.launchpad.net will have feature tracking. These applications will share a navigation system so if you are used to using the one app, and moving around Launchpad objects (upstream, ubuntu and derivatives, people and so on) then you will easily feel comfortable moving around in a different app. The big advantage of this is that it keeps you “in the zone” as you move around Launchpad. So say I am working on the spec system, and I click on the link to Carlos’ homepage in Launchpad. Typically, when I do that, it’s because I want to see what Carlos has on his plate in terms of feature development. Using subdomains gives us this for free, because I will be jumping, say, from http://blueprint.launchpad.net/distros/ubuntu/dapper/ to http://blueprint.launchpad.net/people/carlos/ and as you can see I’m automatically still in the “specs” mode. I’ve watched people using Launchpad, and usually when we jump from thing to thing we still want to keep focused on the same “facet” of that thing.
• A better menu system. A lot of the navigation will shift to the top-bar menu and breadcrumbs system. Right now you can see an (ugly) first step towards that, if you hold your mouse over the Launchpad in the top left corner you see a dropdown menu that takes you to distros, products, projects, people, meetings… now imagine you could continue navigating in to the specific product or distro or package you are looking for. Less clicking for everybody. The breadcrumbs will also become part of the menu system, so say you are looking at the 1.5.0.2 release of Firefox (two thumbs up btw guys) and you want to see what features are planned for 2.0, you should be able to get there just by hovering over Firefox in the breadcrumbs, then see the 2.0 series, and go straight to it.
• Better switching between apps. At the moment, we confuse two different kinds of switching. You can switch between objects that you are viewing, and you can switch between the aspect or facet of the object too. Sometimes, clicking on “Bugs” in the actions menu does BOTH kinds of switch, and that’s really bad. Its unpredictable. So we will work towards ensuring that any action link has a predictable result – it either is an action in the current application on the current object, or it changes the app but keeps you on the current object, or it changes the application and takes you to that app home page (“I’m switching now to think about translations, take me to the Rosetta home page”).
• Canonical object names. We track quite a few kinds of objects in Launchpad. The main ones are distributions (and their structure, releases, packages), upstreams (in the form of overarching projects, as well as individual products and their releases) and people. In order to disambiguate them we’ve kept separate namespaces for them, and used the URL structure to indicate what you are looking at. Hence you can have http://launchpad.net/products/mozilla/ and http://launchpad.net/projects/mozilla/ if you want. Now we want to switch to a different approach, where we canonicalise the names of those three major kinds of object. So there can only be one “ubuntu” thing, and that’s the distro. And only one “mozilla” thing, and that’s a project. And only one “firefox” thing, which is a product. This will let us simplify the URL’s quite a bit, down to http://blueprint.launchpad.net/firefox/ for the specifications for Firefox, we can drop the /products/ bit because we have Canonical names. This also gives us a “teleport” facility, where typing the name of the thing teleports you straight there. An email address will take you straight to the home page of the person you are thinking of. A product name will take you straight to that products Launchpad page in the app you are working on.

As you can imagine, there have been lots of dicussions, debates and fairly intense arguments about the UI for Launchpad. It’s a huge piece of infrastructure, I think it’s quite a bit richer in scope than SourceForge, which would be a reasonable comparison point, so it’s taken a long time for us to get a handle on how most efficiently to present it. I’m pretty confident in this plan, and keen to see it in place in the next three months, perhaps even in time for Dapper.

Further down the line I think we can use AJAX tools to speed up the interaction processes, but I don’t want to jam those into the infrastructure until the core plumbing is robust and mature. Right now the world of AJAZ is very much in flux, and so is the underlying set of frameworks we use in Launchpad: Zope 3 and SQLObject. We have a lot of work to do just to get the core app framework robust for taking Launchpad to scale, and that’s where we are focusing the resources. We’ve published pretty much all the Zope and SQLObject changes we are making, and I think I would like to make more of that work. Once the AJAX stuff matures, we can fold it into the app framework in a general and graceful fashion.

James Dalziel, of the LAMS Foundation, is leading a project that I think is the “next big thing” in e-classroom technology. Basically, LAMS is a tool that describes not content, or people, or processes, but the interactions between all of them that make up the learning experience. Unlike a traditional content management system like Moodle, or a collaboration system or chat system or school information system like SchoolTool, the LAMS goal is to construct the “workflows” that make up a learning module.

So with LAMS, you design a “digital classroom experience” to convey a certain skill or knowledge. You find and link to content (that could come from Moodle, or the web generally, or just be embedded in the LAMS object). You figure out whether you want the learners to read, or discuss, or write essays, or vote, or have forums-style discussions, etc. And you sequence all of that and set it up that you can track the work done by each participant in each stage of the process.

Best of all, these LAMS objects are content in their own right, can be published under open content licences, and shared and improved with open-source style processes so that over time we can create a body of learning experiences that is interlinked and ever-improving. I think these general principles will serve us very well in this first stage of the TSF analytical skills development initiative.

So I just want to say a big thank you to James and the LAMS team for helping to invent something entirely new and very special. I’m sure there will be other, similar frameworks, but it takes a remarkable bunch of people to envision and build something different. Well done.

I wrote most of the spec tracker in Launchpad (click here if you want to see it in action) and it needs a little more love before the next Ubuntu developer summit. So I’ve been hacking on it in preparation for the Launchpad sprint. There’s still another round of updates coming, but for now please enjoy:
Proper implementation tracking: a proper implementation status dial, which lets people say how they are making progress with the actual coding of the feature. JaneW has been asking for that for a while now, since she compiles the weekly Dapper development summary and it should make that process a LOT simpler.

Safe targeting to releases and series: a reasonable way to target a spec to a distro release (“dapper”) or a product series (“1.2”). Anybody that is related to the spec can propose it for a release or series, but only the series managers can accept or decline the feature. So it behaves a bit like a wiki, with only the drivers of the upstream product or the distro able to give the go-ahead for a feature to be an official goal for a specific release.

Along the way I fixed a bunch of embarrassing bugs in the menus for product series. I blogged separately about how product series are *supposed* to work and why they are important in Launchpad. I’m working on making ProductSeries an essential part of the system, since a lot of the data model issues get cleaner when you assume that series is always there.
These changes should all be in production in already at launchpad.net. As usual, these features work equally well for upstreams using Launchpad as they do for the distro teams.