Here’s the story since then:

- Symantec’s services division has been COMPLETELY dissolved. It’s all outsourced now.
- There’s a particular section of the non-services (they just train Partners) dedicated to “database move and merge” processes (not just renaming masters, but also migrating the catalog between OSes, including between Unix & Windows, both directions).
- They do actually run trainings, but not very often. In theory, I’m scheduled to attend one “the next time it happens” in the US. Hopefully by Q2 2012.
- I have a real (confidential) white paper, written by Alex Davies, documenting how to do that properly for NBU 6.5.3; that document is supposed to be paired with a utility to actually do some of the RDBMS work, but the version of the utility is tightly linked to the version of the embedded DB software (the brand of which is oddly escaping me right now) behind EMM, and there are wholly separate utilities for 6.x and 7.x.
- I have successfully performed, for a customer, an OS migration (Solaris to Windows) and *partial* database merge (I didn’t have the correct version of the utility; didn’t chance the volume manager merging manually with SQL statements) of two master servers. (Merged at 6.5.5, then updated to 7.1: note, don’t try to go straight to 7.1, go to 7.0 first, or else your old master server name will magically reappear about of EMM.)

If you’re interested in a professional capacity, let me know, and I can send you the contact info for the DB merge/migration training team.

I didn’t do a very good job of saying it, because I was (perhaps obviously) frustrated at the time, but I don’t mean to imply that all of the blame here falls upon you. Regardless of what features they choose to provide with whatever version level, the degree to which GNU’s software in general and their buildchain specifically are a painfully and rapidly moving target is precisely the sort of bullshit against which I was reacting here. You, as a developer, should not need to waste your time jumping through hoops to figure out how to make their tool build your software properly: it should Just Work… BUT, your end consumer, should open source software ever actually be useful to people who are not systems administrators by profession, should NEVER see an error message like this.

Some small degree of fault also lies with whoever was then maintaining the FreeBSD port for you package. There exists a completely functional structure within that API to assert that version 3.81 of GNU’s make was required for the package to build, and it’s that person’s fault (by virtue of oversight, I have to presume: she or he had probably already upgraded their own GNU buildchain and didn’t even see the error) for not specifying the dependency. You’re correct that you did all that you could by noting the issue in the INSTALL file… but in the real user world, I, not the maintainer of any FreeBSD package let alone this one, wasn’t stepping through every piece of software involved, I was just trying to upgrade (if memory serves) MPlayer, and FreeBSD’s package dependency tree crapped out with a meaningless (and incorrect) error message generated when it tried to build the software you wrote. Yes, I could and did ask Google for the answer, but it’s a functional failure of the entire system that I needed to.

I do take your point about open source software’s being a volunteer effort. Having previously contributed to the NetBSD project (not just monetarily, but also in kind) and currently doing the same sort of thing morally, if very differently in action, for the US Bartenders’ Guild, I’m on that same page with you. The fact remains, however, that a goal of open source software should be usability for real people, just as a goal for the events that the USBG organizes for bartenders oughtn’t be to give bartenders free booze, but to help them serve their customers.

Problems like this are exactly the sort of thing that steer those potential users (and potential contributors, whether monetarily or by volunteering their own time) away from OSS and back to commercial software. That, incidentally, is the Correct response to the rhetorical question with which I concluded the original post.

I can’t find nothing wrong about my one-line reply, it was plain informative, I really can’t see nothing offensive about that, I even bothered to quote the INSTALL file, while you could have easily found the solution to your problem with a quick Google search or in the archive.

I’ll even bother to mention that I myself spent *several* frustrating hours trying to fix the Makefile and make the misbehavior of make < 3.80 recognized, before to resign and realize that trying to fix compatibility with bogus/broken random versions of make was just vain and unreliable anyway, so we *wisely* decided to only support that version and even bothered to *clearly document that* in the INSTALL file.

As for the autoconf hell, I can’t see why it’s mentioned at all as in FFmpeg it’s refrained, a nice portable lovely hand-crafted configure script is delivered instead.

Also consider that free software projects are most of the time a volunteer-based effort, even if you’re not supposed to be grateful, at least you should take into account the time and effort that is delivered to you for free before to spit completely unfounded critics.

Regards.

I’d be happier if they’d actually fix the damn memory leaks in various official Apple UI libraries (stuff from the iTunes store I… well, don’t necessarily blame Apple for). Having to reboot one’s phone once every couple of weeks is really lame.

On the second point, stick around, because I’ve a complaint about that on the way.