- Supabase đã chọn mã nguồn mở ngay từ giai đoạn khởi nghiệp, và khi xây dựng sản phẩm một cách công khai, họ nhận được lợi ích về cộng đồng, tuyển dụng và mở rộng sản phẩm lớn hơn dự kiến
- Những lo ngại điển hình là bị chê chất lượng mã, lộ lỗ hổng bảo mật, và bị đối thủ sao chép, nhưng tính công khai cũng có thể dẫn đến nhiều đóng góp cải thiện và vòng lặp lặp lại nhanh hơn
- Trong tuyển dụng, đóng góp vào kho lưu trữ cho thấy mã thực tế và cách cộng tác của ứng viên, và Supabase chỉ bắt đầu tuyển dụng outbound sau khi đã tuyển được 32 lập trình viên
- Các tính năng dành cho nhóm người dùng nhỏ, tích hợp và adapter có thể do chính cộng đồng xây dựng, giúp mở rộng phạm vi sản phẩm và bù đắp giới hạn ưu tiên của đội ngũ nội bộ
- Năng lực phòng thủ của một công ty mã nguồn mở không đến từ việc giấu mã, mà đến từ việc tích lũy lâu dài tốc độ thực thi, thương hiệu, đội ngũ và cộng đồng
Vì sao Supabase chọn mã nguồn mở ngay từ đầu
- Supabase là mã nguồn mở từ ngày đầu tiên, và vì các nhà sáng lập vốn là người dùng lâu năm cũng như người ủng hộ các dự án công khai như PostgreSQL, Python, Bitcoin và React, nên vào thời điểm đó đây không phải là một quyết định quá khó khăn
- Trái với dự đoán rằng xây dựng doanh nghiệp một cách công khai sẽ tạo áp lực lớn, trong quá trình phát triển sản phẩm và công ty đã xuất hiện nhiều lợi thế bất ngờ
- Đây là kinh nghiệm của một công ty công cụ cho lập trình viên hoặc PaaS, nhưng nhiều nội dung cũng có thể áp dụng cho các công ty phần mềm nói chung
- Có ba nỗi lo lặp đi lặp lại thường ngăn cản việc chuyển sang mã nguồn mở
- Mọi người có thể chỉ trích mã lộn xộn hoặc chưa hoàn thiện
- Hacker có thể tìm ra và khai thác lỗ hổng bảo mật
- Đối thủ có thể đánh cắp sở hữu trí tuệ
Nỗi lo “mã của tôi quá tệ”
- Nỗi bất an về mã kém chất lượng phần lớn gần như là vấn đề của cái tôi, và nếu ai đó bỏ thời gian xem xét nó thì rất có thể họ đã tìm thấy trong đó điều gì đó đáng để theo đuổi
- Giống như câu chuyện Stone Soup, khi chia sẻ một ý tưởng hay với cộng đồng, người khác có thể đón nhận và cùng cải thiện nó
- Cộng đồng có thể refactor hoặc thay thế mã tệ, đồng thời đưa vào các hướng dẫn mới về chất lượng mã để quy trình đóng góp sau này cũng tốt hơn
- Những thành viên độc hại chỉ biết phàn nàn về mã mà không đề xuất cải thiện vốn dĩ không phải kiểu thành viên cộng đồng mà bạn muốn có
- Những người đóng góp mã nguồn mở thường có “nghĩa địa” dự án cũ của riêng mình, và đó trở thành thư viện ý tưởng và cách tiếp cận cho những ai muốn xây dựng thứ tương tự
- Ai đó có thể lấy cảm hứng từ một cách giải quyết vấn đề cụ thể
- Ít nhất, điều đó giúp giảm thời gian lặp lại cùng một sai lầm
- So với khả năng một dự án cũ làm hỏng danh tiếng, khả năng nó được dùng hữu ích hoặc hoàn toàn không bị chú ý là lớn hơn
Mã công khai và bảo mật
- Khi vận hành một giải pháp lưu trữ với mã công khai, nỗi sợ lớn nhất là tác nhân xấu đọc mã, tìm ra lỗ hổng và tấn công dịch vụ
- Theo kinh nghiệm của Supabase, câu nói trong Linus's law rằng “nếu có đủ nhiều con mắt, mọi bug đều trở nên nông” cũng áp dụng cho vấn đề bảo mật
- Ngay từ sớm, các nhà nghiên cứu bảo mật, thường là ẩn danh, đã giúp xem xét mã và nền tảng để tìm ra các vấn đề tiềm ẩn
- Nếu cung cấp SaaS, nên đặt hướng dẫn ngắn gọn tại
/.well-known/security.txtđể các nhà nghiên cứu thiện chí biết cách công bố các vấn đề tiềm ẩn - Bitcoin được nêu như một ví dụ cho thấy dự án công khai có thể an toàn hơn một codebase độc quyền
- Trong bài nói chuyện năm 2015, Andreas M. Antonopoulos nói rằng các hệ thống ngân hàng đóng có hệ miễn dịch phần mềm yếu
- Trong hệ thống đóng, các lỗ hổng bảo mật lớn có thể bị che giấu rất lâu, và khi cuối cùng bị khai thác thì thiệt hại có thể rất lớn
- Với giao thức mã nguồn mở như Bitcoin, lỗ hổng bảo mật hiện ra trước tất cả mọi người, exploit thường được phát hiện sớm và lặp lại nhiều lần trước khi được vá
- Một công ty phần mềm thành công có thể được xây dựng trong hơn 10 năm, nên về dài hạn, một hệ thống mã nguồn mở có thể tiến gần đến trạng thái an toàn hơn so với hệ thống độc quyền bí mật
- Trong thời điểm cạnh tranh tuyển dụng các kỹ sư bảo mật giỏi là cực kỳ khốc liệt, giá trị của việc rà soát công khai còn lớn hơn nữa
Lo ngại về đối thủ và sở hữu trí tuệ
- Trong phần mềm, ý tưởng thì rẻ, và giá trị gần như luôn được tạo ra từ khả năng thực thi ý tưởng đó
- Khi chia sẻ ý tưởng với thế giới, thay vì lo ai sẽ truy cập được vào codebase, bạn có thể tập trung vào việc lặp lại nhanh hơn
-
Xây dựng cộng đồng chuyên gia
- Để xây dựng một công ty thành công, cần thực thi tốt trong một thời gian dài, chẳng hạn 10 năm, và phát triển tệp khách hàng
- Trong cuộc đua đường dài này, lợi thế mà đối thủ có được nhờ nhìn vào codebase có thể không lớn nếu xét trên toàn bộ 10 năm
- Trong khoảng thời gian đó, codebase có khả năng sẽ được lặp lại và refactor nhiều lần
- Về lâu dài, cách chiến thắng là xây dựng một đội ngũ và cộng đồng giỏi nhất thế giới trong việc lặp lại và cải thiện giải pháp của chính mình
-
Chiến thắng trên thị trường
- Nếu một thị trường tiềm năng tổng thể (TAM) lớn và đang tăng trưởng thực sự đáng theo đuổi, thì khả năng đó là cuộc chơi người thắng ăn hết thường không cao
- Cần tìm ra phân khúc người dùng mà bạn có thể khiến họ ấn tượng trước tiên và lặp lại nhanh chóng
- Thời gian dành để tập trung vào đối thủ là thời gian có thể dùng để cải thiện sản phẩm hoặc đội ngũ
- Nếu đối thủ có thể fork dự án mã nguồn mở của bạn và ra mắt nhanh hơn, thì có lẽ bạn vốn đã được định sẵn sẽ thua trong cuộc cạnh tranh đó
- Trong phần mềm, IP và bằng sáng chế nổi tiếng là khó thực thi, nên bớt lo bảo vệ ý tưởng phần mềm bằng luật sư sẽ giúp tiết kiệm thời gian, tiền bạc và năng lượng tinh thần
- Doanh nghiệp có thể được bảo vệ tốt hơn bằng cách trở thành bên triển khai ý tưởng phần mềm đó tốt nhất thế giới
-
Cạnh tranh với cloud ở giai đoạn sau
- Khi dự án đạt quy mô đáng kể, bạn có thể phải đối mặt với tình huống các nhà cung cấp cloud lớn như Elastic hay Mongo cung cấp sản phẩm đó với mô hình phân phối mạnh hơn
- Vấn đề lớn nhất của một công ty mới bắt đầu là trước tiên phải đi được đến mốc đó
- Nếu AWS đủ quan tâm để rút tài nguyên từ một trong những dòng sản phẩm trị giá hàng tỷ đô của họ nhằm cạnh tranh với bạn bằng một sản phẩm lưu trữ, thì bạn đã làm rất tốt rồi
- Cách phản ứng mang tính xây dựng hơn là xác định trước những lĩnh vực mà bạn có thể dẫn trước bất kỳ ai trong cạnh tranh
- Nhiều nhà cung cấp cloud thường có trải nghiệm lập trình viên (DX) không tốt, nên bạn có thể biến DX thành năng lực cốt lõi
- Nếu 6 năm sau Google muốn cướp mất bữa trưa của bạn, thì trong những năm trước đó thương hiệu, đội ngũ và cộng đồng phải chuẩn bị cho một cuộc chiến kiểu David đấu Goliath
- Cần lập kế hoạch từ đầu để không bị bất ngờ trong tình huống như vậy, và tận dụng thời gian cùng sự tập trung để xây dựng chiến lược chiến thắng
- Nếu đối thủ đến để tìm ý tưởng, họ sẽ luôn chậm hơn một bước, và đặc biệt ở giai đoạn đầu khi nguồn lực còn hạn chế, bạn lại càng dễ tiêu tốn nhiều năng lượng hơn cho nỗi lo về đối thủ
Tác động trong tuyển dụng lập trình viên
- Một trong những vấn đề lớn mà startup gặp phải, bất kể quy mô, là sự khó khăn trong tuyển dụng lập trình viên
- Khó tìm nguồn ứng viên
- Khó đánh giá lập trình viên
- Khó thuyết phục về chất lượng của đồng đội tương lai
- Mã nguồn mở có thể giúp giảm bớt vấn đề tuyển dụng lập trình viên
-
Tìm nguồn ứng viên một cách công khai
- Mọi lập trình viên đều được hưởng lợi từ mã nguồn mở, và nhiều người muốn đóng góp cho các dự án mã nguồn mở thú vị để đáp lại lợi ích đó
- Lý do đóng góp có thể là cộng đồng tốt, học công nghệ mới, hoặc niềm vui giải các bài toán kỹ thuật khó trong một codebase xa lạ
- Nếu hạ thấp rào cản đóng góp mã cho một dự án mã nguồn mở, bạn có thể thu hút những lập trình viên giỏi tìm đến dự án
- Người đóng góp có thể tham gia thảo luận issue, sửa bug, xác định vấn đề và review PR
- Không phải mọi người đóng góp đều đang tìm việc, nhưng nhiều người có thể bị thu hút bởi triển vọng được làm toàn thời gian với mã nguồn mở
- Supabase chỉ bắt đầu tuyển dụng outbound sau khi đã vận hành hơn 2 năm và tuyển được 32 lập trình viên
- Mã nguồn mở là kênh phát hiện nhân tài chủ lực của Supabase và sẽ tiếp tục như vậy
- Với công ty làm việc từ xa và bất đồng bộ, chiến lược tuyển dụng qua mã nguồn mở giúp ứng viên tự bộc lộ năng lực, từ đó việc xác minh năng lực đó trở nên dễ hơn
-
Đóng góp thực tế thay cho LeetCode và bài test dạng assignment
- Một trong những điều khiến lập trình viên phàn nàn nhiều nhất khi tìm công việc tiếp theo là phải giải bài LeetCode hoặc làm bài test dạng assignment trong quá trình phỏng vấn
- Những cách này tốn nhiều thời gian, mệt mỏi và thường không đại diện cho công việc thực tế họ sẽ làm
- Khi ai đó đóng góp vào kho lưu trữ, bạn đã có sẵn những tư liệu sau
- Ví dụ về cách họ giao tiếp với đội ngũ và thành viên cộng đồng trong môi trường làm việc từ xa, bất đồng bộ
- Ví dụ về đóng góp mã thực tế
- Ứng viên cũng có thể nhìn lại phía công ty
- Họ có thể kiểm tra xem đội ngũ có coi trọng chất lượng mã hay không
- Họ có thể thấy công ty có giao tiếp hiệu quả hay không
- Họ có thể đánh giá công ty có đưa ra quyết định kỹ thuật tốt hay không
- Những người được tuyển qua kho Supabase đã tự biến mình thành những cá nhân không thể thiếu, có người dẫn dắt phát triển các kho hiện có hoặc khởi động thư viện client và SDK mới
- Họ không cần phải giải bài LeetCode trên Zoom
Mở rộng các tính năng cho nhóm người dùng nhỏ và tích hợp
- Khi xây dựng startup, thường chỉ có thời gian để giải quyết những vấn đề lớn nhất
- Để di chuyển nhanh, cần tập trung vào những gì 80% cơ sở người dùng yêu cầu {p:80}
- Những tính năng do nhóm người dùng thiểu số yêu cầu rất dễ bị đẩy lùi vô thời hạn
- Nếu hệ thống là mã nguồn mở, những người dùng này có thể tự đóng góp tính năng, từ đó làm tăng tính hữu ích của phần mềm
- Hiệu ứng này thường xuất hiện ở các tích hợp và adapter
- Người dùng có thể muốn tích hợp Azure hoặc Vercel
- Nếu ai đó khác cung cấp nguồn lực phát triển để tạo ra kết nối đó, toàn bộ người dùng của dự án đều được hưởng lợi
Không tiếp tục phát minh lại cùng một bánh xe
- Trong một thế giới không có mã nguồn mở, các công ty công nghệ sẽ tiếp tục phát minh lại bánh xe
- Supabase không chỉ công khai các dự án mới dưới dạng mã nguồn mở, mà còn cố gắng hỗ trợ các dự án mã nguồn mở hiện có trước khi xây mới
- Việc các hãng xe dùng hàm độc quyền, thành phần UI độc quyền, thư viện windowing độc quyền, hệ điều hành độc quyền và driver độc quyền để hiển thị những thông báo lỗi mà hiếm khi ai nhìn thấy là sự lãng phí thời gian và công sức của lập trình viên
- Supabase Launch Week là tập hợp kết quả mà đội ngũ và cộng đồng đã thực hiện trong 3 tháng qua, và lợi thế của việc vận hành một công ty mã nguồn mở thể hiện ở tốc độ tiến triển của cộng đồng
- Có thể xem thêm tại Launch Week 4 post, và nếu muốn tham gia thì có thể ghé Supabase GitHub
1 bình luận
Các ý kiến trên Hacker News
Ở đây có một giả định lớn về khả năng sinh lời bền vững, và đặc biệt nếu xét tới thực tế như mức lương lập trình viên ở Mỹ thì có những điểm không khớp với cảm nhận thực tế
Tóm lại, một công ty mã nguồn mở cần được sét đánh hai lần. Một lần vào dự án mã nguồn mở, và một lần nữa vào công ty
Nhóm Graphistry yêu thích và làm việc với mã nguồn mở hằng ngày, đã góp phần khởi đầu dự án dẫn tới Apache Arrow và Nvidia RAPIDS, đồng thời cũng công bố mã nguồn mở cho client Python/JS. PyGraphistry[AI] là một công cụ kiểu dao đa năng Thụy Sĩ cho đồ thị, và còn bao gồm cả những công cụ như GFQL, một dạng triển khai ngôn ngữ truy vấn đồ thị Cypher có thể nhúng, native với dataframe và được tăng tốc bằng GPU
Nhưng tăng trưởng bền vững chủ yếu đến từ việc bán giấy phép tự host trên cloud/on-premises cho máy chủ trực quan hóa đồ thị bằng GPU cho doanh nghiệp, chính phủ và các công ty dữ liệu. Sau vài năm cầm cự, may mắn là mảng này đang tăng trưởng tốt; chỉ riêng doanh thu SaaS hosting cũng đủ duy trì một nhóm nhỏ, nhưng không gánh nổi phần lớn đội ngũ. Nếu không có doanh thu từ giấy phép tự host, phần lớn chu kỳ đổi mới sẽ biến mất
Tôi có cảm giác bài viết này bỏ lỡ giao điểm giữa vận may kiểu trúng xổ số, đặc thù thị trường SaaS và khả năng phòng thủ về công nghệ. Việc ra mắt Louie.AI và GFQL trong trường hợp của chúng tôi đang thay đổi khả năng kinh doanh của mã nguồn mở, nên không phải là bất khả thi; nhưng nhìn từ trải nghiệm đi tới đây, tôi thấy lo cho các nhà sáng lập mới đọc bài này
[1] https://graphviz.org/
Nói cách khác, mấu chốt là liệu họ có phải kiểu khách hàng sẽ nói “Tốt quá, vậy chúng tôi hủy hợp đồng nhé” khi bạn nói “giờ chúng tôi công khai mã nguồn” hay không
Bài viết nói rằng “khi nói chuyện với các nhà sáng lập khác về mô hình kinh doanh mã nguồn mở, có ba nỗi lo lặp đi lặp lại: có thể bị chỉ trích vì code lộn xộn, tệ hoặc chưa hoàn thiện; hacker có thể tìm và khai thác lỗ hổng bảo mật; đối thủ có thể đánh cắp tài sản trí tuệ”, nhưng tôi nghĩ còn thiếu điều thứ tư
Đó là Amazon/AWS có thể thương mại hóa và bán dịch vụ dựa trên code của tôi mà không trả gì cả
Khi trao đổi với người dùng và nhận phản hồi thì vẫn phải lịch sự, nhưng trong lòng tôi nghĩ “nói thì dễ. Tôi mới là người thực sự làm ra nó. Im lặng đi hoặc gửi PR đi”. Không ngạc nhiên là những người như vậy hầu như chẳng bao giờ gửi PR
Cứ tiếp tục thực sự làm ra thứ gì đó, còn những người chỉ trích thì phủi họ đi là được
[0] - https://heywillow.io/
Nếu các công ty lớn muốn bắt chước thì nghĩa là bạn đã đang thắng, và cần có kế hoạch trước để giảm thiểu rủi ro đó. Tuy nhiên nếu tôi hiểu đúng bài viết, ý họ là ở giai đoạn khởi đầu thì đó không phải vấn đề cần tập trung hay lo lắng
Các công ty cloud nuốt chửng những sản phẩm mã nguồn mở khác là vì các sản phẩm đó đã không chọn giấy phép bảo vệ đúng mức thành quả của mình
Đây là một bài viết rất sâu sắc và hay, nhưng có một điều mà nhiều dự án bỏ lỡ: hãy bán cho khu vực chính phủ dân sự
Chính phủ Mỹ có nhiều chương trình công nghệ như tài trợ NSF, và do các cơ quan dân sự, cơ quan tình báo, chính quyền bang bị phân mảnh với nhau nên rốt cuộc tạo ra một bức tranh mua sắm phần mềm cực kỳ rộng lớn. Rào cản về quy định và tuân thủ cũng không cao như mọi người nghĩ, nhất là nếu vài hợp đồng đầu tiên được giành cùng đối tác. Đây là nguồn doanh thu ổn định và được bảo đảm, thường theo cam kết 3–5 năm để tài trợ cho dự án, và khả năng sinh lời cũng rất cao
Tôi mong nhiều công ty mã nguồn mở hơn tận dụng điều này. Vì rất nhiều công ty hoàn toàn tư nhân đưa thư viện mã nguồn mở vào sản phẩm của họ, gắn thêm biên lợi nhuận khổng lồ rồi lấy hết phần lợi ích
Ví dụ: https://x.com/ssankar/status/1749202248700420587?s=20
Khi còn ở chính phủ, tôi đã thấy nhiều phần mềm thực chất chỉ là bản đồ mã nguồn mở + DB mã nguồn mở nhưng có giá 12 triệu đô la. Ở các mảng khác, tôi cũng thấy PDF OCR giá 2 triệu đô la mỗi năm, hay công cụ kiểu weights & biases có giá 30 triệu đô la mỗi năm
Ngoài việc phân phối phần mềm còn có những động lực khác. Ví dụ như ưu tiên sửa một lỗi cụ thể hoặc khiếm khuyết bảo mật. Các cơ quan tình báo có khả năng đã trả rất nhiều tiền cho safetensors
Có bốn con đường Supabase có thể đi: bán trực tiếp cho Cybercom, bán trực tiếp cho DOS hoặc thông qua hợp đồng theo nhóm, bán cho VA qua PWS, hoặc bán trực tiếp cho các nhà thầu phần mềm lớn của chính phủ
Cách thực hiện là gửi cold email cho GS 14/15 hoặc cấp tương đương, thuê một cựu GS15, hoặc tìm gói thầu phù hợp trên SAM.gov rồi dùng GovPro.ai theo kiểu trọn gói, hoặc rogue theo kiểu tự xử lý để viết đề xuất
Đến lúc bộ máy quan liêu của chính phủ phê duyệt hợp đồng lần cuối, phần lớn startup có lẽ đã cạn tiền rồi
Hợp đồng có thể sinh lời tốt, nhưng thủ tục quan liêu là khổng lồ và cần người có kinh nghiệm xử lý chúng. Đây không phải con đường phù hợp với tất cả mọi người, và cũng tốn nhiều thời gian lẫn đàm phán
Chưa nói tới bộ máy quan liêu khổng lồ, chính phủ liên bang là tổ chức chính phủ lớn nhất, chậm nhất và khó làm việc nhất. Chỉ riêng trong nước Mỹ đã có hàng chục nghìn thực thể chính phủ khác như trường học, thành phố, quận, bang, khu cấp nước/cứu hỏa, thư viện, v.v.
Nếu muốn bước vào khu vực công, tốt hơn là tiếp cận nhỏ và rộng thay vì dồn tất cả vào nơi lớn nhất
Khu vực chính phủ sinh lời cao nhất trên thế giới là Bộ Quốc phòng Mỹ.
Nhưng Bộ Quốc phòng thì quan liêu đến khó tin, rất nhạy cảm về lịch trình và ám ảnh với bí mật
Mô hình kinh doanh của Supabase là tiếp thị bản thân như một công ty mã nguồn mở, nhưng thực tế thì nếu tỉnh táo sẽ chẳng ai muốn tự host nó cho production
Vì những thứ như tài liệu thiếu một cách tinh vi, lỗi tinh vi, các tính năng quan trọng bị thiếu một cách tinh vi. Vì vậy họ nhận được lời khen là mã nguồn mở, nhưng thực tế không thực dụng; tôi xem đó chỉ là công cụ tiếp thị
Thứ nhất là sự yên tâm. Ngay cả khi hiện tại không tự host, bạn vẫn có thêm một lối thoát nếu không hài lòng với dịch vụ. Tất nhiên cũng phải cung cấp quyền truy cập dữ liệu thô
Thứ hai là chất lượng mã. Nếu từng phải xử lý thứ mã nhìn bề ngoài chạy tốt nhưng thực sự rất tệ, bạn sẽ hiểu việc có mã không đáng xấu hổ khi công khai quan trọng đến mức nào
Thứ ba là khả năng đóng góp. Trước đây tôi từng nghĩ điều này không đáng kể, nhưng sau khi thực sự trải qua nhiều lần, việc có thể yêu cầu hoặc tự đóng góp khi thiếu tính năng, có lỗi, có vấn đề hiệu năng... là rất lớn. Với hầu hết dự án mã nguồn đóng, chỉ cần có một kênh minh bạch để gửi yêu cầu tính năng đã là may mắn rồi
Vượt qua một ngưỡng nào đó, mọi người có thể quyết định bỏ công sức fork. MariaDB là một ví dụ như vậy
Cũng từng có người trực tiếp nói rằng chính điểm đó khiến họ yên tâm khi dùng dịch vụ managed của công ty chúng tôi
Trở thành một công ty mã nguồn mở hợp pháp và thực sự có vẻ dễ hơn nhiều
Nếu không phải ý đó và tôi đã đọc sai, thì phần còn lại lại khiến Supabase trông rất tích cực
Về mặt thương mại có thể điều đó không khả thi, nhưng tình trạng hiện nay đang làm xói mòn mạnh mẽ tiêu chuẩn mà ta có thể kỳ vọng ở phần mềm mã nguồn mở, và tôi cũng không thấy lợi ích dài hạn rõ ràng nào cho các công ty chọn cách đó
Nó cho phép nhà phát triển nhìn thấy mã thực sự đang chạy, ngay cả khi họ không tự chạy nó
Tôi thích Supabase, cũng thích mã nguồn mở thương mại nói chung, và đồng ý với nhiều phần của bài viết
Nhưng đoạn “trong phần mềm, ý tưởng rất rẻ. Giá trị gần như luôn được tạo ra từ việc thực thi ý tưởng” nghe hơi gượng
Tôi từng nghe kiểu diễn đạt này trong những tình huống như “tôi có một ý tưởng startup tuyệt vời, bạn ký NDA trước khi tôi nói nhé?”
Nhưng nếu công khai phần mềm dưới dạng mã nguồn mở, bạn không chỉ cung cấp ý tưởng đơn thuần, mà còn cung cấp một phần đáng kể kết quả thực thi của ý tưởng đó
Tất nhiên mã không phải toàn bộ phần thực thi; nó còn mở rộng sang bán hàng, marketing, hỗ trợ, v.v. Dù vậy bài viết này xem nhẹ giá trị của mã quá mức, và ngầm nói rằng nếu không có bán hàng/marketing thì nó vô giá trị; tôi không nghĩ điều đó đúng
Nếu chia giá trị, tôi xem bán hàng/marketing/xác thực khách hàng chiếm 90%, mã khoảng 10%. Tôi đang vận hành một SaaS bootstrap có doanh thu ở mức đầu 7 chữ số, và có thể nói mã nhìn chung khá lộn xộn và liên tục tiến hóa
Nhà thì không thể sao chép miễn phí, nhưng phần mềm thì có thể
Thứ mà nhà phát triển được trả tiền là quá trình tạo ra mã, và việc giải quyết những vấn đề nhỏ nhặt không nhìn thấy được
Vì vậy bán phần mềm mới có lợi nhuận cao đến vậy. Nếu không bán phần mềm thì không thể kiếm tiền từ nó. Phần mềm không giống các vật thể vật lý trong thực tại mà chúng ta cùng chia sẻ
Với tôi, câu hỏi cốt lõi không phải là mã có đủ tốt không hay đối thủ có sao chép không, mà là liệu có thể kiếm đủ tiền để xây dựng một doanh nghiệp bền vững hay không
Những dự án mã nguồn mở được trích dẫn và yêu mến không phải là doanh nghiệp tốt: PostgreSQL, Python, Bitcoin, React
Mongo và Elastic rất tuyệt nhưng là ngoại lệ. Có nhiều công ty cơ sở dữ liệu mã nguồn đóng thành công hơn công ty cơ sở dữ liệu mã nguồn mở
Công ty mã nguồn mở rất khó. Nhưng với người dùng thì vô cùng giá trị
Gạt sang một bên tranh luận giấy phép nào là “mã nguồn mở”, điều quan trọng là các công ty này đã kết luận rằng những giấy phép được dùng rộng rãi như (A)GPL, Apache, MIT để lại quá nhiều khoảng trống cho đối thủ tạo dịch vụ managed/hosted và cạnh tranh bằng quy mô. Ví dụ như trường hợp Amazon cung cấp OpenSearch rẻ hơn ElasticSearch
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Có vẻ câu hỏi này được dùng với nghĩa “công ty chúng ta có nên công khai mã nguồn của phần mềm không?”
Nhưng với tôi, việc trả lời câu hỏi gốc lại cung cấp con đường để trả lời câu hỏi đã được diễn giải lại. Câu hỏi gốc không nói về phần mềm mà công ty bán, mà về bản chất của phần mềm mà công ty sử dụng
Cá nhân tôi, nếu có lựa chọn thay thế, tôi sẽ luôn chọn sản phẩm mã nguồn mở. Ngay cả khi sẵn sàng trả chi phí hỗ trợ hoặc quyên góp cho dự án. Quyền được tự do xem mã nguồn về cơ bản là quan trọng, kể cả với phần mềm mà tôi tuyệt đối không có ý định sửa
Tôi biết với nhiều người đây có vẻ là lập trường cực đoan. Nhưng tôi ghét ý nghĩ rằng mình không thể tháo rời lò vi sóng, tay nắm cửa hay hộp số. Có thể tôi sẽ không lắp lại đúng cách được, nhưng cũng có thể tôi tìm ra bánh răng bị sứt và sửa với 2 đô la thay vì thay mới 90 đô la. Hoặc có thể tôi tạo ra một chiếc lò vi sóng Frankenstein có gắn hộp số
Việc mở rộng chức năng máy chủ web, hoặc hiểu vì sao plugin của tôi làm ứng dụng host bị crash, là quan trọng với tôi. Tôi cũng cho rằng điều đó quan trọng với xã hội. Vì vậy tôi vẫn bám lấy chủ nghĩa cực đoan mã nguồn mở của mình. Dù bạn có cho tôi xem một máy chủ web siêu nhỏ đời mới xử lý HTTPS/4 trong 5KB bằng AI tích hợp, tôi cũng sẽ thấy thú vị, nhưng nếu nó không phải mã nguồn mở thì tôi vẫn sẽ tiếp tục dùng stack hiện tại
Chính tâm thế này khiến phần mềm tôi tạo ra là mã nguồn mở, và đôi khi mọi người trả tiền cho nó
Về ý “Nếu 6 năm nữa Google định cướp bữa trưa của bạn, bạn cần có một thương hiệu, đội ngũ và cộng đồng đã chuẩn bị cho cuộc chiến David đấu Goliath trong vài năm qua”, theo kinh nghiệm của tôi, với người phụ trách mua sắm thì những thứ như thương hiệu, cộng đồng, đội ngũ, trải nghiệm nhà phát triển gần như chẳng có ý nghĩa gì so với compliance
Điều này đặc biệt đúng nếu đối đầu trực diện với một nhà cung cấp hiện hữu như Google
Với Supabase, thực tế trong vài năm qua họ đã chuẩn bị các compliance như SOC2, HIPAA, GDPR để đáp ứng những yêu cầu này, nên nhận xét đó rất chính xác
Sản phẩm của chúng tôi cũng đã suy nghĩ về vấn đề này. Một ngày nào đó chúng tôi sẽ open source toàn bộ theo giấy phép MIT hoặc Apache, tùy lúc đó thích giấy phép nào hơn, và điều này cũng đã được công khai trên trang web. Không phải kiểu AGPL hay open core
Nhưng tôi cảm thấy việc kiếm tiền từ sản phẩm theo cấu trúc đó là hoàn toàn bất khả thi, và kinh nghiệm trước đây cũng vậy. Tư vấn thì có thể, nhưng sản phẩm thì khác. Supabase đã nhận vốn đầu tư mạo hiểm khổng lồ, và gần như mọi dự án open source “lớn” cũng vậy
Nếu bootstrap, đặc biệt với một dự án tham vọng và khó, bạn sẽ không thể xuất hóa đơn trong một thời gian. Con người chỉ có thể làm miễn phí trong một khoảng thời gian giới hạn, còn một nhóm nhỏ liên tục trao đổi chặt chẽ trên mã nguồn đóng có thể di chuyển nhanh hơn nhiều nhờ giảm được overhead cần có của một dự án open source thành công
Tôi muốn nghe ví dụ về các dự án có quy mô tương tự, nhận 0 đô la đầu tư, bắt đầu trong 5 năm gần đây, có ít nhất 2 thành viên full-time, tồn tại hơn 3 năm, và vẫn khuyến nghị cách tiếp cận này. Tôi tò mò họ đang kiếm sống như thế nào. Tôi cho rằng những chuyện như Redis sẽ không còn xảy ra nữa. Ít nhất là tôi chưa thấy. Ngay cả một dự án đơn giản như langchain cũng nhận hàng chục triệu đô la vốn đầu tư mạo hiểm; tôi từng nghĩ những dự án như vậy mới là ứng viên để một nhóm vài người thử kiếm tiền từ nhiều nguồn doanh thu
Toàn bộ phần mềm của tôi đều được công bố dưới public domain, tức là phần mềm tự do, nhưng không cái nào trong số đó trở thành dự án hay cộng đồng open source thành công. Phần mềm tự do trước hết là hệ tư tưởng, sau đó mới là thực hành hay tính năng
Tôi nghĩ việc biến công ty thành open source là không hợp lý, trừ khi bạn nhắm tới nhà phát triển, hoặc đang làm một sản phẩm mà thực tế sẽ không ai tự host
Supabase là ví dụ tiêu biểu cho cả hai trường hợp. Một ví dụ cho trường hợp sau là Plausible Analytics; bạn có thể tự host. Tôi cũng đang làm vậy bằng Coolify.io. Nhưng nếu không tự xây một hệ thống CI/CD để lấy và merge các bản cập nhật từ các release, bạn sẽ bỏ lỡ cập nhật