hating to love it

Posted 6 Sep 2000 at 14:02 UTC by bownie Share This

Does a disillusioned worker in the software industry make a useful contributor to a free software project? Can you keep it together at work so as to achieve personal goals in the evenings?

How many years in the workplace before you hear the sound of your idealism snapping? You arrive all guns blazing. You're all bright ideas, coding standards, shiny log books, fresh faced and full of gusto.

Several fights, several years, several disappointments down the line you begin to realise just how much inertia some organisations have. You're bitter, you're passed over, you're left behind. Get back to you shell scripts, laddo. Leave the real design for your bosses to do in the team meetings while you're busy staring out the window.

"But no, dammit, I want to be able to at least do it Right Some Time if I can't do it Right First Time! I'm going to write some free software and earn the respect of my peers, so see if I don't! Yeah! You corporate types can't keep me down! Yeah!" etc.

So you do it. You join a project. You're not stupid, you're not that ugly, you've got good ideas and have been looking for an outlet where they'll be appreciated. Finally you can do it. You lose that feeling of restlessness, you achieve some form of validation, you can prove yourself at last completely outside the scope of your job.

Perhaps without realising it you've now entered completely different philosophical territory. This leads to the question, does the free software project make the day job more bearable or is the day job there to provide a structure for the evening project? And then there's obvious corollary, Do Real Geeks Just Code?

Re: just code?, posted 6 Sep 2000 at 14:53 UTC by bagder » (Master)

    And then there's obvious corollary, Do Real Geeks Just Code?
Yes. We never do anything else.

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! :-)

Who owns the code?, posted 6 Sep 2000 at 14:59 UTC by logic » (Journeyer)

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.

Re: Who owns the code?, posted 6 Sep 2000 at 17:24 UTC by matt » (Journeyer)

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.

Hard to do it all day, posted 6 Sep 2000 at 17:28 UTC by matt » (Journeyer)

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.

Burnout and creativity not compatible, posted 6 Sep 2000 at 17:56 UTC by imp » (Master)

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.

Choosing the right project, posted 6 Sep 2000 at 20:03 UTC by DrCode » (Journeyer)

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.

open source, closed source - actually no differences?, posted 7 Sep 2000 at 06:01 UTC by lkcl » (Master)

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.

Re: Open Source/Closed Source, posted 7 Sep 2000 at 17:02 UTC by DrCode » (Journeyer)

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.

Re: Open Source / Closed Source, posted 12 Sep 2000 at 04:33 UTC by lkcl » (Master)

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

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page