Does "Open" Mean "Free for the Taking"?
What should you do when someone takes credit for your work on an open-source project?
- By Jill Dyché
- January 19, 2017
You know you're onto something when people take pleasure in deriding your average ideas and stealing your good ones, so immediate props to Drew, whose code is so awesome that, well, read on.
This is an uncomfortable problem. I'm a programmer, and a contributor to various open source projects. I reliably comment my code because it's important to me to be seen as a true contributor and considered among my peers as a serious coder.
A colleague has been commenting on my code, inserting comments in which he seems to take credit for writing it. His comments are at best inappropriately wordy and at worst wrong. (I have also overheard him talking about his "all-night codewriting binges" when I actually see him leaving the office at 4:30 most days.)
The final straw was that this guy included an entire code script of mine in a formal presentation to our IT management team. After the meeting I confronted him about his brazen plagiarism and was surprised when he didn't refute my accusations. Instead, he justified his behavior, explaining that open source coding is essentially volunteer work, thus it's "all for one, one for all."
This is a new one on me. Does the fact that the code is open source change the rules?
Drew in Lansing, Michigan.
Wow, Drew. First off, kudos for documenting your code. Really. The going rate these days, according to one study, is 1 comment for every 5 lines of open source code, super-important when these types of projects go mainstream.
I'm actually a huge stickler for people getting credit for their own work. I think it started when, as an English major undergrad, I watched a fellow student get expelled from school for lifting an entire passage from Sherwood Andersen's Winesburg, Ohio and passing it off as her own work.
These days, more technology is labeled "open." Open data. Open platform. Open APIs. Open source. More people than ever contribute to open projects, be they code, social media comments, team communication sites, or private messaging apps. Unfortunately, there's an assumption that as soon as something is shared, it's automatically in the public domain, and therefore publicly-owned.
When I was a management consultant, my small firm would often compete with the larger consultancies. These big firms would pester my clients. "Why would you continue using a niche consulting firm," they asked, using the term niche pejoratively, "when you could engage a full-service firm like ours?" Then I'd invariably discover one of our PowerPoint slides in the large firm's deliverable or an unattributed quote from one of my books in their pitch deck. This was at once the sincerest form of flattery and blatant plagiarism.
Check your version control system. Most keep metadata on who writes what code. I'm not an open source expert but I'm sure your colleagues are already well aware of (or don't really care) which code is yours.
The larger opportunity here, of course, is to go to your boss and tell her that this code-poseur is taking credit for your work. This is a good opportunity to gauge your boss' perception of the quality of your code, not to mention your work ethic. It will also give you the chance to understand her philosophy on the topic of credit for code. This is important because your code-thieving colleague might represent a broader cultural norm at your company that you should at least be aware of.
Obviously, source code, fiction, and PowerPoint slides are all different and have different rules. It sounds obvious, but the rule of thumb is the same as it ever was: If you're using something that someone else created, get permission or attribute it to the original author.
Code on, Drew. The industry needs you!
Whipsawed by a work conundrum? Email me a question about analytics programs, data management, organizational issues, or culture at Jill@upside.tdwi.org.
Jill Dyché has advised clients and executive teams on their analytics and data programs for as long as she can remember. Longer, in fact. She’s the author of four books on the business value of technology and regularly talks to teams about what keeps them up at night. Ambivalent about analytics? Maddened by management? Constricted by your culture? Check out Jill’s Q&A column, Q&A with Jill Dyché, here.