https://RustRocket.rs -- Cloud Monk Losang Jinpa, Ph.D., MCSE / MCT, https://Rustaceans.rs, Full Stack Cloud Native Rust DevOps Engineer - Rocket Framework Rust Microservices on Kubernetes-AWS-Azure-GCP

Return to Cloud Monk's Package Manager Book, Cloud Monk's Books (DevOps for 20 Languages by Cloud Monk and Functional Programming Compare and Contrast 10 Languages by Cloud Monk), Cloud Monk Library, Cloud Monk, Markdown

Leanpub is the combination of two things: a powerful ebook and course writing platform, and an online storefront where you can buy our authors' ebooks and courses.

By combining a simple and elegant writing and publishing workflow with a store focused on selling in-progress and completed ebooks and online courses, Leanpub is more than the sum of its parts, making it easy for authors to publish updated versions of their ebooks and courses for all of their readers, amongst other things.

Leanpub's self-published authors earn a high percentage of royalties: 80% on every sale. This is why we show you how much the author is going to earn when you're choosing what price to pay. With our “variable pricing” model, you decide how much you're going to spend, and how much the author is going to get.

If you'd like to read more about what we're up to, here's a link to Leanpub cofounder & CEO Peter Armstrong's manifesto and book on Lean Publishing.

If you're thinking of buying a Leanpub book and you have some questions, check out our our Reader Help Center.

If you're thinking of writing a Leanpub book or course, please go here to create a one.

If you're ever looking for helpful resources, we've got a great Author Help Center. We've also got a friendly Author Forum, which you can join after you create your first book or course.

If you have any questions you can't find answers to, please feel free to email our friendly team at hello@leanpub.com any time.

Leanpub is a service provided by Ruboss Technology Corporation. Our mailing address is:

1321 Blanshard Street, Suite 301 Victoria, British Columbia, Canada V8W 0B6

Ruboss is a company incorporated in British Columbia, Canada. Our incorporation number is BC0792951.

We are based in Canada, but the EU has decided that all merchants need to charge VAT to EU customers. So, we have registered to charge and remit VAT under the VAT MOSS program. Our VAT identification number is: EU372002581.

Fair Use Source: https://leanpub.com/about

by Peter Armstrong, Co-founder, Leanpub

Last updated on February 17, 2013. The original version of this manifesto, written in 2010 and revised in early 2011, is archived here.

Lean Publishing is an attempt to solve the following problems, which are shared by authors and publishers:

• How do we make the best book?
• Will anybody care about the book?
• How will people find out about the book?
• When will the book be done?
• Will the book be released while it’s still relevant?
• How should we price the book?
• How do we produce ebooks that look good on all ebook readers?
• How do we do all this and still produce a great looking print book?
• Should we even make a print book?
• Do we really need to use Word?

“Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

This is an ambitious and inclusive definition. It’s also a mouthful. In this manifesto, we’ll unpack this definition, and consider each of the ideas in turn.

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

Why would you want to publish a book in-progress?

The fundamental reason is that a book is a startup: a risky, highly creative endeavor undertaken by a small team, with low probability of success. And if you undertake either a book or a startup in “stealth mode”, it’s very easy to create something that nobody wants. The best way to determine whether you’re building something that people do want is to show it to them.

There are four parallels to consider when comparing books and startups.

• Risk: There are market risks, technical risks and a very low probability of success.

Creative: Both writing a book and creating a startup are highly creative processes undertaken by one or a few people working closely together.

• Stealth: Historically it has taken about a year, often spent in isolation or “stealth mode”, to develop and release the first version.

• Funding: Historically, startups have been funded by VCs and authors have been funded by publishers, both of which are hit-driven businesses.

Let’s look at each in turn.

Doing a startup is a highly risky endeavor. There are market risks (is there a market for the product? will some other company beat us to market?) and technical risks (is the product even possible? will it be any good?). Together with all the other ways a startup can fail (founder issues! lawsuits!), these risks ensure, there is a very low probability of success: the standard calculation is that 10% of venture-backed startups succeed, 20% limp along, and 70% catastrophically fail. The founders take all these risks because of the potential for a huge payday and to change the world–this has been referred to as “changing the world, one million dollars at a time.”. Founders at Work and Paul Graham’s essays.

Writing a book has a similar set of risks. There are market risks (will anyone want to buy the book? will someone else write a similar book first?) and technical risks (do I have what it takes to finish a book? can I write a book that is entertaining and engaging?). The author takes these risks for the possibility of fame and fortune–albeit a much smaller fortune than can be acquired by building a successful startup.

All things considered, it’s completely unsurprising that the probability of success for both startups and books is so low.

There is a reason that there are no startups founded or books written by 100 people: doing anything creative with that number of people produces a product in which any brilliance is diluted. (This is the reason why the phrase “designed by committee” is not a compliment.)

A book or a startup is best created by 1 or 2 people, who are the authors or founders. You can create a book with 3 or 4 authors, but essentially all the great books have been written by one author. In fact, if you have more than 4 authors, you’re not even really producing a book–you’re really producing an anthology of individual essays. Similarly, a startup typically has 2 co-founders (Apple had Steve Jobs and Steve Wozniak, Microsoft had Bill Gates and Paul Allen, etc.). You can create a startup with 3 or more founders (BEA had three: B, E and A), but that’s the exception–and it’s extremely rare for any successful startups to have more than 4 founders.

There is actually an interesting, subtle difference between the ideal number of authors and founders: to achieve great results, it seems the ideal number of authors of a book is 1 and the ideal number of founders of a startup is 2. My personal take on the reason for the difference, having written two books and started one startup, is that writing a book is essentially the technical portion of creating a startup–a solitary endeavor which requires long periods of sustained thought. (Also, in writing, having one voice in the book is essential.) However, creating a startup is a more multi-dimensional activity: besides the solitary time spent at your computer creating the product, there are a vast number of activities (raising funds, reacting to the market, acquiring customers and evolving along with their needs, etc.) which are too much for almost all individuals to sustain over the time it takes to develop a product.

Startups have traditionally operated in secrecy from the moment of being founded until the “first customer ship” or “product launch.” In this time, the founders and the early employees rapidly and secretly build the product envisioned by the founders in order to get it to market before anyone else does. There has typically been very little outside feedback sought or received until the product is ready for beta testing, which is usually very shortly before its launch.

A similar situation exists for authors. Many authors will work on their manuscript in isolation until it is complete, before submitting it to publishers. Sometimes they seek an agent to market the completed manuscript to publishers. Alternatively, authors can submit book proposals to publishers, seeking a contract for a project before beginning serious writing. In both cases, the manuscript has little contact with its true customers–readers–before it is largely completed. Traditionally in the technical book space, only a handful of readers are brought in as reviewers before a book goes to press.

Typically, startup founders spend much of their stealth mode period not only in building the product, but also in raising money from angel investors (accredited wealthy individuals) or Venture Capitalists (VCs). While many startups are bootstrapped by the founders (either by their savings or by doing consulting on the side), the goal for almost all startup founders has been to get funded.

Similarly, the goal for most authors has been to get a publisher. Historically, publishers have been needed by authors not only because of their access to printing presses and distribution channels, but also as a source of funding. A publisher often pays an advance against royalties, which the author typically uses to replace some of the lost income that s/he would have earned during the time spent writing the book. Since the prospect of repaying an already-spent advance is distasteful, this typically gives the publisher a lot of leverage over the author in terms of the content of the book. This can be a good thing, since it motivates authors to actually finish their books as well as to listen to good suggestions from their development editors, but it also can lead to a book being finished prematurely or at a lower quality.

So, in both cases, the investors (angel / VC / publisher) end up having a significant effect over the startup or book that they are funding. This is entirely unsurprising, since people naturally want a sense of control over what they are buying. If you were a publisher and you had an author making what you felt were bad choices, chances are you’d have something to say too!

Because of the influence that investors in a startup or book have over the output, it helps to understand their goals. Both publishing and venture capital are hit-driven businesses.

VCs encourage their portfolio companies to swing for the fences, as they need the huge wins to make up for the majority of their portfolio companies that fail.

Similarly, publishers produce many books but get the bulk of their profits from only a handful. Once these books are developed and begin to be marketed, the publisher gets a better sense of which books (if any) have the potential to be breakout successes, and focus their marketing efforts on those ones. Since publishers want to produce hits, they tend to force all books to seek as wide an audience as possible. This presumably isn’t much of a problem for fiction, but it is a problem for technical books such as computer books, since it forces much introductory material (that the author doesn’t want to write) into books, in order to theoretically broaden the potential market for the book as much as possible. (Of course, the risk is that this material will bore and alienate some readers, but publishers seem willing to take this risk.) This doesn’t just apply to computer books: how many otherwise-decent business books about startups seem compelled to explain (badly) the history of Silicon Valley or who Marc Andreessen is?

When you consider these four factors together, the consequence is that it’s very easy to create something that nobody wants.

The usual outcome of the above is as follows: with a startup or a book, what typically happens is that the founders or authors get some money, lock themselves in a room and slave away to produce something targeted at a very broad market (it has to be a hit, remember?), which the market may or may not want. If they get the product slightly (or completely!) wrong the first time, the money (the advance or seed money) is mostly (or entirely!) gone and there’s not enough money left to buy the time to iterate enough times to actually produce a product that people want.

For the past few decades of startups, and much longer for books, the methodology outlined above has actually been the state of the art. VCs and publishers have used the models described above since there hasn’t been any credible alternative articulated until recently. VCs and publishers are many things, but stupid is usually not one of them. The above approach seemed to be the best process available.

After all, startups are hard – surely this kind and rate of failure is inevitable, right?

Maybe not.

Recently, the startup community has been energized by new ideas about how a startup should be done. This thinking originated in Steve Blank’s ideas about Customer Development, explained in his seminal (self-published!) book The Four Steps to the Epiphany.

Briefly, the concepts of Customer Development and the Lean Startup involve launching the product extremely early (so early that you’re embarrassed by it) and iterating rapidly in response to customer feedback. These iterations follow the OODA loop (Observe, Orient, Decide and Act) of USAF Colonel John Boyd, applied in close consultation with customers known as “earlyvangelists” who will be the early adopters of the product and who will evangelize it to others.

The Steve Blank and Eric Ries intellectual connection is more than the standard mentor relationship: Steve Blank actually funded IMVU, which Eric Ries was the CTO and co-founder of, on condition that Eric Ries take his class about Customer Development!

Since writing books and doing startups have so many parallels, understanding how the Lean Startup ideas apply to startups helps understand how the Lean Publishing process applies to writing and publishing books. So, Eric Ries’s and Steve Blank’s blogs and books are an excellent resource for all writers, not just for people doing startups. This is especially true since both Eric Ries and Steve Blank are excellent and entertaining writers.

The Lean Startup approach of doing Customer Development and getting meaningful feedback from early customers is very similar to the process of releasing a book very early in the writing process and getting meaningful feedback from readers. In both cases, if the Lean approach is done well, the startup or book will evolve in ways that are not necessarily planned from the outset. (This is similar to the concept of Agile software development, but the scope is actually broader in that the entire direction of the startup or book can change.)

Now that we’ve looked at the parallels between books and startups, seen how the startup metaphor for writing a book is instructive, and considered Lean Startup theory, we can continue understanding the definition of Lean Publishing.

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

Why are lightweight tools important? Simple: if the tools are “heavy” and cumbersome, there will be more friction in the process of releasing versions of a book. If you need to typeset every book version which is released, as well as getting approval from development and/or technical editors before releasing a version, it can take days or weeks between versions. The lighter and more automated the toolchain, the faster these releases are possible.

If the toolchain is fully automated, it is possible to release a new version of a book 5 minutes after the author is happy with it. This isn’t just possible in theory: this is what we do every day at Leanpub. And in the world of traditional publishing, leading publishers such as O’Reilly and The Pragmatic Programmers have built their own toolchains with similar goals. The Pragmatic Programmers, O’Reilly and Leanpub are discussed in the third chapter of this book: Practice.

The driving force behind this is the common recognition that a toolchain must be lightweight and automated for releasing books in-progress: if every version of an in-progress book needed to be manually typeset, the time and cost would be prohibitive – even with outsourcing.

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

This idea comes from the world of Open Source Software. Eric Raymond has explained the development process used by Linus Torvalds in developing the Linux operating system kernel as follows:

“Release early. Release often. And listen to your customers.”

As this fantastic essay explains, the idea is that rapid, sometimes daily, iterations on something as complex as a computer operating system kernel can occur was revolutionary. If it’s possible to do iterative development on something as difficult as rocket science, surely it is possible to do this with a book?

However, historically it has been extremely difficult to iterate on books: the only iterations are second and subsequent editions, and those editions only get produced for successful books. Primarily, this is an artifact of the fact that books were printed, put on trucks and sold in stores. With that workflow, it has obviously been very difficult to iterate on an unfinished or unsuccessful book, in a way that distributed these iterations to its readers.

Lean Publishing is based on the premise that the inability to iterate on a book is a historical problem which has been overcome by ebooks, provided that publishers are willing and able to generate versions via a lightweight process and to solve the update distribution problem.

So, Lean Publishing repurposes Eric Raymond’s idea for books as follows:

Publish early. Publish Often. And listen to your readers.

By publishing early you get your ideas out there. If no one cares, you find this out as quickly as possible, sparing yourself as much wasted effort as possible. In the startup community, this idea is called “fail fast”.

Furthermore, by publishing often, you build an authentic community, as your readers feel connected to the development of the book. This is the same effect as in Open Source software: Linux had an engaged community of developers since Linus released it early and often, whereas commercial software that is released as Open Source long after it is done–such as Sun’s OpenSolaris operating system–often fails to gain momentum and build a community.

Building a community of readers is essential, and not just for marketing purposes. Most importantly, you can listen to them.

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback,

Why is reader feedback important?

Well, how else will you know if what you are writing is understandable and enjoyable?

If you are oversimplifying your readers will tell you. If your writing is incomprehensible, your readers will tell you. With Flexible Rails,

Publishers know that reader feedback is essential, so they pay development editors to provide good quality reader feedback. In essence, the development editor is a professional proxy, or surrogate, for readers.

You know who else is good at providing reader feedback?

Readers.

Authors have always known this: this is why great writers often enlisted their peers to review their partially finished or finished manuscripts.

However, while these types of interactions were essentially mutual favors between authors, today normal readers often want to read in-progress books.

Why?

For non-fiction books such as computer programming books, readers will benefit from earlier access to the information. If the information is new and in demand, it can help readers’ careers immensely. Common knowledge is cheap knowledge: once something is understood well enough that the relevant material is contained in print books in stores, understanding it is not worth as much as when it was new and confusing.

For other types of books, readers benefit by enjoying a more authentic connection to the author and to fellow readers.

For fiction, the author can publish the work in serial. Writing in serial has merits and drawbacks, but the one thing it will help authors to do is to finish their books. We discuss serial fiction in more detail in the next chapter.

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

The concept of the pivot goes back to Eric Ries and Lean Startup theory. While the word “pivot” has now become a cliché, it does have meaning which should be examined for books.

“I want to introduce the concept of the pivot, the idea that successful startups change directions but stay grounded in what they’ve learned. They keep one foot in the past and place one foot in a new possible future. Over time, this pivoting may lead them far afield from their original vision, but if you look carefully, you’ll be able to detect common threads that link each iteration. By contrast, many unsuccessful startups simply jump outright from one vision to something completely different.” –Eric Ries, “Pivot, don’t jump to a new vision”

Similarly for books, if you just start a new book every time the writing bogs down you’ll never finish anything. But if you incorporate reader feedback and evolve your book accordingly, a much better book can result.

But how do you know when to stop pivoting? How do you know when you have the right book?

For a startup, the equivalent question is: How do you know if you have the right product?

Marc Andreessen answers this with the concept of “Product-Market Fit”:

The only thing that matters is getting to product/market fit.

Product/market fit means being in a good market with a product that can satisfy that market.

You can always feel when product/market fit isn’t happening. The customers aren’t quite getting value out of the product, word of mouth isn’t spreading, usage isn’t growing that fast, press reviews are kind of “blah”, the sales cycle takes too long, and lots of deals never close.

And you can always feel product/market fit when it’s happening. The customers are buying the product just as fast as you can make it – or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. You’re hiring sales and customer support staff as fast as you can. …

Lots of startups fail before product/market fit ever happens.

My contention, in fact, is that they fail because they never get to product/market fit.

…

When you get right down to it, you can ignore almost everything else.

–Marc Andreessen, “The Pmarca Guide to Startups, part 4: The only thing that matters”

This is the main benefit of publishing in-progress: getting to Product-Market Fit. The advance sales are just a nice bonus.

Once you have product-market fit for a book, it is a lot easier to build traction. This brings us to the last component of the definition of Lean Publishing.

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

Successful startups know that traction is the most important thing. What is traction? Early and growing success in a market, a foothold, progress, momentum.

How do you get traction? Well, as discussed, it helps to have the right product, for the right market, at the right time. So, somewhat circularly, having product-market fit helps you build traction. Equally circularly, in terms of books, some books are a lot easier to build traction around than others. Again, this comes down to product-market fit.

Using the Lean Publishing approach helps you gauge reaction to your book, improve it, and judge whether you have product-market fit before pouring lots of effort into marketing the book.

If you don’t have product-market fit, you can continue to pivot the book, or you can just kill it. Both are good outcomes, since you will minimize wasted effort.

If you do have product-market fit, then the Lean Publishing approach can also help you build traction.

Since the book is published in-progress, authentic, word-of-mouth (or word-of-tweet) buzz can build before it is even done. Your readers have Twitter followers and Facebook friends. Some of them even have blogs. It doesn’t take a Social Media Expert to tell you that’s a good thing, provided the book is good.

If you are a publisher, this is also the point where you do all the normal things you do to help a book build traction. The difference, is that using the Lean Publishing process means you are starting further ahead, with more product-market fit.”

Fair Use Source: https://leanpub.com/manifesto

“This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.”

• http://help.leanpub.com/en/articles/3788293-the-leanpub-faq
• http://help.leanpub.com/en/articles/4405350-leanpub-author-faq

• So many different incompatible implementation of Markdown (it is worse than the different incompatible versions of BASIC Programming Language in the 1980s) - https://github.com/markdown/markdown.github.com/wiki/Implementations

• https://www.adamhyde.net/whats-wrong-with-markdown - “Non-standardized formats suck! Markdown is good for limited use cases. Use it for README files on GitHub.”

• https://wincent.com/blog/markdown-sucks

• https://www.reddit.com/r/programming/comments/4dqad9/why_markdown_sucks/

• https://news.ycombinator.com/item?id=19744711 - Aardwolf said on April 25, 2019: “For me Markdown sucks because it ignores single newlines. Almost any place where I have to type markdown feels like it's plain text (typing a readme in an actual plain text editor, a git comment in vim, a plain text box like this one here in hacker news and reddit that also ignores newlines, …), and plain text is supposed to listen to your newlines. But markdown will happily turn your two things you put on separate lines into a single line, ruin source code or ascii art without adding special formatting, etc… It should wrap long lines, but should listen to explicit newlines. The simplest text editor can, and does, do that.”

• https://golifelog.com/posts/markdown-still-sucks-1636034939101 on 4 Nov 2021:
  • He says, “Now that I’ve written here (https://golifelog.com/posts/markdown-still-sucks-1636034939101) for over 300 days, I can confidently say that Markdown is not for me. In fact, I’ll go so far as to say if I had to use Markdown to write my newsletter, there would be no newsletter. Aside from learning the syntax, my biggest issue with Markdown is the lack of real-time formatting. I don’t like the idea that I have to wait to publish my article to see all the formatting. Oh, that’s how big H2 header is?? Nope, need to change it. Oh and I forgot the space after the “#” which you don’t need for other commands. I am a true target of the famed WYSWYG functionality.”

• https://www.slant.co/versus/1903/3448/~markdown_vs_dokuwiki

• https://github.com/tchapi/markdown-cheatsheet
• GitHub README.md
• https://commonmark.org
• https://github.com/commonmark/commonmark-spec/wiki/List-of-CommonMark-Implementations