Introduction
The best thing about running your own open source project is the opportunity to wear so many hats – software architect, designer, domain expert, and so on. The worst thing, of course, is exactly the same – the multitude of hats you may have to wear. But there’s no experience quite the same and facing the challenges involved is certainly educational.
The purpose of this talk is to share some of the lessons learned running the SOFA Statistics project since 2009.
Quick Overview of SOFA
SOFA, which stands for Statistics Open For All, is an end-user statistics and reporting application with the tag-line “the user-friendly, open-source statistics, analysis, and reporting package”. SOFA is written almost entirely in Python with a little JavaScript for the dynamic charts. To date there have been over 200,000 downloads and the project won the People’s Choice Award in the 2012 New Zealand Open Source Awards.
SOFA lets people connect to databases, import data from spreadsheets, produce report tables and charts, and run some basic statistical analyses such as the ANOVA or the independent samples t-test.
So what are some of the hats involved in running a project like SOFA? And are there any lessons applicable to other open source projects?
Hat #1 – Software architect
Before you write your first line of code you need to have a basic idea of how you want the application to work overall. Is it a web application? Desktop? Should it be possible to run it from a script i.e. headless? Which languages and frameworks will you use? These are important decisions because they can become costly to change later on.
If you look at very early versions of SOFA they are very similar to the latest version. The new version may be much more robust and feature complete, with lots of little touches to make it easier and more flexible to use, but it is obvious that the DNA was set very early on. This slide from a presentation in 2010 remains broadly accurate.
In the case of SOFA the intention from the start was to be a cross-platform desktop application. It was assumed that an important use case was to be able to link dynamically to SQL databases and to produce output that could be viewed in web browsers. Being able to script SOFA using Python was also considered an important capability. Two of the biggest decisions looking back were to use Dojo for the JavaScript charting tool kit and wxPython for the GUI tool kit. Since that time a considerable amount of code has been written which relies on those choices and it would be expensive to change at this stage. Fortunately, both libraries are mature and aren’t subject to the sometimes insane pace of creative destruction common in the technology environment.
Hat #2 – Help Desk
When you run a project with end-users there will inevitably be demand for you to adopt a help desk role. Sometimes answers come from members of the community but more often they have to be answered by yourself. Running the SOFA project has entailed responding to thousands of sometimes highly-technical emails. Although this has an obvious cost in time it provides a number of benefits to the project:
- reputation – the project develops a reputation for being friendly and supportive
- UX input – it is much easier to develop a clearer idea of the sorts of things that trip people up when using the application, and talk through possible ways of resolving these
- bug squashing – it becomes possible to debug installation or functional problems on different operating systems/environments e.g. Windows 7 users in China. Often people are able to provide access to the data they were using when a bug occurred e.g. when they were unable to import an ODS spreadsheet with a more complex internal format than usual; or when the x-axis didn’t display properly on a chart. Access to problem cases is invaluable when making systems more robust.
Additionally there is the satisfaction of being able to help people. If your project is aimed at users of varying technical abilities like SOFA is (SOFA standing for Statistics Open For All) then even quite simple assistance will often be sufficient to get people unstuck. Of course, every improvement to the interface or documentation reduces the help desk load.
One recommendation: don’t run your own forum – use the infrastructure provided by google groups or similar.
Hat #3 – Designer/UX
If your project is aimed at end-users it will probably need a lot of design work done. How will the website look? If there is a desktop or phone app gui, what should that look like? And how should it function in terms of User Experience? What about all the visual assets, logos, icons, themes etc? How can you create a consistent branding? Will you be making videos? Will you need images for your blog?
To get the basic look-and-feel of SOFA I ran a small competition at what was then called NatColl (now Yoobee ACG School of Design). The offer was $50 worth of soft drinks and pizza to the class and $50 for the winning design and the students were provided with a clear brief as to the target users of SOFA and other design constraints.
As for the other visual work I had to do that myself. Fortunately there are excellent open source tools available (GIMP, Inkscape, Openshot) to make that easier. Here are just some of the hundreds of images which had to be made for different purposes (installers, documentation, blog posts, articles, interface, chart themes etc). A professional designer would have done much better but the point being made here is how many may be required.
Part 2 will look at the following hats: Promotions Manager/Copy Writer, Domain Knowledge (Statistics), Product Manager, and, more briefly, Testing Manager, Documentation Manager, Community Manager, Research & Development Team, Legal/Business Management, Web Developer, and Project Manager.
