When I talk to college students who are working on their first open source projects, the message I emphasize over and over and (yes, one more time) over again is the importance of working openly. And yet, as I discovered myself while writing this post, working openly is harder than it sounds.
When I talk about working openly, I mean that doing things "the open source way" is more than using an open source license (although clearly you must have one of those, too). Working openly means being public about your process, from start to finish, including all the messy bits in between.
I usually tell students that by recording and sharing (in whatever format) the whole project, they are doing a couple of good things:
- By documenting "wrong turns," they can prevent future maintainers/participants from making the same wrong turns.
- By documenting the decision-making process, they'll help the next person who is scratching their head trying to figure out why students did this versus that.
- Documentation creates a project history, which represents the project's personality and character over time. If someone is thinking about joining a project, they're more likely to join a project that has some back story than one that is just naked code.
And there are other reasons, too, like the possibility that you might receive useful feedback from outside your team or even school.
Creating obstacles
This all sounds quite logical. And it is. Yet when confronted with the request to document my own feedback (what you're reading right now), I will admit that I became a little stuck.
Here were the obstacles that got in my way I created to prevent me from finishing this one (little) article:
- I didn't know where to publish it (silliest excuse ever).
- I didn't have time to write it.
- I wanted everything I was saying to be perfectly correct (and considered having it reviewed by two, three, or even five other people to be sure I'd been clear).
- I wasn't sure that the things I was saying hadn't been said before—and better than I could say them.
- I wasn't positive that I was an expert and that I had the "right" to write about them (imposter syndrome).
So I dithered. I started writing the article, but got pulled off onto other things—all legitimate work that had to be done, but also all being done in part to avoid sitting down and writing this.
And I rewrote (and rewrote). That took time. And half the time I was starting to rewrite ideas before I'd even finished writing them, which is perfectionism getting in the way of getting something done.
Then IRC would beckon. I'm not usually very chatty on IRC, or more accurately, my chattiness is sporadic. I find that when I am the chattiest, it's because I am frustrated by something or am avoiding something (I hope my boss isn't reading this).
And the ideas that I must be saying something entirely novel and that I must be an expert in order to add value... well, to be honest, I'm still struggling with those. But I also realize that sometimes hearing something explained in another way makes a difference, and maybe that's what I can do.
Better, but not easy
I soldiered on and finally finished this post, which ended up being more about about why it can be hard to work openly than about why you should work openly.
And forgive me for getting “meta”, but I suppose that was kind of the point, right? The process of writing the article ended up being valuable in and of itself because (I hope) that I've shown that it isn't always easy, but it is always important.
5 Comments