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 www.hentzenwerke.com.
You should also spend a few minutes at www.amazon.com,
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
etc.
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
etc.
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
etc.
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 OpenOffice.org 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 Amazon.com,
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 Amazon.com 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 OpenOffice.org, 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.
|
