Lessons in Creating open source software

2010 August 25
by Karen

Ed Corrado has a nice post entitled “Little Things Matter” on some key things that open source software creators should keep in mind. I agree with the spirit of what Ed says wholeheartedly.

I can’t tell you how many times when I was an open source noob, I’d wonder what the heck the installation instructions were talking about or was frustrated because no one answered questions posted to the listserv. I suppose that is one of the reasons I thought “when I write a book on open source web applications that it will contain specific installation instructions”. Having written that book now, its not as easy as it might seem. I mean do I give step by step instruction on MySQL using the command line or MyPHPAdmin? Instruction for what OS? It is daunting for both people writing documentation and those using it.

Which bring us to the point that Kathryn Greenhill makes in comment on a post by Roy Tennant which highlights the Ed’s commentary. Open source software means that users need to take an more active role than often people are used to taking. More than once at the end of a frustrating day working to get something installed properly, I’ve gone back in and edited software’s documentation wiki or sent an email with suggested changes. Better and more thorough documentation almost always comes from a community effort.

To do this though one has to learn how to participate in an open source community. Learning how to participate is a ongoing process though because one may participate in new ways or in different communities over time. The idea though is that community members are able to build confidence over time by acquiring new skills. Case in point, there is a patch for a Drupal module I’d like to test, try and report back on. But I’ve never done that before. So I don’t know how to apply the patch, which means I’m sort of stuck until I either:

  1. Go searching the internet for instructions
  2. Ask someone who I know might how to do it to help me

At the moment I’m not feeling brave enough to deal with the situation. I’m nervous about the possibility of seriously messing up my test server and having to rebuild it, but I’m also afraid of looking stupid because I have to admit that I’m outside my comfort zone.

Many of the things that Ed suggest in his post help to build a larger comfortable starting point for users trying to implement open source software and participate in the community. Without that it sort of feels like you’re hanging on by your finger nails trying to do this stuff and it makes you not want to try. Everyone needs a starting point and if you’re creating open source software you have to think about starting point you are giving people to be part of your software’s community.

2 Responses leave one →
  1. 2010 August 26

    All very true, but it’s also important to acknowledge that providing “good for newbies” software, beyond just being more polite onlistservs, requires a buncha _work_ to get it there.

    I think we may have gone too far with our pro open source propaganda, now some people expect ALL open source to be as easy to install and maintain as the best commerical software, and blame the developers for insensitivity (or worse) if it’s not. It takes a lot of work to get it there. Even if you really want to get it there (and not all developers do, but I agree more should), it takes time and work, and immature software isn’t usually going to be there yet, and the more complicated the software is the longer it’ll take to get mature. And then some of it just depends on the motivation _and_ skill of the developers, yeah. As well, of course, as how much developer resources are are available for the project.

    On the developer side too, it’s true, some people don’t understand that it takes significant work and energy to lower the barrier of participation (as a user or developer) to your project — or know exactly what the steps to that work are. It doesn’t just happen automatically. Sibyl Schaefer’s article in the Code4Lib Journal was one attempt to elucidate some of the issues involved in creating accessible open source software and a succesful open source community. http://journal.code4lib.org/articles/2493

    We need more articles like that, approaching from other angles. This blog post is a good stab it too, thanks.

  2. 2010 August 27


    Good points. In my mind, maturity of software not only has to do with the quality of the code but also the quality of the community. In my opinion a good community has lots of people involved not just developers. Developers can only do so much. I don’t consider myself a very good coder but I feel like I’m a pretty darn good at testing and documenting. So I try to contribute in those areas. Unfortunately there is a lack of understanding that it take all kinds of people, playing all different roles to make an open source project successful.

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS