My day job….
December 5th, 2006 by HenUsually I don’t blog about work; at most I’ll mention “saw something interesting at work today” etc, however I’m going to ignore that for once.
I get paid to do open source bugfixing. Which is very cool. On Tuesdays I do Commons, on Wednesdays I’m currently looking at fixing Standard Taglib bugs and on Friday I play with Maven Archiva. Monday and Thursdays are company time - which tends to be split between working on an internal app I’ve written, meetings and investigating open source issues that are deemed to be of interest in triage.
Which leads me to something that happens every day - triage. I spend 1 to 2 hours each day looking at issues reported the previous day, deciding whether they are unimportant (to non leading-edge customers), worth keeping an eye on or worth investigating. I look at a range of Apache projects, happily including many of the Commons components. The internal component I’ve created and maintain is the second half of the system for putting copies of the upstream issues in our internal JIRA and is written using lots of Commons components so that also has a nice overlap with other things I’m doing.
At some point being the build guy will want a chunk of time; though I can make that easier by release managing commons components that are ready. So another nice overlap.
That’s the aim for me - overlap. Achieve 2 goals with only 1 times the effort; or at least not 2 times the effort. That frees up the evenings and weekends, which at this time of year tends to be mostly family based (so I’m not doing as well at keeping a track of apache-wide mailing lists as I usually do
).
What are the downsides? There are a few.
I have to work hard to keep writing new software, so much time is spent bugfixing (which is a lot of Commons too) that the amount of time spent writing something new is low. This has diminished my time for osjava.org as that’s the stuff I often use when writing apps. It took a while to realize this and I only like writing apps I have an itch for. Currently the internal app and the commons nightly build are filling this void, but it’d be nice to come up with something else.
Bleeding edge developers don’t need and aren’t prepared to pay for support (my assumption). The people who need support are those who are using stable releases. Thus when I’m looking at Struts, I’m very focused on 1.2 and to a lesser extent 1.3; not the new 2.0 stuff. When I look at Axis (someone else specializes on this so I only look into it from time to time) it’s 1.x and not 2.x - err, Axis2 1.x. This is a problem for all developers - balancing stable and boring with unstable and interesting. Maven Archiva uses Webwork, so I’m hoping that playing, testing, documenting and hacking on that will give me a nice lead into Struts 2.
Balancing the overlap. If I fix a bug on work time, do I plaster “Fixed by SourceLabs!” all over the place on the issue? God no, how tacky. However, they are paying for me to spend 50% of my time hacking around on open source issues that I think are relevant. It’s obviously nice PR to be able to say I fixed something on work time - but it’s more important that when a customer looks at the issue they know that the money they’re paying helped fund the fix - and that they should keep on paying
I’ve one part of the solution so far, I attach a lot more patches, even if I’m going to apply them myself a short while later.
Concall meetings. Big companies love their conference calls…. Ugh. Fortunately the triage meetings each day are on IRC - much nicer.
Time to go play with my son after an afternoon of prodding Commons IO. Probably ought to send a link to this to the boss first
