Kinh tế học của việc viết sách kỹ thuật
(architectelevator.com)- Sách kỹ thuật có thể mang lại khoản tiền đáng kể từ nhuận bút, nhưng vì việc viết, sản xuất và quảng bá tốn hàng nghìn giờ nên đây là công việc khó bắt đầu nếu chỉ nhìn vào tiền
- Để kiếm 100.000 USD từ một cuốn sách, số tiền thu được trên mỗi bản khác nhau rất nhiều tùy phương thức phân phối; cần khoảng 6.000 bản eBook tự xuất bản, 10.000 bản in tự xuất bản, hoặc 25.000 bản qua xuất bản truyền thống
- Doanh số thực tế thường hạn chế, trừ một số sách bán dài hạn; theo tiêu chuẩn nhà xuất bản, bán 10.000 bản được xem là thành công, và sách phụ thuộc vào một công nghệ cụ thể có thể lỗi thời chỉ sau 12–18 tháng
- Gumroad, Leanpub, Amazon và nhà xuất bản truyền thống khác nhau về chia sẻ doanh thu, công cụ sản xuất, quyền kiểm soát, thương hiệu, phạm vi tiếp cận và hỗ trợ quảng bá, nên thu nhập và cách làm việc của tác giả cũng khác nhau
- Sách không chỉ tạo doanh thu bán trực tiếp mà còn ảnh hưởng đến tư vấn, workshop, diễn thuyết có phí và uy tín nghề nghiệp; đặc biệt với tư vấn viên độc lập, sách trở thành công cụ chứng minh chuyên môn
Khó viết sách kỹ thuật nếu chỉ vì tiền
- Nguyên tắc cơ bản áp dụng cho tác giả kỹ thuật, diễn giả và biên tập viên series là nếu người khác kiếm tiền thì tác giả cũng phải kiếm được tiền
- Nguyên tắc đầu tiên khi viết sách kỹ thuật là đừng viết vì mục đích kiếm tiền
- Tuy vậy, điều đó không có nghĩa là không thể kiếm được khoản thu nhập tốt từ sách kỹ thuật; quy mô doanh thu phụ thuộc rất lớn vào doanh số và phương thức phân phối
- Nhuận bút thường được phân loại là thu nhập thụ động, nhưng thực tế giống khoản đền bù trả chậm cho công sức viết, sản xuất và quảng bá trước đó hơn
- Các nền tảng như Leanpub, gửi e-mail mỗi khi có phát sinh bán sách, giúp tác giả cảm nhận ngay thông báo bán hàng
Cần bán bao nhiêu bản để kiếm 100.000 USD?
- Doanh số ước tính để kiếm USD 100,000 từ một cuốn sách thay đổi rất lớn tùy thu nhập trên mỗi bản
- eBook tự xuất bản: giá bán lẻ $20, nhuận bút $16, cần khoảng 6.000 bản
- Bản in tự xuất bản: giá bán lẻ $30, nhuận bút $10, cần khoảng 10.000 bản
- Sách kỹ thuật xuất bản truyền thống: giá bán lẻ $50, nhuận bút $4, cần khoảng 25.000 bản
- Dù có nhiều người theo dõi trên mạng xã hội, điều đó không tự động chuyển thành mua hàng; kết quả thực tế phụ thuộc vào tỷ lệ chuyển đổi
- Tỷ lệ chuyển đổi 2–5% trên website đã là mức rất tốt; nếu 100.000 người xem trang sách Leanpub và tệp độc giả mục tiêu phù hợp, khoảng 3.000 người có thể mua
- Trên Amazon, người dùng thường vào trang sách với ý định mua sẵn nên tỷ lệ chuyển đổi có thể cao hơn
Doanh số thực tế và tác động của bán dài hạn
- Một số sách kỹ thuật và kinh doanh nổi tiếng đạt doanh số lớn trong thời gian dài
- Enterprise Integration Patterns (2003): hơn 100.000 bản
- Team Topologies (2019): hơn 150.000 bản
- UML Distilled (1997): hơn 300.000 bản
- Design Patterns (1994): hơn 500.000 bản
- The Unicorn Project (2018): hơn 500.000 bản
- Tất cả các ví dụ này đều đi qua kênh xuất bản truyền thống, nhưng không có nghĩa là xuất bản truyền thống luôn bán được nhiều hơn
- Tác giả cho biết không biết trường hợp sách kỹ thuật tự xuất bản nào vượt 100.000 bản
- Theo tiêu chuẩn nhà xuất bản, bán 10.000 bản có thể được xem là thành công, và sau đó tác giả có thể được mời viết cuốn tiếp theo
- Trên Leanpub, một số tác giả công khai doanh số
- Software Architecture for Developers của Simon Brown đã bán gần 27.000 bản tính đến tháng 5/2024
- Con số này có thể bao gồm cả bản phát miễn phí
- Platform Strategy đứng thứ 19 trong danh sách bestseller mọi thời đại của Leanpub
Cách ước tính doanh số trên Amazon
- Amazon không công khai số bản bán ra, nhưng với sách trong khoảng 5 năm gần đây có thể ước tính doanh số sơ bộ bằng số lượng đánh giá trên Amazon.com
- Công thức kinh nghiệm là số bản bán = số đánh giá trên Amazon.com × 60
- Công thức này khá khớp với Team Topologies và The Software Architect Elevator, nhưng có thể đánh giá thấp doanh số của sách cũ
- Design Patterns có số đánh giá tương tự Team Topologies nhưng đã được bán lâu hơn nhiều
- Trước đây Amazon có thể còn nhỏ, hoặc ít người để lại đánh giá hơn
- Các edition khác nhau tích lũy đánh giá riêng, nên cần cộng gộp
- Amazon đôi khi cũng hiển thị khoảng doanh số hằng tháng cho một số sách
- The Software Architect Elevator: mức 100+
- Tidy First của Kent Beck, Building Microservices của Sam Newman: mức 250+
- Design Patterns: mức 500+
- System Design Interview: mức 1k+
- Designing Data-Intensive Applications của Martin Kleppmann: mức 2.5k+
Kinh tế học về vòng đời của sách
- Dù có thể kiếm 100.000 USD từ một cuốn sách, không nên kỳ vọng kiếm được trong vòng 1 năm
- Enterprise Integration Patterns mang lại hơn 100.000 USD cho mỗi tác giả, nhưng trong khoảng thời gian 20 năm
- Tuổi thọ của chủ đề sách ảnh hưởng rất lớn đến doanh thu
- EIP vẫn bán vài nghìn bản mỗi năm sau 20 năm xuất bản
- Sách về một công nghệ cụ thể có thể lỗi thời sau 12–18 tháng
- Một cách kéo dài tuổi thọ của sách là phát hành ấn bản 2, ấn bản 3
- 37 Things và Cloud Strategy bán ổn định trong khoảng 4 năm; 37 Things phát triển thành The Software Architect Elevator và tổng cộng bán tốt hơn 7 năm
Phần của tác giả theo từng kênh phân phối
- Tỷ lệ ước tính từ giá bán lẻ quay về cho tác giả khác nhau theo kênh
- Gumroad: khoảng 88%, đã tính phí thẻ tín dụng 2%
- Leanpub: 80%
- Amazon Kindle: 65% nếu giá dưới $10, 35% nếu từ $10 trở lên
- Amazon KDP: giá × 60% - chi phí in
- Nhà xuất bản truyền thống: khoảng 5–8%
- Gumroad chi trả 90% trừ phí thẻ tín dụng 2–3%
- Leanpub cung cấp tỷ lệ nhuận bút công bằng và hệ thống render sách; các tính năng bổ sung có phí hằng tháng nhưng có thể được miễn cho tác giả đã được xác minh
- Kindle eBook có tỷ lệ nhuận bút tốt dưới $10, nhưng giảm mạnh xuống 35% ở mức từ $10 trở lên, là mức của phần lớn sách kỹ thuật
- Với sách in KDP, tác giả chịu chi phí in sau khi lấy 60%
- Ví dụ tính toán cho sách kỹ thuật 300 trang là $30 × 60% - $5 = $13
- Cuối cùng tác giả kiếm khoảng 30–40% giá bán lẻ
- Nhà xuất bản truyền thống trả khoảng 15% doanh thu thuần; tính theo giá bán lẻ là khoảng 6%, tức khoảng $3 cho một cuốn sách $50
- Nếu có đồng tác giả, phần đó được chia đều nên thu nhập trên mỗi người giảm tương ứng
- Tỷ lệ nhuận bút audiobook và eBook của nhà xuất bản truyền thống khoảng 25%, và nhờ chi phí phân phối thấp, chúng có thể chiếm một nửa tấm séc nhuận bút
Cách kiếm thêm tiền từ sách
- Với nhiều tác giả độc lập, sách không phải sản phẩm bán trực tiếp mà là công cụ xây dựng thương hiệu
- Sách có thể giúp kéo về cơ hội kinh doanh và nâng đơn giá tư vấn
- Một workshop có phí có thể tạo doanh thu tương đương bán 1.000 bản sách
- Trong workshop cũng có thể phát sách miễn phí
- Diễn thuyết có phí cũng khả thi, nhưng phí diễn thuyết rất khác nhau và không thể mặc định là sẽ được trả
- Sự kiện trực tuyến có phí hoặc webinar có thể có lợi vì không tốn thời gian và chi phí di chuyển
- Nếu làm việc toàn thời gian, các lựa chọn tạo thêm doanh thu có thể bị hạn chế; một số nhà tuyển dụng có thể giới hạn việc tổ chức workshop
- Sách có thể giúp mở ra cơ hội phỏng vấn tuyển dụng nói chung, nhưng không giúp bạn vượt qua chính buổi phỏng vấn
- Với tư vấn viên, sách là tài liệu thể hiện chuyên môn và lời khuyên mà họ muốn bán
Định giá và sản phẩm số bổ sung
- Nhà xuất bản truyền thống thường định giá sách kỹ thuật ở mức $40–$80
- Với sách tự xuất bản, tác giả tự định giá; khoảng giá theo kinh nghiệm là khoảng $25–$30
- Nếu thuê biên tập viên và họa sĩ minh họa chuyên nghiệp, chất lượng sách tự xuất bản cũng có thể tiệm cận sách xuất bản truyền thống
- Ví dụ giá tối thiểu của bestseller trên Leanpub tương đối thấp
- Software Architecture for Developers: $15
- Art of Data Science: $20
- Event Storming: $9.99
- Một cuốn Leanpub giá $20 có thể mang lại thu nhập cho tác giả cao hơn một lượt bán Kindle giá $40
- Khi bắt đầu sách trên Leanpub, đặt giá ban đầu thấp ở $9.99 có thể là cách thưởng cho độc giả sớm
- Độc giả sớm nhận mọi bản cập nhật miễn phí
- Họ chấp nhận rủi ro sách chưa hoàn thiện và gánh nặng đọc bản thảo chưa biên tập
- Khi sách trưởng thành hơn thì tăng giá
- Một chiến lược giá hữu ích nhưng chưa được thử là sản phẩm số bổ sung
- Cung cấp workbook, template, toolkit, video dưới dạng mua thêm
- Dựa trên lời khuyên rằng khiến người mua hiện tại chi thêm $10 dễ hơn tìm một người mua hoàn toàn mới
Chu kỳ thanh toán và báo cáo
- Hầu như mọi kênh bán đều có thời gian giữ lại vì xử lý hoàn tiền hoặc phí thanh toán khoản nhỏ
- Gumroad: 7 ngày
- Leanpub: 60 ngày
- Amazon: 60 ngày
- Nhà xuất bản: 60–180 ngày
- Gumroad thanh toán vào cuối tuần sau khi bán, nên trường hợp xấu nhất phải chờ khoảng 13 ngày
- Leanpub giữ tiền cho đến khi hết thời hạn bảo đảm hoàn tiền 60 ngày
- Amazon cũng thanh toán theo lịch tương tự
- Nhà xuất bản truyền thống có chu kỳ thanh toán đa dạng, từ hằng tháng đến nửa năm một lần
- Leanpub cung cấp báo cáo trực tuyến tức thì, Amazon cũng cung cấp báo cáo trực tuyến hằng ngày với độ trễ nhỏ
- Nhà xuất bản gửi báo cáo PDF cùng với khoản thanh toán
Series sách và thu nhập của biên tập viên series
- Series sách của nhà xuất bản truyền thống là cách gom nhiều cuốn dưới một thương hiệu chung để thúc đẩy bán chéo
- Ví dụ tiêu biểu là Martin Fowler’s Signature Series của Pearson, và Enterprise Integration Patterns cũng thuộc series này
- Những cuốn dùng tiêu đề tương tự như “Up and Running” của O’Reilly hay “In Action” của Manning nhắm tới sub-brand và bán chéo, nhưng không phải series theo nghĩa có biên tập viên series
- Phần thông thường của biên tập viên series là 1% doanh thu thuần, khoảng 20 cent cho mỗi cuốn sách $50
- Khoản này không bị trừ từ phần của tác giả, mà được trả riêng dựa trên giả định series thúc đẩy doanh số
- Với một series thành công có nhiều cuốn vượt 50.000 hoặc 100.000 bản, 1% cũng có thể tích lũy đáng kể
- Để vượt 100.000 USD doanh thu từ series, cần bán khoảng 500.000 bản, và để trở thành biên tập viên series, trước hết phải là tác giả thành công
- Việc viết, sản xuất và quảng bá sách tốn hàng nghìn giờ, nên khó tính doanh thu sách thành thu nhập theo giờ
Chọn tự xuất bản hay xuất bản truyền thống
- Lựa chọn kênh xuất bản không chỉ là tỷ lệ nhuận bút mà còn là sự đánh đổi giữa quyền kiểm soát và mức độ hỗ trợ
- Tác giả mới có thể hưởng lợi từ uy tín và hình ảnh thương hiệu của nhà xuất bản truyền thống
- So sánh sơ bộ như sau
- Gumroad: tỷ lệ nhuận bút và quyền kiểm soát cao, nhưng công cụ, thương hiệu và hỗ trợ quảng bá yếu
- Leanpub: tỷ lệ nhuận bút và quyền kiểm soát cao, có công cụ tạo PDF và EPUB
- Amazon: phạm vi tiếp cận tốt và có báo cáo trực tuyến, nhưng có thời gian chờ khi thay đổi
- Nhà xuất bản truyền thống: tỷ lệ nhuận bút và quyền kiểm soát thấp, nhưng sản xuất, thương hiệu, phạm vi tiếp cận và hỗ trợ quảng bá mạnh
- Với Gumroad và Amazon, bạn phải tự mang đến một cuốn sách đã hoàn thiện
- Leanpub có thể render PDF từ script Markua hoặc cho phép viết trong trình duyệt
- Dù dùng Leanpub, bìa, minh họa, hiệu đính và dàn trang vẫn là trách nhiệm của tác giả
- Thuê chuyên gia biên tập và artwork có thể tốn $500 đến vài nghìn USD tùy quy mô và độ phức tạp của sách
- Trên Leanpub, có thể thay đổi nội dung và giá bất cứ lúc nào, đồng thời tạo coupon dùng một lần
- Amazon có thời gian chờ 72 giờ cho mỗi thay đổi, và trong thời gian này cũng không thể đặt bản sao dành cho tác giả
- Nhà xuất bản truyền thống lên lịch trước nhiều tháng theo pipeline sản xuất, và các thay đổi muộn thường không được hoan nghênh
- Nếu mục tiêu là tiếp cận tối đa độc giả thay vì tối đa doanh thu, nhà xuất bản truyền thống có thể là lựa chọn tốt hơn
IngramSpark và phân phối bản in
- IngramSpark là một trong những công ty in ấn và phân phối sách lớn nhất thế giới, có thể giúp sách tự xuất bản được đặt mua tại nhà sách và thư viện
- Cấu trúc thanh toán giống Kindle Direct: 60% giá bán lẻ - chi phí in
- “Expanded Distribution” của Kindle Direct cho phép sách xuất bản trên Amazon cũng được phân phối qua Ingram
- Ngược lại, sách xuất bản qua Ingram cũng có thể được bán trên Amazon
- Phân phối sách in đang có xu hướng hội tụ về hai gã khổng lồ là Amazon và Ingram
Lộ trình xuất bản có thể mở rộng theo từng bước
- Các kênh xuất bản không hoàn toàn loại trừ nhau
- Một cách tiến hành là bắt đầu bằng bài blog để nhận phản hồi nhanh, sau đó mở rộng lần lượt sang Leanpub, Kindle/KDP và nhà xuất bản truyền thống
- 37 Things đã đi theo lộ trình này và phát triển thành The Software Architect Elevator
- Trước đây, nhà xuất bản truyền thống thường không thích sách đã tự xuất bản, nhưng hiện nay điều đó đã thay đổi
- Nếu sách tự xuất bản đã tự bán tốt, nhà xuất bản sẽ cho rằng họ có thể đẩy doanh số lên cao hơn và đánh giá rủi ro là thấp
Marketing, quảng cáo và khuyến mãi
- Leanpub không mang lại nhiều traffic tự thân; tác giả phải tự kéo traffic đến
- Nguyên tắc cốt lõi của tự xuất bản là tự marketing
- Gumroad có thể giúp nhận nhiều traffic hơn, nhưng chi phí để được chú ý là lớn
- Amazon thực sự mang lại traffic thông qua xếp hạng tìm kiếm và đề xuất, có ảnh hưởng lớn đến doanh số
- Nhà xuất bản truyền thống có thể làm paid placement, liên kết chéo với các sách bán chạy khác, gửi sách cho influencer, v.v.
- Tên nhà xuất bản có thể tạo niềm tin và tăng tỷ lệ chuyển đổi
- Cũng có các hình thức quảng cáo theo từng nền tảng
- Leanpub có The Shelf
- Gumroad Discover lấy ít nhất 30% doanh số và tăng mức độ hiển thị
- Quảng cáo Amazon hoạt động bằng cách chọn keyword và đặt giá thầu, hiển thị với nhãn “sponsored”
- Chi phí nhấp chuột quảng cáo Amazon có thể dễ dàng lên tới $1
- Nếu kiếm $10 mỗi lượt bán và tỷ lệ chuyển đổi là 20%, bạn sẽ tốn $5 tiền quảng cáo để tạo ra một lượt bán
- Khi đó lợi nhuận giảm một nửa
- Cần xác định liệu đó có phải là lượt bán sẽ không xảy ra nếu không có quảng cáo hay không
- Người mua xem mô tả sách, bìa và review
- Goodreads được đánh giá là đáng tin hơn review Amazon; Amazon sở hữu Goodreads và hiển thị cả hai điểm số cùng nhau ở một số khu vực
- Ngoài quảng cáo trả phí, nhiều tác giả quảng bá sách qua blog, mạng xã hội và sự kiện
- Thuyết trình tại sự kiện có thể có hiệu quả yếu trong việc chuyển thành bán sách; nếu diễn thuyết ở nước ngoài chỉ bán được 5–10 cuốn, cần có phần thưởng khác tương xứng với thời gian bỏ ra
- Coupon của Leanpub là một tính năng khuyến mãi hữu ích
- Gắn coupon giảm 25% cho sách $20 có thể bán tốt hơn một cuốn sách có giá niêm yết $15
Khởi đầu rốt cuộc vẫn là viết một cuốn sách
- Mọi cấu trúc doanh thu và chiến lược phân phối chỉ áp dụng được sau khi trước hết hoàn thành cuốn sách
- Cách kiếm 100.000 USD từ sách kỹ thuật rốt cuộc là bán từng cuốn một
1 bình luận
Ý kiến trên Hacker News
Tôi đã xuất bản 4 cuốn sách kỹ thuật, và cũng đã hoàn thành bản thảo thứ năm, hiện đang trao đổi với các nhà xuất bản về việc phát hành
Tôi đã đọc nhiều bài tương tự, nhưng cảm thấy bài này thực tế và bao quát nhất
Đặc biệt, phần “bán được 10.000 bản là thành công, còn 2.000 bản có thể là điểm hòa vốn” cần được nhấn mạnh hơn nữa
Ngay cả nhiều sách lập trình xuất bản truyền thống cũng không vượt quá 2.000 bản, và tự xuất bản có khả năng còn khó hơn
Phần “Reality Check” của bài viết vẫn chưa đủ lạnh lùng. Tác giả chọn đưa ra các ví dụ sách kỹ thuật bán chạy, nhưng thực tế là phần lớn sách lập trình không đạt đến mốc 10.000 bản, vốn được xem là “bán chạy”, và nhiều cuốn thậm chí không vượt quá 2.000 bản
Tính kinh tế của việc viết sách kỹ thuật không tốt, và sẽ còn tệ hơn khi rác do LLM tạo ra tràn vào thị trường
Đừng viết để kiếm tiền; chỉ nên viết khi bạn thật sự muốn viết vì những lý do khác như sự nghiệp hay giáo dục
Có thể kiếm tiền từ sách kỹ thuật, nhưng con đường kiếm tiền không phải là “doanh số bán sách”; mà là bán vài cuốn sách để tạo độ tin cậy, rồi dẫn đến các buổi diễn thuyết, sau đó kết nối sang công việc tư vấn mới thực sự ra tiền
Một cuốn sách về kỹ nghệ phần mềm bán được 100.000 bản là trường hợp thật sự ngoại lệ, còn sách viết về một công nghệ cụ thể bán được 1.000 bản cũng có thể là kết quả khá phổ biến. Mà đó còn là tính trong vài năm
Không có tiền trong mảng này. Có một thị trường nhỏ cho các tác giả có thể đều đặn sản xuất nội dung kỹ thuật tạm ổn, kiểu các series như “...for Dummies”. Nếu 10 cuốn sách cùng lúc tạo tiền bản quyền thì so với thời gian bỏ ra có thể cũng ổn, nhưng nếu chỉ một hai cuốn thì có khả năng kiếm còn kém hơn một công việc lương tối thiểu
Dù vậy, điều đó không có nghĩa là không nên thử; nó gần với một sở thích của những người có điều muốn chia sẻ và kiếm chi phí sinh hoạt từ công việc chính. Hơn nữa, việc sao chép sách bất hợp pháp rất phổ biến, và điểm khó là ngay cả những người được bài viết giúp ích và có khả năng chi trả cũng đã quen với việc chia sẻ bản lậu miễn phí
Gần đây tôi đọc một cuốn sách kỹ thuật tệ hại, rõ ràng có vẻ do LLM tạo ra, nên đã liên hệ với nhà xuất bản; họ khẳng định rằng “đó chỉ là phong cách của tác giả và không dùng LLM”. Tất nhiên tôi cho rằng tất cả đều là lời nói dối
Có vẻ dù xuất bản sách kém chất lượng thì rốt cuộc vẫn có doanh thu
Sách của tôi bán được 91 bản trong 5 tháng, là sách nói về cách machine learning hoạt động. Tôi là tác giả vô danh, không có mạng xã hội, ngân sách quảng cáo bằng 0, nên chỉ dựa vào hiển thị tự nhiên trên Amazon
Tính kinh tế chắc chắn là không tốt, nhưng tôi không viết vì tiền. Lý do lớn hơn, mang tính hiện sinh hơn, là tôi muốn để lại lời nói của mình cho thế giới
Dù không bán được nhiều, sách vẫn có thể là công cụ tạo độ tin cậy cho tư vấn hoặc, tuy hơi khó chịu, cho các chiến dịch ‘influencer’
Năm 2020, sau khi đọc hết toàn bộ tài liệu FFmpeg, tôi đã viết một cuốn sách về FFmpeg
Tôi muốn học FFmpeg thật kỹ bằng cách thử dùng các chức năng mà tài liệu cung cấp vào chuyển đổi âm thanh và video thực tế; sau đó công bố thành quả dưới dạng mã nguồn mở như một phần mở rộng của tài liệu chính thức[0], rồi cũng đưa lên Kindle[1]
Trong 4 năm qua tôi đã bán được 743 cuốn và kiếm gần 2.000 USD. Dù vậy, lạ là mỗi lần nhận email thanh toán hằng tháng từ KDP, tôi lại thấy tự hào hơn cả tiền lương FAANG+ hằng tháng của mình
[0] https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook
[1] https://www.amazon.com/dp/B087GYV15Y/
Vì vậy tôi đã nghĩ: sao không dùng nó cho mọi việc biên tập video? Khó hơn UI, nhưng các lệnh đến năm 2050 vẫn sẽ giống như bây giờ, và cũng có thể script hóa
Tất nhiên mọi thứ đều có liên hệ với nhau, bạn cũng không tự viết ffmpeg, cũng không tạo ra công nghệ mã hóa video hay camera, nhưng nếu cứ xét theo kiểu đó thì sẽ không có điểm dừng
Như bài viết nói rất chính xác, viết sách là một ý tưởng hay vì nhiều lý do, nhưng tạo thu nhập không nằm trong số đó
Theo trải nghiệm cá nhân, vào thời hoàng kim của thị trường sách kỹ thuật 15–20 năm trước, viết một chương được trả 1.500 USD. Đó là công việc trong 2–3 tuần, và thù lao tốt hơn bài viết tạp chí vốn mất thời gian tương tự nhưng trả ít hơn một chút
Một cuốn sách có lẽ khoảng 25.000 USD, nhưng mất ít nhất 6 tháng
Tất nhiên đó là khoản thanh toán khi hoàn thành, và nếu sách thành công thì có lời hứa về tiền bản quyền sau này, nhưng trừ khi cực kỳ may mắn, chuyện đó hầu như không xảy ra
Dù vậy, nhận 2.500 USD theo giá trị ngày nay cho chưa đầy một tháng làm việc cũng không hoàn toàn tệ, và danh xưng tác giả đã xuất bản là một lợi thế khi kiếm việc tư vấn
Nhưng ngày nay, bản thân “hợp đồng viết tạp chí hay sách thực sự trả tiền” gần như đã biến mất
Tôi đã viết một giáo trình về cách dùng workstation âm thanh số tên Cubase, đồng thời đưa vào cả kiến thức nền như lý thuyết âm nhạc, khái niệm audio, mixing, effect, nhạc cụ, v.v.
Mất 2 năm để viết; trong đó 1 năm tôi dồn toàn bộ thời gian rảnh, nên tính theo toàn thời gian thì tương đương khoảng 9 tháng đến 1 năm làm việc.
Nhưng chẳng ai mua. Khoảng 2 năm sau, nhờ một người trong ngành tình cờ quảng bá giúp nên sách mới bắt đầu bán được.
Tôi đã liên tục cập nhật cho đến nay, bắt đầu từ Cubase 6 và giờ đã tới Cubase 13; sách bán khá ổn định, thường đem về khoảng 400 bảng doanh thu mỗi tháng. Không phải số tiền lớn, nhưng đủ trả một phần sinh hoạt phí, và mỗi khi Cubase ra phiên bản mới thì cũng đáng để bỏ trung bình 2 tuần cập nhật.
Tôi bán qua dịch vụ in theo yêu cầu của Amazon trên toàn thế giới. Trước đây tôi dùng Lulu, nhưng thực chất đó là cấu trúc thuê lại Amazon; Amazon cho lợi nhuận trên mỗi cuốn thấp hơn nhưng bán được gấp 3 lần Lulu. Sau đó Lulu ngừng hỗ trợ khổ sách tôi dùng, nên lựa chọn càng dễ hơn.
Tôi cũng đã ra một cuốn khác, nhưng cả giá lẫn doanh số đều nhỏ hơn. Việc làm sách khá thú vị nhưng khó, và gần với kiểu “làm sẵn khi có thời gian rảnh, rồi một ngày nào đó có thể thu hồi trong 1–2 năm”.
Nếu mỗi tháng 400 đô la thì tổng cộng khoảng 52.800 đô la, và đó là thù lao cho khoảng 1 năm làm việc.
Cũng kiếm được phần nào, nhưng rất có thể không bằng một năm làm việc toàn thời gian.
Viết sách kỹ thuật là một ý tưởng cực kỳ tệ, chỉ những người lý tưởng chủ nghĩa, khoác lác hoặc bị ám ảnh bởi hệ tư tưởng mới thử làm.
Sách của tôi ở đây:
https://hypermedia.systems
(https://hypermedia.systems/tricks-of-the-htmx-masters/#html-...)
Kiểm tra lại thì repository mà tôi đã star đã được lưu trữ, và gần đây có repository mới được đưa lên, nhưng tôi không tìm thấy phần giải thích. Tôi muốn biết liệu đó là cập nhật nội dung, refactor cách build sách, hay có thể nghe giải thích hoặc có link liên quan không.
Cũng có thể chỉ viết vì thế giới.
Nhiều người trong chúng ta có công việc chính thu nhập cao để nuôi sống bản thân, và việc viết tốt có thể làm như nghề tay trái.
Ưu điểm là không cần cố nhồi cho đủ số trang nên có thể viết súc tích, và cũng có thể nhận báo lỗi từ cộng đồng.
Tôi không coi thường những người kiếm tiền từ sách. Tôi tôn trọng mọi tác giả và biên tập viên. Chỉ là một số nhà xuất bản thì có thể biến đi cũng được.
Với nhiều người, cũng có những con đường khác không lấy tiền làm động lực. Cần nhớ lại đạo đức hacker ngày xưa.
Vì vậy tôi thấy điều đó phần nào giải thích vì sao phần lớn tài liệu về phát triển game nằm sau những cánh cửa đóng kín, hoặc sau quyền truy cập vault 500 đô la của GDC, hoặc chỉ còn là tri thức truyền miệng trong nội bộ ngành.
Tài liệu tốt vốn đã khó có được, tài liệu kỹ thuật còn khó hơn; sau những đợt crunch hơn 70 giờ mỗi tuần, tôi nghĩ gần như chẳng còn năng lượng để viết bằng đam mê nữa.
Động cơ lợi nhuận làm vẩn đục dòng nước. Herodotos, Newton, Darwin đã viết những điều đáng để suy nghĩ, và những thứ như vậy thúc đẩy xã hội tiến lên.
Ý tưởng rằng lòng tham là tốt và động cơ lợi nhuận là động lực cốt lõi là điều rất gần đây, và có thể có hại cho sự phát triển dài hạn của văn minh.
Nhìn vào open source thì thấy nó đã trở nên hỗn loạn vì thiếu tầng thanh toán. Và rồi người ta dùng chính mã open source đó để bootstrap LLM miễn phí.
Nói rằng không nên viết sách kỹ thuật vì tiền là đúng, nhưng đồng thời viết vì tiền cũng được.
Nếu tiếp cận sách như một việc kinh doanh, có đủ tiền để kiếm.
Có một bài tổng kết về việc vừa làm công việc toàn thời gian vừa làm sách và các việc liên quan như nghề phụ trong vài năm, kiếm được gần 400.000 đô la. Không phải tất cả đều là doanh thu bán sách trực tiếp; phần lớn đến từ những cơ hội mà cuốn sách mở ra.
Hơn nữa, nhờ cuốn sách tôi có thể tự bảo lãnh visa Mỹ và thẻ xanh cho mình, và hiệu ứng mở ra nhiều cơ hội nhờ đó còn chưa được tính vào.
Insight cốt lõi là sách là một sản phẩm. Phải viết sao cho hữu ích với ai đó. Sau khi đọc sách, độc giả có thể làm được việc hữu ích nào mà trước đây họ không làm được? Nó giúp họ đạt được điều họ muốn nhanh hơn như thế nào?
https://swizec.com/blog/5-years-of-books-and-courses-or-how-...
Tôi chia sẻ không phải để khoe, mà để khích lệ. Chúng ta cần nhiều cuốn sách sâu sắc và hữu ích hơn.
Nếu muốn đi theo con đường này, trước hết tôi rất khuyên nên đọc Write Useful Books. Ước gì cuốn đó đã có khi tôi bắt đầu.
http://writeusefulbooks.com/
Nhìn từ bên ngoài thì bạn có vẻ đã là người có vị thế khá vững.
Tôi không thích việc các indie dev influencer phớt lờ quán tính mà họ đã tích lũy rồi tweet rằng “ai cũng làm được”. Tôi không biết đủ để nói bạn có thuộc trường hợp đó hay không.
Tôi đã viết 9 cuốn sách kỹ thuật; trong đó 4 cuốn do nhà xuất bản lớn Apress phát hành, 5 cuốn tự xuất bản độc lập (https://wjgilmore.com/)
Trong số đó, Beginning PHP and MySQL đáng ngạc nhiên là đã tròn 20 năm kể từ khi xuất bản[1], và đã được dịch sang nhiều ngôn ngữ
Trước đây khá lâu, tôi cũng từng biên tập khoảng 70 cuốn ở Apress và vài cuốn ở Wiley. Tôi hiểu khá rõ ngành này, và dù vài năm qua không trực tiếp tham gia, tôi vẫn theo dõi rất sát
Lời khuyên là thế này. Nếu muốn viết sách thì hãy viết. Nhưng nếu bạn có một ham muốn bệnh hoạn là dành vô số thời gian để viết rồi sửa, đồng thời tự dằn vặt rằng mình ngu ngốc, thiếu sót và là một tác giả tệ hại, thì ít nhất hãy làm với khả năng rằng sẽ có người đọc và bạn cũng có thể kiếm được tiền
Để tạo khả năng thành công, hãy đóng gói cuốn sách theo nhiều cách. Những tổ hợp như bản in, bản in + video, bản in + video + tư vấn từng rất thành công với cá nhân tôi
Tôi khuyên nên dùng Leanpub.com để làm sách. Nó chuyển Markdown sang PDF, epub, v.v. và giúp tiết kiệm một lượng thời gian đau khổ khổng lồ. Tôi không có liên kết tiếp thị gì cả, chỉ nói vì nó thật sự hữu ích
Nếu muốn làm việc với nhà xuất bản, thì tính đến năm 2024 tôi không khuyến nghị, nhưng bạn phải chọn cực kỳ thận trọng. Hiện tôi nghĩ chỉ có hai nơi đáng cân nhắc làm việc cùng, và ngay cả trong trường hợp đó tôi cũng tuyệt đối sẽ không nhượng các quyền thông thường
[1] Từ ấn bản thứ năm trở đi, do bất đồng quan điểm với nhà xuất bản nên tên tôi đã bị bỏ khỏi sách
Không nên xem cuốn sách là đã kết thúc vào ngày xuất bản
Jeff Geerling đã nhiều lần phát miễn phí sách DevOps của mình, nhưng tôi vẫn trả tiền mua. Vì sau khi xuất bản anh ấy vẫn tiếp tục làm việc và cải thiện nó
Nếu nhiều tác giả chọn cách này hơn, chất lượng sẽ tăng lên
Tôi đặc biệt khuyên những ai quan tâm nên đọc Write Useful Books của Rob Fitzpatrick
https://www.amazon.com/Write-Useful-Books-recommendable-nonf...
Đây không hẳn là sách về sách kỹ thuật, nhưng chủ yếu nói về cách viết nonfiction đáng được giới thiệu, và một phần trong đó tất nhiên cũng áp dụng cho sách kỹ thuật
Nó có rất nhiều lời khuyên thực tế cần thiết để thật sự “làm” một cuốn sách, và chính cuốn này đã khiến tôi ít nhất cũng thử nhúng chân vào
Tôi đã viết nhiều cuốn sách. Cuốn đầu tiên rất tệ nhưng lại bán rất chạy
Vì khi đó chưa có Stack Overflow, các nền tảng hệ điều hành chưa đầu tư đủ vào hỗ trợ nhà phát triển, và tài liệu cũng rất tệ. Hiện giờ không điều nào trong số đó còn đúng nữa
Bản thân phương tiện sách in cũng đang suy thoái nhanh chóng. Những cuốn tôi viết về sau tốt hơn nhiều nhưng lại ngày càng bán ít hơn
Hiện tôi đang làm TikTok pha trộn nội dung quản lý dự án với các chủ đề tôi đang quan tâm, và có lẽ sẽ tiếp nối bằng một series bài giảng video dài trên YouTube
Có thể chưa phải tất cả đều được đưa lên, nhưng cuốn được ghi gần đây nhất có vẻ là Enterprise Android, một chủ đề ngách hơn nhiều so với các cuốn trước như Programming Android
Dù là cuốn sách hay hơn, nếu bản thân nhóm độc giả nhỏ hơn rất nhiều thì khó vượt qua khác biệt đó
Cá nhân tôi nghĩ cuốn sách đầu tiên cách đây 10 năm là tác phẩm hay nhất của mình, nhưng vì chủ đề quá hẹp nên nó bán ít hơn nhiều so với các cuốn sau
Ngoài ra, hiện nay có nhiều lập trình viên hơn trước rất nhiều. Có thể họ đọc sách ít hơn, nhưng nói rằng Stack Overflow và các nền tảng mã nguồn mở đã giết chết xuất bản sách kỹ thuật thì khá không chính xác
Có vẻ như bạn đang chiếu tình huống của mình lên toàn bộ thị trường. Mong bạn xem đây là một góc nhìn khác, không phải công kích
Tôi đã viết và xuất bản vài cuốn; cuốn tôi tự hào nhất lại bán ít nhất
https://www.amazon.com/dp/1484232275/ có điểm 5.0 trên Amazon và 20 đánh giá, đồng thời tôi cũng nhận được rất nhiều phản hồi tốt qua email, chat và trực tiếp
Chỉ là chủ đề thuộc một lĩnh vực quá hẹp, nên trên thực tế gần như chẳng có mấy người quan tâm :-)