Why working openly works (even when it's hard)

No readers like this yet.
hands

Opensource.com

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:

  1. I didn't know where to publish it (silliest excuse ever).
  2. I didn't have time to write it.
  3. 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).
  4. I wasn't sure that the things I was saying hadn't been said before—and better than I could say them.
  5. 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.

User profile image.
Gina Likins | University Outreach, Open Source & Standards Team at Red Hat I have been working in internet strategy for more than 20 years, participating in online communities for nearly 25, and working in open source for more than four.  I'm passionate about finding ways to help our open source communities thrive and be more welcoming for everyone.

5 Comments

Thanks for the article. Great to see the perfect list why not to publish an article. It is exactly what I always bump into. A good reminder to just write that darn article ;)

This is a great and timely feedback. Thanks for stressing the importance of documentation and challenges one faces in the process. Hope our students and I act and document our projects.

Fantastic, thank you for writing this. I have been thinking about a blog and podcast that is somewhat unique - at least, as unique as you can be today, especially in the tech space. But, divinely dealing with the imposter syndrome and others. This was very helpful and encouraging!

Interesting post! I love the list for sure :-) It's also got me thinking of other ways we can and should work openly. Now the question is, which of the wonderfully accurate obstacles listed is the one I'll hide behind instead of putting my thoughts down in a post, eh? :-)

I had to smile :-) and really enjoyed reading because it mirrors exactly the feelings I had when participating the first time in an Open Source Community, especially the points 3, 4 and 5 hit the nail on the head. But those doubts disappear quickly after recognizing that the community embraces every contribution and helps you to move forward. Thanks alot for sharing.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.