hating to love it

And then there's obvious corollary, Do Real Geeks Just Code?

Except maybe for eating at times. Or sleeping occationally. And having a sip of coke.

We do need to shop food too. But other than that, we just code.

It has happened that before we code, we had to install or sorts of hardware and software. And adjust the chair. And answer the telephone when some of your few social contacts invokes a voice connection.

But we only code.

Except when we have to put our silly programs and tarballs up on a web page. Making web pages is not coding. It's fiddling.

But Real Geeks Just Code. Oh yes! :-)

Another very concerning question related to this is "who owns the code"? Read that contract you signed; did it contain sweeping language about the code you write during your tenure with the company?

This is one of the most concerning things to me, and something I always look for when signing a new contract. While my primary role has traditionally been systems administration, I receive the same contract that the programming staff receive, which usually contains wording which conveys ownership of almost anything you do to them, even on your own time. I've been careful to accept employment with companies that understand that I do software development as a hobby, and whose contracts have adequately protected my ability to do that.

The employer code ownership clause in most contracts is indeed a sticky one. When I originally started at an ISP, they had an overly broad clause in their contract that I didn't think anything of because I wasn't going there to code and didn't really have too many dreams of free software. I ended up coding later, and noticed the clause in a later handbook revision. I went straight to the head of engineering (who was, incidentally, a part-owner) and got his verbal assurance that things I'd done on my own time were mine. Looking back, I should have got it in writing.

Nowadays I'm working under a contract that simply stipulates work done for the company or with company resources is company property, which is fine with me. I certainly don't fall under either when I go home and do my part.

I almost said "hard to put out all day", but that sounded bad. Now, by comparison, "hard to do it all day" sounds less bad. :-)

Anyway, if I've had a day where I've actually coded at work (and not just fixed problems or discussed), it becomes more difficult in the evening. The same goes for if I've used up my daily quota of thinking about project design, or something similar. I seem to have a limited amount of each each day and just need to work on something requiring a different skill at night, if I do choose to work at night.

I once had a horrible job. The folks I worked for insisted on designing everything from the silicon out. Including new networking protocols that were supposedly better than TCP/IP, but wound up being more complex and less scalable than TCP/IP. It was a horrible place to work and I got burned out on it in a few months. During this time my contributions to the free software movement were uninspired and boring. Despite being not challanged at work, the day job zapped my strength and will to do anything extra with computers.

So I quit the company. I'm much happier, but much poorer, now. The stock options that I had there would be worth about $1M before taxes today (well, maybe a little less, as the nasdaq is down today). Had I been smart, I'd have stuck it out. But it was a 5 year vest and I'd be only 80% vested by now. But I wouldn't have worked in the cool jobs I've worked at over the past 4 years, so like I said, I'm poorer, but happier. After considering the delta in salary, I think the difference was worth it. I have a much brighter future due to my Open Source involvement.

As other posters have pointed out, make sure that your off hours work isn't considered IP owned by the company. Timing Solutions, the company that I work for, has a very friendly IP poilicy. I get to contribute back changes to the base OS as it is in our best interest to have other people maintain them. I even get paid to fix some bugs from time to time if they are biting us hard. So your best bet is to get another job. Pick the battles that you want to fight and admit that this windmill won't move and go to the next one.

As a previous poster pointed out, there could be a problem with your employer claiming that all work is theirs. I'm not sure if such contracts are legal, but the best thing to do would be to choose an open-source project that's far removed from your employer's business. For example, if you write software for a bank, you probably shouldn't work on, say, GnuCash; but a compiler would be okay. A game is usually a safe choice (it's my choice), but not if you work for Electronic Arts.

And if you work for Hughes Aircraft, you probably shouldn't write an open-source missile-guidance system.

from recent experience, i can say that it is definitely possible to become as disillusioned working on open source as on closed.

that every time you make a cvs commit, it is reversed or complained about over some detail, or modified and interfered with such that the next stage of work, the following day, has cvs conflicts.

that designs and implementations are rejected EVERY single time because they were not thought of by those people you are supposed to be working with.

where working on a project turns into a fight for dominance, under the pretence of requiring [pettily stringent and specific] coding standards and limitations on designs and practices to the here, the now, the safe and stable.

the only difference between open source and closed source is that anyone can make a decision to code fork. i choose not to do so, with the consequence that the people who enjoyed working with me, and worked with me for their own reasons rather than being paid or forced to do so, have followed suit and are also no longer working on samba.

i urge you to learn from my difficult, bitter experiences, please.

Sure, human nature being what it is, I wouldn't expect major differences between open-source and closed-source projects. A similar incident happened to me when I tried to submit a patch to one of the window-manager projects; not only was it rejected, but it re-ignited an old flame war on their mailing list about user-interfaces.

But there's no point in being bitter. You do have to see things from the original developers' point-of-view: They've been working on the project for a long time, have many users that rely on it, and so they feel that they have to be conservative about making changes.

The real advantage of open-source is that you can start your own project, something that many programmers rarely get to do at their day jobs. Plus, you can work in an area where you have no prior experience.

DrCode, i _am_ one of the original developers of the NT Domains for Unix project. or, i was.