The Fedora ambassadors have given me food for thought: my humble dissertation project (facilitation of a GSM interface for the ces.org.za website), which hardly involves any coding (but lots of documentation, as well as a field test), could still become “open source” – at least partly. Even if some of the processing happens in “black boxes” outside the project (for now anyway), the project could still have the gamut of open-source accessories: licence, wiki, version control system, repository, community, etc. After all, many thousands of people around the world stand to benefit via the CES website. This would increase the project’s chances of propagating and persisting beyond the scope of my Masters project. Also, I will have proven my capacity not only for research but also in open source project management.

The challenging parts are to do with the other parties to the project: my co-programmer, a non-student and fellow volunteer in the CES; and the university itself, embodied in my department, supervisor and examiner/s. I believe none of these is in any way hostile to open source (rather, the contrary) but at the same time, their knowledge and experience is basically of open source products rather than processes. It could challenge them to have a whole crowd involved, even (/especially?) if it’s scattered worldwide. However, I am aware of two initiatives within the university which could lend legitimacy to such a strategy: the Open Content project, and the Social Responsiveness initiative.

My inclination is to seize the bit between my teeth, and make it a primary feature of my project that it’s open-source, and claim credit for that. After all, what’s the worst that can happen?…Even if I’m forced into the mould of conventional individualistic work, I will have gained valuable experience along the way. Over the next few days I will be looking in more depth at my options…

Suddenly the hitherto cute phrase “productively lost”, which was presented from the beginning as a goal of POSSE, takes on meaning for me. Not so much within the proceedings of the course so far; I have felt somewhat at home there. Rather, I am applying it to my last several months at UCT. Although I had done coursework for my Masters remotely in past years, this time since relocation has been my chance to roam the field of IT, obsessively reading and absorbing the big-picture stuff to the detriment of my last modules of coursework, and circling my dissertation project, planning and preparing. I have been intensely curious about the David-and-Goliath confrontation between corporate and open-source production, seeing it as a crucial sub-plot of the drama of homo sapiens’ redemption or disgrace. Now I am finding my own feet on the stage.

4 Responses to Productively lost indeed.

Remember: your number one job as a student is to *complete your degree*.

“After all, what’s the worst that can happen?”

You need to talk to your advisor and institution before considering such a move. The best thing that could happen, in my (jealous, guarded approach to completing a degree) is that you make everything open in terms of licensing, and no one comes to play. That way, you have a project that is given to the world, and while you are trying to get done in a timely manner, no one interrupts your work.

The worst thing that could happen is your project could be successful, even to a small degree, and you have people interacting, attempting to submit patches, trying to impose their view/direction, etc., on a project that is inherently about your work and, worse, bounded in time. There is no 50% Masters, or even an 80% Masters — a degree is either done, or it is not.

This is something that others in the community may have a perspective on, but I would not look to the Fedora ambassadors unless they themselves have experience *open-sourcing their degree work*. Building community and supporting that community is a project unto itself, and you have to ask yourself whether that is orthogonal to the goals of the degree you are trying to complete.

(Mind you, I’m being fairly curmudgeonly on purpose… but that is because there is no one, perhaps other than your advisor, who will help make sure you are successful in your degree. Open projects run on the mantra that contributors may, or may not, contribute what they claim they will. When you collaborate on work that is critical path, you have to know that your contributors/collaborators are engaged with the same mindset as you: that it MUST get done. Think about your degree defensively and jealously — as no one else will.)

Thanks Matt, my post was actually written last night and as promised in the last sentence in the 3rd para, I am in the process of looking at my options, and will be consulting my fellow CES volunteer soon. As for your fear of the project getting too successful, I have an exit strategy, in that I won’t rely on reaching completion, but will be writing up the project only as far as the field test, which will happen using interim “black box” stuff, in the form of outside service providers. My “dissertation” actually only has to be a mini-dissertation considering how much coursework I have also done.

I agree with Matt about making sure that the open source community work you’re thinking about doesn’t interfere with your ability to complete your thesis and graduate – we want you to be able to do that and go on to do fantastic things, after all.

I disagree with his descriptions of best and worst case scenarios, but take this with a grain of salt because I haven’t open-sourced my Masters’ project (I haven’t yet gone to grad school) – although I did open-source my dayjob… multiple times, including when it wasn’t my job to do so (and was in fact discouraged from doing so). When I worked on the QA team for an open source product, the director of QA didn’t see why I wanted to spend my time on “building community” and only cared whether the tests I was responsible for got run. Several months later, the QA community I built up ended up doing more QA work than the entire rest of the “official” QA team combined…

I’d suggest taking the workshop time to do exactly what you’re doing now – setting up an infrastructure for your own development to be done out in the open. Know your critical path, and make sure that even if nobody else contributes, you’ll be able to complete your project in time. I can see three scenarios here:

0. People contribute and you get distracted and don’t complete your thesis.This is the worst case scenario, and I believe it’s what Matt was referring to.

1. Nobody contributes. Then you’ve got exactly what you would have had anyway – your thesis work – except you’ve got all of your work already published, with fine granularity, out in the open – automatic portfolio creation. I don’t think this is the best-case scenario, though. Rather…

2. You finish your thesis work, and others have already started to extend it. This is what I would call the best-case scenario; your work is living beyond you. You’ll need to be transparent (radical transparency, remember) about this project’s beginnings as your schoolwork, and your motivations and restrictions for contributing to it yourself; stay focused and don’t be afraid of saying no to work and managing contributions if it gets to be overwhelming.

You can say “Look, I’m hosed with graduating right now, I’m going to work in my own branch and you folks will have to continue developing without me for a while, I’ll be back in N weeks.” So long as your code is available, they can move to a different location and continue contributing, and you’ll always have the option to merge back afterwards. People can always support themselves, tinker with the code and documentation and such themselves in the background, independent of you. That’s what open sourcing a project is about, really – removing yourself as a bottleneck, so that others won’t have to bother and distract you to get things done.

You can, at any point in this scenario, drop back to option 1 and focus on your thesis – get it done, make sure you graduate… and so long as you’re doing your development in the open, others can still pick up on it.

Another way of phrasing this is what one of my college professors told me: problems are divided into 3 classes. First is mission-critical, live-or-die – that’s what you need to make sure you can carry all of the work for at all times, the stuff you need to graduate. If someone else picks up on some of it and saves you some work, great – but you can’t count on that. The third type is stuff nobody cares about, things and features that don’t matter. Don’t even bother with things that won’t make a difference.

But the second type is the stuff that isn’t mission critical, but would be nice to do “if only I had more free time.” This is where open communities shine. Give others the ability to pick up on it – because what’s optional to you may be mission-critical to those who choose to build on your work. If it doesn’t get finished, no harm done – it wasn’t mission-critical, you still proceed as planned. But if it does happen, then – bonus! Life is better all around.

Hope this makes sense – as usual, feedback/pushback welcome, it’s how we all learn. And again, I haven’t open-source my graduate work (I haven’t gone to graduate school yet) so I have only done this from an industry dayjob perspective, so you may want to pay heed to Matt, who has indeed worked open source into his academic (professorial) dayjob.

Thanks Mel, I think that your third option was what I had in mind when I replied to Matt that I have an exit strategy – not from the project, but from any stated degree of completion thereof, further than what I had already committed to, namely a modest field test using improvised functionality. Now that I’ve got Tim, the CES sysad/programmer up to speed with the project being opensourced (new verb there), he can stand in as project leader if and when I need to coccoon.