I’d be pretty delighted. I’m paid for getting projects done, not for keeping hold on some copyrighted code. I want all my code to be open sourced, and reused.
Yep, I'm required to make my work freely available when I can. Some of it is sensitive so not all of it can be, but otherwise we have to. Also all of my code and data is open source, which is not required but we have permission. Where I worked previously was totally different, it took months to get any code release approved.
You can find all the code I've ever written on Github, licensed MIT. I only wish I could do the same for the code I've written for pay. I cannot release that, because people more powerful than me have decided that I don't own it.
I was hoping you'd be at least the slightest bit more specific :) are you working in a proprietary startup? are you working in academia? presumably you're working on a codebase with the intent to distribute it to users at some point?
All of the code I write now, I release publicly under a permissive license.
I do not use any cloud services for storing data, and do not use any social media websites (other than perhaps HN, but all my actions are public here anyways). So that's a nop.
If there are things I think others will want when I'm gone (e.g. photos, documents), put them in a place where they can be physically accessed.
> Depending on how much trouble this might cause, you probably shouldn't
> upload it anywhere. Even a "private" repository on GitHub/BitBucket might
> be too risky.
I don't think that he was talking about using BitBucket to host your malware
repo. Probably more along the lines of projects that aid in the downloading of
possibly copyrighted music/videos (for example). It's a legal grey area because
you really don't know if your are on the wrong side of a law until a court
makes a decision since there is no clear-cut way to know.
Some other examples:
1. You want to keep track of your dotfiles that you use at work. In general,
this may be ok to put public, but it may contain work-specific stuff
(hostnames, configurations, etc) that might get you in trouble for publishing
publicly. For example, my work shell config has aliases that include connection
information (sans password) to internal databases.
2. Resumes and/or cover letters. If you update your resume to say that you're
looking for work, or looking for work in another area, this could give info to
your current employer that you don't want to hand out. You might also want to
keep your cover letters in version control if you use something like LaTeX or
have specfic parts that you want to be boilerplate (e.g. description of
yourself and/or your exerience). If you keep this in public, then everyone
knows when/where you are applying for work, which may not be desirable even if
your employer doesn't care.
So, would you rather have me hoard this into my local workspace until forgotten? Or release it in the open since I will be working on a project that actually pays money. At least if somebody will be building something similar he/she can look up at this code and maybe make a derivative out of it.
Careful. Excluding open source, sharing code from a former or current employer sends a signal about how you're likely to handle the prospective employer's IP.
I fear that opening sourcing my personal projects would work against me. The code that i develop in my spare time is done for my own benefit, and just for fun - no documentations, no unit tests, and there are hacks there which i'm proud of.
I fear a future employer would look at that code and think that is how I write code in professional environment.
I wouldn't be comfortable sharing code I wrote for a previous employer because I treat that as confidential. I'd be happy to show my personal code with the understanding that it tends to be improvisational and done a bit more casually than production code. But along the way I'm sure I'd show enthusiasm discussing the architecture of my personal projects as well as my home infrastructure: everything running on VMs, control panels, private git server, Jenkins, and everything deployed to containers.
If not, why not?
reply