Help  |   Contact Us  |   About Us  |   News and Events
Books, conferences, and other information about... Moving to Linux Switching to OOo Building Linux Apps Using Visual FoxPro
Buy      Download      Your Account      Catalog      Support      Conferences      Resources      Fun

Resources - Write/Edit for Hentzenwerke

Wanna write or edit a book? Here's all you need to know about how the publishing process works here.

Write/Edit for Hentzenwerke
About HWP

Our mission is to produce great books for serious software developers. Not simply books that are satisfactory, or OK, or good enough. We want the reader to hold up every single book of ours and say, “This is a GREAT book!”

For a similar perspective, look at the automobile industry. There are the mass market producers – GM and Ford and Toyota. They produce huge numbers of average cars. Some are pretty good (like the Corvette), while some really shouldn’t have ever been allowed on the road (like, well, you know which ones.) Most publishers are like GM, Ford and Toyota, building cars in large numbers for the guy next door who drives to work each day.

There are also the luxury automobile manufacturers – Mercedes, BMW, Jaguar. They produce cars for the mass market, but are always at the high end of the market, and everyone would love to have one of those machines in their driveway. There are a few publishers that fit this mold – O’Reilly come to mind immediately - and readers are rarely disappointed by their books.

And then there are the exotics – Ferrari, Maserati, Lamborghini. These automobiles are high performance, finely crafted automobiles. They are truly the great cars of the world. But they’re built for niche markets, and for serious drivers who demand great cars. We, too, produce high performance, finely crafted books for niche markets - for serious developers who demand great books. If you're not up to working on a book with the passion and zeal required to produce a GREAT book, then you'll want to move on along to another publisher.

Types of books we produce

The first thing you have to understand, before you can write or edit for HWP, is what type of books we publish. Our mission is to produce truly great books for serious software developers.

If you haven't done so already, wander through our catalog at You should also spend a few minutes at, and read the reviews of our books to get a feel of how our customers feel about what they buy. (Search for "Visual FoxPro" and then hunt for related titles, or look for a specific title from the list in our catalog.) We also welcome you to visit the various online forums that are related to the subjects covered by our books and ask around there.

Our titles cover a specific topic in depth, and are written by individuals who have significant day-to-day, on the job experience with the language or tool in question. We generally don't write for end-users, nor do we produce 'day and date' books - tomes that are released concurrently with the release of a product and thus can't cover the material in-depth or with demonstrated experience. If you page through a book of ours, you'll see that each page is packed - the text is dense, we don't pad the page count with double-spaced paragraphs, extra large fonts, fancy doo-dads in the margins, gratuitous or redundant screen shots, or a layout that is more style than substance.

Many authors wonder how many pages a book should be, or what it should cover. Most publishers set page counts for a book in order to meet a predetermined corporate standard - regardless of the subject or material to be covered. Our authors have one guiding principle - to write until they have covered the subject completely, and then to stop. It's as simple as that.

Similarly, tech editors wonder how far they should go in terms of making changes and corrections to the manuscript of the author they're working with. Again, it's simple – the tech editor should edit until he/she is happy with the manuscript - is it a book that they’d want to buy and read themselves?

As a result, you’ll find that each HWP book is written only with the reader in mind, not to fill out a catalog or match with other books in a corporate series.

What a HWP book looks like

HWP books all generally follow the same format, so that a reader of one book knows what to expect from another book. In addition, there are certain elements that I think belong in each book, so by using the same format, we make sure each book has them. Here's what you'll find, page by page, in a HWP book:

Title page: Contains the name of the book and the name(s) of the author(s).

Legal page: All the regular legal stuff that belongs in the front of the book, as well as contact information and identifying information about the book.

Dedication: Each author can dedicate the book as they wish.

Our Contract with the Reader: Where we describe what the reader can expect from the book and from HWP.

Acknowledgements: This is where the author(s) gets to thank (or blame!) their family, friends, and others who helped them out before, during and after the writing of the book.

About the Author(s): Biographies of each author and tech editor.

How to Download Files: A description of how to download the files that accompany the book.

List of Chapters: A one page synopsis of the chapters in the book.

Table of Contents: A detailed outline of each chapter, down to the first (and usually deeper) section head.

Introduction: Some authors like to write an introduction for their book. Others prefer to use Chapter One as the introduction. This is where the Introduction goes if there is one.

Body: Depending on the content of the book, an author may just write a series of chapters, which are numbering sequentially, like so:

Chapter 1
Chapter 2
Chapter 3
Chapter 4

In other cases, the content of the book lends itself to a more granular set of divisions. This is also true if there are a lot of chapters – seeing a list of 30 or 40 chapters is difficult for the reader to grok, and thus dividing the chapters into sections is helpful, like so:

Section I
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5

Section II
Chapter 6
Chapter 7
Chapter 8

In yet other cases, the author may want to divide the book into further pieces, and uses “Parts” to collect sections. This organization would look like this:

Part One

Section I
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5

Section II
Chapter 6
Chapter 7
Chapter 8

Part Two

Section III
Chapter 9
Chapter 10
Chapter 11

Appendix (one or more): Some authors include additional material that doesn't fit inside a chapter. An example would be a reference table of commands and functions; another would be a list of URLs or suggested readings.

Index: Keywords and the page number(s) that they're found on. Note that each book includes an ebook in CHM and/or PDF format, and thus, the reader can do a full text search across the entire contents.

HWP ebooks

The contents of each of our printed books are also available in electronic files. These files were initially in HTML Help (.CHM file) format, but in 2002 we’ve switched to the Adobe Acrobat (.PDF file) format due to a combination of security holes in the HTML Help Engine and limited deployment opportunities compared to PDFs (which are usable on a variety of operating systems. These ebook files are available for download from our website either through a email/password or username/password combination (if purchased directly from us) or via a keyword from the book (if purchased elsewhere.) These ebooks allow the user to bring the book ‘on the road’ with them, to a customer’s site, home, or vacation, without having to lug heavy books with them.

Customers can also order just the ebook version of a book; this is particularly attractive to overseas customers who don’t wish to pay large shipping charges and wait for weeks for the printed book to arrive.

The company

OK, now that you have an idea about our products, a word from our sponsor.

I run Hentzenwerke InterGalactic (the corporate parent of HWP) from my home office in Milwaukee, WI with the help of over 50 (to date) part-time staff, independent contractors and third-party vendors. Part-time staff helps me run the company, fulfill orders, answer email, and perform other administrative chores. I contract with authors, technical editors, copy editors, layout and graphic artists and indexers from all over the world to produce a final manuscript for a book. 

At the completion of this process, I send the manuscript to my printing company, who produces the printed copies, and stores the books in their warehouse. Orders arrive via snail mail, fax, carrier pigeon, email, and our online store at our website from individuals, groups, resellers and distributors all over the world. Once processed, orders are sent to the fulfillment center at the warehouse and books are shipped out to customers. OK, just kidding about the pigeons. The PETA people wouldn’t allow it.

At the same time, we ship a sizable quantity to our distributor, Independent Publishers Group in Chicago, who takes care of sales to online sites and stores all over the world.

The history of HWP - how we got here

I’m a mechanical engineer by training (BSME, Rose-Hulman Institute of Technology in Terre Haute, if you’re interested) and a software developer by trade, having written dBASE, FoxPro and Visual FoxPro applications as an independent developer since the early ‘80’s. I’d done a fair amount of writing during high school and college, sports for the local newspaper, school yearbook, that sort of thing, and frequently contributed to a variety of publications after graduation. In the early-90’s, I started writing a column for Pinnacle Publishing’s FoxTalk technical newsletter, and shortly thereafter wrote Rapid Application Development with FoxPro 2.6, a 125 page book published and marketed by Pinnacle.

A year later I wrote the introductory volume for Microsoft Visual FoxPro 3.0, Programming Visual FoxPro 3.0, for Ziff-Davis, the folks who at the time published PC Magazine. This 900 page behemoth became the standard text for anyone learning Visual FoxPro, and still sells an occasional copy nearly a decade later. A year after the release of the 3.0 book, I started looking for a publisher for a general purpose, language-independent guide to software development practices. Each of the publishers I talked to felt that there wasn’t enough sales potential in a book that didn’t talk about a specific tool or language. I ended up putting together my notes in book format, finding a printer, and publishing the book, the 1997 Developer’s Guide, myself. We sold direct – through advertising, trade shows and word of mouth, and moved several thousand copies around the world.

Because of my experience with the RAD book and the Ziff 3.0 book, Pinnacle asked me to edit their next series of FoxPro books, The Pros Talk Visual FoxPro. I pulled together four industry experts to write this series and four more folks to edit the works. Pinnacle took care of the marketing and publishing. The series was eventually combined into a single Microsoft Press volume.

Shortly thereafter, I approached Ziff about an update of the Visual FoxPro 3.0 book for the upcoming 5.0 release of Visual FoxPro; unfortunately, Microsoft’s marketing of the 3.0 product left something to be desired, and Ziff didn’t want to do a 5.0 book due to a predicted slowdown in sales. A few 5.0 books were eventually released, but to lukewarm response.

The situation with publishers didn’t seem to be improving as Visual FoxPro 6.0 entered alpha testing; seeing reader frustration with the attempts made at 5.0 books, and wanting to write a follow up for 6.0, I decided that I could self-publish a 6.0 update of my 3.0 book, and pulled together several other authors who had experienced the same reluctance of major publishers to commit to some sort of a 6.0 book.

I was able to get seven authors together to produce a collection of five books on Visual FoxPro 6.0; each book would cover a very specific area of VFP development. In addition, I would be updating my ’97 DevGuide for 1999. I formed a new company that would be responsible for the production, marketing, and order processing for all these titles. At the time (early 1998), Internet e-commerce was just starting to become mainstream; this meant we could market and sell our books both through our own website as well as though other online booksellers. Amazon, through whom we had sold a number of ’97 DevGuides, quickly became our biggest customer, as thousands of programmers immediately flocked to them as their number one resource for computer programming books.

Since that initial group of six, I’ve continued to add titles to our offerings, both on more Visual FoxPro titles as well as new topics, such as Microsoft Office Automation and Visual SourceSafe. Here’s our history and current intended schedule of publication:

1996 10 DevGuide ‘97 (Hentzen)
1998 11 Effective Techniques for Application Development with VFP (Booth/Sawyer)
  12 Hacker's Guide to VFP 6 (Granor/Roche)
1999 2 DevGuide '99 (Hentzen)
  4 Advanced Object Oriented Programming with VFP (Egger)
  5 Internet Applications with VFP 6 (Strahl)
  12 Fundamentals of VFP 6 (Hentzen)
2000 6 Microsoft Office Automation (Granor/Martin)
  7 1001 Things You Wanted To Know about VFP (Akins/Kramek/Schummer)
  9 Client/Server Programming with VFP and SQL Server (Urwiler/DeWitt/Levy/Koorhan)
  12 Creating VFP Apps with Visual FoxExpress (Archer/Jurden)
2001 3 VFP Certification Exam Study Guide (Winegarden/Delay)
  6 Essential SourceSafe (Roche)
  7 What's New in Visual FoxPro 7.0 (Granor/Hennig/McNeish)
2002 2 Debugging Visual FoxPro Applications (Folsom)
  4 Hacker’s Guide to VFP 7.0 (Granor/Roche/Hennig/Martin)
  4 The Visual FoxPro Report Writer: Pushing It To The Limits & Beyond (Pountney)
  5 Prechazime na Visual FoxPro 7.0 (What's New in Visual FoxPro 7.0 - translation localized for Czech Republic) (Granor/Hennig/McNeish)
  6 WebRAD: Building Database Websites with VFP/Web Connection (Chattaway/Pearson)
  8 DevGuide 3 (Hentzen)
  9 .NET for VFP Developers (McNeish)
  11 MegaFox: 1002 Things You Wanted to Know About Extending Visual FoxPro (Akins/Kramek/Schummer)
2003 3 What's New in Visual FoxPro 8.0 (Granor, Hennig)
  4 CrysDev: A Developer's Guide to Integrating Crystal Reports (Berntson)
5 Das Visual FoxPro 8.0 Update Buch (What's New in Visual FoxPro 8.0 - translation localized for Germany) (Granor/Hennig)
  8 OOoSwitch: 501 Things You Wanted to Know About Moving to from Microsoft Office (Granor)
  10 FoxTales: Behind the Scenes at Fox Software (Nietz)
  10 Painless Legacy FoxPro Applications on Modern Networks (Bourke)
  12 Linux Transfer for Network Administrators (Jang)
2004 3 Building Your Own Visual FoxPro Framework (Chazotte)
  4 Linux Transfer for Power Users (Hentzen)
  6 Deploying Visual FoxPro Solutions (Schummer)

In the early days, we sold books to the Visual FoxPro community. It wasn't difficult because I had a lot of visibility in the community - through online forums, writing, speaking, and other activities. In addition, my authors were all well-known in the community as well so pretty much everyone knew we were the folks with the best FoxPro books around. Over the years, that reputation has grown to the point where we became the sole source for Visual FoxPro books.

People bought from us either directly through our website, or through Amazon, with whom we started selling through in our early days. We also took special orders from bookstores until we developed a relationship with a wholesaler who handled that part of the trade for us.

However, in order to grow, we expanded our marketing past direct simply taking orders. Here's what we did.

Marketing, selling and distributing our books

Customers can purchase our books directly through our website, through online booksellers like, at their local bookstore, through resellers in other countries, and at trade shows where we have a booth.

As you examine the titles we have produced, you’ll see that we don’t produce “me-too” titles – each of our books covers a unique topic, often in a very narrow niche, and thus, often doesn’t really have a direct competitor. For example, there were over 20 books on Visual FoxPro 3.0, but most attempted to cover the entire product, and usually didn’t do justice to any area. There was one 1000 page book that addressed object orientation in VFP 3 (arguably the most important feature in 3.0) with just two sentences! By contrast, we published a 400+ page book that only covered Object Orientation in VFP.

As a result, customers who are interested in a particular topic usually are looking for a specific book from us, not just ‘any old book on’ a topic. This means that they often come looking for us on the Web, and either find us through an online store like Amazon, or find us directly.

I initially make the customer aware of a title through several means. First, I often select authors with high visibility in their subject area. This visibility includes regular participation in online forums, columns and regular contributions to industry publications, and speaking engagements at industry events. Their visibility attracts attention to their work, including the book. Next, I advertise regularly in the appropriate trade magazines and websites, which to date have been primarily oriented toward Visual FoxPro, but are starting to include other venues. We attend trade shows at the appropriate conferences, and hold promotions to generate interest and buzz.

I provide a great deal of information about our books on our website, in the form of chapter listings, very detailed table of contents, and a series of sample chapters from each book. In addition, we continually request happy readers to post comments on for potential customers to review.

Authors are expected to provide updates and errata as appropriate to the book; that material is posted on our website and encourage readers to visit for updates. By doing so, customers learn of new books that we have produced since their last purchase, as well as of books that they may not have been aware of if their purchase was not made directly from us.

I also do occasional email announcements to alert existing customers of new books and special promotions. We've accumulated a sizable mailing list, both because many of our customers buy directly from us, as well as the fact that many customers who do not buy directly from us still come to our website to download additional materials (and need to register to do so.) As a result, our emails are generally quite productive.

We have resellers in England, Germany and Australia. We entered into a distribution agreement with Independent Publisher's Group in late 2002 - they handle all North America bookstore accounts and some special reseller accounts overseas. We continue to expand our distribution network worldwide. We had a booth at the nation's primary book fair, Book Expo America in Los Angeles in May, 2003.

The sharp-eyed among you may wonder about our plans for distribution past the VFP world. Up to this point, most of our books have been focused primarily on Visual FoxPro, a market basically ignored by other publishers. Thus, we’ve had a lot of success because (1) VFP developers were starved for books, and (2) we’ve been virtually the only game in town. As we broaden our horizons to include non-VFP titles, there will be significantly more competition. What are our plans for dealing with this?

It’s a fair question, but one that we’ve considered ourselves. First of all, our cost structure is such that we don’t have to sell 10,000 or 20,000 books in order to make a profit or for our authors to make reasonable earnings. We as a company, and my authors individually, can be successful by selling just a few thousand books. (Details on how my authors do can be found in “the money” section under “The Publishing Process at HWP”.) Thus, given that our minimum goal is to sell in the ‘thousands’ of books, not the tens or hundreds of thousands, we have some latitude.

Second, we are still focused on very targeted books - titles that have a unique propostion for the reader, in new or specialized markets. However, the size of the new markets we’re getting into are significantly larger than the FoxPro market, and so we just need a small piece of those markets.

Third, the new markets we're entering (Crystal Reports and, for example) have sufficient general interest that bookstores are interested in stocking our titles. In order to support that interest, we're extremely aggressive with promotions - tabletop placements, advertising in book publications, email campaign through online retailers, and so on.

Together with our existing direct marketing, advertising in the appropriate places, and continued word of mouth capabilities, we think our marketing will be enough to move our non-VFP books in sufficient quantities to satisfy everyone involved.

Finally, don't forget that we’ve got a couple of competitive advantages that should be sustainable for the foreseeable future. I believe these are sustainable because of the entrenched attitudes at the major publishers. 

  • First, we sell direct, which results in higher margins, and a direct relationship with the customer. 

  • Next, because of our personal involvement in each and every book, we're able to produce consistently high quality books. 

  • Third, because of our cost structure, we can go after ‘small’ markets that are otherwise ignored. We regularly update our website with source code, errata and FAQs; an attractive feature to many readers but one that is often ignored by big publishers. 

  • And finally, we include an ebook file with every purchase; another attractive feature to most readers but a major structural decision that a big publisher is not likely to adopt easily. 

These factors make a HWP book a compelling purchase, and worth going the extra mile to obtain for enough people so that we can meet our sales goals.

And it’s just possible that a title of ours will generate sufficient legs so that it will move in even larger quantities. In short, the upside is there, but without the corresponding downside.

Author requirements

I expect that an author use the product, tool or technology that they are writing about in a full-time, professional basis, and that they have demonstrated expertise and mastery with the topic. Because our books cover highly technical material for advanced users, programmers and developers in an in-depth manner, I do not work with “professional authors” – individuals who use a tool or technology for the purpose of writing a book, and then put that tool aside. While that approach can work extremely well with some topics, particularly end-user software, doing so with highly technical topics results in shallow, superficial, incomplete books. A professional writer who doesn't use the tool regularly simply can't be knowledgeable enough to produce the in-depth material that exhibits real-world experience that I require.

I would expect an author to have, at the minimum, many hundreds of hours of day-to-day experience with the subject they're writing about. And, interestingly enough, this expectation doesn't change much with beta products - if you haven't lived with the beta day-in and day-out and done some significant work with it, then you're not ready to write for me.

Finally, I expect an author to support their book after having written it by participating in the appropriate online forums, providing errata and FAQs in response to reader requests, and generally promoting it when possible, such as via speaking engagements at user group meetings and conferences, and writing related articles in other venues.

You could click here for the scoop on becoming an author. But why don't you exhibit some patience and read the rest of this... you'll get there soon enough.

Editor requirements

A tech editor’s responsibility is two fold – to ensure that the material presented in the book is correct and complete, and to ensure that the source code provided with the book runs properly and matches what is presented in the book. 

Most tech editors also provide feedback about the approach and general content of the book as well, indeed, sometimes to what may appear as nearly an unhealthy degree! A tech editor for a single author book should have demonstrated competence with the material covered in the book; for a multiple author book, this requirement may be modified as each author will in essence provide a tech edit for the material of other’s authors.

Again, click here for the scoop on becoming a tech editor if you can't wait - but be sure to read this entire thing at some point.

What’s in it for you?

Well, there’s a monthly royalty check, for one thing. (Yes, we pay monthly, unlike some publishing houses that pay twice a year.) But an author should not be in it strictly for the money. Any individual who has the technical know-how to write a great book can make more money plying their trade rather than writing about it – period. A book will take hundreds of hours of direct writing time, plus more time involved in research, and even more time spent acquiring background. That same amount of time could invariably be better spent billing out at a consultant’s rate.

That said, there are significant advantages to writing (or editing) a book beyond money and the scratching of the natural “I want to write a book” itch. First, many authors feel a need to give back to the community from which they learned so much, and a book is a great medium to do that. Second, a book is a great way to develop visibility and additional technical credentials. Most of my authors and tech editors have garnered consulting projects (either as a full-time developer or on the side) as a result of readers contacting them. In addition, the credibility that comes from having written a great book allows the author or editor to increase their billing rates.

And there are two more things. Once an author has submitted their final manuscript, they (and the tech editor and post-print editor) can also get complimentary copies of every book we produce until the end of time.

And writing a book is just plain fun. Hard work, sure, but so is climbing a mountain, and that's why people strap on the boots.

What about tech editors? They, too, get a check every once in a while, a lifetime supply of books, and their name on the cover of the book. Anything else? I've found generally that tech editors often use the chance to tech a book in order to ensure they read every word of a book whose content they're interested in. And others like to be involved in the book publishing business - just not as an author. Editing, while full of its own special challenges, is definitely not as difficult as doing the original authoring. And some use technical editing as a way to break into the authoring business.

Back to Top

Help  |   Contact Us  |   Legal  |   Privacy  |   Copyright  |   Join Our Mailing List