I’d like to take a break from boring you two readers of my blog about my experience with Linux and VMware, and take a moment to annoy you with a rant.  Diversity is the spice of life after all.

This little remonstration of mine is about the Manning Early Access Program (MEAP).  Well, specifically just  one book.  I’ve got my eye on a couple of other books available with MEAP to see how they pan out before considering the whole "early access" useless.  Anyway…

It’s been over a year ago that I "bought" a copy of the book NHibernate in Action.  I did so because I want a bit dissatisfied with the documentation for NHibernate 1.2, and thought that the book would help me.  I wasn’t an NHibernate virgin/noobie, but I did need some help with a couple of things, and I really didn’t have a large network of NHibernate masters to turn to for help.

I was disappointed when I saw that the book wasn’t in print yet.  Then I was happy to see that I could order the book, download a PDF, and the hardcopy would be sent to me when the book went to print.  Given that, in the summer of 2007 it was expected NHibernate in Action would be in print in late 2007, I thought it was reasonable to pay the money up front, and get the finished product mailed to me a couple of months later (I like to have hard copies of my books).

Well, here we are now, a year later.  As of September 9th, 2008 writing, summer of 2008, the softbound print date for NHibernate In Action is schedule for December, 2008.  Since I downloaded my PDF of the book in August of 2007, there has been a total of one updated PDF.

Now, I can understand when deadlines get missed, and stuff is late.  But, I think that, with a technology book, being over one year late is inexcusable.  A lot happens in one year in the programming space:  NHibernate 2.0 is now in Alpha.  What will be released first, NHibernate 2.0 or the printed copy of a book on NHibernate 1.2?  NHibernate 2.0 is now available.

I think the money spent on the PDF was worth it, but I honestly feel I got hosed on the cash I paid out for the hardcopy.

I just can’t help but feel that the extra money I paid to get a hardcopy of NHibernate in Action would probably have been better spent using the bills to make little origami swans, ducks, and platypuses and then floating them out to sea.

I will be watching a couple of other books of interest to me on MEAP.  But, in all honesty, I don’t think I will be buying any more books in this fashion until Manning Publications does something to restore my faith in their Early Access Program.  I still my get the PDF’s if I have an immediate need for them, but I can’t see purchasing a book in this manner anymore.

Updated August 25, 2008:  NHibernate 2.0 has been released

Updated September 9, 2008:  I see that the softbound print date has changed from November, 2008 to December, 2008.

Updated September 19, 2008:

Well, I just got the following e-mail from Manning publications:

Dear NHibernate in Action MEAP customer,

NHibernate in Action is almost ready! The last updates have been submitted,
the technical review is complete, and all chapters are in final production.
Some of you have been working with the MEAP for over a year, but we expect
the final ebook to be released in just over a month, with the print book to
follow shortly thereafter.

We appreciate your participation in the MEAP and especially all the valuable
feedback you provided in the Author Online forum. Your excellent comments
helped shape the final book.

To thank you for your patience, we’d like to offer you a $15 Manning Gift
Certificate to use for any print, ebook, or MEAP at Manning.com. Just enter
"_____" in the Promotional Code box when you check out. The Gift
Certificate will expire October 1, 2008.

Happy reading,

Manning Publications

(Note:  I removed the promotional code from the e-mail and added emphasis on the expiry date)

I guess this is some sort of attempt at placating us for unacceptable amount of time this book has taken.  Is it just me, or does anybody else see the irony in them thanking us for our patience with this book by telling us to hurry up and use the $15 Manning Gift Certificate?

"We’re a bit reluctant to use that because it will introduce more code into our code base that isn’t ours. Because it’s OSS, there’s no support, and if there was a bug in it, we’d have to maintain it ourselves. That being case, we’d rather just write our own code, because that way we know what is going on with it and can maintain it better. We don’t want to have to figure out somebody elses code."

There are variants of this argument, but the basic tenent is the same: we don’t want code from others (note that NHibernate here is just an example, this criteria seems to be invoked frequently when suggesting OSS products). For some reason "internal code" (code written by employees or contractors working for a company), is deemed more maintainable and supportable than "external code" (code from 3rd parties, such as OSS projects).

As a consultant, I find huge flaw in this argument for one very simple reason: my mere presence on a client site is a sign that they have some tolerance to code that "isn’t theirs". My typical engagements involve me coming in, writing code, and then moving on. I guess I’m kind of like an IT gyspy that way, but with out the gaudy fashion sense and the ability to place curses on those who cross me.

Anyway, the odds are VERY good that I will have to go through some sort of hand-off procedure at the end of my contract. In a perfect world, this would be an in depth session with an employee of the company, closing of any knowledge gaps of the code I was working on.

Typically, this involves explaining the architecture of my code, how to configure it, how to deploy it, etc. Even when I work on teams, there is still some sort of knowledge transfer about my specific parts of the code, with the more general architecture/configuration/deployment knowledge being disseminated over the course of the contract.

Realistically, this isn’t a very in depth or detailed process: usually it just involves some high level descriptions, nothing in detail. In fact, often this is usually just a formal acknowledgement that somebody has saddled with the responsibility of looking after my code now that I’m gone, and they know where to find the files. Formal documentation consists primarily of a README, or maybe a few pages in a Word document.

Realistically, the knowledge that has been passed on is seldom enough to quickly allow someone to solve even the most simple bug. So guess what: the code was created internally, but you now have to deal with all the issues that you used to exclude OSS projects:

•   There is no support – you will have to fix all bugs yourself.
•   At a very low level, you don’t know what is going on so you have to figure out the code yourself.

Maybe I’m biased, but in a lot of cases, I find OSS products easier to work with. Typically there are a lot of forums, mailing lists, and other users that I can ask questions of when I get stuck. Not so much with internal code. In many cases, even the people who wrote the code aren’t helpful, often for reasons as simple as the code was written a year ago and they haven’t used it since. In fact this very reason (failing memories) can make internal code more like external code over time.

Before we finish up, let’s just beat down the "…no support…" argument right now. With mininal effort, I can find commerical third-party support agreements for the bulk of the OSS products I currently use. And from what some would perceive to be reputable vendors – these aren’t fly by night organizations. As well, regardless of support or not you will need to maintain a bug regardless of external or internal code. You will have to assign someone to figure out what is being done with issue, and possible devise a work around – this is a constant no matter if the code is internal or external.

You don’t want external code? Odds are that you’ve already go some. Why start splitting hairs because is OSS?