Open Source Code in the Workplace
Every progressive developer comes across the same dilemma eventually:
“If we publish this package publicly, it can be maintained by the community but .. as a company, we don’t want to have responsibility to maintain it.”
It seems a little shameful really; sitting on a cloud of generosity, handing down packages to the lowly devs of the world but offering no support and expecting said lowly lackies to keep it alive while reaping the benefits.
But!
It is a completely legitimate position. If you’re in a small sweatshop agency, there’s very little benefit and an awful lot of investment, so it is understandable most of the time.
So what do we do?
Well, how about a compromise. If you find yourself about to create an abstract package that’s just crying out for open source publication.. why not go ahead and do just that — but with your personal account.
Personal account!?
Okay, not necessarily. A personal work account perhaps but even so, if you’re working on this invaluable positronic brain of a tool, perhaps in your spare time (being the good little socialist worker bee that you are, with an insatiable thirst for knowledge) why ever not?
But they won’t like that!
Very possibly. IP is IP and if you’re fiddling around during work hours, as it were, it won’t go down well but there is a possible way around that..
Just tell me already!
Set your company’s open source account as a collaborator. Then, when you’re at work, commit with that account, or better yet a personal work account. That way, the company has the power to deal life with one hand or death with another if they so choose but also you continue to build the thing as your own entity.
Better yet, encourage your colleagues to get involved and maintain alongside yourself — presenting your team to the world as a solid corpuscular body of pro-humanity development. Hench and awe-inspiring. Which looks good and feels good, just like.. erm.
Bit shady though, right?
Nah, not at all. Consider the idea that you were two separate people: one employee, and one codey person-of-leisure. There’d be no conflict of interest there, so why not flirt a little with splitting that personality, because at the end of the day, you’re both working toward the same goal and improving your skills doubly so (not to mention essentially doing out-of-hours work for free).
Produce at work, perfect at home.
I agree
I’m glad! But what do you think? Are these just the feverish ramblings of a burnt-out engineer?