I have the piece of software. It's free. It's open-source. But the tool I am ultimately interested in uses a proprietary library. And, given that I am researching, I do not know yet if the tool is going to raise interesting prospects or not. So I do not want to ask my advisor to purchase a $2,000 license for a library I might not use more than three weeks.

But there is a patch.

By patch I mean, a piece of code written by some user of the free, open-source software, to replace the proprietary, $2,000 at its cheapest library by a free, open-source library which provides a similar service.

So, really, the word "patch" does not really cover it.

Because I am still trying to figure out which dependencies are affected by the new piece of code, which parameters have to be changed, which "obvious" alterations stem from this addition.

I thought numerous times, "this is it, now, it's going to work".

But it's not working yet.

So I'm trying to fix it. On a Saturday. I don't usually work much on Saturday, unless there is an emergency. Fighting with stupid technical details that prevent me from implementing some promising idea is an emergency, mind you.

Especially given that the piece of software is rather bulky and that most of the changes I make take about twenty, twenty-five minutes to test.

I hate that!

I'm not afraid of being stuck in my research itself. If one of my ideas do not work out the way I was hoping, I can still gain something from the fact that it did not, and I am usually confident that I (or my advisor) will find some other direction in which to move on.

But technical details?

They stress the hell out of me.

Note that the fact that my advisor does very little hands-on work, and therefore has a very foggy idea of how demanding technical issues can be, and therefore does not value our technical fights very much, might not be totally irrelevant here.

Gaaah!