Ceci n'est pas un blog

Moving to Pelican

2026-09-20T15:00:00+08:00

I launched this blog 18 years ago as a Django 1.0 site. 9 years ago, I relaunched the site as a Lektor site, as that was what I was using for BeeWare’s website.

It seems like very nine years, I am scheduled to rebuild my blog on a new platform, because I’ve just moved this site to be hosted on Pelican. Unlike the switch to Lektor, this isn’t driven by maintaining parity with BeeWare’s tools - when I mentioned I was thinking about migrating my blog to MkDocs or Zensical (to match BeeWare), a close friend chastised me, and told me to Just Use Pelican. So I did.

During the Lektor refresh, I mentioned that I was hoping to give the site a visual refresh “in the near future”. This remains an aspirational goal.

How to Succeed at Sprinting

2026-06-23T10:00:00+08:00

Over the last 12 years, BeeWare has earned a reputation as being a model project for running sprints. I’ve been running (or helping to run) Django sprints for 7 years before that. This is a playbook of what I’ve learned over the years about running a successful sprint.

Firstly - a caveat: the sprints that BeeWare (and to a lesser extent, Django) have run have been very focussed on attracting first-time Open Source contributors and building buzz about the project. That’s not the only way to run a sprint, and it’s not the only audience to attract. If your goals are different, you might not gain as much from this guide.

However, my experience has been that for projects that are targeting “entry level” programmers, the process of engaging beginners can serve as a great way to build positive energy around your project. I attribute a lot of the success of BeeWare in the broader Python community to the explicit outreach we’ve done in making first-time contributors feel welcome. The sprinting process is as much advertising/marketing for BeeWare as a great community to be part of, as it is the classical understanding of “improving the project”.

Before the sprint

Work out what you want to accomplish

Go to the sprint with a clear vision of what you want to achieve from the sprint. Are you looking to gain new contributors? Do you want to make as many people as possible feel good about the project? Are you looking for a multi-day opportunity to deep dive into a topic with experts? Do you have an area of focus where warm bodies can help? Know what you want to achieve, and clearly communicate that in your community ahead of time. This is an area where long term momentum helps - BeeWare is, by now, a known quantity at PyCon US sprints. Long term PyCon attendees with no attribution to BeeWare will point confused first-timers (or first-timers who have been disillusioned with sprinting on other projects) at BeeWare, based purely on our historical reputation. That reputation takes time to build, but every long journey starts with a single step.

Most of the rest of this guide assumes that your goal in the sprints will be to attract new people to contribute to your project.

Polish your contribution guide

You need a contribution guide, and it needs to be bulletproof. BeeWare’s contribution guide has developed over many years. It needs to describe everything that is needed to set up a development environment, run tests, and anything that needs to be done to pass CI (e.g. running pre-commit checks). The instructions need to work on Windows, macOS and as many Linux distros as you can manage (or, it needs to be clear ahead of time where they won’t work). Any friction in getting a working development environment will be an impediment to the sprinter sticking around.

Curate your first “good first issue” list

Make sure you have an easy to find subset of issues that are clearly understood, are easily reproducible, are well described, and have a reasonably clear path to a fix. The more introductory your audience, the more explicit these instructions need to be. BeeWare is an unusual project in that it is an umbrella project of many smaller projects, so we use a GitHub project board with a specific view for issues ready to be completed. That list can be filtered by priority, complexity, experience level, and anything other detail that might be useful.

It’s also important that the good-first-issue list is clear about the skillset that is required. If you need to know non-Python languages to fix an issue, then that needs to be clear. The vast majority of sprint attendees will only know Python - so that also needs to be factored in.

This can be an opportunity to teach people new skills, though. For example, attendees might not know C, but if you can present an issue that only requires a small amount of C, in a way that utilizes transferable knowledge from Python, you might be able to get someone contributing in this way. BeeWare gets this with Toga contribution - contributing to the macOS/Cocoa backend strictly requires knowing Objective C… but for simple issues, you really only need to be able to read some Objective C docs and see that a doFooBar() method exists, so it’s approachable for Python-only developers.

If you can: have a “big picture” project

One of the reasons BeeWare got good at sprints is that, in the early days, we had a complete test suite, but a lot of the tests were marked as skips because of a missing implementation. We could point someone at the list of tests that were marked as skipped, and say “make one of them pass”.

This sort of specific situation is obviously difficult to reproduce, but if you can, it’s magic. Large scale housekeeping projects are a good candidate here - something like “we’re updating all of our documentation from ReStructuredText to Markdown” is something where individual files can be tackled independently. There’s a long TODO list which are all similar and can be described in abstract terms, but require individual independent contributions.

It doesn’t have to mean writing code, either. It could mean working through a ticket backlog - if you’ve got 1000 open issues, that’s the sort of thing where having a group of individuals to try and reproduce each problem and confirm if they are still problems. If you can clearly articulate your triage process, a sprint is a great opportunity to throw bodies at a backlog.

During the sprint

Get there early on the first day

The early bird gets the worm - in so many ways. You get to claim the best sprinting spots; and you get to claim the enthusiastic people who show up early on the first day. If you roll in at 11AM, you’ve missed 3 hours of contributors who wanted to contribute, but had no point of contact.

Make it easy to be found

If you’re going to the trouble to tell people you’re sprinting, make sure they can find you. It’s worth having some signs to draw attention to which table/room you are in, on top of anything the conference provides. I travel to PyCon US with pop-up banners - they’re great to stand in front of the room to draw attention - but tape or Blu-tack and an A4 printed page, or a plastic sign holder in the middle of your table can be just as effective.

Welcome everyone to the room

Don’t assume you can just put up a sign and people will “find their own way”. If you see someone enter the room, go out of your way to say hello, introduce yourself, and see if you can get them hooked. It helps to have a short canned speech describing the first steps for contributing - for many, “do the tutorial” is a good first step. BeeWare has honed this down to a specific Sprint Guide to help us shape that initial conversation, and give a clear TODO list for people when they arrive.

It also helps if that speech is focussed on them rather than you and your project. If you can make your project feel like a place that needs them specifically, or is well suited to their specific skills, or aligned with their or needs, then all the better. This could be as simple as asking “What brings you to our sprint?”, or asking where they work and what they use Python for. In addition to making a personal connection, it gives you an opportunity to tailor your “pitch” to their interests, and a way to narrow any suggestions for sprint projects that are more likely to be “on topic” for them.

Help every attendee find their first issue

If someone turns up and flails for an hour, they’re going to go away disappointed - and probably won’t tell you when they leave. You need to help them get initial traction. This is where the contribution guide, curated first-issue list and welcome script all come together.

Make sure that you have a process to make sure that two people don’t pick the same issue. This doesn’t have to be high tech - it can be as simple as posting a comment on the issue they’ve picked saying they’re working on it.

Set them up for success

When you help someone pick a first issue, don’t throw them a nasty crunchy bug that is hard to reproduce. Get them to fix a typo, or add an error message for a bug that can be easily reproduced. The first issue is where they will be learning about your project’s contribution process. Make it easy for them to get the first win; their second issue can be something more complicated.

Circulate around the room

Don’t plant yourself in the corner and assume people will find you when they need help - circulate around the room and ask how people are doing. If nothing else, this is a chance to make a personal connection with the audience; but it is also surprisingly effective at getting someone who is beating their head against a simple problem to admit they’re having a simple problem, and get them unstuck.

Be wary of assumed knowledge

You might think that everyone at PyCon knows how to use Github. You would be wrong. I’ve had to walk sprint attendees through very entry level Github tasks. It is inevitable that someone will submit a pull request from the main branch of a fork, and you’ll then have to walk them through cleaning up the mess they’ve made. The same goes with assumptions about Python environments, environment variables - things that you’d think would be assumed knowledge for someone attending a Python conference. Often part of the challenge of helping sprinters is working out what it is they don’t know - because often they don’t even know enough to know they don’t know something.

Make yourself available

If you’re committing to running a sprint, you won’t get anything of your own work done. For the first half day, you’ll be introducing and onboarding contributors; for the rest of the time, you’ll be reviewing PRs. You can’t just put on headphones and focus - you need to be there for the community that has joined you. If you’re sprinting well, you will get nothing done on your own TODO list.

Celebrate every win

When you merge someone’s PR, make a big deal about it. Django sprints have historically had a gong (or other obnoxious musical instrument, like an air horn or bike bell) that you get to bang when your PR is merged. It doesn’t have to involve equipment, though - I usually try to start a round of applause in the room - pretty soon, everyone knows if you hear applause, someone just got their wings.

If you have the budget, having a small token of appreciation for that first win can also be a useful incentive. BeeWare has challenge coins that are given to everyone on their first commit; but it doesn’t need to be an expensive thing - even a “sprint exclusive sticker” could work.

Be relentlessly positive

People attending sprints often have a lot of imposter syndrome. After all - they’re attending a conference, and they’ve just seen all these super-rock-star-ninjas speak about their projects… how could they possibly contribute? A big part of running a successful sprint is to dispel that mental model, and get them over the mental hurdle of contributing at all. Reinforcing the “yes, you can contribute” message at every opportunity is important to ensuring nobody bounces off because of imposter syndrome.

This is one of the reasons that Challenge Coins work - it provides a very small, but tangible reason why it’s worth working through the imposter syndrome. You’d be shocked how much people will struggle through to get $1.50 worth of enamel and steel.

Be aware of CI limits

BeeWare has literally broken CI systems during sprints through the load that has been generated. At the very least, expect a CI backlog. If you’re giving out tokens for completion like challenge coins, you might need to use “review approval” rather than “merge” as the success criterion. If you have any way to optimize your CI processes, that’s also worth doing ahead of time.

Set boundaries for yourself

Sprinting for 3-4 days, being “on” and positive for the whole time, is exhausting. Make sure you take time for yourself - step away for coffee and for meals, and don’t be afraid to step away at 5PM.

After the sprint

Have realistic expectations

I go into every sprint hoping that we’ll uncover the Next Great Contributor. Realistically - this never happens. Sprinting isn’t magic. In my experience, it’s more about exposure and marketing - a way to make a community feel good about your project. Over time, those good vibes accumulate.

The passage of time

2026-01-07T20:00:00+08:00

20 years ago…

20 years ago, to the day, I received a short email from Adrian Holovaty:

Would you be interested in commit access on the Django magic-removal branch? We’ve really appreciated your contributions lately and would love to see more.

With that, I became a member of the Django core team. I couldn’t have predicted how that email would change my life.

18 years ago…

18 years ago, not quite to the day (25 January 2008), I received a short email from Stephen Phillips, founder of a new Django-based startup in the media space. They wanted to bring some Django expertise in house, and I was a notable member of the Django Core team.

However, they were based in Brisbane. I said I had no interest in relocating… so he offered me the job as a remote employee. I’ve been a remote employee every since.

The company was called Plugger; it was renamed to Wotnews not long after I joined, and became WeAreHunted before I left. As well as a bunch of experience in a startup environment, I got my first exposure to iOS development - we developed MySpace’s first iPad app.

15 years ago…

15 years ago, to the day, I made the first commit to the repository that became TradesCloud. The startup bug had got a hold of me, and my co-founder and I were convinced that we had an idea that was a winner.

11 years ago…

It turns out it wasn’t. And the pressure of trying to keep the lights on in a failing startup, plus a bunch of other things going on in my life, meant I was in the middle of a major depressive episode. I didn’t actually seek professional help until around April of 2015.

However, along the way, I had also hit a technical limitation with Django - I needed a mobile app. A mobile-enabled PWA wasn’t up to the task, and I didn’t have the time or resources to develop both an iOS and Android app. All my company’s business logic was written in Python… so why couldn’t I use Python to write my mobile app? Someone should do something about that…

9 years ago…

9 years ago, around this day, I was in the process of shutting down TradesCloud. We had made the decision to shut down TradesCloud just before Christmas, and we turned off the lights on January 31 2017.

But it wasn’t a complete loss - by this point, BeeWare was in development.

4 years ago…

4 years ago, on this day, I received an email to reschedule a meeting with Kevin Goldsmith and Stan Seibert at Anaconda to speak about BeeWare. This was the fourth meeting I’d taken in the previous 2 months from Anaconda staff… and I was so flattered that they were interested in the project I founded that it had not yet occurred to me that I had been having job interviews.

Just over a month later, I accepted a job offer to join the Anaconda Open Source team.

Today

The last 20 years has been a wild ride. It has, at times, taken an emotional toll; and being geographically isolated has been difficult - especially when leaving my home city was almost impossible for 2 years due to worldwide lockdowns.

However, I have also done things in my professional life that I never could have imagined I would have the opportunity to do. The work I’ve done has had an impact on every continent on this planet, and on other planets. I’ve seen my work used by multi-billion dollar companies, and I’ve seen it used by not-for-profit groups to have a profound impact on the world.

More importantly, I’ve made friends all around the world, who I love with all my heart. I don’t get to see you all in person anywhere near as often as I want to; but that doesn’t mean I love you all any less.

But for an email 20 years ago, none of this would have happened. At the very least, it would have been radically different - given the state of the tech industry in Perth, it’s difficult to believe my career would have had an even remotely comparable trajectory was it not for stumbling onto a freshly open-sourced web framework in late 2005. I can’t begin to thank Adrian and Jacob enough for the faith they showed in me all those years ago in offering me commit access to Django. I hope I have been able to pay forward even a fraction of what you gave me by sending that email.

Where do you see Python in 10 years?

2019-05-03T10:00:00+08:00

At PyCon US 2019, I was extremely honored to give the opening keynote. While the PyCon Video team worked their usual magic to publish the video really quickly, some people prefer to consume text rather than video, so this is the transcript of my remarks.

I’ve been an active and visible participant in the Python community for over 13 years now. And as a result, I’ve spoken at a lot of PyCons and DjangoCons. But for those who haven’t met me before: Hi, you may have noticed I’m not a local.

I was born, and I live to this day, on little dot down the bottom of the map: Perth, Western Australia. Perth is not usually one of the cities people think of when they think of Australia. Its kinda like Cleveland - a fine city, but not usually the first one that jumps to mind when you think of the US.

Perth has a fascinating history, and has had a bigger impact on the world than many realize - and some of those stories are convenient metaphors - so today I would like teach you all about Perth, and maybe we can learn some valuable lessons about life along the way.

First off - some terminology. We are in Ohio. Someone from Ohio is called a Buckeye. Someone from Western Australia - is called - and I swear I’m not making this up…

…a sandgroper.

We’re so named after this delightful fellow - Cylindraustralia kochii. It’s a pygmy mole cricket. About 2 inches long, lives in the sand dunes at the beach.

And they’re not venomous!

Acknowledgement of Country

Sandgropers - the people, not the insects - have a tradition about how you start big public events like a PyCon. Australia, like the US, Canada, and many other colonized countries, has a messy history with their indigeneous peoples. In recognition of that fact, starting in Perth in the 1970s, Australian public gatherings have, increasingly, started with a recognition that the land where the gathering is happening wasn’t always white man’s land.

It’s called Acknowledgement of Country - and in that spirit, I’d like to acknowledge that I come from Whadjuk Noongar Boodja; and I’d like to recognize the Eriehonan and Haudenosaunee peoples, the traditional owners of the land where we meet today, to recognize their continuing connection to their land, waters and culture, and to pay my respects to their Elders past, present and emerging.

Content Warning

Also - as a content warning, later in this talk, I will be discussing issues of depression and self harm. If that’s something that will impact you, please do whatever you need for self care. I’ll give another warning before we get to that part of the talk.

So - to the subject at hand. We’ve established that, yes, I do come from a land down under… but who am I?

Who am I?

Well, in my day job, I do data engineering for Survata. Survata is a market research company. They use Python and data science to help brands to understand their customers.

Survata gives me the flexibility to flit around the planet to meet all you wonderful people - but as lovely as it is to have the support of a wonderful company like Survata, that’s not really why I’m here today.

I became involved in and I’m known to the Python community through my work on Django. I joined the Django core team way back in 2006. Because I lived in Perth, I didn’t meet another member of the Django core team until 2008.

Django is a big part of the broader Python ecosystem; but it’s not the only part. Django isn’t the only Python web framework; and web programming isn’t the only thing people do with Python.

In my current day job at Survata, I don’t use Django at all. But I do make extensive use of NumPy, Jupyter, Pandas, and the ecosystem of tools around those libraries.

And there many other uses of Python. You can use Python on embedded devices. There are libraries for performing astronomical calculations, biotech and gene sequencing. It’s used as a scripting language for operating system automation, as a control language for devops, and as a teaching language.

None of this has happened overnight. Python as a language is 28 years old. It took maybe 10 years for Python to gain significant traction in our industry, and another 10 before it gained really widespread support.

And, as a result, we get.... this. A gathering of three and half thousand people who have organized to travel from all over the planet - even Perth - to converge in, of all places, Cleveland, to talk about a programming language for a couple of days.

It’s worth stopping for a moment to reflect on the magnitude of what Guido set in motion 28 years ago, and what we, collectively, have done since. It should be celebrated, because it’s no small feat.

And because this is the big tent of the Python community, we have a real opportunity to look to the future as well. This weekend, and into the sprints next week, we have the opportunity to dream big ideas, work out what problems we need to solve, and where we’re going to collectively focus our efforts over the coming weeks, months and years.

So, to kickstart that conversation, I’d like to pose a question to everyone in this room.

A question

Where do you see Python in 10 years?

The one thing I’m certain of is that everyone in this room will have a different answer to this question - that’s inevitable when a language is used by so many people for so many different things. But if you’re here in this room today, I think it’s probably fair to assume that you like Python to some degree. And in 10 years, you’d like Python to be at least as vibrant a community as it is today.

I’m sure nobody wants to have to rewrite all of the libraries on PyPI, or rebuild all the communities and user groups in the Python ecosystem, or re-establish all our ecosystem norms in a new community, just because Python is no longer a viable language for new projects.

So - this question - Where do you see Python in 10 years - is really about asking what we need to do today to ensure that Python remains a relevant, vibrant, and healthy community.

Time for some more sandgroper facts.

Black Swans

The state bird of Western Australia is the Black Swan. It appears on the Western Australian Flag, and on the crest of the City of Perth. The river running through the middle of Perth is the Swan river.

But a black swan is also a metaphor.

Prior to the 1600s, it was well known that all swans are white. Swans of other colors were known to not exist. And then in 1697, Dutch explorer Willem de Vlamingh visited Western Australia - and discovered that swans could also be black. This radically changed the worlds idea of what a swan was.

In 2001, essayist and statstician Nassim Nicholas Taleb used this as a broader metaphor.

Taleb defined a Black Swan event as an event that is a surprise to the observer, that has a major effect on the world, but in hindsight, can be easily explained. In hindsight, it was obvious that swans could be be black. But until someone visited Western Australia, it never occurred to anyone to challenge that assumptions.

Black swan events don’t have to be immediate, either - the impact can be felt over time. The rise of the personal computer was a black swan event. In 1947, CEO of IBM Thomas Watson famously said there was a world market for maybe five computers. Today, almost everyone in this room is carrying five computers. In retrospect, Watson’s comments are just quaintly naive. But at the time, they weren’t controversial - they were the common understanding of the world. And the change wasn’t immediate, but in retrosoect, it was inevitable.

Python’s Black Swan

In my opinion, when we’re thinking about what the future holds for Python, we need to be thinking about Python’s black swans.

Python is a popular language right now. We’d like it to stay popular. What could happen to affect that popularity? What change could happen in the industry, in hardware, or in the community, that could alter the popularity of Python? That would cause Python to become that annoying legacy language that we have to know, but would rather replace at the earliest opportunity?

Black swan events are only truly obvious in hindsight - but the best way to avoid them is to actively challenge your assumptions. And question what would happen if those assumptions turned out to be incorrect.

And I think there’s a couple we have cause to be concerned about.

Black Swan 1: Everyone uses a laptop

First - where do you run Python?

For pretty much the entire existence of Python, a “computer” was a large box that sat on your desk, or maybe in a rack in a server room. Over time, the box got smaller, and you started carrying it around in your backpack, but you used the same operating system - Windows, or a Unix derivative.

Over the last 10 years, we’ve seen the emergence of a new class of computing devices - much smaller, and usually portable. Phones, tablets, watches, and set top boxes.

These devices are becoming ubiquitous - and they’re replacing laptops as primary computing devices. My son started high school last year. He doesn’t have a laptop for school. His entire educational experience is delivered through a tablet device.

If you go to python.org, tablets, phones and set top boxes don’t even rate a mention. To me, that seems like a pretty big oversight of the way the everyday experience of computing has changed over the last 10 years. Phones and tablets are acheiving market penetration that desktop and laptops have never seen. And yet, as a community, we don’t have a story for how you can use Python on these devices.

So what happens to Python when laptops don’t exist, or become niche devices? If I’m a novice programmer, and there’s no installer for Python on my tablet, and I can’t use Python to write an app for my tablet… why am I going to learn Python?

Black Swan 2: Python can stay on the server

Not all Python runs on laptops, though - some of it runs on the server. And you can use Python to write a web application.

10 years ago, when Django was the cool new thing, you installed Python on the server, and you used it to render HTML and CSS to the browser. If you were really hip, you’d sprinkle some AJAX in as well, adding autocomplete to your search box - but you made sure that if the user didn’t have Javascript enabled, the page would gracefully degrade and would still work.

These days - good luck finding a web page that works without Javascript enabled. As with mobile devices, the last 10 years has seen a dramatic shift in where code is being executed, and increasingly, code is being run in the browser. Javascript evolved from an optional client-side add on, to a language implementing key logic in the browser, to a language that replacing Python on the server.

Again - if I’m a novice programmer, and I’m faced with Javascript - a language I can use to get a native experience in the browser, and can transition that onto the server… and on the other hand there’s Python, a language that only works on the server - why am I going to learn Python?

Black Swan 3: Installation is a solved problem

Ok, so lets say that despite those two problems, I have decided to learn Python. And I reach the point where I need to install a package.

I’ve been a user of Python for 20 years, and in that entire time, I don’t think there’s ever been a period where I’d describe Python’s packaging story as “stable”. And because information lives forever on the Internet, old advice continues to linger, long after it’s considered the “right” answer, and then well meaning but misinformed people spread outdated advice on stack overflow, perpetuating the problem.

The situation is bad enough that it’s a punch line for comics. In XKCD 1987, Randall Monroe lampoons Python’s environment experience as so degraded that it has made laptop a toxic waste site.

Brett Cannon did a really good writeup about this comic, trying to diagnose what has happened on Randall’s computer. It’s a really enlightening autopsy, well worth the read.

One thing that Brett points out - and it’s the part that’s most concerning for me, from the perspective of looking for Black Swans, is this:

Why can this joke be made at all?

Good jokes always contain an element of truth. And the way you respond to that truth matters. This joke is part of a narrative about what Python is. And if that picture isn’t positive, then long term - that’s an existential threat. If I’m a new user, why would I want to learn Python if everything I read about it ends up with a joke about my computer becoming a toxic waste site?

Black Swan 4: Code distribution doesn’t matter

And I haven’t even got to the question of how I distribute my application to someone else. Whether you’re distributing a Django application, or distributing a user-space application - Python hasn’t ever had a consistent story for how I give my code to someone else - especially if that someone else isn’t a developer, and just wants to use my application.

Contrast that with, for example, PHP, whose distribution story is “use FTP to upload all the files”. Or Go’s story, which is “here, have this executable”. I’m not saying that the PHP or Go solutions are a panacea - they’re not. And I’m not saying Python’s story will be as simple as any of these. But we haven’t got a story at all - and we’re competing against languages that do. And again, why would I want to learn Python if I can’t get a clear answer for how I can give my code to my non-programmer friends?

… or is our Black Swan something else?

That’s 4 possible Black Swans that I’ve identified. Maybe it’s something else? I know there are people in this room who will assert that Python’s C API is a potential problem. Or the GIL. Or the lack of a good front-end story. Or focussing on Unix and Mac to the exclusion of Windows. Maybe the problem won’t be technical at all - maybe it will be cultural. Some aspect of Python’s community or development process that drives some segment of users or potential contributors away because of percieved hostility, or conflict, or diverging interests.

Or maybe it won’t be any one of these things. My point is that we can’t predict the future. But we can challenge our assumptions. We can look criticially at ourselves as a community. We can examine the trends in our industry and our society, and make plans based on those assessments; not just reacting to problems when they’re already wildfires, but proactively addressing problems before they become critical threats to the ecosystem.

This is not about blame

I also want to be very clear here. This isn’t an accusation. I’m not blaming anyone of not doing their job. The Python core team is doing the absolute best they can with the resources they have - and they’re very limited resources.

What I’m talking about here is trying to avoid Black Swans. To start a conversation about longer term priorities, and how we marshal the resources that we, as a community, have at our disposal.

BeeWare

For whatever it’s worth, these existential problems are one of the reasons I changed the focus of my open source contributions a few years ago. As I said eariler, I developed my reputation working on Django. But these days, I’m spending most of my volunteer time on the BeeWare project.

For those that haven’t come across it before, BeeWare is a collection of open source tools and libraries for creating native user interfaces in Python - for desktop, but also for iOS, Android, single-page webapps, and other new hardware platforms.

A key part of that work is getting Python to run on phones and tablets at all, working out how to run Python code on Android, iOS, and in the browser, bridging to native APIs on those platforms, and wrapping those APIs in a cross platform layer.

Another big part is developing a distribution story - working out how to integrate with native platform tools, and get an application written in Python wrapped as an app, with an installer, or uploaded to the App store or Play store.

Now, BeeWare is a work in progress. It’s current state is “compelling proof of concept”. It’s not a version 1 product ready to start using to develop your mission critical application; but I have been able to demonstrate that cross-platform native applications, written in Python is possible.

I’m also not the only person working on this problem. The Kivy project has similar goals, but with differences in their underlying approach.

As far BeeWare is concerned; about 18 months ago, I did a live demo at PyCon Australia 2017 where I wrote a Fahrenheit to Celcuis application, in 50 lines of Python code, and deployed it on MacOS, Linux, Windows, iOS, Android, and as a single-page web application, all in the space of 20 minutes.

And when I say deployed - I don’t just mean “I ran the code”. I mean on Mac, it was a standalone .app file. On Windows, it was an MSI installer. On iOS and Android, it was a packaged app, running in the device simulators, but it could have been uploaded to an App store. And it was running in a browser, completely client side, including doing the Fahrenheit to Celcius conversion in Python, in the browser.

Sisyphus

Now - as you might imagine, this is a big project. I’ve been working on BeeWare for years, and there are days when I feel like Sisyphus, eternally pushing a boulder up the hill.

Unfortunately, there hasn’t been a lot of visible progress since I did that demo. There’s even been some regressions - Android and web support is currently broken, for example. And that’s because it’s not my day job. I’m tinkering on this in what I amusingly refer to as my spare time - and as a result, progress is slow.

Now despite all this - I’m actually optimistic about Python’s future.

To explain why, I need to tell you another piece of Sandgroper history, about a yacht race.

The 1983 America’s Cup

I need to tell you about the America’s Cup.

The America’s Cup is the world’s oldest international sporting trophy. The America’s Cup race is held about every 4 years; Those of you from San Francisco may remember the 2013 America’s Cup, raced in San Francisco Bay.

But from the first race in 1851 to 1980, the winner was the the New York Yacht club.

In 1983, New York lost to the Royal Perth Yacht Club, and it’s yacht Australia II, breaking a 132 year winning streak.

Now, it’s difficult for me to understate how big a deal this was in Australia, and in Perth specifically. This was event that put Perth on the world stage for pretty much the first time.

Many of you here today probably even know about the 1983 America’s Cup without even knowing why. Some of you may have heard me drop the line that “I come from a land down under” earlier on. That’s a line from a song by Australian rock band “Men at Work” - that song was the unofficial theme song for Australia II. And it was popular in the US primarily because of the 1983 America’s cup. The movie Crocodile Dundee was concieved of and able to get financed and released, in part, because of the exposure Australia received from the America’s Cup.

Just to be clear, though - Outback steakhouse? You can’t blame us for that. We had nothing to do with it.

Ok, but other than the Perth connection - why does the America’s Cup and Australia II matter?

Lesson 1: A fair game

First off - lets talk about the New York Yacht Club’s winning streak. The yachts in the 1983 race were what are called 12 meter yachts. Despite the name, it’s got nothing to do with the size of the boat - it describes a set of rules for the design of boats, involving sail area, waterline length, and more.

However, the America’s Cup hasn’t always been raced by 12 meter yachts. Prior to 1956, a range of yacht classes were used. According to the deed for the trophy, the defending club must accept regular challenges; but they’re allowed to set the rules for those challenges.

And so, for many years, the New York Yacht Club would impose rules like “the challenger must come from an ocean yacht club, and must sail to the competition site on it’s own hull”. That is - a challenger from England would have to cross the Atlantic in their yacht… whereas the defender would pop out from Newport harbour. And surprise surprise - under those conditions, New York’s yachts were lighter and faster.

So, lesson 1 from the America’s Cup - it’s not enough to just follow the rules; you have to ensure the competition is fair.

The New York Yacht Club wasn’t breaking any rules. They didn’t write the deed for the trophy. They were just playing the hand they were dealt. But nobody in their right mind would call the resulting competition fair.

In a situation like this, you have a choice. You can either keep winning in a competition that has been stacked in your favour, or you can change what is in your control, and make it a fair competition. But you don’t get to claim you’re the best in the world, winning on merit, unless you’ve leveled the playing field.

Could this be an metaphor for the IT industry… you know? I think it might be. I’ll just leave that thought over here.

Lesson 2: Watch out for Black Swans

But to their credit, the New York Yacht Club adopted the 12 meter rule in 1958, so since then, the competition had been fair - so why hadn’t anyone else won? And why did Australia II win?

Well, a Black swan happened. Sailing is highly competitive, and the New York Yacht Club always fielded a strong defence, with well designed yachts, and highly capable crews. When you add in the home-harbour advantage - knowing the seas and prevailing winds of Newport harbour - it’s easier to continue winning.

And the design of 12 meter yachts was essentially finnessing a well established design. Sure, there were variations between boats, but they were relatively well understood tweaks of a basic design.

But Australia II was a Black Swan.

When Australia II arrived in the US, the lower half of the boat was shrouded in secrecy. This invited all sorts of wild theories - especially when it started winning races. On two separate occasions, the Australian team caught SCUBA divers trying to take a peek. There were all sorts of accusations that whatever was under the shroud must be illegal.

But, the team kept the secret right up until the victory celebration, when the team owner stood on the dock, and called for the boat to be raised into the air for all to see - revealing the winged keel. On most boats, the keel is simple flat surface, used to lower the centre of mass of the hull, counterbalancing sail forces.

Ben Lexen, the designer of Australia II, thought about it differently. He reason that the keel is a hydrodynamic surface - so lets treat it as one. And he added a pair of wings on the bottom of the keel. Those wings perform a similar role to the winglets on an airliner’s wings - winglets on a plane’s cause the wing to generate more lift, and less drag. And the same is true on a keel - the winglets make the keel more effective at keeping the boat upright, which means the sail is more effective, and the boat is faster.

The blue paint was camouflage so that if you did get a photo of the keel, you’d see the outline of a traditional keel shape.

Fast forward to the 1987 Americas cup. Every yacht had something secret. There were fiberglass hulls. There were all sorts of keel shapes. There were dynamic keels. And the innovation has continued to this day; carbon fibre hulls, solid sails, and more.

The America’s cup isn’t sailed on 12 meter yacht’s any more - The next America’s cup in 2021, will be sailed on what are called AC75 yachts which are quite literally, flying boats. They’re so light, and generate so much thrust from their sails, that they’re able to use their keel as a hydrofoil and lift out of the water. These boats travel at amazing speeds.

All of this innovation has happened because one team decided to challenge the assumptions of 12 meter yacht design. It was controversial. It was risky. But it worked. And yacht racing hasn’t been the same since.

And - just to nail the metaphor home - the name of Australia II’s tender boat was the Black Swan.

Computing’s winged keel

What does this have to do with Python? Well, I think we’ve already seen a winged keel in our industry: WASM.

For those who haven’t heard about it, WASM is “Web Assembly”. It started life as a research project trying to identify the set of primitive Javascript operations that will execute fast in modern javascript engines. That set of primitives is very close to the capabilities of an assembly language - Allocating memory, Simple integer and floating point operations, and so on. And as a result, you can use that set of primitives and compile C to this “assembly language” target.

WASM is the extension of that work, defining a binary format for transmitting “assembly” content, rather than transmitting Javascript that has to be parsed and interpreted. That makes WASM code smaller and faster to process… but no less portable than Javascript, because at the end of the day, it’s still Javascript.

Essentially it’s separating Javascript into two parts - a fast, sandboxed runtime that is almost universally available because it’s in the browser; and a language that targets that runtime. For the purposes of our industry, it means that the rules have changed. You no longer have to adopt Javascript the language to adopt Javascript the runtime.

Python on WASM

That means there’s an opening for Python - and other languages, for that matter - to be languages available for client side logic in the browser.

WASM is still in the relatively early days. There are still some issues being worked out - one of the big ones being the interaction between the DOM and WASM. And making a viable WASM-based Python will require some work.

But the winged keel has been revealed. What we do with that knowledge is up to us. Are we going to dig into the technology, get creative with the rules, determine how we can exploit the rules to our advantage, and sail off in our flying boat? Or are we going to continue to race flat keeled 12 meter yachts and wonder why we don’t win races any more?

Lesson 3: The team matters

But there’s more we can learn from Australia II. Ben Lexen was a very talented yacht designer. He did a remarkable thing when he put winglets on Australia II’s keel. But he wasn’t a competitive sailor.

John Bertrand was an amazing skipper. But he couldn’t design a yacht.

And there were 14 other people on board the boat, and an entire support team on the tender and back at the harbour ensuring those 15 sailors could be competitive. Sailing is a team sport. You don’t just need a top-notch engineer or skipper. You need a wide range of skills, and it’s only when all those skills come together that you achieve success.

And the same is true of software. Although there’s a historical narrative about great software development being done by a sole hacker tapping away in their basement, that’s never actually the case. What we see today as the Python community is the result of countless thousands of hours of effort from countless people.

And, being primarily software engineers, the coders often get the most attention. And yes - writing good software takes a lot of effort; and doing it well takes time and skill.

But that’s only considering the code. Any project - especially one the size of Python - is much more than the code.

Project and Team Management is a skill.

Graphic design and UI design is a skill.

Developer relations is a skill.

Technical writing is a skill.

Now, these skills could be broadly considered in the remit of a “well rounded” software engineer. But what about things that aren’t even remotely software related?

Who organizes the community events?

Who provides legal advice?

Who handles communications and public relations?

Who builds the relationships with potential donors and manages fund raising?

Who makes the strategic deals with the Googles, Microsofts, and Amazons of the world to ensure Python is a supported language on product roadmaps?

It turns out - there are people in the world who can’t program, but who have remarkable skills that are very, very useful.

Lesson 4: Money makes things happen

And Australia II has another lesson here. Ben Lexen and his team didn’t do all this engineering design work out of the goodness of their heart. Competitive sailing has been described as the ability to stand in a cold shower tearing up $100 bills. The Australia II challenge was bankrolled by a gentleman named Alan Bond. The 1983 challenge was the third challenge that Bond had financed, collectively absorbing hundreds of millions of dollars.

Without Bond’s money, the Australia II challenge would not have happened. And without a commitment over multiple Cup campaigns allowing the design team to become deeply familiar with 12 meter yacht design, and funding the research effort, it wouldn’t have culminated in the winged keel.

Expertise costs

Whether it’s competitive sailing or software, expertise is needed - but experts kinda expect to get paid.

From inside the bubble of open source software development, it’s easy to lose sight of the fact that some of the cultural norms we see… aren’t normal in other industries.

Open source software is an industry where it’s apparently expected that having worked your 9-5 day job doing something you’re skilled at, you’ll go home, and do some more, for free, and then encourage multi-billion dollar organizations to benefit from your effort.

In most industries, if you’re good at something, you get paid to do it. And people outside software have really useful skills – skills that many open source projects badly need.

But it’s true of writing software, too. People are paid well to write software. But there’s plenty of software that should be written, but isn’t - or isn’t written in a timely fashion, because we’re waiting for volunteers to do the job.

Django is a web framework, and it took the DSF over 3 years to coordinate the most recent redesign of it’s website. Why? Because if you need volunteers, you’re immediately constraining the amount of time and effort that anyone can put into the job.

And I don’t want to undermine the significant contribution the volunteers have given to Python and the Python community - but I do want to challenge the idea that volunteering is the only way that Python or open source can progress.

If you pay people for their time, they’re much more likely be able to maintain their attention on a problem until designs are fully fleshed out, and consequences are considered, and the work gets done.

PyPI MOSS Grant

We saw an amazing demonstration of this in the Python community with the rewrite of PyPI.

PyPI has been around for 15 years. It badly needed a rewrite for almost half it’s life. Everyone agreed a rewrite was needed. But the work never got finished. Why? Because nobody was being paid to work on it.

Then Mozilla gave the PSF a grant of $170000. And the work was done in 6 months. Why? Because a couple of people could focus on getting the job done, instead of trying to fit bugfixes in on weekends between their kids football games, or trying to convince their boss that even though improving PyPI wouldn’t make any money for the company directly, it was a worthwhile activity.

PyPI is an unfortunately rare example. What opportunities have we left on the table - or are we at risk of leaving on the table - beacuse we aren’t resourcing them? What constraints have we placed on our own growth because nobody was enthusiastic enough to volunteer their time to address some gap, or make the most of some opportunity?

And who have we excluded from the development process because they had other life commitments, or couldn’t justify donating all their spare time to a volunteer effort? Or because they can’t take up a short term grant contract because they live in the US and need healthcare coverage?

Research and Development matters

It’s not just about maintenance of existing infrastructure, either. History has shown that research and development is how you ensure success in the long term. And groups that don’t do R&D eventually get beaten.

Australia II’s investment in R&D led to the winged keel, and kickstarted a whole generation of progress in yacht design.

The black swans I identified earlier aren’t something that can be addressed with a trivial fix - they’re going to need concentrated effort, and probably a bunch of dead ends along the way.

I’ve been doing what I can with BeeWare; but I’m really only doing that on weekends. And the same is true of a lot of Python, and the Python ecosystem. For the most part, the Python we have today has been developed in the spare time of volunteers, or in whatever fragments of time engineers have been able to extract from their employers.

What if it didn’t have to be that way? What if Python had an R&D division - a permanent engineering group that could focus on strategic tasks for the Python ecosystem.

When Bell Telephones gave a bunch of engineers the resources to engineer strategically, we got Unix. When Xerox funded a team in Palo Alto to engineer strategically, we got Xerox PARC, which gave us graphical user interfaces, and ethernet and laser printers.

When you give talented people the resources to think big, amazing things can happen.

The Python community has talented people. We just need to give them the resources to think big thoughts, and do big things, without the need to demonstrate that the work will generate profits in the next quarter, or without the need to spend half their time on one grant writing the proposal for the next grant.

And it could open the door to giving high profile, paid career opportunities to groups that have been historically underrepresented in open source developent.

How do we pay for this?

The underlying problem we have, though, is how to pay for it. Open source is an amazing way to do engineering - but it’s not a business model. We need to work out how to fund our engineering goals of open source without compromising the social goals.

Common Pool Resources

This problem is an area of academic economics research. Elinor Ostrom won the 2009 Nobel Prize for Economics for her study of Common Pool Resources, or CPRs. Real-world examples of CPRs are things like forests, or grazing lands. They are situations where anyone could access the resource. The best individual strategy for using the resource is to take as much you can get. But the best communal strategy is to collaborate. To limit what you take, and to contribute back to maintaining the resource so that, in the long run, the health and productivity of the resource is maximized.

Ostrom’s work looked at examples of Common Pool Resources that are being managed in the real world. Some of them have been collectively operated and maintained for hundreds of years.

Sacred topics

One of the key findings of Ostrom’s work are the conditions required for sustainable CPRs. And one of those conditions is exclusion. In order to sustain a common pool resource, you have to be able to restrict access to the resource to those that are committed to adhering to community principles.

The problem is that this is in direct opposition to the Free Software guidelines - which state that you can’t restrict the ability of people to redistribute software.

I don’t know how we reconcile these two positions. It may require some very serious consideration of some ideas that have been considered sacred for a long time, or at the very least, to draw a clearer distinction between software and the communities around them. But we can’t avoid these discussions. The consequences of this discrepancy has a very deep impact on people in our community.

To that end - I’ve got one last piece of Sandgroper history that I’d like to share with you.

And as a heads up - we’re about to get into the sensitive topics I flagged earlier.

C.Y. O’Connor

Charles Yelverton O’Connor was born in 1843, and became the Engineer-in-chief of the Public Works department of Western Australia in 1891.

He had a wide range of responsibilities, but there are two major public works that he’s remembered for.

Fremantle Harbour

The first is Fremantle Harbour.

Perth is actually a really dumb place for a large city to be. Sure, it’s a long way away from everything - but cities on the ocean need harbours. But Perth doesn’t have a natural deep water harbor.

So they needed to make one. And they did that by dredging the mouth of the Swan River. And this was done, under the direction and supervision of CY O’Connor, in the 1890s.

The Goldfields Water Scheme

But that wasn’t O’Connor’s only major achievement. The other was even bigger - the Goldfields Water Scheme.

In the early 1890s, gold was discovered near the towns of Coolgardie and Kalgoorlie. This started Western Australia’s gold rush.

These towns are in the middle of a desert. There are no natural water sources. But people need water - so they would paying 5 shillings a gallon to have water carted by horse from Perth. Adjusted for inflation, thats around US$100 a gallon.

But there was so much gold, they were willing to pay. The 1890’s goldfields gold rush doubled the population of Western Australia in four years.

But some people were dying of thirst and disease, so the government wanted to do something.

CY O’Connor’s solution was a pipeline, running 530km - 330 miles - from Mundairing weir in the Perth hills, to Kalgoorlie, with a series of 8 pumping stations along the route to get the water to it’s destination, lifting the water 340m in altitude over the pipe’s length. It takes 5 days for a drop of water to make it’s way from Mundairing to Kalgoorlie. Again - this was built in the 1890s.

Fremantle Harbor and the Goldfields pipeline were conceived, planned and delivered in the era of horse drawn carts and steam engines.

These were both mammoth undertakings. It took considerable financial commitment from the government of the day to make them happen.

But like all ambitious plans, they weren’t universally popular.

Criticism of these two projects was widespread. People who had alternative plans that had been rejected took to the presses to express their dismay. Two successive editors of Perth’s Sunday Times newspaper made it their personal mission to see O’Connor brought to account for the way he was wasting public funds. They took every opportunity to accuse him of corruption, of ineptitude, calling for a Royal Commission into his activity.

And all this public criticism and pressure took it’s toll on O’Connor. One early monring in 1902, he took his own life.

These two projects - Fremantle Harbour and the Goldfields Pipeline - they were ambitious - but they weren’t foolhardy. They were well designed. And they have shaped Western Australia. They have both been in continuous operation from the day they were commissioned. Kalgoorlie is, to this day, an active gold mine - one of the world’s largest. And children are taught CY O’Connors name and story in Primary School because of the importance of the work he did. But the combination of the public narrative surrounding his work, and his own mental health issues led to the worst possible end.

Unfortunately, this is a story that will sound familiar to anyone who has been around the open source community for any period of time.

Burnout

I have been a part of online communities for 30 years, and a maintainer for almost 15.

And I’m here to tell you - dealing with people is emotionally exhausting. The sense of entitlement that some people bring to discussions about a tool they’ve received at no cost, and without any obligation to give back in any way, is phenomenal. And dealing with the messy parts of community so that everyone else doesn’t have to - is just as exhausting.

And over time - those pressures add up. And when you’re doing all that mental and emotional labour as a volunteer, it makes you question why you bother at all. My personal experience - I was diagnosed as being in the middle of a major depressive episode in early 2015. Now, there were a number of contributing factors, but one of the big ones was the pressures imposed by my volunteer work dealing with the Django community - in particular, dealing with Code of Conduct issues - and one code of conduct issue in particular.

I burned out on the Django community. And I’m still part of that community because of the many amazing friends I’ve made - but I don’t actively contribute anywhere near as much as I once did.

The (hidden) human cost of FLOSS

I can think of dozens of others who have had similar experiences; who have either scaled back their involvement in open source, or dropped out of the community entirely, because of the treatment they’ve received at the hands of others in our community.

Fortunately, I never reached the point of contemplating self harm - I was able to find the help I needed before reaching that point. But I know people who have.

Are we, as a community, comfortable that we’re doing this to our peers, our leaders - or to anyone, for that matter?

Do we want to build our community on the expectation that volunteers will give of themselves until they burn out? Are we OK with the idea of project founders martying themselves so that the wider commmunity can have access to a web framework, or a packaging service, or a numerical processing library?

Or do we want to find a way to structure our community to make sure that people who are able to do good work have the resources to do what they do well; and access to others who can actively support them in that work, and access to individuals with skills in other areas?

Wrapping up

10 years ago, Python 3 was released. Despite numerous cries that it would kill python, we’ve come out the other side as a larger, stronger community. The transition to Python 3 required some bold technical decisions, and OK - maybe some mistakes were made - but ultimately, the gambit appears to have worked.

That success wasn’t inevitable. It took planning and effort. And future success isn’t inevitable either. What about the next 10 years?

Calls to Action

What can you do to help?

Call to action 1: Start thinking about Black swans

Firstly, we need to start thinking about the Black Swans that have the potential to redefine us.

We can’t affort to just think about the most pressing problems that are obvious right now. Our immediate sources of pain, or potential sources of revenue.

We need to think about the problems we’re going to have. Because addressing those problems is going to take time, and by the time those black swans become the pressing problem… it may be too late.

Call to action 2: Improve resourcing of maintenance and R&D efforts

Secondly, we need to improve our resourcing of maintenance and R&D efforts. We need to work out how to harness the not-insignificant amount of money that is available in our industry to do the work that we collectively need done. And part of that discussion may mean re-thinking aspects of the way our community operates, or re-shaping the nature of the financial relationship we have with users, and especially large organizations.

Call to action 3: Value contributors and their contributions

Third: as a community, we need to re-evaluate the way we value contributors and their contributions.

And as a simplistic reading - yes, I mean money. Giving them access to the resources they need to continue doing the work they’re doing, or to scale up the work from a part-time volunteer effort to a permanent facility.

But I don’t just mean money. We need to value each other as human beings. When you see something online and you’ve got some hot take you want to post - think about whether it really needs to be said. And if it does need to be said - are you saying it in a constructive, empathetic way? Consider the collective effect of a thousand messages with the same tone being directed at someone who volunteered to do something for you.

Ok - those are all still very high level calls to action. These are things that require discussion, planning, and ongoing contemplation. The rest of this conference is a great time to start those discussions, but we’re not going to see any magical fix by this time next week.

You want something concrete? Well, here’s two more:

Call to action 4: Get out your wallets

Firstly, Get out your wallets.

The Python Software Foundation, the Django Software Foundation, NumFocus, and many others accept donations. Encourage your employer to support these organizations to a level that reflects their signficance to their business. Give those organizations the financial resources to do maintenance and R&D work on behalf of the community.

If you’d like to support my own work on the BeeWare project, you can join the project as a financial member. I’m currently able to cover my hosting costs and pay for stickers and challenge coins; If I can get some more financial backing, I could start making a more substantial time commitment to BeeWare. If you’ve got other ideas for how to fund BeeWare, or you’d like to know more about the project, we have a booth in the main hall; come have a chat.

Call to action 5: Contribute

Lastly, if you have the means, or your privilege allows, contribute. Whether that’s on your own time, or on your employer’s time, consider contributing to open source - no matter your level of experience. This is a collective effort, and every little bit helps. The BeeWare project definitely needs help; but so do dozens of other projects in the Python ecosystem. And if my experience as a sandgroper proves anything - it’s that Open Source really does open up the world.

Where do you see Python in 10 years?

It’s taken 28 years for Python to get to where we are today. And it would be a shame to have to develop it all over again, simply because we didn’t pay attention to the way the world is changing, and plan for how Python will fit into the future that is evolving around us.

And, as Python the language grows and adapts, we need to make sure that our community grows and adapts as well. This awesome language we know and love would be nothing without the community of people behind it - and as that community grows, I want to see it go from strength to strength.

I hope I’ve been able to convince you that Python has a vibrant future ahead of it - we just need to plan for that future, and work out how we’re going to execute on those plans in a sustainable fashion.

And, if I still haven’t convinced you about Python’s future, maybe I’ve convinced you to come visit Perth. We’re a long way away from everything, but I promise we’re worth it. Not all the animals will kill you - for example, there’s the happiest animal on earth - the Quokka. Only found on a one island, Rottnest, about an hour by boat from Perth.

I hope to see you there someday.

Autopsy of a slow train wreck

2017-08-27T12:06:12+08:00

At DjangoCon Europe 2017, and again at DjangoCon US 2017, I gave a talk entitled “Autopsy of a slow train wreck: The life and death of a Django startup”. After I gave those presentations, a number of people requested that I publish the content in blog form so they could share it with colleagues.

Transcript

I’ve been a frequent (almost constant) fixture at DjangoCon events over the last 10 years. And if you met me at one of those DjangoCons in the last 6 years, or seen me speak, I may have introduced myself as the CTO and co-founder of TradesCloud. TradesCloud was a software as a service company for tradespeople - plumbers, electricians, carpenters and the like.

TradesCloud was my startup. I say “was”… beacuse in January of this year, my business partner and I closed the doors on TradesCloud, and shut down the service.

Gold-plated Lamborghinis

As an industry, we’re fond of promoting the glossy side of startups. That a plucky bunch of engineers can take an idea and a personal credit card, build a business empire, and drive off into the sunset in a gold-plated Lamborghini.

And yes - those unicorns - and gold plated lamborghinis - do exist. There are even a couple of them in the Django community (the unicorns, not the lamborghinis).

But it’s important to remember that those stories are unicorns. They’re not the normal startup experience for most people.

The reality…

In the VC-backed startup world, the general expctation is that if a VC firm invests in 20 companies, only 1 of them will actually succeed spectacularly. 4 will have some sort of exit that at least results in a breakeven financially; but 15 will fail outright, with a significant or complete financial loss.

Interestingly, this isn’t something unique to tech. Tech does it at a much grander scale, especially when VCs are involved - but open any small business advice book - the sort that is targetted at the plumbers and electricians of the world - and they’ll warn you that 50% of businesses fail in their first year.

And yet, despite the fact that failure happens all the time, we don’t talk about it. We don’t talk about why things fail. And as a result, many of the same lessons have to be learned over and over again. Those that experience failure often feel like they’re doing it alone, because of the significant social stigma associated with failure.

So - this is my small attempt to restore the balance. In this talk, I’m going to talk about TradesCloud - my failed business. TradesCloud was a slow train wreck - we survived for 6 years, almost to the day. And we had plenty of optimism that success was just around the corner… but that never quite happened.

What was Tradescloud?

But what was TradesCloud? What prompted me to dedicate 6 years of my life to it?

Well, it started as a problem that thought I could solve. If you find yourself needing a plumber, how do you pick one? Well, 15 years ago, when I first had the idea for what became TradesCloud, the best option was opening the phone book and looking for the brightest, shiniest ad, maybe arranging a bunch of quotes, and pick one basically at random. If you were really lucky, you might be able to use Google - but that’s still looking for the shiniest ad. If they turned out to be good… well we won’t need a plumber for a while, so that knowledge is useless. And if they turn out to be awful… we can’t warn anyone off, either.

“There has to be a better way”. And, of course, I did nothing about it. I say nothing - I did start tinkering around with a web framework… you may have heard of it… Django. I originally got involved in Django because I wanted to add aggregation functions to the ORM so I could compute average ratings. And in 2008, I mentored a student - Nicholas Lara - to add aggregation as a Summer of Code project. So… success?

An idea is born…

In late 2010, I met up with a former boss for a drink, and he tells me about his brother. His brother owns a pest control company, he has the same problem - but from a different angle - I’m looking for tradespeople in my area that can be reccomended - he is smaller company that wants to compete with the big players with the shinier ads based on quality of service.

And so, TradesCloud was born. We had an idea. At the time, it wasn’t called TradesCloud - it was called CleverPages - because it was going to be a clever Yellow Pages. In my spare time, I started hacking together a proof of concept.

Mistake 1: Validate, then build

That was our first mistake, and the first mistake most tech-oriented people make. As much as Django sells itself as a rapid development framework, any non-trivial project still takes time and effort. And I spent a couple of months of spare time hacking together a proof of concept.

German military strategist Helmuth von Moltke once noted “No battle plan survives contact with the enemy”. Or, in non-military terms, Scottish poet Robert Burns said “The best-laid schemes o’ mice an’ men gang aft a-gley”. And so it is with business ideas. All the time I spent working on that prototype could have been eliminated if I’d actually spoken to a plumber first.

Just because we had an idea, and I could implement the idea in software, that didn’t mean we had a good business idea. It meant we had a good idea for a hobby project. And the difference is critical. A business is an idea that generates revenue. A hobby project may be fun to work on. It may even be useful for other people. But if you can’t sell something, if you can’t pay the bills with it - it isn’t a business. And conflating the two ideas is a major problem.

What we should have done is validate the idea first, and then build it.

But, we didn’t do that - and when I finally had something to show off, my business partner opened the local newspaper, picked a bunch of local plumbers, and called them in an attempt to sell the idea.

He called 10 plumbers. 5 of them suggested he place the idea in an anatomically implausible location. 4 of them had their secretary provide the same advice. One plumber did sound interested, and said he wanted to have a chat.

Mistake 2: If you can’t sell it, it’s not a business

This was mistake number 2. Or, at the very least, it should have been a warning flag.

At the end of the day, business is about selling something. Selling a physical product. A subscription. Selling services. But whatever you’re doing, you’re selling something. And in order to sell something, you have to have customers. If all your prospective customers hang up when you call… you have a problem. You don’t have a sales channel. It doesn’t matter if you’ve got a machine that turns lead into gold - if you can’t get that idea in front of the people who are going to buy your product, you might as well shut up shop right now. The fact that it was very difficult to get plumbers to answer the phone should have been a warning sign that our prospective audience wasn’t going to be easy to crack.

But, we persisted, and had a chat with the one plumber who would talk to us. We did our pitch, and he said “Nope. Not interested. But if you can make that pile of paper disappear, I’ll give you as much money as you want.”

This was a conversation that set the direction of our company for years to come. Was this a mistake or a success? Well, that’s a little hard to judge. There’s an extent to which we changed direction because it was the only direction that seemed open to us - which was a bad move. But it was a very lucrative direction, so… maybe it’s a wash.

What we identified in that conversation was a significant business problem - a business process that was being performed manually, and took three hours a day, and identified a simple and reliable way that it could be automated. We identified a couple of other processes we could automate, and ways to report on some key performance indicators. We identified a path forward that could use mobile tech to improve communication and process management. By the time we were done, we’d worked out how to immediately free up a full time employee, with potential for more. So as long as we charged less than the cost of that employee - about $50k a year - the business owner would be ahead.

Our costs were next to nothing. Our newfound customer told us that these business processes were due to one specific contract that they had - and there were many others on the same contract. So - should have been easy to sell the same software to everyone else on the contract, and… profit! Right? So - lets keep it simple, offer them a 50% saving - and after doing some fancy footwork to reverse engineer a good explanation for why that was what we were charging, and just start making $25k a year per customer, right?

Mistake 3: Humans gonna human

Well, no. That was mistake number 3.

Mistake 3 is that we didn’t take into account is the human factor. In theory, charging anything less than $50k per year - rationally - should have been a no-brainer, easy sale. But we were selling to humans. And humans don’t ever behave rationally. There’s an almost bottomless body of research about how bad humans are at evaluating economic decisions and consequences.

And so, when we walked in the door of a prospective customer, we did our pitch, they were almost universally blown away. And then we told them the price, and they starting describing anatomically implausible locations again. Why?

Humans aren’t rational

Firstly, a sale of that size isn’t easy. Asking a plumber to spend $100 a month - they know they can afford that. It’s probably less than what they spend on coffee in a month. But asking them to spend $2000 a month? That’s a lot harder for them to justify. That actually starts to make a dent in their bottom line. So they’re going to take some convincing. They’re going to want proof that it actually works, that it’s actually going to deliver the benefit you promise.

Software is hard to sell to humans

Secondly - we were selling software. While we were completely honorable, and completely truthful, and we were able to deliver everything we promised, and our software made makes birds suddenly appear every time we were near - we weren’t the first IT salesperson they’ve had to deal with. And we - we collectively - are part of an industry that has, for 40 years, systematically over promised and under delivered what software can do for a business. So that is something that needs to be overcome.

No really - Software is hard to sell to humans

Thirdly - we were selling software. Who here is currently holding a phone worth a couple of hundred, maybe even a thousand dollars? Now, how many of give more consideration to whether you should buy a 99c app from the app store than you do the decision to buy the thousand dollar phone?

That’s the problem selling software. And multiply it a thousand times when you start dealing with non-tech audiences. We’ve been conditioned to expect that physical, tangible things are expensive - but software? That should be cheap, or better still free.

As a side note - this is one of the major problems we face with funding open source projects as well - but that’s a subject for a different rant, and a rant that I’ve had before.

Humans are people

Lastly - we were dealing with personal relationships. If we walked into a small plumbing business to speak with the manager, there was an odds-on chance that the bookkeeper, or another significant employee in the business, was the wife of the manager. And you start talking about being able to cut an employee… well, you can guess how well that conversation goes. And even if it wasn’t a family member, people don’t generally want to fire people.

Mistake 4: Beware favourable patterns

Mistake number 4 happened as the result of an unfortunate coincidence. After closing our first sale, we got that customer to give us an introduction to some other possible customers. And he gave us the best possibilities first. So our first two sales were both $2k a month. Our third was a smaller business - only $500 a month - but that gave us the confidence that we had something that we could sell to medium and small businesses.

We’d closed three sales in rapid succession. We had $4500 a month in revenue, and the sales were really easy to close. We thought we had found a money printing machine.

And then we hit a wall. The next few sales calls we made just went nowhere. Never a hard no… but lots of ums and ahs about price, and “we’ll have to think about it“‘s…

We confused initial success with a pattern that was going to continue. After three sales in a month, we essentially didn’t close a sale for another 8 months. And that’s not a good sign.

Arguably, we got bitten by circumstances there - when you have lots of early success, it’s easy to think that success will be ongoing. This is a time where you need to be objective. If you can’t consistently close sales, if you can’t reliably predict your close rate - you have a problem.

Mistake 5: Do the math

Mistake number 5, though, was completely our fault. We completely failed to do basic math.

Our value proposition - the business process that we had optimized - existed because of the processes required by one particular contract. Our pricing scheme was simple - we charged $1 per job completed. Our initial customer - they did about 2000 jobs a month, so we charged them $2000 a month. Which is great, because it also happened to hit our 50% savings target that we originally identified.

What we didn’t do was add up how many jobs there actually were in the system. It turns out that if we managed to close every company on that contract, we would have only generated $12k a month in revenue. Which sounds like a lot, especially when your costs are so low… but our costs weren’t low. We also had two founders who were full time, and needed to be paid. Our burn rate was closer to $22k per month.

Mistake 6: Pricing is what the customer will pay, not your burn rate

And this led to mistake number 6: We didn’t have a serious pricing discussion until it was way too late. Mislead by our initial success, our pricing was really determined by taking our burn rate, and working backwards - not forwards from what the market would bear. My co-founder and I would have regular discussions about pricing - but all of those discussions happened against a background of “how are we going to make payroll this month”. Which is the wrong time to be having that discussion - because two important options: drastically reduce the price, and shut down the company - are effectively off the table.

So, we had a product that was too expensive to sell, and a market that wasn’t big enough. Now the good news is that the paperwork reduction niche we’d found wasn’t unique to that one contract - There were many other simliar contracts with similar paperwork requriements. But we’d found the thousand pound gorilla in the market. Other contracts were smaller, and the paperwork and process requirements were subtlely different.

Mistake 7: Establish your sales channel

And that wouldn’t have been a problem - if we hadn’t made mistake number 7 - we never established our sales channel.

We got our first sale almost by accident. We bumped into a customer who gave us an opportunity. Subsequent sales came by word of mouth. Word of mouth is an incredible sales channel if you can get it. But as a result, we never cracked the most important problem - how do we sell to someone who hasn’t heard of us? How do we get in the door? How do we establish trust? And as a result, our sales were essentially constrained by the personal networks of our existing customers. Perth is a small, geographically isolated city. When we’d exhausted personal networks… we hadn’t learned the most important thing - how to sell our product to someone who didn’t have a personal introduction.

Joel Spolsky once noted that there’s no software product priced between $1000 and $100000. This is because a product that costs less than $1000 can be bought on a credit card. But if software costs more than can be hidden on an expense statement, you need to have salespeople, and that means you have to pay them, and their commissions, and pay for the steak dinners and drinks used to closed the sale. We had a product that was squarely in this dead zone. Too expensive to be a casual purchase, but not expensive enough to support the sales process it needed.

TradesCloud had a serious problem. Once we closed a sale, we had almost zero churn rate. The only customers we ever lost were because they closed down, or they dropped the contract where we offered an advantage.

What we didn’t have - and what we never really established - was a good way to prove to new customers that we were, indeed, that good. There wasn’t a good way to “trial” TradesCloud. We were managing processes that were at the core of a trades business. Those processes have to work. And they can’t be duplicated or doubled up. So - there was no way to “stick your toe in the water” - you had to jump in, or stay out. And since we had a huge price tag, most people were conservative, and said no. If they got a recommendation from someone they knew, it was a little easier - but if that didn’t exist, we had a problem.

In order to close a sale, people have to believe - really believe - what you’re telling them. It has to be obvious, and undeniable that you will give them benefit - or the cost of trying has to be vastly less than the cost of the software itself. In our case, even if we dropped our price to zero, we didn’t have a zero cost, because the cost of institutional process change involved in adopting a new piece of software at the core of business operations is huge.

Our best sales person was completely accidental. He wasn’t our employee - he was an employee who changed employers every 6 months. He was in upper management, had a reputation for getting things done and turning companies around, so he kept getting poached. And he’d seen the benefits of TradesCloud with one contract, and so it was easy to get in the door every where else he went. And because he was known around the industry, his word was extremely valuable. When he said “This is good”, people believed him. His word was trusted.

Mistake 8: Sales don’t stop when you sell

But even when we did make a sale, the mistakes didn’t stop. Mistake number 8 - we didn’t pay enough attention to onboarding new customers. A sale for a product isn’t closed when a contract is signed. It’s closed when the person who uses the software has accepted it into their daily lives, because that is what prevents churn. If you’ve selling a small personal tool, the person who buys and the person who uses is probably the same - but in our case, the purchase decision was rarely made by the person who actually had to use the software. And you have to get those people on board. If anything, they’re more important, because they’re the ones who are going to make the bosses life hell if the software they buy isn’t doing the job - or worse - is doing the job too well.

Over and over again, we saw internal sabotage. People would simply refuse to change processes, and would find any excuse. “Oh, the software didn’t work, so I had to go back to doing it manually”. And after a month or two, the boss would call us and say “what happened to all the benefits you promised?”, and we’d say “well, you only get the benefits if you actually use the software”.

What we learned - the hard way - is that you sell to the business owner - but you also have to sell to the users. If you’re dealing with software that is part of a key business process, change management is key. You have to show them how your tool does what they currently do by hand. And you have to show them that their jobs aren’t at risk. That first employee whose 3 hour/day task was replaced? She wasn’t fired - she redeployed inside the business. She went from doing a mindless office task for most of the day, and could start expanding into other parts of the business. About 2 years after we first deployed TradesCloud, she was running accounts and payroll.

But, despite all these mistakes, we were able to stumble along, and were complete self funded for almost 2 years. Now, that meant burning a lot of personal funds, and my co-founder doing a bunch of consulting on the side. But that’s just part of the startup experience, right?

Mistake 9: Establish failure criteria

Well, maybe it is. But in retrospect, mistake number 9 was an entirely personal one - I shouldn’t have lost as much money on the experience as I did. I knew what I considered success criteria, but I never considered what my failure criteria would be.

After 2 years, I had reached a point where my personal financial runway was running out. TradesCloud either needed to start paying a full wage, or I wasn’t going to be able to continue. And this pivoted the business. Fundraising is a full time job. Everything else goes on hold - sales, support, development - everything. We tried to get VC investment, but the VC scene in Australia is pretty bad, and even worse in Perth. Eventually, we managed to secure a $250k cash investment from a colleague of my business partner; and we got some matching funding through an Australian government program. And that gave us another 2 years of runway.

The way we were able to secure that runway was by changing our tactics. Instead of going after individual plumbers, we started going after the head contractors - the multimillion dollar facilities management companies. And we were able to sell them a really great story. These companies are all competitive, and they’re looking for any advantage they can get. But they’re also technologically laggards, because they’re big established companies. They have inertia when it comes to adopting new technology. So we were able to walk in, and promise a mobile-enabled workforce, real-time tracking, enforced health and safety practices - all sorts of things that made them really excited, because they could use those features as differentiators against their competition.

Mistake 10: You are who you are - Don’t deny it

But - and here’s mistake number 10 - we forgot who we were, and who we were selling to. We were selling to multimillion dollar companies. The reason these companies are technologically laggards? They’re conservative. They don’t take risks. There’s no incentive for individual employees to take risks. And so, they make safe decisions.

And when they adopt new technology, they don’t just pick something - they put it out to tender, and get multiple bids, and then they invite bidders into the head office to interrogate them, and eventually, after 6 months, they pick someone - the safe option. We got into a tendering process with almost every major facilities managmeent company in Australia. The tendering process almost always started because we pitched them the idea of providing TradesCloud to all their subcontractors - but what they heard was “provide software to all their subcontractors”. And so, at the end of the tendering process, we were told, every time - we prefer your technological solution… but we’re going with your competitor, because you’re too risky. A 2 person company was too much of a risk for a multimillion dollar company to trust.

So after 2 years of trying this tactic, and being turned down by every facility management company in Australia, the money was running out again, but i’d built up a bit of cash buffer again. But in between failing to sell to multinational companies, we’d found a bit of success selling to smaller facility management companies and large constructions companies. And the good news was that these companies were big enough that when they bought software, they wanted it customized - so as well as the $2k/month, they would pay $40k up front so that everything matches their requirements.

On the back of that change, were got a loan from our investor. Between making more personal sacrifices, and that cash injection, we were able to stumble along for another 18 months.

Mistake 11: Take the hint

This was mistake number 11. We didn’t take the hint. Each of those points where we took investment was, potentially, a point that would have been a natural point to shut down the business. And, in retrospect, we should have. The writing was on the wall. The simple truth is if you can’t close sales, you don’t have a business. And yes - you can stumble along hoping that you’re going to find the missing sales ingredient - but that takes resources. It takes money, and it takes emotional capital as well.

One of the reasons the failure of TradesCloud was so personally galling, is that it didn’t fail for any reason that I would consider “my fault”. From a purely technical perspective, we were significantly more reliable than the multi-national companies we were integrating with. We delivered new features in timeframes that our customers considered inconceivable. When I went in an did demonstrations to the multimillion dollar head contractors, they expressed doubt that we could actually do what we said we were doing… right up until I showed them the code doing it, live.

But none of that mattered. TradesCloud failed, ultimately, because we couldn’t sell what we had - or, at least, we couldn’t sell it in quantities that allowed us to cover costs. And when you’re there giving your all, doing things that are being called magic by prospective customers… and you’re still failing… that’s hard to internalize. And when you layer on top of that the fact that I’m a husband and a father, and the sole income for the family - that introduces all sorts of guilt and fear into the mix. And then you take all that stress, and add in the long hours and weekend work in the desperate hope that this will be the thing that saves the company…

And when work is all that defines you, you will feel like you're dying when it starts to disappoint.
— Alice Goldfuss (@alicegoldfuss) February 2, 2017

… and you start to understand why, 2 years ago, I had a major depressive episode.

Mistake 12: Quitting is always an option

Mistake number 12 - I lost sight of the fact that quitting was always an option - and that quitting didn’t mean failure. If, after 2 years, I had taken an honest audit and said “you know what - this isn’t working. I’m out”. I would have had 4 years of my life back. That’s four years I could have sunk into a different project. But I didn’t pay attention to any of my signs. I conflated success of the company with my own personal success. I lost sight of the fact that this was a job. And it was meant to provide some income and some intellectual engagement. And if it wasn’t doing that - walking away was always an option. But I didn’t ever really consider it seriously.

Mistake 13: Partnerships require actual partners

Why not? Well that was mistake number 13, and it was another personal failure - I didn’t stand up to my co-founder as much as I should have. And as a result, we wasted a lot of time, and effort, and in some cases, money. Now - I have to be clear - if only because there’s a chance he might see this video - i’m not blaming Mark here. Mark is a great guy, and he’s extremely talented, and he’s got absolutely no shame at fronting up to companies thousands of times bigger than his, and telling them how they should be doing things. He opened a lot of doors that I know I wouldn’t have ever even considered knocking on, let alone opening. He was a real asset to the business. The failure was a personal one, and it was mine.

We didn’t go into TradesCloud as complete equals. Sure - we were 50/50 partners on paper - but when I met Mark, he was my first boss out of university. I worked for him for 4 years as a very junior subordinate. And a lot of that power dynamic remained. I let him do a lot of things because “well, he must know what he’s doing”. I caved on decisions because I could see his side, and he was more experienced. And, Mark is a great sales guy. He can make you believe in things. And he made me believe in TradesCloud - but that’s a double edged sword. It got me through all sorts of lows - but it also meant I believed even when I probably shouldn’t have. I should have putting my foot down and said “no more” a lot more often than I did - both for the benefit of the business, and for my own mental health.

The end

And so, when the money ran out for the third time, neither Mark nor myself had the energy to continue. We had a couple of last minute hail-Mary options that we thought might have saved us… but one by one, they all fell through. In the end, we were able to pay back the loan to our investor; but his equity investment was essentially lost. And in January, we closed the doors for the last time.

And that’s the TradesCloud story. I will warn you, though, that the plural of anecdote is not data. This is my story. Many stories are like it, but this one is mine. I don’t profess to having any particular business insight - I just know that TradesCloud didn’t work. And these are the 13 reasons I can identify why.

In the aftermath, I’ve had a lot of people - many of them in this room - reach out and give me a virtual hug, or a spoon. And many asked me if I was sad to see TradesCloud go. But frankly, the emotion I had was relief. On January 31 2017, I slept like I hadn’t slept for 6 years - because I knew I wasn’t going to be woken up by a server alarm. And I knew I could sleep in, because I wasn’t going to get a support call at 6AM.

The fact that I wasn’t even slightly disappointed by the loss of TradesCloud from my life - that’s the biggest sign for me that I waited far too long to step away.

The good news, though, it that the process of running TradesCloud hasn’t burned me completely. It was an amazing learning experience. And I landed on my feet - At DjangoCon US last year, I put my name up on the jobs board saying I was looking, and it hadn’t been there half a day before my good friend Andrew Pinkham approached me and said.. Uh… are you that Russell Keith-Magee looking for work?

The other silver lining is that the TradesCloud experience drew my attention to problems in the world of mobile development, which has influenced the path that my new toy, BeeWare, has taken. And I’ve been busy trying to work out how to turn BeeWare into something.

But this time, I’m a little older. A little grayer. Hopefully a little wiser. And I should have a better idea what to look out for. If you want to talk about that… well… get in touch.

Searching for a new place to hang my hat

2017-05-31T08:00:00+08:00

Back in January, I announced that I was shutting down TradesCloud, my 6-year old startup. I was very fortunate to be given a very soft landing with some good friends at JamBon Software. However, that was a contract tied to a specific project; that project has now come to a close, and while I thoroughly enjoyed working with Andrew and the team at JamBon, the upcoming projects they have in their pipeline either don’t match my skills, or would require me to be on-site.

This means I am, for the first time since completing my PhD 16 years ago, jobless.

I recently started fund raising with the aim of allowing me to work on BeeWare full time. I’ve had some fantastic support from the community, but I’m still a long way off being able to justify making BeeWare my full-time job.

I still want to try and make funded open source development work; but in the meantime, I need a job. So, this is a reverse job advertisment. I’m available for hire. Here’s what I’m looking for.

I’m based in Perth, Western Australia, and I’m not looking to relocate. I have strong family ties in Perth, and some other personal reasons for not wanting to move - so unless an offer is extraordinarily lucrative, I’m not looking to move.

I’d like to think that I’ve proven I can make telecommuting work. I’ve been telecommuting for almost 10 years now, spanning up to 12 time zones. Some of that telecommuting has been very public - after all, what is an open source project like Django but a huge telecommuting community.

And as my conference travel schedule will attest, I’m not opposed to travel - either for regular meetups with a dev team, or to be face-to-face with a customer.

I’ve developed a lot of reputation in the Python community with Django and BeeWare, so I’d like to stay in those communities and leverage that experience as much as possible. There’s always room for other languages in any technology stack, but if my life doesn’t contain a healthy dose of Python, I’m not going to be happy.
I don’t have any particular domain of interest. I have a background in Physics and Artificial Intelligence, but I can get excited about surprisingly mundane problems - as my 5 year dalliance with plumbers and electricians will attest. As long as there’s a technical challenge lurking, I can find interest.
I’m happiest as a developer when:
I’ve got a problem to solve that has a clear success criteria. Implement protocol X. Make Y 20% faster. Build an interface between A and B. It’s done when it works - no subjectivity or opinion about it.
I get to see the look in someone’s eyes when you’re teaching them, the penny drops, and they see some tangible result of their learning efforts.
I get to see someone in the wild actually use something I’ve developed to solve a real world problem.
I have long term engagement in a problem. I’m sure I could make a lucrative career in short-term consulting; but I need to feel invested in what I’m doing.
I enjoy working with diverse teams, and I expect employers to back that up, not just give lip service to the idea.
I’m passionate about Open Source. I’m not a complete zealot - I appreciate that there is a place for commerical and proprietary software - but where possible, I like to collaborate and give back to the community as a whole. That means contributing to existing open source projects (like BeeWare and Django), or open sourcing internal tools that others may find useful. If a role at your company gave me the opportunity to work on BeeWare tools, that would be amazing.
While I’ve historically been in senior engineering and CTO roles, I’m interested in stretching into developer relations. I enjoy public speaking and delivering training. If there’s a way for an employer to make use of the fact that I enjoy a stage, then I’m happy to oblige.

Do I sound like someone who would be a good match for your team? If you think you’ve got a position that might be a good match, get in touch. I’ve also got a more traditional Curriculum Vitae.

Moving to Lektor

2017-04-29T16:00:00+08:00

Almost nine years ago, I launched cecinestpasun.com as my personal blog. At the time it was a Django 1.0 site. I’ve used it intermittently, but never really paid any attention to it.

So, instead of persisting in the upkeep of a blog (and blog software) that is massive overkill for my small amount of publishing, I’ve moved the content over to Lektor, published as static content on Github Pages. I’ve used Lektor for the BeeWare homepage, and it’s proven very enjoyable to work with, and it allowed me to port over my old Django content in a morning.

I’m hoping to to a visual refresh in the near future; but in the meantime, I can at least save some money on hosting.

Opposing preference deals with the right

2017-02-13T07:47:54+08:00

The WA Liberal party recently announced a preference deal with the right-wing One Nation party in the upcoming state election. I wrote this letter to my local member, Mr Peter Abetz.

Dear Mr Abetz,

I write to you as my local member during this election season to express my extreme displeasure at the fact that the WA Liberal Party has announced plans to preference One Nation over the Nationals on their Legislative Council ticket in this upcoming election.

One Nation is a blight on the Australian political landscape. Their brand of extreme right wing nationalism has no place in a civilised society. Internationally, the rise of the far right into positions of power is a trend that disturbs me greatly.

It offends me deeply that the Liberal party is willing to pander to a group like One Nation in the hope of securing preferences. It demonstrates a disturbing lack of awareness of the history of such manoeuvres. The number of right wing and extremist candidates that have been inadvertently elected to positions of power by such deals is significant.

More importantly, it shows a complete lack of moral leadership. To make a deal with the far right in an attempt to deny the Nationals - a one time coalition partner - power, strikes me as the perfect example of cutting off one’s nose to spite one’s face.

I consider myself a centrist swing voter. I know that I (and every other citizen) is free to cast my vote below the line in defiance of any official preference deal. However, this single decision on behalf of the Liberal party has ensured that I will cast no vote favouring the Liberal party in this upcoming State election. If you and the Liberal party cannot find the moral fortitude to oppose nationalism, then I hold very little hope that they will “Put people first”, or represent any of the “family values” that I hold dear.

Quo Vadimus

2017-01-01T12:52:28+08:00

It’s been 6 years, almost to the day, since I started work on my startup, TradesCloud. And it’s been a rollercoaster ride.

TradesCloud was mostly self-funded. We did take a small tranche of investment from a friend, as well as some matching funds from an Australian Government program, but we were never able to attract VC interest to provide a large injection of funds.

Initially, that didn’t matter. We started with a bang. Our first customer was incredibly lucrative, and required surprisingly little technical work. The next couple of customers we similarly lucrative, and really easy sales to close. We were proud to be self funded, kicking against the prevailing wisdom of the Valley that said you needed million dollar valuations to succeed.

Unfortunately, that initial success was misleading. We never managed to grow, and although we slowly picked up customers, we never reached a point where we were cash flow positive.

We tried - and failed - to sell to small companies; but we never found an effective sales channel. Small companies in the home services market (plumbers, electricians, and so on), don’t like computers or computer software. The only thing they like less than computers and computer software are the people who sell them computers and computer software. They’ve been burned many times before by sales people who have told them about the miracles computers can do for them. So when someone turns up on their doorstep and proclaims that they have the answer to all their problems, it doesn’t even matter if it’s true - you don’t get past the front desk.

We tried - and failed - to sell to large multinational companies too. The story here was different, but repeated with every potential customer we found. Initially, they denied there was a problem. Then they accepted there was problem, but denied they needed to fix it. Then you got a break - you found someone who had just moved into a management position at the company, and was looking to make quick win by adopting something high profile. Mobile enabled cloud solutions fit that bill nicely. They’d ask for a few meetings, then because they need to cover their asses, they’d start a multi-month RFC bidding process… and then pick some other company’s solution. After the fact, we were consistently told that we had the superior technical product, but that we were too big of a strategic risk because we were a 2 person company. Never mind that as soon as we made one of these deals, we wouldn’t be a 2 person company any more. Nobody ever got fired for buying IBM, so they would go with the bigger, less capable, but less “risky” option.

We had a small amount of success with medium sized companies. However, the companies that could see the strategic advantage usually only saw the benefit because they were groaning under the weight of their internal administrative processes, which were mature enough to identify that a problem existed, but not mature enough to efficiently affect a company-wide change to a new process. They were also usually reaching out to us because their accounting department had established that they were on a trajectory toward bankruptcy if they didn’t fix things. As a result, several of our medium-sized customers went bankrupt or closed their doors within months of adopting TradesCloud - not because of TradesCloud itself, but because their businesses weren’t healthy to begin with, and they weren’t able to realise the benefits of a streamlined process in time.

As a result, for the entirely life of TradesCloud we suffered a simple cash flow problem. We didn’t have enough customers, generating enough revenue, to pay our own salaries and the server resources needed. There have been many months where my business partner and I haven’t drawn a salary, or have only drawn partial salaries; and while you can do that for a while if there is promise of a brighter tomorrow, every bank balance has it’s limit.

We contemplated keeping the product alive in a “limpalong” mode. We do have some customers, and those customers are incredibly loyal, and have told use they don’t want to see TradesCloud go. However, it isn’t quite that easy. TradesCloud isn’t set-and-forget business. It requires ongoing maintenance, and it generates support queries. Those support queries aren’t easy to offload - many of them require critical thinking skills and knowledge of the TradesCloud codebase. But they’re not enough to consume 1 FTE. Essentially, we’d need to find someone who would be willing to operate on a contract where they would only get a couple of hours work a week, but at completely unpredictable times - and they would have to drop everything when the phone rang. That’s not an easy employee to find - or if you can find them, they’re not cheap.

And this isn’t a task that I’m willing or able to continue long term, either. As I’ve made quite public, I had a major depressive episode last year - due, in no small part, to the fact that I had been carrying the pager for TradesCloud 24x7 for 4 and a half years. I’ve had symptoms that come close to PTSD when my SMS tone rings. For 6 years, I have been scheduling conference travel over weekends and redoes to make sure I’m in the air during business hours. I have stood on the balcony of hotels in the south of France at 3 in the morning answering support calls from customers who have just started their day in Australia. And during my episode, and in the 18 months since, I’ve still been carrying the pager. That isn’t good for my mental health.

And so, we reach the end of our six year journey. At close of business on January 31, TradesCloud will be shut down.

We’re still exploring a couple of fire-sale options. There is enough interest in the capabilities of TradesCloud that we might be able to sell the codebase for someone else to operate. It would be nice to get some payoff from 6 years of effort, but it certainly won’t be time to order the gold-plated Lamborghini.

It’s a bittersweet moment. On the one hand, I’m sorry to see 6 years of effort fail. But I’m also ready to move on. In truth, I’ve been ready to move on for quite some time. And now I actually can.

One of my favourite TV writers is Aaron Sorkin. Sorkin’s first TV show was called Sports Night - a “behind the scenes” look at a late night cable sports news show. It was an odd piece - it was originally sold as a sitcom (canned laughter track and all). While it was incredibly funny, it wasn’t that kind of funny. It was very deep and intelligent humor. It also had moments of profound insight and wisdom. It was notionally about sport, but it was very rarely just about sport - and when it was, it was about the grandest intentions of sport, not the vain personality show and advertising opportunity that most modern sports have become. The show shares a lot of similarities (and more than a couple of plot lines) with Sorkin’s most famous piece, The West Wing.

When Sports Night was cancelled, they were able to run the show out with a storyline about the parent company selling it’s cable station because it wasn’t profitable. The entire team behind the Sports Night show (the fake on air one) were worried that they were going to lose their jobs. Dana, the show’s producer, meets a man in a bar during her lunchbreak who offers some advice:

> “I’m what the world considers a phenomenally successful man. And I’ve failed much more than I’ve succeeded. And each time I fail, I get my people together, and I ask them - Where are we going? And it starts to get better.”

Dana is not entirely satisfied with this advice. But unbeknownst to Dana, the man was the owner of a media company who, shortly thereafter, puts in a bid for the cable company, and then declares his intention to preserve the cable channel. The name of the company is Quo Vadimus - Latin for “Where are we going?”.

The time has come for me to ask myself: Quo vadimus?

I’m not desperate for work. After a conversation at DjangoCon US in Philadelphia last year, Andrew Pinkham and the fine folk at Jambon Software offered me a contract. It’s been extremely liberating to be able to sink my teeth into a new set of technical challenges in new domains.

Jambon have also given me some liberty to work on BeeWare on company time. BeeWare has been a big part of my open source contribution over the last couple of years, and I’m just starting to get to the point where that work is paying off. I’m hoping that over the next six months, BeeWare will start showing some highly visible results. In my ideal world, I’d like to be working on BeeWare full time, with a team of people - but I need to work out how to pay for that.

I don’t know exactly what the future holds, but I have hope - and that’s more than I’ve been able to say for a while.

On a replacement for Twitter

2016-02-06T11:04:47+08:00

I’ve been a user of Twitter for almost 8 years. Over that time, I’ve gone from a skeptic, to a regular user, to someone for whom Twitter is an indispensible tool for keeping in touch with the outside world. The tipping point for me was when I left my 9-5 office job and started working from home. All of a sudden, I lost the “water cooler” conversations that an office allows. Twitter provided that outlet.

However, over the last few years, I’ve become acutely disappointed in Twitter as a product, and Twitter the company behind it. And I’m not alone; a number of my friends - the people who I’m on Twitter to keep in touch with - have abandoned the platform altogether.

There are a litany of well established problems with Twitter as a platform. Twitter has consumed an ungodly amount of VC money, and has at their disposal an small army of engineers. Yet these not-insignificant resources are routinely being spent on features that nobody wants or needs.

Some of these decisions are understandable. As part of becoming a financially viable company, Twitter needs to find an economic model that will validate their multi-billion dollar market cap. Since they’ve chosen an advertising driven revenue model, it’s inevitable that a good chunk of their resources will be spent enhancing the advertisment delivery process. To that end, features like promoted tweets are inevitable, and while I don’t like ads in my tweet stream, I can see why, given Twitter’s business model, they are necessary.

However, other engineering priorities are completely nonsensical. There are many aspects of Twitter’s engineering priorities that could be criticized, but the most significant is their approach to handling (or not handling) spam and harassment. Twitter has made repeated statements that they will focus on harrassment on their platform. Every time this happens, well recognized experts in the field suggest things that could be done, many of which are quite simple. And Twitter takes that input, and directs their engineering team to change “Favourites” to “Likes”, or implement “Polls” And then 18 months later, another “we take harassment seriously” press release is published, and the cycle repeats.

Over the last year or so, I’ve become increasingly of the opinion that Twitter’s time has now passed. They’ve had plenty of opportunity to correct the problems with their platform. And instead of fixing the problems, they appear to be dedicated to making their platform worse. At this point, I’m looking for a replacement.

Building a new platform

So - what would a replacement for Twitter look like?

Native

There’s nothing wrong with having a website - it’s a natural thing for a web service to have - but for a tool like a microblogging platform, it’s essential that there is a native, well integrated app experience on both desktop and mobile platforms from Day One.

Decentralized

Microblogging platforms are the first communications protocols that are based on monolithic central stores. All the protocols that have been of historical importance - email, Usenet, RSS - were all decentralized from the outset.

The idea that all the world’s communication is stored in a single company’s database - be it Twitter, Google, or Facebook - scares me no end. It means if the company folds, an entire generation of content could be lost. It also makes an easy target for any government that wants to curtail or control speech.

Decentralization has the added benefit that it is a better engineering solution. It’s been a while since the Fail Whale was a regular occurrence, but a decentralized network would be much less prone to whole-network outages, and a harder target for malicious parties to attack.

Trust

As a monolithic silo, Twitter holds the keys to who is considered “trusted” on their platform. You can get the blue checkmark as a verified account, which enables (ahem) Brands to establish themselves as official mouthpieces - but beyond that, this verification process isn’t very enlightening.

Being decentralized introduces the opportunity for different measures of trust to be used. Imagine a decentralized network with a wide range of nodes providing authentication. One node might require members to provide proof of identity. Another might require all members to sign (and adhere to) a code of conduct. Yet another might allow entry by invitation only. This process of distribututed trust is then a source of data that can be used to acheive other goals.

Safety

If a platform has the a solid concept of trust networks at it’s core, that means it’s also in a much better position to deal with issues of harassment. For example, I could mark my account to refuse contact, or refuse to distribute my content that can’t prove they’ve signed a CoC.

The safety of people who are going to use the network needs to be the prime consideration, not an afterthought.

A Protocol, not a Platform

All of these points point to the important factor being the protocol, not the platform. While a solid reference implementation definitely needs to exist, it’s also essential that others can develop their own protocol-compliant implementations, improving the reference implementation, and expanding upon it.

It’s also essential that the protocol itself have a mechanism for expansion. If I want to add a new type of content, I should be able to do so. It’s then up to the writers of clients to determine if they need to support various protocol extensions.

Financially viable

I’m not interested in adopting a new communications platform unless the future of that platform is secure. A lot of the poor decisions being made by Twitter are being made for financial, rather than enigneering or social reasons. This means that any new social network needs to have an answer for how they’re going to be financially viable.

This is something that might be achievable with VC money, but I think it’s much more likely that the answer to this problem will be just as distributed as the network itself. VC’s have tried to bootstrap several social networks with a huge piles of promotional cash - Path, Ello, Peach, and others - and each of these attempts has failed spectacularly.

Nobody is going to leave Twitter in favour of an identical clone of Twitter. There needs to be a reason to adopt a new network, and money can’t make people care. The features that will make people care - things like removing advertising or centralized control of the network - often reduce the value of the platform as a whole (or, at least, the value to investors, who want a return on their investment).

App.net came close to achieving financial viability in 2012 - they sold subscriptions, and for a year or so, were financially viable. However, they weren’t able to maintain subscriptions. This is largely because they didn’t have an answer for…

The Critical Mass Problem

… how to deal with the cricital mass problem. For the moment, at least, almost everyone I know is on Twitter. Until a critical mass of my friends are on a new platform, I don’t particularly want to run Yet Another Social Network Program on my computer and phone. When App.net started, I signed up… and then didn’t use my account after a month, beacuse everyone I knew was still on Twitter.

A new social network needs to have a good reason for people to commit to using it. This might happen because Twitter does something so monumentally stupid that everyone leaves at once, but there would need to be something waiting in the wings to take over.

Alternatively, there needs to be a bridge between existing networks and new ones.

Ease of use

Above all, it should be no harder to get started with this new platform than it is to get started with Twitter. If your installation instructions start with “First, generate a 4096-bit RSA public key”, you’ve just failed.

Satisfying the wish list

The good news is that there are several decentralized microblogging platforms out there. The bad news is that unfortunately, they appear to be largely developed by people who are more interested in the technology than the platform. Advertising your network as being “based on Bitcoin and Bittorrent” doesn’t tell me why I should use your platform - it tells me what technology you’re using. Frankly, I don’t care if my social network is implemented with carrier pigeons - as long as it lets me get the job done.

A decentralized microblogging platform probably will use Distributed Hash Trees or blockchain technology - but that can’t be the focus of development or the primary marketing message.

My dream platform

So - how do we get a replacement for Twitter?

Well, my dream platform would be a lot more than just a Twitter replacement - it would be a platform for building rich communication interfaces, with microblogging being just one important channel. Consider all the various ways that we communicate with each other at the moment:

Microblogging platforms like Twitter and Facebook
Sharing platforms like Flickr, Instagram, and Vine
Long-form blogging platforms like WordPress and Medium
Chat tools like IRC, ICQ, Hipchat and Slack
Broadcast platforms like Twitch and Periscope
Commenting platforms like Disqus
Forum platforms like Discourse
Formal communications over email

Each of these types of media requires a different mode of interaction with the content they distribute - but they’re fundamentally about getting a chunk of content - be it a 140 character tweet, a photo, or a streaming URL - from one user to one-or-many other users in a timely fashion, and soliciting responses in different forms.

Making it real

Of course, this sort of abstraction is, more often than not, a complete distraction to actually making a product real. However, in this case, I think it provides a path to potential financial stability, and a way to overcome the critical mass problem.

The key point to remember is that all the content is linked and distributed using the same protocol. A long-form blog can be shared in the same way as a microblog message or a photo. A message can reply to a photo, or a photo reply to a blog post.

This means you can pick on one of the services as a starting point, and as long as the protocol has room for expansion, other services can come later - and other parties can contribute applications that use the protocol.

Financial viability comes in providing the “first seed”. A distributed protocol will require some nodes to be permanently available for discovery purposes. This is especially important in the early days, when there might not be enough participants in the network to ensure that content is shared efficiently. Providing this “first seed” service could be offered as a paid service.

Why would people pay for this service? Well, this first seed could also provide the bridging services - gathering content from, and rebroadcasting content onto, existing social networks. For example, any short message or photo posted on the network could be reposted to Twitter; one of the roles of the paid service would be to provide a publicly visible web presence for any content shared.

In these early days, the paid offering would look very similar to a hosted blogging or photo sharing platform. However, embedded in that blogging platform is the incentive for others to engage deeper with the platform - by creating an account on the network, you can interact with this hosted content in a richer way, and post your own content.

Once the network is established, the bridging and seeding services will become less important, but other services - such as the trust and authentication network - will become more important.

Conclusion

Of course, the devil is absolutely in the detail. The core protocol design needs to be robust, the core marketing message of the initial product offering needs to be clear and polished so that it doesn’t get written off as “Yet Another X Clone”, and the product itself actually has to be compelling.

However, I really do think that the time is ripe for a new service to take the stage and change the web for the better. Twitter has made making too many mis-steps of late and hasn’t shown any serious signs that they’re interested in correcting them. Facebook doesn’t present a fundamentally better vision of the future.

But after 25 years of use, abuse, and refinement, some common patterns are starting to emerge in the way we communicate, and I think there’s an opportunity to re-think the whole thing from the ground up, and build a decentralized platform for communication that incorporates concepts of authentication and trust at the core.

I only wish I had enough time to look into this more seriously. As it stands, I already have far too many side projects - and a project like this could easily become all consuming.

In the meantime, if you want to share your thoughts about this, I’m @freakboy3742 on Twitter. If I ever end up on another platform, I imagine I’ll be @freakboy3742 there, too.

Expressing disappointment in my government

2015-08-28T14:43:09+08:00

Today, I wrote a letter to my Member of Parliament, Ken Wyatt, Member for Hasluck. Mr Wyatt is a member of Liberal Party, which forms the dominant part of the Coalition that currently forms government in Australia, under the leadership of Prime Minister Tony Abbott.

Dear Mr Wyatt,

I am a resident in your electorate. I write to express my extreme disappointment in the actions of the government you are a part of.

Three issues in particular have moved me to express my frustration to you.

Marriage Equality

Firstly, I wish to express my dismay at the complete lack of leadership that the government is showing on the question of marriage equality.

I am a married, heterosexual man. I have many LGBTQI friends. I am utterly appalled at the notion that members of my government believe that the loving relationships they have with their partners are somehow “less” than the relationship I have with my wife.

Every reputable poll taken on the issue confirms that I am in the overwhelming majority of Australians in holding this position. New Zealand, the USA, United Kingdom, Ireland, South Africa and Canada - countries that have been close partners of Australia - have all agreed on this issue.

Yet, it took the Liberal/National party room 6 hours to decide that it was too hard to decide that event a conscience vote was called for.

Every complaint or objection I have ever heard against gay marriage is utterly laughable - especially from a government that professes to stand for individual liberty. Your own party founder, Robert Menzies put it best:

“As the etymology of our name ‘Liberal’ indicates, we have stood for freedom. We have realised that men and women are not just ciphers in a calculation, but are individual human beings whose individual welfare and development must be the main concern of government … We have learned that the right answer is to set the individual free, to aim at equality of opportunity, to protect the individual against oppression, to create a society in which rights and duties are recognised and made effective.”

How any member of the Liberal party can reconcile that statement of principles with an opposition to even voting on gay marriage in the parliament genuinely astounds me.

I am especially concerned at the prospect that Liberal Party policy now appears to be leaning towards a referendum or plebiscite on this issue. This is a cop-out response - and a response demonstrating a stunning absence of leadership from a government, especially one that professes to be one of “strong leadership”.

Completely aside from the massive waste of taxpayer funds that would be necessary to execute a popular vote, I have genuine concerns about the effect that the public debate would have on those who are affected by this issue. It would require hate-filled organisations such as the Australian Marriage Forum to be provided taxpayer funds to spray hateful statements over public airwaves, in the interests of a “full and frank debate”. LGBTQI people are already the subject of discrimination and abuse on a daily basis. They don’t require the government to be actively funding their abuse.

You don’t even need to look far to see what the timbre of the debate will be - “Won’t someone think of the children” - as if child molestation was the sole domain of gay individuals. Protests about children having the “right” to 2 parents of different sex - and ignoring the fact single parent families are entirely legal, and that multiple studies have demonstrated that the important thing is having 2 loving parents, not 2 mixed-sex parents. This debate will do almost nothing to further the state of debate. If the government took the time to actually communicate with LGBTQI people, you’d find that this is a regularly expressed concern.

It may also be enlightening to read up about the biology of the marriage debate. This essay was written by someone in the shadow of the “Proposition 8” debate in California; however, it deals entirely with the biological issues of “gay” marriage.

The short version - legislating marriage as being “between a man and a woman” is actually a biologically impossibility, and could effectively require relationships that most people would consider as “gay” marriage.

I certainly hope the Liberal party will revisit this issue in the near future, and demonstrate some of the leadership that it purports to have.

Refugees

The second issue I wish to raise with you is your government’s appalling policies on refugees and migrants. I am sick to the back teeth with the posturing of both the Government and the Opposition, as the two parties struggle to see who can be a bigger bastard to people who are simply doing what comes naturally to every one of us - doing everything in their power to ensure the safety of their families.

I am ashamed that Australia has detention camps such as the one on Manus Island. I am especially ashamed of a government that staffs these facilities with private contractors, and then does everything in its power to deny basic freedoms to those held there. And, to make matters worse, the government then change the laws to actively assist those private contractors to perpetrate abuse and prevent oversight, barring access to journalists.

Let me be clear: I am not impressed by the machismo and posturing shown by either party on this issue. The ratcheting of attacks on migrants, refugees and asylum seekers has been the undertone of multiple elections, and I am completely sick of it.

I would like our government to show any signs of compassion for fellow human beings who are suffering from extraordinary circumstances - many of which are of Australia’s own making, as a result of our involvement in foreign theatres.

However, this morning, news leaked of a truly astounding development - that the recently formed “Border Force” was going to run “Operation Fortitude” this weekend - in which, the police and Border Force agents would apparently be stopping people in Flinders Street Station in Melbourne to check their papers.

As I write this email, it appears that “Operation Fortitude” has been cancelled. To which I say: good riddance. I am ashamed that anyone in this government ever thought this was a good idea. The idea that weekly “national security announceables” will somehow convince the electorate that the government is possessed of strong leadership is, frankly, insulting.

The posturing of this government in an attempt to be “Strong on national security” does not impress me. I wasn’t impressed by the grandstanding machismo of bullies in high school. I’m even less impressed when that grandstanding is being carried out by my political leaders - people who I would hope my children would look up to and admire.

Given that both parties have taken these “Strong on national security” policies to several elections, with the only differentiator being how they planned to be cruel, I don’t hold much hope that these policies will change any time soon.

Climate change

Lastly, I would like to take your government to task over it’s handling of clean energy and climate change. Mr Abbott’s thinly veiled contempt for the issue of climate change is deeply concerning.

I can accept that some moderation is required when tackling climate change; we can’t completely shut down the economy over this issue.

However, when a supposedly free-market loving government dismantles a marketplace scheme for carbon pricing, and then actively undermines the investment market in clean technologies, claiming that wind turbines are “visually awful” (compared, I assume, to the visual splendour of an open pit coal mine and power station smoke stack), the position of the government is embarrassing.

Again, I would like to see some genuine leadership from the government on this issue.

Conclusion

Before you write off my complaints as “left wing propaganda”. I consider myself a centrist.

Consider this the cries of someone from the Menzies “forgotten people”. I don’t expect that Liberal party policy will change overnight; but I hope that if enough people like myself express their concerns to you, we might see the ship we’re on turn towards a more promising shore.

However, I hope that if enough people express similar sentiments to you, you might be able to take those opinions to the party room and affect change from within.

Personal funding, and the culture of open source

2012-07-05T15:10:00+08:00

Update 1 Jan 2015 Following the decision by the Gittip (now Gratipay) community to continue to support Neonazis and serial abusers, I am no longer subscribed to or recommend the use of the Gittip platform.

Yesterday, Alex Gaynor posted a blog entry expressing his views on personal funding.

I’m in complete agreement with Alex’s premise (with the same this-is-potentially-self-serving caveat). The Open Source community has generated some of the best software in the world, and done so with a fraction of the financial resources of comparable proprietary and commercial efforts. There are many projects that would benefit from having full-time attention rather than the spare time that currently keeps them alive.

However, the problem I see is that in order for something like Gittip to really work, there needs to be a fairly significant cultural shift in our community - not just amongst those that write the code, but amongst those who consume it.

Alex said that he didn’t think anyone has a moral obligation to give back, but I disagree. If someone uses code I wrote and open sourced, they don’t have a moral obligation to give back to me, but in my opinion, they do have a moral obligation to give back to the community - to pay it forward, if you will. I don’t care if they release their own code, answer questions on a mailing list, or triage bugs; I don’t care if they’re contributing to my project, or to someone else’s entirely. With some notable exceptions (cough*Alex*cough), a freshly minted graduate probably won’t be able to make contributions that are as significant as an experienced veteran of the industry. And some people won’t be as talented and productive as others. But, on aggregate, over a lifetime working in the industry, everyone should aspire to make contributions to the community that are equal in value to what they have taken from the community - and if they aren’t able to give back in kind, giving back financially is one way to square the ledger.

Unfortunately, my experience has been that most people gloss over the philosophical arguments in favour of open source, and focus instead on the price, viewing open source as a cheap way to fill a software stack. As a result, they don’t see an open source community that has given to them and to which they should also contribute. My experience has been that if you don’t have to pay, the vast majority won’t pay. I’ve been lucky to work at one company that went to great lengths to give back to Open Source. However, I’ve also worked at a company, and spoken to representatives of others, that, when asked to donate to an Open Source project that they have used to generate hundreds of thousands of dollars in revenue, asked - with a straight face - “What’s in it for us?”

If you need any more proof of this, look at the experience of charity organisations. Unless you’re dealing with a “cool” cause, or you come up with a good gimmick, generating donations on any sort of useful scale is hard graft. It’s very easy to say Github has 1.7 million users, and if every one of them donated just $1 a week, we’d have $1.7 million to direct at open source development every week. However, it’s another thing entirely to get 1.7 million people to actually commit to that expense.

But the whole personal funding approach won’t work unless you can get a non-trivial proportion of those 1.7 million Github users to contribute financially. So for me, the real question is how to affect the social change that makes donation like this the rule, not the exception. Unless there’s a plan for how to get to there from here, my concern is that Gittip won’t move beyond a well-intentioned, but small-scale experiment.

Unfortunately, the only options I can think of involve changing the very dynamics that have made open source successful in the first place. Any attempt to punish people who aren’t donors will only serve to drive them away from considering open source as an option in the first place. Given that we’re starting from a position where money is the scarce resource, we don’t really have any rewards that can be offered, other than the warm sensation of knowing that you’ve contributed. On top of that, anything with a financial component will be disproportionally onerous to students, or anyone in a developing economy.

Gittip has certainly got a discussion going. I’m very happy that the discussion is happening, and I’m eager to see where it leads. However, I’d like to think that we can do better than just hoping and praying that this week’s “beer money”-level donations grow organically until they’re “rent money”. If personal funding really is the way to drive the development of open source work - and I certainly hope it is - we’re going to need a better plan than that.

I can haz a question (or five)?

2010-06-27T12:58:44+08:00

So… people have noticed that I have this habit at conferences.

It’s been lampooned and questioned online; I’ve also been asked about it in person.

I ask questions. A lot of questions. More often than not, I ask the first question at every talk I attend.

And people think it’s weird.

However, there is method in my madness.

Back in the day, I was a Physics undergrad student who migrated to the Computer Science department to do my Honours degree. To make some use of my undergrad qualifications, my Honours thesis was revolved around a computational physics problem. Although my thesis topic was strictly computer science, it wasn’t one of the research foci of the department.

Half way through the year, Honours students were required to give a presentation to the faculty describing their work and their progress. The presentation was assessed, and formed a major part of the mid-term mark for the course. A component of the mark for that assessment (I think it was 10%) was allocated to how well the student answered questions.

So, I diligently gave my presentation, describing the problem I was addressing, and how I was going to address it. My slides all worked, and I hit my time allocation. Everything went reasonably well – or at least I thought so.

Time for questions … and the sound of crickets. Nobody asked anything.

I didn’t know what to make of that. Was my presentation so awesome that nobody could think of anything to ask? Was it so bad that nobody understood it? Did I pitch it at completely the wrong level?

To make matters worse – because I didn’t answer any questions, I received no marks for that component of the assessment. After all, I didn’t answer a question, so they couldn’t assess how well I handled questions.

After that day, I made a resolution. Unless there’s a pressing reason like a schedule overrun, nobody gets out of a room that I am in without getting at least one topical question.

It takes a lot of work to write a presentation, and a lot of practice and confidence to do them well. There may not be school marks on the line at professional conferences, but it’s no less demoralising to realise that your hours of effort spent crafting your presentation haven’t been able to stimulate any interest in an audience. The only worse feeling is to be presenting to a empty room.

During most talks, that means I’m actively sitting there trying to work out what question I’m going to ask. When the floor opens for questions, I will take a look around to see if anybody is making a move for the microphone. If it looks like nobody is going to ask a question, I get up and ask my prepared question. If someone actually does run to the microphone, I won’t try and beat them (unless I have a question that I really want to ask). It’s not that I need to ask a question – I’m happy as long as someone asks a question.

The interesting side effect is that once I have asked my question and the speaker has responded, there is often a line behind me. The time it takes for people to digest a talk and compose an interesting question is often longer than the time a session chair is willing to wait for that question to emerge.

So – that’s why I’m such a regular fixture at conference microphones. Personally, I think this is a job that should be considered part of the role of an good session chair; if a room doesn’t provide an initial question, don’t just shut down the floor. Provide the breathing space that allows the room can consider what it is they want to know.

However, until such time as session chairs start doing this regularly, you can expect to see me at the microphone, being “that guy”.

An end to my Evolution

2010-04-12T14:46:24+08:00

I am stepping down as a maintainer of one of my open source projects - Django Evolution.

This shouldn’t come as a surprise to anyone - there hasn’t been any significant development work done on Evolution in over a year. My personal commitments and my work on Django core are absorbing all my free time at present. As a result, I can’t give Evolution the attention it needs or deserves, especially given the changes that will be required to update Evolution to work with Django 1.2.

For me, Evolution was always a bit of an experiment. The documentation has always warned that Evolution was not production ready, and the bug tracker would back up that assessment. My aim with Evolution was to demonstrate that a semi-automated migration framework was possible, and to hopefully kickstart a development effort that would ultimately lead to a merge into Django’s trunk.

In a way, this has happened, just not in the way I intended. Following the release of Evolution, other schema migration projects have been announced – most notably, South – and these project provide alternate approaches to the schema migration problem. Some of these projects have been successful, some have not; some have adapted ideas similar to those used by Evolution, some have taken alternative approaches.

I’m disappointed that Evolution didn’t meet all of my original goals, but I’m happy that the community has developed a bunch of solutions to the schema migration problem. A big thank you to everyone that helped out along the way – especially Ben Khoo, who started the project with me; Christian Hammond, who joined as a co-developer later in the project; and anyone that took the time to report a bug, write up a patch, or contribute on the mailing list.

Looking forward, I’m sure that the core Django project will look at this problem at some point in the future. I don’t know what that will look like (although I have some ideas), but I’m looking forward to working with the community to provide a great framework that integrates the best that the community has to offer.

In the meantime, Christian Hammond will be maintaining Django Evolution. Christian has a vested interest in Evolution surviving – he uses it in Review Board. I wish him all the best.

Getting hgsubversion to work under OSX

2009-08-15T16:33:26+08:00

I’ve been using git as a DVCS for about a year. One of the big selling points for git has been git-svn - a compatibility layer between Subversion repositories and the git client. This means you can continue to use your old SVN repository to store your code, but interact with it using a modern DVCS tool that allows for local (and offline) commits, local branches, etc.

This has been an absolute godsend for my work with Django. Local commits, local branches, and git-stash have all become an indispensable part of my daily routine.

However, git isn’t the only DVCS. Of late, I’ve been experimenting with Mercurial. Mercurial doesn’t ship with a direct equivalent of git-svn, but it does have a very robust plugin framework. One of the plugins that is available is hgsubversion - a plugin that lets you treat a Subversion repository as if it were a public Mercurial repository.

Almost a year ago, Ben Collins-Sussman wrote a document describing how to get hgsubversion working. However, that document appears to refer to an older version of hgsubversion, as some of the commands no longer appear relevant. It’s also a more generic Unix tutorial, so it tends towards “compile the sources” as a solution for dependencies. When you have a stable binary platform like OSX, there is usually an easier way.

For the benefit of my own memory later on, and for the benefit of anyone else in the same boat, here’s an updated set of instructions, slightly tuned for OSX. The basic procedure should work for any other operating system, but you’ll need to work out how to adapt the instructions for your local conditions.

Install Mercurial

First, Install Mercurial. You need to have version 1.3 or greater. The default OSX installer works fine.

Install Subversion

hgsubversion requires the binding API from Subversion 1.5 or greater. CollabNet publishes an OSX installer for Subversion that won’t collide with the system version. Download and install this package. It will install Subversion 1.5 into /opt/subversion.

Configure the shell environment

In order for hgsubversion to know about the non-standard Subversion install, you need to configure the shell environment to point at the new version. Set the following environment variables so that hgsubversion can find the Subversion 1.5 bindings:

$ export DYLD_LIBRARY_PATH=/opt/subversion/lib:$DYLD_LIBRARY_PATH
$ export PYTHONPATH=/opt/subversion/lib/svn-python:$PYTHONPATH

You can set these in a normal shell session, or, if you intend to make this a permanent arrangement, you can add these lines to ~/.bash_profile. If you take the .bash_profile option, you would also be well advised to set the PATH so that the right subversion binary is available:

$ export PATH=/opt/subversion/bin:$PATH

To check that this has worked, run the following at a shell prompt:

$ python -c "import svn.core; print svn.core.SVN_VER_MINOR"

You should get a response of 5 or 6. If you get 4, you’re still using the default 1.4 install of Subversion.

Install hgsubversion

hgsubversion is available as a Mercurial checkout. I put my tool checkouts into ~/tools; any other location will do (provided you adapt the later instructions):

$ cd tools
$ hg clone http://bitbucket.org/durin42/hgsubversion

Configure hgsubversion

To enable the hgsubversion plugin, edit your ~/.hgrc file and add the following lines to the [extensions] section:

rebase=
svn=/Users/rkm/tools/hgsubversion/hgsubversion

Substitute your own home directory for /Users/rkm; if you used a directory other that ~/tools, modify as appropriate. The important thing to note is that you’re not referencing the hgsubversion directory that you cloned - you’re referencing the hgsubversion directory inside the directory that you cloned.

Clone your SVN repository

Now you can clone your repository. For example, a public HTTP repository for a Google Code project could be cloned using:

$ hg clone svn+http://<project-name>.googlecode.com/svn project

This will make a clone of the repository into a directory named project. Note that the checkout doesn’t contain the trunk part of the repository URL.

You can also clone a password-protected repository. Again, using Google Code as an example:

$ hg clone svn+https://<project-name>.googlecode.com/svn project

It’s important to note the use of svn+https. If you leave off the svn+:

$ hg clone https://<project-name>.googlecode.com/svn project

This will still work - however, hgsubversion won’t retain your HTTP credentials, so you’ll need to re-enter them multiple times every time you pull or push updates.

The cloning process will create a complete clone of every commit, every branch, and every tag, so this can take a while. If the clone is interrupted at any point (say, due to a network outage), you can resume the update with a simple hg pull.

Use your repository

Now you can use your repository. After editing some source files, you can commit, then push your changes:

$ hg commit
$ hg push

This push will turn into a full subversion commit with the same commit message you gave to Mercurial. To retrieve repository updates:

$ hg pull
$ hg update

or, if you have the fetch extension installed:

$ hg fetch

Caveats

The one notable limitation of hgsubversion is that requires that your subversion repository follow the basic convention of having the root directories /trunk, /branches and /tags. However, structure inside those directories doesn’t appear to matter (at least, a lot less than it matters with git-svn).

For example, I was able to clone the complete Django repository. The repository contains represents SVN trunk as the default branch, and creates internal branches for each of the branches for each, and ended up with a repository where trunk is the default branch, and each of the SVN branches are represented in the clone:

kronkite:django rkm$ hg branches
0.96-bugfixes              11237:04a273c619a1
soc2009/model-validation   11236:da7d967cd1d3
soc2009/i18n-improvements  11231:12da37d23998
soc2009/admin-ui           11230:72ecf612cdcb
soc2009/multidb            11228:b6a31d61ba90
default                    11225:a8c596f1915f
soc2009/test-improvements  11187:d8486ecb2e9f
releases/1.0.X             11184:f4d145484767
...

SVN Tags are also imported:

kronkite:django rkm$ hg tags
tip                            11237:04a273c619a1
releases/1.1                   11168:019f09dd0f74
releases/1.0.3                 11163:d24312cdc2ad
releases/0.96.4                11159:0d3dd0109d2c
releases/1.0.2                  9313:11a6391f263e
...

Conclusion

So there you have it. I used git for the life of the v1.1 branch of Django. Now that I have a viable SVN clone in Mercurial, I’m aiming to use Mercurial for my work on the v1.2 branch. We’ll have to wait and see which one wins out for v1.3.

If you have any comments or corrections to these notes, let me know via email.

Updated 10:25PM 15 August 2009: corrected the clone examples and explanation of ``svn+``

Even better than I thought

2009-07-08T13:35:06+08:00

Yesterday, I blogged about a positive experience I had with Packt Publishing’s relationship with Open Source projects. In that blog entry, I called on companies, including Packt, to give more back to the communities that produce Open Source, including financial contribution where possible.

It has since been drawn to my attention that Packt already contributes financially to the Django Foundation, as well as other Open Source projects. Packt pays a royalty back to projects when they sell books on an Open Source topic

Packt - I salute you again for this excellent policy, and I apologize for the error on my part.

My broader comment still stands: there are many companies that derive profit from open source, but give little if anything back to the projects from which they derive that profit. To those companies - I strongly encourage you to follow the example of Packt.

Oh yeah... I should probably mention...

2009-07-07T12:08:55+08:00

In publishing my most recent blog entry, it occurred to me that I never actually got around to blogging about the fact that on June 19, my wife gave birth to a beautiful baby girl. I twittered, emailed, photographed, and phoned in just about every way possible… but forgot to blog about it.

So - At 11:23AM on June 19, Beatrix Ruth Lorraine Keith-Magee was brought into the world by caesarian section. She was a happy and healthy 3.2kg, and scored 9 on her Apgar test.

After some initial feeding problems, she has settled in nicely to a rhythm. Her brother Tobias is enraptured, as is her mother and father.

Doing the right thing

2009-07-07T12:06:12+08:00

My life has been fairly busy of late. My daughter was born on June 19; Django v1.1 is almost out the door; and we have lots of interesting stuff underway at work.

So, when Packt Publishing contacted me asking if I would like to review their recently released book, I declined. I barely have enough time to read books at the moment, let alone review them.

However, I asked if I could have a complimentary copy anyway. After all - I am a Django core developer, and if I (and many other people) hadn’t volunteered my time to develop Django, Packt wouldn’t have a topic to publish a book about.

To my surprise, they agreed. Sitting on my hard disk is a freshly downloaded copy of “Django 1.0 Template Development”, by Scott Newman. If Django template development sounds like something you might be interested in knowing more about, and you want to know more about this book, a sample chapter is available.

I find this kind of attitude encouraging. It would have been very easy to dismiss my request, but Packt took the opportunity to give a little something back to the community that enables them to derive financial benefit. In this case, it quite literally costs them nothing: it’s an e-book, so there’s no physical costs; I’m hardly the target audience, so this doesn’t represent a lost sale opportunity. However, the gesture does gain Packt a lot of goodwill in my eyes.

Personally, I would like this sort of thing to become commonplace, rather than the exception. Donating five or ten books out of a print run to the core developers that maintain a project would hardly be a big expense for a major publisher, but it would mean a lot to the people (such as myself) that volunteer countless hours of their own time to manage and maintain open source projects.

Packt Publishing - I salute you. However, I also encourage you to make this a broader policy, not just a once-off offer to someone who took a chance by asking when approached. I call on other publishers to follow the example of Packt in this instance.

Of course, it need not stop at donated books, either. Financial or other contributions to fundraising foundations (such as the Django Foundation would also be most welcome. I appreciate that this is a much harder sell, as it involves talking about real money. However, the issue runs deeper than an accounting line item.

As with many discussions about rights (be they human rights or intellectual property rights), the parallel issue of responsibilities is often overlooked. Yes, every human has certain inalienable rights - but those rights come with the responsibility of participating and contributing to their culture as a whole. This principle of responsibility was sufficiently important that it was enshrined as Section 29.1 of the Universal Declaration on Human Rights.

Similarly, while Open Source software comes with the right of free (as in beer and as in speech) use and redistribution, there is a responsibility to give back. For the individual, this can mean contributing help on a mailing list or IRC channel, or contributing patches. For corporations, this can be as simple as allowing employees to use company time to contribute to projects. Financial and in-kind contributions are another option. When the business model of a company is entirely based on leveraging open source products - such as publishing companies with an Open Source focus, or service companies that use Open Source exclusively - I believe there is a strong moral imperative to contribute in a meaningful and substantive way back to the communities that make their companies possible.

Packt has made one small step down this road. I’m proud to say that Wotnews, the company where I hang my shingle, is a company that has not only started down the road, but is now getting Frequent Flyer points for their travels. Right now, I’m in the process of organizing travel to DjangoCon09, and Wotnews has offered - for the second year in a row - to pick up the tab for my flight and conference expenses. Given that I’m based in Perth, and the conference is in Portland, this is a substantial contribution.

Stephen Phillips and Richard Slatter (Founder and General Manager, respectively, of Wotnews) were under no obligation to contribute in this way - or in any other way, for that matter - but they have taken the opportunity to give something back to the community that has provided the foundation for their own company. As a result, DjangoCon09 will benefit from having a core developer in attendance that wouldn’t otherwise be able to make it.

The gesture is also deeply appreciated on a personal level. It’s difficult to measure the depths of my gratitude to Stephen and Richard for running a company they way they do. Not only have they built a great team and work environment, but they fully acknowledge their responsibility to give back to the open source projects like Django that contribute to the success of Wotnews. I can only hope that if I am ever in a comparable position, I live up to the example that they have established in Wotnews.

This Week in Django

2008-11-14T11:35:04+09:00

This week, I was a guest on This Week in Django, a great podcast that tracks the weekly activities of the Django community. The audio has just been posted and made available through iTunes.

I had a great time doing the show, shooting the breeze about my history and contributions to Django, my plans for the future. It ran fairly long - 2 hours in the recording, 1:40 after editing - but I’m happy with the result. We covered a lot of ground, and after listening to the recording I’m not completely embarrassed by anything I said (although I really do need to get a better microphone and a less noisy chair).

As an added bonus, Michael spliced in a piece of post-interview discussion where I give a pretty good clue as to the origin of the numbers in my handle. In related news, I now have the honor of being the first guest on the show to give TWiD an explicit tag.

What! No comments?

2008-11-05T13:12:33+09:00

One interesting (and potentially controversial) feature of this blog is that there is no comment interface. What, you say! No comments! Sacrilege! Doesn’t Russell understand the wisdom of the crowd? Is he so pig headed that he thinks he is always right and can’t stomach dissent? Is he censoring debate? What is he afraid of?

The real reason is this: when it comes to blog comments, I’m of the same mind as Dave Winer and Joel Spolsky: I don’t believe blog comments enhance the process of online discussion. Messrs Winer and Spolsky raise valid points in their respective discussions, but I have some additional reasons for disliking comments.

Rhetoric and Dialectic

While an individual blog is an excellent forum for rhetoric, it is not a good way to develop a dialectic. In the classical sense, Rhetoric is the art of persuasion by a single speaker. Dialectic, on the other hand, is the process of exchanging arguments and counterarguments, the outcome of which is a refutation of one of the points of view, or the synthesis of a new point of view representing the best parts of the two arguments.

Blogs are clearly an effective forum for rhetoric. Using a blog, a blogger can take as much time as necessary to compose a compelling argument; anyone is free to read any blog they choose, and particularly compelling blog entries will soon find themselves linked to by others. If a blogger says something interesting or compelling in a blog entry, others will link to that entry, and many people will read the argument.

However, in order to have an effective dialectic, both speakers need parity in their speaking platform. On a blog with comments, the blogger and the commenter do not have this parity. Although you could theoretically write a multi-page blog comment, in practice, this isn’t what happens. The format of blog comments encourages (and almost requires) short form responses, rapidly delivered. Those that take their time to compose a suitable comment response will find themselves a long way down a list of shorter responses, and if you take too long to compose a response, you may find that comments on the blog have been closed by the blog owner.

So how do you give both speakers parity? You give them both the same tools. Rather than trying to force one half of an argument into a comment box, you provide a way for both speakers to take the time to consider their responses. The dialectic evolves over time, in successive blog posts on different blogs.

Community fragmentation

A dialectic doesn’t have to be confined to blogs - any forum where speakers have parity of position can yield a dialectic. For example, every non-trivial open source project will have some sort of forum for discussing the development of the project itself. In the Django community, this is the django-developers mailing list.

A community around a project will usually contain a large number of bloggers. This community of blogs can provide an invaluable resource for individuals to explore ideas, discuss issues of relevance, and exchange helpful tips. However, each blog will only attract a subset of the entire community. There is only one point in the community that it is reasonable to assume that every community member will read - the central community forum.

When a blog carries comments, discussions will inevitably evolve around the subset of the community of that blog. Unfortunately, this can give the illusion that a vibrant and representative discussion is taking place, when in reality, only a small subset of the entire community is even aware that the discussion is taking place. Slowly, the community fragments into groups, none of whom are necessarily even aware that others exist. This fragmentation can be extremely destructive for a community.

If you remove blog comments from the equation, this problem becomes significantly reduced. In the absence of comments, it is a lot harder for a community subset to develop. The central point of discussion for the community remains where it should be - in the central community forum.

It takes a lot of effort to build a community, and to build a discussion resource with the critical mass necessary to make it self-sustaining. I don’t have the time or inclination to build a community around this blog - especially when I have already spent so much time helping to develop a community around Django. I’m happy to post my opinions and tips on my blog, but I will continue to have Django design discussions in the appropriate forum - the django-developers mailing list.

Sturgeon’s Law

I’m a firm believer in Sturgeon’s Law - 99% of everything is crap. Blog comments are certainly no exception. Things are made worse by the fact in that the world of blog comments, Sturgeon’s Law has a very important corollary: John Gabriel’s Internet F*ckwad theory. Frankly, I don’t have enough time in my day as it is without having to spend it deleting spam, and wading through “Django iz teh suxx0r” comments to find a nugget of wisdom.

Forcing people to post responses in their own blogs has three effects:

It raises the bar to entry by just a little bit. Any old moron can poke a comment in a comment box (and if the general level of internet discourse is any indication, morons do this with alarming regularity). By forcing comments into blogs, it means you have to be have to be smart enough to work out how to get a blog from any one of the dozen free blog hosting services on the internet. This isn’t a huge barrier, but it’s enough to stave off one particular class of ignorant obnoxious trolls.
It serves as a mild encouragement to say something interesting. If you’re just commenting on a blog, it’s easy to get away with “Me Too!!!111!!!!” as a comment, but if you have to go to the trouble of writing a publishing a blog entry on your own blog, you are more likely to go to the trouble of add a comment - even if only a brief one. I’m not interested in listening to an echo chamber - I want to hear real discussion and real debate.
I’m a big believer in personal attribution. If you have something to say, you should be able to say it - but you should also be responsible for what you have said. Anonymity can be important - if you’re whistleblowing on government corruption, for example - but in general internet discourse it simply isn’t required. People say all sorts of things on the internet that they wouldn’t say in person under the guise of an anonymous login. On the other hand, people are generally proud of their blogs and homepages. By forcing people to closely associate their identity with their words, I believe it is possible to force people to think twice before posting something flagrantly inflammatory.

Summary

I’ve been a citizen of the web for almost 15 years now. My position on blog comments is not theoretical or abstract - it’s based on what have seen and absorbed over the years, and the places where I have found the most value. If you disagree, I ask that you ask yourself this one question: If every blog comment that has ever been written were to disappear tomorrow, would the world lose an important intellectual resource? I, for one, don’t think they would be particularly missed.

Do you disagree with me? Then blog about it! I look forward to the dialectic.

EzyDVD store passwords in the clear

2008-10-24T10:06:01+08:00

I’ve been a customer of EzyDVD for some time. They were one of the first players in Australia to take e-commerce seriously; I like their no-fuss website, and their customer service has always been very good.

However, I had a somewhat alarming experience recently. I had a problem with an order that I placed, so I emailed their customer service line. I didn’t hear back from them, so I called their customer service line. The helpful lass on the other end of the phone solved my problem quickly.... but in the process was able to tell me my account password.

You don’t have to be in this industry for long to know that storing passwords in clear-text is a bad idea. I’ve taken this up with their webmaster, but I haven’t heard back yet. In the meantime - any readers that use EzyDVD - be warned.

freakboy3742

2008-10-21T10:59:00+08:00

Once upon a time, I was an undergraduate at Curtin University of Technology. As a way of earning some extra cash, I worked as a tutor for the School of Computing. One of the subjects I taught was was “Information Technology 111” (otherwise known as IT111), an introductory “how to find the On switch” course.

IT111 was a compulsory course for Chemistry students, and for some reason, I ended up with a tutorial class that had a disproportionate number of female students… many of whom were quite familiar with the ‘giggle and bat eyelids’ school of eliciting help from male tutors.

One afternoon, I was teaching in one lab, while some of my eyelid-prone female students were working on an assignment in a different lab. They were quietly discussing a problem they were having, when one of them said quite loudly “Oh, I don’t know - why don’t you go ask Freakboy?”. Then two of them stood up, walked down the corridor, and into my lab.

How do I know this? One of my friends was sitting in the lab with them, and saw them walk down the corridor and into the lab where I was teaching. The name stuck, and the rest is history.

As for the 3742 - freakboy is a surprisingly common handle, so the 3742 is a way to make freakboy unique. The numbers themselves are drawn from one piece of geek culture, and one piece of cult film. I’ll leave it as an exercise to the reader to work out the references.

Yet Another Blog Engine

2008-10-13T13:19:28+08:00

At DjangoCon 2008, Cal Henderson made a joke that everyone in the Django community has built, is building, or intends to build a blogging engine. He asked the audience to put up their hands if they were building a blogging engine. I put up my hand. Although I probably could have claimed blog-writer status through my work proofreading coltrane for James Bennett’s book Practical Django Projects, this site is the real reason.

I’ve been meaning to set up a blog for a while. My old home page (finding it is left as an exercise to the reader) dates from my days in university, which means it is has been over a decade since it was written (by hand, with no dynamic content at all), and almost 5 years since I made any serious updates. Given that I volunteer a lot of my time working for a prominent web framework, this rates as a pretty bad case of the cobblers children having no shoes.

That said, I’m honestly not expecting to blog that much. I find writing to be an agonizing process. I am acutely aware of the power that words have, and I am also aware of the fact that I am by no means an expert wordsmith. However, from time to time there are things that I need to get off my chest, and from time to time I’m in a position to provide a useful tutorial, so its useful to have a podium from which to bludgeon some words into submission. I’m also hoping that by giving me a forum in which to exercise my writing muscles, this blog might make the act of writing a little less painful.

One point of interest regarding this blog: you may notice that there is no comment interface. This is deliberate. In the near future, I intend to blog to explain my reasons for this. In the meantime, if you feel the need to respond, write an entry in your own blog. If you don’t have a blog, there are many freely available options - or you can do the Django thing and build your own.