I'm really glad you got a chance to interview Andy. I went to visit with him a few months ago, and was so excited by what he had to say that I immediately invited him to keynote at our upcoming Open Source Conference in Monterey July 17-20.
He really is a very cool guy, with a great view of the future, and an incredibly engaging thinker. I went down to see him wanting to evangelize him not just to recreate the old Mac desktop on Linux, but to think about how the web, and web-based services, was changing what user interface means in delivering applications today, and discovered that he was way ahead of me.
Andy has so much to share...lots of great experience with a previous revolutionary product, lots of great ideas about the future, and a real passion for open source. I can't wait to see what he and his team come up with. There's a really good chance that we're going to see something that's a real advance, not just playing catchup to stuff that Andy was part of designing 15 years ago.
I'd talk frankly with your employer and the customer in question and see if you can get them to see that it's in their interest to have you work on the project on paid company time, AND to release the improved sources that result from your work.
I don't know what company you work for, but the benefits of being a "good open source citizen" are the same as the benefits for other community relations (environmental policy, social benefits for employees): by giving something back, you demonstrate that you're a good place to work, you raise your profile among the community of customers and potential employees, etc. Given how hard it is to find good people these days, I'd say that having a "good citizen" open source profile would be a great recruiting tool, worth a lot to any company in the computer business.
I've felt (and argued) for some time that one of the really big issues for the open source community is how to encourage participation in the open source community by people who use their products but don't necessarily think of themselves as part of that community.
This problem only gets worse for applications where you don't actually have to distribute software in order for it to be used (e.g. web search engines, "infoware applications" like Amazon or Yahoo, or other hosted applications.) In the old days, you had two options for getting your software to be used: get great at selling it (usually proprietary), or give it away. Now there's a third option: put it up with a web interface. And this third option doesn't require any software distribution, so we need to work harder at the social norms.
Well, Alex, I don't have any investors to please, since I started the company on a shoestring and built it up over the years by providing a service that people valued enough to pay for. But I do have a business to run, and I can tell you that if we had profit margins any leaner, we wouldn't be able to do some of the books we do. What's more, if our objective was to "maximize" profits, there are a lot of things we could do.
There's an analogy I like to use, to help anyone who has never run a business to understand the kinds of things you have to take care of: if you're going on a long trip, you need to watch the gas gauge, and you need to make sure that you fill up before you head out across Death Valley. This doesn't mean that you're going on a tour of gas stations (which is the mistake that a lot of businesses make, as they think only of profit, and not of providing a real service), but neither does it mean that you're some kind of capitalist pig for making sure that the car doesn't run out of gas.
Sounds like you are thinking that a feature is a bug. The cover glued along the sides of the spine is the famous "lay flat" binding I've been talking about. That's how it works.
The reason Programming Perl doesn't have it is that the book is too thick. You can only use RepKover up to a given spine width (and I forget the exact dimension.) Fortunately, the thicker books lie open pretty well anyway, except at the very front and very back.
Regarding the fact that you sometimes get a book that's not the latest printing...that's part of the inefficiency of the book inventory and distribution process. It's very hard to tell who has what printing, and very expensive to recall books every time you fix a few typos. Most publishers don't roll in any changes between major editions. At O'Reilly, we fix errata every time we reprint, which means that there is some version skew, but at least you have a good chance of getting one of the most recent printings.
Most of these postings have been thoughtful and interesting. This one seems to carry quite a bit of misinformation. It's the only one I feel I *have* to reply to (rather than wanting to reply to, to give more information.)
Let me take the points in order:
SGML vs. Framemaker: O'Reilly was pushing SGML before most of the world ever heard of it. We started the docbook effort in the late 80's, and have worked on it for the past ten years. That being said, we have a business to run, and a lot of the SGML tools just haven't cut it for producing books in a time and cost-effective manner. We found that we were delaying books a month or more to do them first in sgml, and then we had a format that authors couldn't update easily. With Frame, we could get the books out on time, and we could export them into formats that authors could easily update.
We have continued to push vendors to use SGML, and to develop better tools for SGML (and now xml), and are continually evaluating new ones as they come out. We convert from frame to sgml as needed, but we don't always use sgml as an entry format at this point.
I believe in using open standards, but even more, I believe in using what works, and in not being religious about that. I believe that over the long run, open is better, by an order of magnitude, but that doesn't mean that you don't need to mix and match. (I would lay odds that not even Red Hat and VA Systems use open source for their accounting systems, for instance.) Valuing openness doesn't mean being doctrinaire.
As to "despite many protests from people in the company they instead use framemaker", I think that a better description would have been "despite many protests from people in the company, they persisted in trying to do everything in sgml, until finally they compromised, and now use whatever tool is best for the job at hand." The order is completely reversed: we used homegrown sgml tools before we used frame, and we've continued to use and grow them (note the continued work on docbook) so that we can no longer use frame when they surpass it.
"There were also protests about the NT solution for web services." Damn right there were, and they started with me. But as I noted in my original response, I felt that if the people most closely involved felt they could do better with NT, I owed it to them to let them try. Meanwhile, we've continued to develop PACE (the Perl-based publishing system that we use for Web Review, perl.com, and xml.com) and use that heavily in other parts of the company.
That's something that people need to understand: how do you get good at doing books that answer real problems if you don't try to solve those problems yourselves? We try everything, and we try to figure out what works, and what doesn't. I wish we did more of that, not less.
And despite all the NT bashing that goes on in this group, there are advantages as well as disadvantages there. I like people who can understand that. (I was so heartened by seeing Miguel de Icaza, the architect of GNOME, learning everything he could from Dick Hardt (of ActiveState and Win32 Perl fame) about how Microsoft's object models work. You get better by studying everything.
"People had to fight tooth and nail to get Linux books published initially." What a load of BS! That's not just a misinterpretation, it's downright wrong. We published our first Linux books long before most of the people reading this posting had ever heard of Linux. We didn't do lots of books that said "Linux" on the cover because we already had books that covered the programs but said "UNIX" and we didn't see the need to re-issue them with the only addition being a new marketing spin.
There is one thing that *is* true, and it's something I still don't understand. Despite all the attention paid to Linux, Linux books haven't sold all that well up to now, at least relative to its market share. (Maybe it's all the good free online documentation.) Computer book retailers like SoftPro in Burlington MA make the same observation. We've emphasized open source technologies like Perl because people seem to buy more books, and that seemed to indicate a greater hunger for information! But this hasn't stopped us from doing any Linux books. (Actually, there's one we missed, due to a miscommunication with the editor, which was Troan's Linux Programming book.)
"rabid NT people in those hallowed halls seems like sacrilege." Get over it. One of the things I like to look for is passion and intelligence. I'll take a rabid NT hacker who knows his stuff over a second rate Linux hacker any day. The reason Linux is better than NT is because there are more great and rabid Linux people who like to share what they know than there are great and rabid NT people who can do the same. The culture of Linux is a culture of sharing, which makes it a more fun market to publish for, but at the end of the day, I want to help everyone make more out of their life with computers. And I find cool stuff everywhere. Linux, Perl, Web, PalmPilot, BeOS, Mac, you name it.
As Lao Tzu said:
"I find good people good, and I find bad people good, if I am good enough."
Find the good in whatever technology you need to use; cast out the bad, or try to improve it. But don't cast it out without looking at it. That's my guiding principle.
The binding we now use lays flat, just like spiral binding. Try it.
Incidentally, in our early years, we did use spiral binding, and polls told us that customers overwhelmingly preferred it, because it would lie flat.
Eventually, though, bookstores persuaded us to use more traditional bindings, and sales jumped more than 10x. So what customers say and what they do don't always match up.
But we always took this "lay flat" request very seriously, which is why we pay extra for the RepKover binding.
BTW, someone mentioned that one possible reason that one of the questioners said the bindings broke was that they didn't understand the way repkover looks. Unlike perfect binding, which glues the pages right to the spine, repkover glues the pages to a strip of cloth inside the book, and leaves a space between that and the actual spine. Sometimes this makes people think that the spine is broken...but this is actually a feature, the thing that lets the book lie open to a page without the pages flipping over.
In general, I agree with you. A lot of publishers put books out in hardcover (or add CDs) purely to justify a much higher price. And that price is disproportionate to the added cost.
That being said, the manufacturing cost is a relatively small part of the cost for any book, and hardcover does ncrease the cost significantly. Most publishers set the price as some multiple (in traditional publishing, at least in the old days, 6x, in computer book publishing, 15-20x) of the manufacturing cost. So if a paperback costs $2.50 to print and a hardback $3.50, you might expect the difference in price to be at most a few dollars, and then you find out it is $10 or $20 because of the multiplier.
A couple of provisos: even the most generous of publishers, who just wanted to offer hardcover as a service, would need to at least double the increase in cost, because the typical aggregate discount of 50% or more given to resellers means that the publisher will get only $1 for every $2 increase in price. What's more, the author royalty will be affected by that price increase, even though it has nothing to do with what's between the covers.
Even further, hardcovers take a lot longer to produce, and require you to inventory a lot more materials than paperback. So there are some hidden costs there as well.
When you look at all these factors, a price increase of $10 for hardcover over paperback is fairly typical. I'd imagine that you could get by with a $5 spread, but you'd be taking extra risk for benefits that were passed along entirely to the consumer.
Yes, the camel is the symbol of perl because we used it on the cover of the O'Reilly book. Larry asked for a camel because he thought that a camel was ugly but well-adapted to its environment. So the association was made by Larry, but because of the book.
When we first started putting animals on our books, the only books we published were hands-on books for hackers--or more specifically, for programmers, system administrators and power users who wanted to get under the hood of whatever program they were using.
Somewhere in there, we published our X books, which were targetted at corporate adoption as reference manuals. At the time, we weren't that well known, and the animals were a little too wierd for the suits, so we developed a more conventional look for the X books.
Now, we're so well known that the animals have cachet even with big companies. But over the years, we still realized that not all our books are the same, and we wanted the animal brand to represent a particular kind of book--a hands on book, by people on the front lines, for people who wish they could look over their shoulder.
So, over the years, we've tended to not use animals on books that aren't "how to" books. The first time I made that decision, it was for a Posix Reference Manual. It was a good book, but kind of dry, and I didn't think it represented the kind of book that people expected from us. So I decided it shouldn't have an animal so that people's expectations wouldn't be set wrong.
We've blown it a few times. For example, when we started publishing our Java series, we decided to create a new, somewhat tamer, look because, once again, we were thinking of that as a consistent series for corporate adoption. But as it turned out, we didn't need to do that (because even the corporations now think that the animals are cool). Ever since then, we've had furious debates internally about whether to switch back to the animals for the Java books, since they really are the same kind of hands-on books as our original UNIX books. As the company has evolved, we've done some variations as well--the Linux cowboy imagery, the lock and key engravings on security books, and so on.
We've also done some books--the Be reference manuals, for instance (BE, Inc.), and in those cases, we've used a non-animal look because those books were not solely our product, with our kind of approach.
Edie Freedman, the creative genius behind the animal brand, is worried about eventually running out of animals, but that isn't an issue yet.
The animals have become a powerful brand because they mean something: hands on books for hackers. To bring this back to Open Sources, it's a book of essays, not a hands-on book, and that's why we didn't put an animal on it.
Slashdot Mirror
He really is a very cool guy, with a great view of the future, and an incredibly engaging thinker. I went down to see him wanting to evangelize him not just to recreate the old Mac desktop on Linux, but to think about how the web, and web-based services, was changing what user interface means in delivering applications today, and discovered that he was way ahead of me.
Andy has so much to share...lots of great experience with a previous revolutionary product, lots of great ideas about the future, and a real passion for open source. I can't wait to see what he and his team come up with. There's a really good chance that we're going to see something that's a real advance, not just playing catchup to stuff that Andy was part of designing 15 years ago.
I'd talk frankly with your employer and the customer in question and see if you can get them to see that it's in their interest to have you work on the project on paid company time, AND to release the improved sources that result from your work.
I don't know what company you work for, but the benefits of being a "good open source citizen" are the same as the benefits for other community relations (environmental policy, social benefits for employees): by giving something back, you demonstrate that you're a good place to work, you raise your profile among the community of customers and potential employees, etc. Given how hard it is to find good people these days, I'd say that having a "good citizen" open source profile would be a great recruiting tool, worth a lot to any company in the computer business.
I've felt (and argued) for some time that one of the really big issues for the open source community is how to encourage participation in the open source community by people who use their products but don't necessarily think of themselves as part of that community.
This problem only gets worse for applications where you don't actually have to distribute software in order for it to be used (e.g. web search engines, "infoware applications" like Amazon or Yahoo, or other hosted applications.) In the old days, you had two options for getting your software to be used: get great at selling it (usually proprietary), or give it away. Now there's a third option: put it up with a web interface. And this third option doesn't require any software distribution, so we need to work harder at the social norms.
There's an analogy I like to use, to help anyone who has never run a business to understand the kinds of things you have to take care of: if you're going on a long trip, you need to watch the gas gauge, and you need to make sure that you fill up before you head out across Death Valley. This doesn't mean that you're going on a tour of gas stations (which is the mistake that a lot of businesses make, as they think only of profit, and not of providing a real service), but neither does it mean that you're some kind of capitalist pig for making sure that the car doesn't run out of gas.
The reason Programming Perl doesn't have it is that the book is too thick. You can only use RepKover up to a given spine width (and I forget the exact dimension.) Fortunately, the thicker books lie open pretty well anyway, except at the very front and very back.
Regarding the fact that you sometimes get a book that's not the latest printing...that's part of the inefficiency of the book inventory and distribution process. It's very hard to tell who has what printing, and very expensive to recall books every time you fix a few typos. Most publishers don't roll in any changes between major editions. At O'Reilly, we fix errata every time we reprint, which means that there is some version skew, but at least you have a good chance of getting one of the most recent printings.
Most of these postings have been thoughtful and interesting. This one seems to carry quite a bit of misinformation. It's the only one I feel I *have* to reply to (rather than wanting to reply to, to give more information.)
Let me take the points in order:
SGML vs. Framemaker: O'Reilly was pushing SGML before most of the world ever heard of it. We started the docbook effort in the late 80's, and have worked on it for the past ten years. That being said, we have a business to run, and a lot of the SGML tools just haven't cut it for producing books in a time and cost-effective manner. We found that we were delaying books a month or more to do them first in sgml, and then we had a format that authors couldn't update easily. With Frame, we could get the books out on time, and we could export them into formats that authors could easily update.
We have continued to push vendors to use SGML, and to develop better tools for SGML (and now xml), and are continually evaluating new ones as they come out. We convert from frame to sgml as needed, but we don't always use sgml as an entry format at this point.
I believe in using open standards, but even more, I believe in using what works, and in not being religious about that. I believe that over the long run, open is better, by an order of magnitude, but that doesn't mean that you don't need to mix and match. (I would lay odds that not even Red Hat and VA Systems use open source for their accounting systems, for instance.) Valuing openness doesn't mean being doctrinaire.
As to "despite many protests from people in the company they instead use framemaker", I think that a better description would have been "despite many protests from people in the company, they persisted in trying to do everything in sgml, until finally they compromised, and now use whatever tool is best for the job at hand." The order is completely reversed: we used homegrown sgml tools before we used frame, and we've continued to use and grow them (note the continued work on docbook) so that we can no longer use frame when they surpass it.
"There were also protests about the NT solution for web services." Damn right there were, and they started with me. But as I noted in my original response, I felt that if the people most closely involved felt they could do better with NT, I owed it to them to let them try. Meanwhile, we've continued to develop PACE (the Perl-based publishing system that we use for Web Review, perl.com, and xml.com) and use that heavily in other parts of the company.
That's something that people need to understand: how do you get good at doing books that answer real problems if you don't try to solve those problems yourselves? We try everything, and we try to figure out what works, and what doesn't. I wish we did more of that, not less.
And despite all the NT bashing that goes on in this group, there are advantages as well as disadvantages there. I like people who can understand that. (I was so heartened by seeing Miguel de Icaza, the architect of GNOME, learning everything he could from Dick Hardt (of ActiveState and Win32 Perl fame) about how Microsoft's object models work. You get better by studying everything.
"People had to fight tooth and nail to get Linux books published initially." What a load of BS! That's not just a misinterpretation, it's downright wrong. We published our first Linux books long before most of the people reading this posting had ever heard of Linux. We didn't do lots of books that said "Linux" on the cover because we already had books that covered the programs but said "UNIX" and we didn't see the need to re-issue them with the only addition being a new marketing spin.
There is one thing that *is* true, and it's something I still don't understand. Despite all the attention paid to Linux, Linux books haven't sold all that well up to now, at least relative to its market share. (Maybe it's all the good free online documentation.) Computer book retailers like SoftPro in Burlington MA make the same observation. We've emphasized open source technologies like Perl because people seem to buy more books, and that seemed to indicate a greater hunger for information! But this hasn't stopped us from doing any Linux books. (Actually, there's one we missed, due to a miscommunication with the editor, which was Troan's Linux Programming book.)
"rabid NT people in those hallowed halls seems like sacrilege." Get over it. One of the things I like to look for is passion and intelligence. I'll take a rabid NT hacker who knows his stuff over a second rate Linux hacker any day. The reason Linux is better than NT is because there are more great and rabid Linux people who like to share what they know than there are great and rabid NT people who can do the same. The culture of Linux is a culture of sharing, which makes it a more fun market to publish for, but at the end of the day, I want to help everyone make more out of their life with computers. And I find cool stuff everywhere. Linux, Perl, Web, PalmPilot, BeOS, Mac, you name it.
As Lao Tzu said:
"I find good people good, and I find bad people good, if I am good enough."
Find the good in whatever technology you need to use; cast out the bad, or try to improve it. But don't cast it out without looking at it. That's my guiding principle.
The binding we now use lays flat, just like spiral binding. Try it.
Incidentally, in our early years, we did use spiral binding, and polls told us that customers overwhelmingly preferred it, because it would lie flat.
Eventually, though, bookstores persuaded us to use more traditional bindings, and sales jumped more than 10x. So what customers say and what they do don't always match up.
But we always took this "lay flat" request very seriously, which is why we pay extra for the RepKover binding.
BTW, someone mentioned that one possible reason that one of the questioners said the bindings broke was that they didn't understand the way repkover looks. Unlike perfect binding, which glues the pages right to the spine, repkover glues the pages to a strip of cloth inside the book, and leaves a space between that and the actual spine.
Sometimes this makes people think that the spine is broken...but this is actually a feature, the thing that lets the book lie open to a page without the pages flipping over.
In general, I agree with you. A lot of publishers put books out in hardcover (or add CDs) purely to justify a much higher price. And that price is disproportionate to the added cost.
That being said, the manufacturing cost is a relatively small part of the cost for any book, and hardcover does ncrease the cost significantly. Most publishers set the price as some multiple (in traditional publishing, at least in the old days, 6x, in computer book publishing, 15-20x) of the manufacturing cost. So if a paperback costs $2.50 to print and a hardback $3.50, you might expect the difference in price to be at most a few dollars, and then you find out it is $10 or $20 because of the multiplier.
A couple of provisos: even the most generous of publishers, who just wanted to offer hardcover as a service, would need to at least double the increase in cost, because the typical aggregate discount of 50% or more given to resellers means that the publisher will get only $1 for every $2 increase in price. What's more, the author royalty will be affected by that price increase, even though it has nothing to do with what's between the covers.
Even further, hardcovers take a lot longer to produce, and require you to inventory a lot more materials than paperback. So there are some hidden costs there as well.
When you look at all these factors, a price increase of $10 for hardcover over paperback is fairly typical. I'd imagine that you could get by with a $5 spread, but you'd be taking extra risk for benefits that were passed along entirely to the consumer.
Yes, the camel is the symbol of perl because we used it on the cover of the O'Reilly book. Larry asked for a camel because he thought that a camel was ugly but well-adapted to its environment. So the association was made by Larry, but because of the book.
When we first started putting animals on our books, the only books we published were hands-on books for hackers--or more specifically, for programmers, system administrators and power users who wanted to get under the hood of whatever program they were using.
Somewhere in there, we published our X books, which were targetted at corporate adoption as reference manuals. At the time, we weren't that well known, and the animals were a little too wierd for the suits, so we developed a more conventional look for the X books.
Now, we're so well known that the animals have cachet even with big companies. But over the years, we still realized that not all our books are the same, and we wanted the animal brand to represent a particular kind of book--a hands on book, by people on the front lines, for people who wish they could look over their shoulder.
So, over the years, we've tended to not use animals on books that aren't "how to" books. The first time I made that decision, it was for a Posix Reference Manual. It was a good book, but kind of dry, and I didn't think it represented the kind of book that people expected from us. So I decided it shouldn't have an animal so that people's expectations wouldn't be set wrong.
We've blown it a few times. For example, when we started publishing our Java series, we decided to create a new, somewhat tamer, look because, once again, we were thinking of that as a consistent series for corporate adoption. But as it turned out, we didn't need to do that (because even the corporations now think that the animals are cool). Ever since then, we've had furious debates internally about whether to switch back to the animals for the Java books, since they really are the same kind of hands-on books as our original UNIX books. As the company has evolved, we've done some variations as well--the Linux cowboy imagery, the lock and key engravings on security books, and so on.
We've also done some books--the Be reference manuals, for instance (BE, Inc.), and in those cases, we've used a non-animal look because those books were not solely our product, with our kind of approach.
Edie Freedman, the creative genius behind the animal brand, is worried about eventually running out of animals, but that isn't an issue yet.
The animals have become a powerful brand because they mean something: hands on books for hackers.
To bring this back to Open Sources, it's a book of essays, not a hands-on book, and that's why we didn't put an animal on it.