Idea: publish a "Best of Raku" book containing CCR essays

[codesections]

This issue documents/elaborates on an IRC conversation I had the other day with @alabamenhu. (Er, ok two weeks ago…).

Here's the idea: as we go through the "collect" phase of collect-conserve-and-remaster, some group of rakoons pick out 15–30 blog posts that do a good job of telling the story of the Raku programming language. Then one or two of us write a brief introduction for each post, putting it in context and framing where Raku was as a language. My thought is that, when taken together, this essay collection could provide a good overview of the "spirit"/philosophy/culture of Raku.

As a model, I've been thinking of books like Coders at Work and The Best Software Writing, vol. 1 – that is, books that combine multiple viewpoints about a technical subject without themselves being hugely technical.

That last point is key to the project, at least as I'm imagining it. Despite the "Best of Raku" label I started this issue with, the goal would actually not be to select the best blog posts about Raku. Many excellent blog posts explain advanced usage topics and really ought to be read split-screen with a REPL. Those posts would gain nothing – and lose a lot – by being collected into a book. Conversely, less technical posts – the sort that could be read in bed without a laptop, or when traveling, or when the uninterrupted focus needed for coding just isn't an option – would gain a lot from being placed in context and read alongside similar essays offering a different perspective.

(To give you an idea of the sort of posts I'm imagining, think "State of the Onion")

In any event, the goal would be to collect the posts, write the connecting material, and turn it into both an EPUB and a physical book that we could self-publish. (That's a very breezy description, but the process I'm suggesting would be a lot of work, and I don't want to minimize that). My current thought is that we would freely distribute the ebook version and sell the print book at cost (though, in both cases, we'd be able to encourage readers to donate to Raku). Part of the reason I'm imagining not trying to profit from selling the book is that it just doesn't feel right in this situation: we're all in this together, after all. Also, the accounting would get significantly more complicated and we'd need to figure out how to divide profits with the various authors – much easier if there just aren't any profits.

(We would, of course, need to ensure that we only publish work when allowed to, either because the post was initially published under an open license, because the author agreed to the publication, or (ideally) both.)

As you can probably tell, this I have a lot of ideas in this area, but all of them are very fluid. I will be very interested to hear thoughts from other rakoons, especially those who have previous experience with publishing Raku books (@JJ?, @moritz? @ash? Others who are slipping my mind, I'm sure).

[alabamenhu]

Obviously, I think this is a great idea, and props to @codesections for codifying much of our discussion here.

FWIW, when I priced out some print-on-demand self-publish options, I found we could get a simple 100ish pg (US Letter or A4) book printed for USD $4.60ish each (+$1.5 for color, +$5 for hardcover), which would be extremely affordable for folks. Even jumping up to 200, the base only goes to $7.70 (+$3 for color, +$7 for hardcover).¹ I agree entirely that offering it at cost should be a given, with donations being requested that could go into the Raku Development Fund to support continued work on the language. After all, it would be designed as a community effort, so it make sense that donations would go back to support the community.

I'm actually probably even a bit more ambitious, as noted in my chat history. I think eventually such a project could spawn a Best of Raku YYYY (or Raku: YYYY in Review) series, where we curate annually some of the best blog posts or even presentations to turn them into a nice collection, maybe with some nice butterfly artwork, maybe an interesting foreword that talks about the progress made in Raku that year, and maybe information about the major conferences for the next year (if the dates are known at time of initial printing), etc. I'm old fashioned, but I know a lot of people like teh physical. For those that don't (or can't afford it), we could have a free-to-download PDF, as codesections notes.

In the meantime though, I think collecting some articles that tell the story of Raku is a fantastic idea. Add in some historical perspective intros/outros to them, and we've got the potential for a fantastic retrospective to ground us for the future.

I can definitely handle editing/laying out the book, etc, so that all folks would need is to get me the texts. The last steps would just be determing how to go about printing and handling payment/donations.

---

1. These reminds me I need to make Intl::Format::Currency …

[JJ]

With some experience on the self-publishing arena, the best option is no-down-payment Kindle Direct Publishing. Is print-as-you-go, you upload an ePub, and I already have the machinery (in Raku) for producing it from markdown sources. The editor (@alabamenhu ) creates an Amazon account, money goes to him. It's not going to be a lot, anyway, but if it is, one round on him the next physical conference.

[moritz]

Preamble

A book tends to be a pretty big project, and many attempts to write books fail.

This is why you should do some thorough planning and thinking upfront.

Thus, here comes a wall of text.

The Idea

I like the idea! I'd be happy to contribute something, though I'm not sure yet what exactly :-)

Experience

I've tried once to write a book about then Perl 6 with multiple authors;
in the end it fizzled out because some authors didn't deliver their chapters
(on time or at all), and nobody stepped up to do the annoying task of being
the project manager, annoying people until they delivered, or searched for
other authors to fill in the gaps.

So, if you want to publish a collection of essays as a book, you need one
person who feels responsible and is basically the project manager.

I've never tried to publish a book with multiple authors through a traditional publisher (technically, we had a publisher lined up for that Perl 6 book, but never got far enough to actually do it). No idea how much hassle that becomes, if every author needs to sign an agreement etc.

Audience and Narrative

You really need to think about who will be reading this book, and what they
will get out of it.

You should also try to estimate how many of such folks are out there.

This also colors the way you chose the title and a narrative. For example,
your audience could be people interested in the philosophy and the history
of Raku. There are likely a pretty limited number of people who would buy
and read such a book.

Or it could be a book talking about technically and socially ambitious,
self-organizing volunteer projects, using Raku as the example. There could be
way more people interested in such a book, though it might be harder
to reach them.

This narrative should be clear before anybody writes the first essay.

Motivations

If you write (or assemble) a book, you should be very clear about why you write it.

Some of the reasons I have written books in the past:

• I wanted to tell people about cool stuff that I finally understood (for example the parsing book)
• I thought there was a niche to fill, and the project could benefit from the book (Raku Fundamentals)
• There simply was no other explanation for the topic that I found understandable (Debian packaging).
• I wanted fame and wealth. Guess how well that worked out :-)
• Writing and publishing a book was on my Bucket List
• When a colleague asks about a certain topic, I can point them to a book I wrote about it (Python CI/CD, Debian packaging). This is actually pretty cool :-)

Whatever your motivations are, they are valid. Some sound more vain than
others, that's human nature. Be honest to yourself about it.

Once you know what your motivations are, ask yourself:

• How likely is it that you'll bring the book to a stage where it satisfies your motivations?
• Are there other approaches that have a higher chance of success?

Self-Publishing vs. Publisher

I've published three books with Apress so far.

In my experience, these are the tradeoffs of going with a publisher:

• You need to find a publisher
• You need to come up with a topic that the publisher likes
• You get a project manager
• You get a process determined by the publisher
• You get a technical reviewer
• You get copy editing
• You get cover design
• You get distribution
• You get a bit of marketing
• You get some input on the book title, subtitle, blurb etc.
• You get a schedule (on which you have some influence)
• You can get an advance (with Apress that's roughly related to the book pages you plan to write; assume around USD 500$ for 120...150 pages; this is a very rough guess)
• You earn much less per sold copy than when you go with self-publishing (assume 10%; you only get any of it once the advance is payed off from the royalties).
• It's a slow process.
• Updates after the publishing are only possible through new editions.

Contrast with self-publishing through LeanPub:

• Very OSS-friendly process:
  • You write your book in markdown, push to a git repo, get the resulting epub/mobi/pdf files in a shared dropbox folder (other options are available, iirc)
  • For each git push, you'll get a preview. Once you have decided to publish a version, you press a button, a few minutes later it's published
  • You can set the price yourself, and get around 80% of that as royalties
  • real-time insight into who many people buy a book
• you need to take care of your own cover design
• you need to take care of your blurb
• you need to take care of your copy editing
• you get a book website
• you get the option to create and hand out coupon codes for reduced or even free copies
• If you want a physical copy, leanpub can give you a print-ready PDF. You have to take care of the printing (or uploading to Amazon/whatever) yourself.
• You can sell unfinished versions of the ebook, buyers get all further updates for free
• After it's finished, you can still publish updates.

When going the self-publishing route, personally, I'd go with leanpub, though you could also do something like use bookdown and render the result in a gitlab or github CI pipeline.

Collaboration

If you do a book project with multiple authors, I recommend that you define
some ground rules. Of course, these can be discussed with the authors, but
you should start with some, just to avoid endless meta discussions.

These are ground rules I'd set, if I were the boss :-)

• There's a defined git repo where you push what you write.
• There's a pre-defined format in which you write things
• There's some kind of CI/CD where you can see the rendered result. Check it and fix markup errors yourself.
• If you have committed to writing a chapter / an essay, you have three months to write it. If it doesn't look ready, you'll get a reminder at the two, three and four months mark. If after four months (so, one month after you should have delivered) it doesn't look complete, I might decide to throw out the chapter. You can still publish it in your own blog.
• Every author can state how much copy editing they want on their contributions; if they don't, copy editing is done as desired.

[alabamenhu]

I was actually figuring I'd go with a Markdown → InDesign → PDF workflow. (technically, MD → XML → InDesign → PDF, but close enough). That can all be easily scripted: I'm admittedly a bit OCD with layout and so still want that extra bit of control in the InDesign stage :-)

I definitely understand the potential for delays on getting copytext in from contributors — that's why we were thinking that if it's a retrospective comprised of already-written articles, the workload would be substantially reduced such that an editor like me or codesections could handle more of the work.

[codesections]

Thanks, @moritz, that was super helpful! I've been thinking about what you said – in particular, the part about motivation. I agree that that's especially significant; here are the motives I've come up with so far, personally: (roughly in descending order of importance/increasing order of self-interest)

1. Identity formation: By working together to select and curate essays that capture the spirit/philosophy of Raku, the core group of editors and contributors will likely develop a much better sense of what Raku's philosophy actually is. That's one of those things that can be surprisingly hard to define, when you come at it directly. Of course, I have some ideas – even some that I feel strongly about – regarding which aspects of Raku are particularly special. But I think building up an extensional definition with a lot of different views on Raku would be an especially powerful way to build consensus on what we're all about.
2. Identity transmission: Unless something goes (badly!) wrong, any book should have many more readers than writers/editors; this book should be especially widely read within the Raku community. If the collected essays do a good job in capturing Raku, then reading the book will be a good way for community members to get a sense of the tone and goals of the language. This is less about educating members of the Raku community – if they've spent much time at all with the language, they presumably have some intuitive sense of what makes it worth pursuing. However, that sense isn't always easy to articulate; I'd hope that an essay collection can let people better articulate what draws them to Raku, both to themselves (motivation) and to others (outreach).
3. Attracting new users: I am not wildly optimistic that a book of Raku essays will be widely read outside of current users of the language. That said, I think that at least some people will be curious to see what Raku is about and want to start with a non-technical overview to decide whether the language is worth diving into. What's more, anyone drawn to Raku by a it's underlying philosophy/goals is likely to be exactly the sort of person who will be most helpful to Raku: If they start using Raku because they believe in the goals of the community, they are likely to be active participants in furthering our goals. (Conversely, they're unlikely to be people who join a community but disagree with its basic philosophy and set about changing things; this can be a real concern for rapidly growing languages like Raku).

[My last two motives are a bit more individual and may not be of relevance to others. But, as you said, it's good to get all our goals out on the table.]

4. Developing reputation: as a free software developer who works primarily in Raku, I would like to earn a reputation within the Raku community. I don't (yet!) have the depth of technical knowledge be able to add to the many excellent Raku books, but I've received positive feedback on a few blog posts and like the idea of being an editor of a book like this.
5. Learning about technical publishing: I don't yet feel that I have the technical background to write a book of my own. But I hope to someday, so the idea of learning the process at a time when I'm not responsible for all the content sounds very appealing.

[codesections]

I was actually figuring I'd go with a Markdown → InDesign → PDF workflow. (technically, MD → XML → InDesign → PDF, but close enough). That can all be easily scripted: I'm admittedly a bit OCD with layout and so still want that extra bit of control in the InDesign stage :-)

I don't have strong feelings on the exact workflow, but just to double check: A PDF wouldn't be our only output format, would it? In particular, I'd think we'd want some format that's more comfortable for reading on a kindle-like ereader (so, mobi and/or epub, pretty much).

[alabamenhu]

I was actually figuring I'd go with a Markdown → InDesign → PDF workflow. (technically, MD → XML → InDesign → PDF, but close enough). That can all be easily scripted: I'm admittedly a bit OCD with layout and so still want that extra bit of control in the InDesign stage :-)

I don't have strong feelings on the exact workflow, but just to double check: A PDF wouldn't be our only output format, would it? In particular, I'd think we'd want some format that's more comfortable for reading on a kindle-like ereader (so, mobi and/or epub, pretty much).

Let me edit that workflow.

Markdown → InDesign → ​^PDF/_EPUB → ProfSuccess :-)

InDesign can save out to either. Mobi is basically deprecated at this point as far as Amazon is considered. They prefer Word (blech), EPUB or KPF.

[codesections]

Mobi is basically deprecated at this point as far as Amazon is considered.

But if we're giving the ebook away, we wouldn't be able to distribute it through Amazon anyway, right? 70% of $0 is still $0, after all, and I didn't think they were OK with that.

[alabamenhu]

But if we're giving the ebook away, we wouldn't be able to distribute it through Amazon anyway, right? 70% of $0 is still $0, after all, and I didn't think they were OK with that.

The official minimum price with Amazon is $0.99 which is more than free but also super affordable. That said, it is possible to list it for free on other book platforms (e.g. Apple, etc), and Amazon has been known to price match it when notified of the fact.

In any case, I think we [c|sh]ould make it a policy to price it at the minimum possible for each storefront we put the book, and any profits earned would be directed to the RDF. As long as we're transparent about it, I don't think there's a problem there (morally at least. We wouldn't be able to incorporate anything with a CC NC license, but realistically the community is small enough we can probably ask for permission with an agreement that profits go to the RDF to allow publication at places that don't allow free distribution). You're the legal expert though so I'd leave that to you :-)

[JJ]

Maybe this would be a good project for Season of docs? Check it out https://developers.google.com/season-of-docs If awarded, someone would fund a professional editor, and volunteers would also get a stipend for their troubles.