Making Programs, Classes, and Source code available for free is a very helpful service to those who would wish to consume that content.

One has to select their audience, however- and know what to expect.

For quite some time I’ve helped with a Plugin called GriefPrevention. Initially, this was because I literally had nothing to do aside from my own personal projects, so I was able to dedicate a lot of time to making very significant changes to address a myriad of problems users of the plugin were having. In some ways, I started to treat it like “my job” (aside from my actual Job of, well, finding one). Most of my Time went into GriefPrevention. BASeCamp/SurvivalChests was abandoned; BASeBlock has been hardly edited since… etc.

A few months ago I got a quite spectacular Job; it involves working heavily with Postgres, C#, SQL, and Java, as well as some legacy libraries and stuff for good measure. Naturally that really only touches the surface of it But the important take-away is that I think it’s awesome. Some work can be a PITA (like making the same slightly complex changes to a query in 19 Jasper Reports) but it beats the hell out of any other Job I’ve had.

I didn’t expect it to be much different. But this rather opened my eyes. The difference between my real work and working on GriefPrevention is quite interesting. Working on GriefPrevention is OK. Fundamentally the plugin is relatively simple. Certainly less strenous than page-long stored procedures used in Reports, or Asynchronous Update Downloading and installation.

But what came as a shock was the fact that much of the time I [i]preferred[/i] to work on work tasks rather than GriefPrevention. I would address WOs instead of GP tickets. To make matters worse, I only get paid for time I put into one of those- take a guess which. Discussions with my co-workers is frequent; meetings take place to plan future additions and changes. The only discussions I’ve had about GriefPrevention are effectively with my inner Monologue since I’m for a number of reasons the only “active” developer (and in this case, “active” means maybe a few hours a week). I work for 8 to 12 hours typically for my Job- I basically go nuts until I’m mentally fatigued. This usually means the chance of any changes to any of my Open Source stuff is nil. It’s sad because I actually play BASeBlock and use BCSearch, and could list off a number of bugs and issues I’ve had with both, but simply don’t have time for them (heck, I didn’t even have time for them when I was unemployed!).

Interactions

Don’t get me wrong, another interesting part of GriefPrevention are it’s users. This is also one of the parts that makes me wonder occasionally why I bother. I reworked the code arduously over a period of a few weeks around the time I started to work on GP, to address some issues that many people had- per-world configurations and a more flexible configuration for controlling behaviour. Most people are reasonable happy with these changes. However those that are not are like a shrill siren piercing a dark night. In this case, right now, the biggest problems seem to be that Configurations are “complicated”, with any number of suggestions up to and including a complete rollback of the rules feature. I’ve been insulted, both passive aggressively and otherwise, both via PM and through project comments. And then been called “unprofessional” when I respond in kind (well, duh, I’m not getting paid to the requirement for professionalism is a bit less. I doubt I’d be particularly happy if a REAL customer cursed me out, but I’d still be obligated to help them in as professional a manner as possible- not only because I get paid for it but also because I put particular care into my products. Arguably, GriefPrevention is no exception, the difference is that it also represents a loss of my Spare Time. Many folks are reasonably understanding of this situation- Primarily my GP contributions center around Weekends, and most importantly around my own schedule. When an Open Source project starts to feel like more work than your actual Job, it starts to make you ask questions. Then when some people running Minecraft Servers act more entitled from Free Software than Entire Marina’s are of their Line of Business Software, the disillusionment leaves me with no choice but to laugh.

Pull Requests

With Distributed Version Systems such as git through github, anybody can fork a project, make changes, and request those changes be implemented into the main branch. My experience with GriefPrevention has not been promising. With stunning frequency, Pull Requests have basic functionality, make no changes to functionality, completely break functionality, perform basic code cleanup on the source, run IDE Wizards, remove dead code, add extraneous null checks, etc. Usually with any non-trivial PR I have to ask myself, “Are the changes in this PR more significant than what I will probably put into my next few commits?” Because merging a PR is typically a PITA since even if I only update once a week, sometimes PRs are based on a fork from several months ago and make no attempt to merge changes before a PR, leaving that instead to me. What I’d love to see is “Fixes X bug that you’ve been tracking down for Months” in the PRs. YES. Thank you, that is great, no matter the cost of attemtping to Merge it (at very least I can try to figure out the change and what caused the issue to begin with and fix it in the Working Copy, ascribing appropriate credit of course). But what do I see instead? “Ran Eclipse Wizards”, “Removed unused Variables”, “Organized Imports”. etc. Sometimes I can find an ACTUAL fix, but it requires poring over the File Changes in that pull or it’s commits searching for such significance. And then it comes to light that effectively the only useful changes are moving some lines of code so that they execute after some other portion designed to null check. Then I discover that an equal or greater “fix” has been applied to the master branch since, making those “fixes” useless, and even where they aren’t useless, I would have to include all those other changes for them to be added.

If anybody wanting to make PRs against GriefPrevention is reading this, DO NOT EVER run any IDE cleanup wizards on the code before issuing a PR. Your PR WILL need to be merged against a later version after more commits and using a wizard WILL touch every file, meaning that you will force a conflict that requires resolution. I’d be all for merging a change to fix some critical bug occurring because recent commits made a change to the same file. Not so much when the PR touches every single file to sort the imports list at the top of the file, thus forcing a merge conflict with changes that occurred since.