![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Yesterday, I hit a gigantic tarball in my current Querki project. (I'm currently rewriting the underpinnings to be journal-based instead of conventionally relational, which should make the system *vastly* more reliable, and permit us to build powerful version control into it. Huge project, but the end result is going to be *sweet*.)
The details of the problem aren't too important: suffice it to say, I realized that one of the key libraries I was relying upon (Kryo) was missing a critical concept, and this was leading to my code that depended upon it getting more and more baroque, with some possible problems coming up that might be entirely unsolvable.
In traditional enterprise software, I might have "support" available to me -- that is, I could report the issue. If that got a friendly ear, my request for an enhancement might get into their issue-management system. And in a while -- a few months if I'm lucky, a couple of years if not -- I might get a good fix. That doesn't exactly work for me.
Fortunately, the library in question (like most of Querki's underpinning) was open source. Which meant that, in a few hours, I could figure out *precisely* what was going on, come up with a fix (enhancing the KryoSerializer shell library around Kryo with a new concept), fork the library, and get the solution up and running.
No, it's not "supported" by anybody, and I might wind up having to maintain my own fork if the owner of the shell library doesn't like my approach. But I managed to clear a major blocker in Querki by adding a major new feature to the underlying tool, in hours instead of months.
Really, having gotten used to a nearly-pure open-source environment for Querki, my patience for traditional closed-source software has gone *way* down. I've never been anywhere near so productive in the traditional world...
The details of the problem aren't too important: suffice it to say, I realized that one of the key libraries I was relying upon (Kryo) was missing a critical concept, and this was leading to my code that depended upon it getting more and more baroque, with some possible problems coming up that might be entirely unsolvable.
In traditional enterprise software, I might have "support" available to me -- that is, I could report the issue. If that got a friendly ear, my request for an enhancement might get into their issue-management system. And in a while -- a few months if I'm lucky, a couple of years if not -- I might get a good fix. That doesn't exactly work for me.
Fortunately, the library in question (like most of Querki's underpinning) was open source. Which meant that, in a few hours, I could figure out *precisely* what was going on, come up with a fix (enhancing the KryoSerializer shell library around Kryo with a new concept), fork the library, and get the solution up and running.
No, it's not "supported" by anybody, and I might wind up having to maintain my own fork if the owner of the shell library doesn't like my approach. But I managed to clear a major blocker in Querki by adding a major new feature to the underlying tool, in hours instead of months.
Really, having gotten used to a nearly-pure open-source environment for Querki, my patience for traditional closed-source software has gone *way* down. I've never been anywhere near so productive in the traditional world...