Mã nguồn mở không chiến thắng nhờ rẻ hơn
(github.com/getlago)- Các công ty mã nguồn mở thương mại khó có thể trụ vững lâu dài chỉ bằng một sản phẩm thay thế gắn giấy phép MIT lên một sản phẩm trả phí hiện có; họ cần có lý do vì sao phải là mã nguồn mở hoặc năng lực sản phẩm vượt trội hơn
- Khác với các dự án phi lợi nhuận hoặc dựa trên tài trợ, doanh nghiệp mã nguồn mở cần có doanh thu để tiếp tục tuyển dụng, tăng trưởng và phát triển bền vững
- Các công ty giai đoạn đầu dễ chọn bản miễn phí hoặc phiên bản mã nguồn mở, còn doanh nghiệp lớn xử lý chi phí SaaS như một hạng mục ngân sách, nên chỉ dựa vào giá rẻ khó có thể đảo ngược quyết định mua hàng
- Điểm mà mã nguồn mở trở nên mạnh là khi mã nguồn đóng gây ra vấn đề minh bạch làm lung lay niềm tin của khách hàng, và khi có vấn đề mở rộng cần nhiều tích hợp và plugin
- Các trường hợp PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte, Elastic cho thấy mã nguồn mở có thể phát triển thành sản phẩm tốt hơn thông qua khả năng kiểm toán, tự host và đóng góp từ cộng đồng
Chỉ là sản phẩm thay thế mã nguồn mở thì chưa đủ
- Những mô tả như “phiên bản mã nguồn mở của Stripe Billing”, “phiên bản mã nguồn mở của Chargebee” hữu ích để giúp người khác nhanh chóng hiểu sản phẩm, nhưng là nền tảng để duy trì doanh nghiệp thì yếu
- Công cụ mã nguồn mở thương mại khó có thể chỉ dựa vào vị thế là phương án thay thế mã nguồn mở cho một sản phẩm trả phí đã thành công
- Việc nhà phát triển sao chép sản phẩm rồi gắn giấy phép MIT là chưa đủ, và bản thân mã nguồn mở cũng không đảm bảo thành công
- Đối tượng được bàn đến là các dự án mã nguồn mở thương mại cạnh tranh với những giải pháp trả phí phổ biến
- Các sản phẩm lấy cộng đồng làm trung tâm hoặc được tài trợ như React, TypeORM, VSCode có thứ tự ưu tiên khác
- React được một tổ chức lớn hơn như Meta hỗ trợ, còn TypeORM huy động kinh phí phát triển bằng quyên góp
- Những dự án như vậy về bản chất không phải là doanh nghiệp
- Để một công ty mã nguồn mở thành công, họ cần có lý do rõ ràng vì sao phải là mã nguồn mở, hoặc phải vượt trội hơn đối thủ
Tiêu chí thành công là doanh thu, không phải lượng sử dụng
- Nếu loại trừ các dự án phi lợi nhuận nhận quyên góp hoặc tài trợ từ công ty mẹ, tiêu chí cuối cùng của một doanh nghiệp mã nguồn mở thông thường là doanh thu
- Doanh nghiệp vì lợi nhuận dùng doanh thu để có nguồn lực tuyển nhân viên, tăng trưởng, duy trì bền vững và tiếp tục phát triển
- Các công ty vừa làm phần mềm miễn phí vừa tạo ra doanh thu là những ví dụ tích cực; công ty mã nguồn mở cũng không phải đang cố bóc lột khách hàng quá mức mà là muốn tiếp tục kinh doanh
- MongoDB đã phát triển thành một công ty cơ sở dữ liệu lớn với hơn 4.600 nhân viên
- Sau đó họ chuyển sang giấy phép SSPL để hạn chế việc các Cloud Provider triển khai dịch vụ mà không đóng góp cho dự án
- SSPL không được OSI phê duyệt, nhưng được mô tả là trên thực tế khá gần với mã nguồn mở
- Khi đo lường thành công dài hạn, cần phân biệt tỷ lệ chấp nhận sử dụng và doanh thu
- Một dự án có tỷ lệ chấp nhận cao nhưng không tạo được doanh thu vẫn có thể biến mất
- Kỳ vọng rằng cộng đồng sẽ tiếp quản dự án được xem là gần như không có bằng chứng hậu thuẫn
Giá rẻ không phải là chiến trường bền vững
- Chiến lược chỉ nhắm vào khách hàng nhạy cảm về giá gần như là một trận chiến thua cuộc
- Trong ví dụ giả định về việc tạo ra phiên bản mã nguồn mở của Amplitude, có thể lập luận rằng Amplitude đắt, là gánh nặng với công ty giai đoạn đầu, và doanh nghiệp lớn cũng có thể tiết kiệm chi phí
- Tuy nhiên, vì các công ty giai đoạn đầu nhạy cảm với giá, họ nhiều khả năng sẽ chọn phiên bản mã nguồn mở hoặc tier miễn phí, và điều đó không đủ để chống đỡ doanh nghiệp
- Chiến lược tạo ra một lựa chọn rẻ hơn thường giống như tấm vé dẫn đến phá sản trong tương lai
- Doanh nghiệp lớn nhìn chung cũng không lo công ty sẽ sụp đổ vì chi phí Amplitude
- Khi đàm phán hợp đồng, họ có thể cân nhắc giá trong phạm vi ngân sách
- Nhưng phần lớn SaaS rốt cuộc chỉ là một trong các hạng mục chi phí
- Điều kiện quan trọng hơn là liệu đó có phải giải pháp tốt không, có tồn tại lâu dài không, và có dễ quản lý không
- Triển khai giải pháp mã nguồn mở có thể khó quản lý
- Ngoại lệ là khi chi phí giải pháp chiếm tỷ trọng rất lớn trong tổng ngân sách
- Các công ty từng phải cắt giảm Oracle vì chi phí Oracle tăng vọt do mức sử dụng cơ sở dữ liệu thuộc trường hợp này
- Nhưng phần lớn giải pháp mã nguồn mở không thay thế 3 hạng mục chi phí lớn nhất, nên giá khó trở thành tiêu chí quyết định hàng đầu
Cách thứ nhất để mã nguồn mở chiến thắng: minh bạch
- Trường hợp điển hình mà giải pháp mã nguồn mở trở nên mạnh mẽ là khi mã nguồn đóng tạo ra vấn đề minh bạch gây mất niềm tin giữa khách hàng và nhà cung cấp
- Một phương án mã nguồn mở thay thế Amplitude là PostHog
- PostHog đã tăng trưởng với các khách hàng như Airbus, DHL, Staples
- Sản phẩm kết hợp nhiều giải pháp SaaS và được cung cấp dưới dạng mã nguồn mở
- Ngay cả mã nguồn blog và roadmap cũng được công khai
- PostHog định vị là sản phẩm tốt hơn đối thủ vì công cụ phân tích xử lý dữ liệu khách hàng nhạy cảm như địa chỉ IP, tên và bản ghi phiên
- Trong môi trường ngày càng có nhiều quy định dữ liệu như GDPR, CCPA, việc bên thứ ba lưu trữ những dữ liệu này có thể là gánh nặng
- PostHog cung cấp hai lựa chọn
- Tự host trực tiếp giải pháp phân tích
- Thuê PostHog làm bên thứ ba, nhưng có được sự minh bạch về cách dữ liệu được lưu trữ và cách có thể chuyển sang tự host trong tương lai
- Dù cách thân thiện nhất với quyền riêng tư là tự host, nhiều công ty vẫn có thể chọn mô hình được host
- Ngay cả khi đó, họ vẫn có thể xem phần mềm vận hành như thế nào đến từng dòng
- Họ có thể biết quy trình chuyển sang mô hình tự host khi cần
- Công ty mã nguồn mở không chiến thắng bằng cách loại bỏ nhu cầu về bên thứ ba, mà bằng cách tạo niềm tin nhờ cho phép kiểm toán công khai cách phần mềm hoạt động
Các ví dụ sản phẩm nơi minh bạch là quan trọng
- Medplum là một nền tảng hồ sơ sức khỏe điện tử mã nguồn mở cạnh tranh với các nhà cung cấp mã nguồn đóng hiện hữu
- Vì là mã nguồn mở, người dùng có thể kiểm tra chính xác nền tảng hỗ trợ gì và không hỗ trợ gì
- SuperTokens là phương án mã nguồn mở thay thế cho các giải pháp xác thực như Auth0
- Đăng nhập xử lý dữ liệu nhạy cảm như tên, email và mật khẩu
- Việc là mã nguồn mở giúp tạo được nhiều niềm tin hơn
- TableFlow là phương án mã nguồn mở thay thế cho các nền tảng nhập CSV như Flatfile
- Điểm quan trọng là dữ liệu được nhập có tính nhạy cảm
- Minio là phương án mã nguồn mở thay thế cho lưu trữ AWS S3
- S3 có thể lưu PII của khách hàng thông qua ảnh chụp màn hình hoặc các tệp JSON có cấu trúc
- Với những công ty quan tâm ai có thể truy cập dữ liệu người dùng, Minio có thể là một lựa chọn thay thế
- AWS khẳng định nhân viên AWS không trực tiếp truy cập dữ liệu khách hàng, nhưng với mã nguồn đóng, khẳng định đó vẫn là vấn đề niềm tin
- Lago cũng xử lý thông tin tính phí và mức sử dụng sản phẩm; thông tin này gần với nội dung nhạy cảm, nên được cho là có thể tạo niềm tin tốt hơn với người dùng thông qua mã nguồn mở
Cách thứ hai để mã nguồn mở chiến thắng: khả năng mở rộng
- Một trong những lợi thế lớn của mã nguồn mở là mở việc phát triển các tính năng ngách cho cộng đồng
- Sản phẩm lõi thường do đội ngũ kỹ thuật trung tâm duy trì, nhưng các tích hợp hoặc plugin do nhà phát triển cộng đồng tạo ra và đôi khi được merge vào nhánh chính
- Giải pháp mã nguồn đóng phải phụ thuộc vào đội ngũ kỹ thuật nội bộ, nên khó mở rộng theo cùng cách
- Điều này đặc biệt có lợi cho các công ty mã nguồn mở xây dựng hệ thống cần kết nối với nhiều thư viện, framework và ứng dụng
- Airbyte là một nền tảng ELT mã nguồn mở, đã tăng trưởng mạnh nhờ các connector do cộng đồng bổ sung
- Elastic cũng là một công ty lớn hơn vốn ban đầu là mã nguồn mở, cung cấp nhiều tích hợp dữ liệu
- SuperTokens lấy khả năng mở rộng làm đề xuất giá trị cốt lõi, và việc thành viên cộng đồng có thể tạo tích hợp với các nhà cung cấp xác thực ít phổ biến đem lại lợi ích cho tất cả
Cách thứ ba để mã nguồn mở chiến thắng: sản phẩm tốt hơn
- Tính minh bạch và khả năng mở rộng góp phần giúp mã nguồn mở thương mại trở thành sản phẩm tốt hơn về dài hạn
- Dự án mã nguồn mở có thể tận dụng phản hồi và sự hỗ trợ của cộng đồng để phát triển nhanh hơn các giải pháp mã nguồn đóng
- PostHog bắt đầu như một lựa chọn thay thế cho Amplitude và FullStory, nhưng sau đó đã phát triển thành một giải pháp bao quát lớn, cạnh tranh cả với LaunchDarkly và Pendo
- PostHog đã huy động được khoản đầu tư Series B trị giá 15 triệu USD
- Sự tăng trưởng này diễn ra trong vài năm qua, và PostHog xem cộng đồng là một trong những lý do cốt lõi
- Dự án mã nguồn mở không chỉ giới hạn ở mã nguồn mở thương mại mà đã đóng vai trò là động lực quan trọng cho việc cải thiện sản phẩm trong nhiều thập kỷ
- Một số phần mềm có thể vẫn là mã nguồn đóng do đặc tính của lợi thế người đi trước
- Nhưng trong những lĩnh vực nơi minh bạch và khả năng mở rộng là vấn đề, những kẻ đến sau bằng mã nguồn mở có thể trở thành mối đe dọa thực sự
3 bình luận
Tôi tình cờ thấy khi đang tìm kiếm, và tự nhiên thắc mắc không biết đến bao giờ AI mới sửa được những kiểu bản dịch dịch sát tiếng Anh như thế này (
bằng sự rẻ).Đây là kết quả chạy Claude 4.5 Sonnet hôm nay (2026-01-12)
"Mã nguồn mở không chiến thắng vì rẻ hơn"
Prompt
Mã nguồn mở không chiến thắng chỉ đơn giản vì giá rẻ.
Yếu tố thành công của mã nguồn mở không nằm ở chi phí thấp, mà nằm ở chỗ khác.
Mã nguồn mở chiếm ưu thế không phải vì giá thấp.
Ý kiến trên Hacker News
Cách dùng từ lợi nhuận (profit) ở đây nghe kỳ lạ và mơ hồ
Tôi đã vận hành các dự án mã nguồn mở/phần mềm tự do gần 24 năm, trong đó khoảng 17 năm có cả doanh thu, nhưng không có “lợi nhuận”, chỉ có doanh thu (revenue)
Theo cách các công ty hay kế toán thường nhìn nhận, lợi nhuận là số tiền còn lại sau khi trừ thù lao và chi phí của những người tham gia dự án
Những dự án mã nguồn mở cần lợi nhuận theo nghĩa này chỉ là các dự án đã nhận vốn đầu tư mà nhà đầu tư kỳ vọng “tỷ suất lợi nhuận”; những dự án như vậy có tồn tại, nhưng không phải đa số
Ngoài ra, đúng kiểu bài thường thấy trên HN, toàn bộ bài quá thiên về mảng web/SaaS. Có thể khó tin, nhưng các dự án mã nguồn mở còn có nhiều loại khác nữa
Trong ngữ cảnh đó, lợi nhuận là phần còn lại sau khi thu doanh thu và trả chi phí; các chi phí đó bao gồm lương cố định, hợp đồng lao động, bảng lương và những thứ tương tự
Một doanh nghiệp sử dụng lợi nhuận theo nhiều cách khác nhau. Có thể tích lũy làm dự trữ tiền mặt để vẫn trả được chi phí trong những tháng doanh thu thấp, có thể mua tài sản như phần cứng mới, cũng có thể tạo điều kiện tuyển thêm người. Không phổ biến như nhiều người nghĩ, nhưng cũng có thể trả cổ tức cho chủ sở hữu
Trường hợp của bạn không có nhiều chi tiết nên chỉ có thể suy đoán, nhưng nếu bạn vận hành một mình, dự án nhỏ, không cần hoặc không muốn tăng nhân sự, thì doanh thu về cơ bản gần giống thu nhập cá nhân. Tháng này nhận nhiều hơn, tháng kia nhận ít hơn, nên trong ngữ cảnh này xem đó là doanh thu chứ không phải “lợi nhuận” thì đúng hơn
Đặc biệt nếu đó là phần mềm gần như không có chi phí gián tiếp nào khác và việc theo dõi chi phí cho mục đích thuế cũng không có nhiều ý nghĩa, thậm chí có thể bạn còn không giữ sổ sách đúng nghĩa. Nếu ở trong tình huống như vậy thì tôi hiểu vì sao bài viết không tạo được sự đồng cảm. Bài này đang nói về một hoàn cảnh khá khác
Nếu không có nhà đầu tư thuần túy đòi hỏi tỷ suất lợi nhuận liên tục, áp lực sẽ giảm đi rất nhiều và dễ làm những việc phù hợp với dự án hơn
Nhưng trong các lĩnh vực sản phẩm cạnh tranh với những công ty đầy tham vọng, tăng trưởng cũng là điều cần thiết và có khả năng là hợp lý
Giữ lại lợi nhuận để chuẩn bị cho suy thoái, cơ hội hoặc các khoản chi lớn không chỉ đơn giản là hợp lý. Càng có nhiều người tham gia và khách hàng, lý do để không đốt sạch toàn bộ doanh thu thu về càng lớn
Trên thực tế, ở các công ty lớn, hai con số này thường không liên quan đến nhau; mỗi con số được định nghĩa tùy theo việc nó được chuyển cho ai và các quy tắc áp dụng cho việc chuyển đó
Cũng có thể có thứ như “lợi nhuận quản trị”, một cách gọi chung cho các chỉ số không được chuẩn hóa hay quản lý bằng quy định. Ví dụ, dù một doanh nghiệp đã rời khỏi kế toán tiền mặt cho mục đích thuế và báo cáo với nhà đầu tư, ban lãnh đạo hiện tại vẫn có thể thấy hữu ích khi tiếp tục theo dõi định nghĩa lợi nhuận theo cách cũ. Có thể là do thói quen, hoặc vì nó phản ánh tốt dòng tiền, hoặc hữu ích theo một cách nào khác
Đây là một trong những vấn đề mang tính hậu hiện đại. SEC, IRS hay nhân viên ngân hàng sẽ không chấp nhận cách nói như “lợi nhuận kiểu SEC” mà sẽ đòi “lợi nhuận thật”. Giống như một chính trị gia địa phương ngây thơ chất vấn bệnh viện rằng nhà thầu “thật ra” đã tốn bao nhiêu
Dù sao thì tác giả bài viết cũng đang dùng thuật ngữ theo góc nhìn của mình, giống như SEC hay IRS. Khi nói “mã nguồn mở không thắng nhờ rẻ hơn”, “mã nguồn mở” ở đây chỉ các doanh nghiệp mã nguồn mở theo mô hình như MongoDB. Vì vậy các yếu tố như nhà đầu tư, mục tiêu tăng trưởng được mặc định sẵn
Trong bài, tác giả cũng đã tự làm rõ điểm này, nên không cần sa vào tranh cãi ngữ nghĩa làm gì
Vấn đề của mô hình kinh doanh này là nó tạo ra sự căng thẳng giữa phiên bản OSS và phiên bản trả phí
Bạn muốn phiên bản OSS tốt, nhưng không được tốt đến mức không ai cảm thấy cần trả tiền cho SaaS hay tư vấn, v.v.
Sự căng thẳng đó rốt cuộc dường như dẫn tới việc những tính năng rõ ràng là cần thiết bị bỏ đi, hoặc các tính năng/kiến thức cần thiết để vận hành ở quy mô lớn bị giấu dưới dạng mã nguồn đóng để công ty tài trợ kiếm tiền
Nếu sản phẩm mang tính hạ tầng, mẫu hình đổi sang giấy phép chỉ được xem chứ không được đụng vào để các nhà cung cấp cloud lớn không thể nuốt chửng bằng dịch vụ một cú nhấp chuột, như Elastic hay Hashicorp, cũng đã trở nên phổ biến
Không có nghĩa là bài viết sai, nhưng tôi không muốn mọi người giả vờ rằng OSS được tài trợ thương mại là một kiểu đôi bên cùng có lợi kumbaya tốt đẹp cho tất cả. Thực tế nó gần với một cấu trúc nơi startup dùng OSS như một growth hack để xây dựng niềm tin, rồi khi đến lúc phải tạo doanh thu thì bằng cách này hay cách khác sẽ siết lại cộng đồng đã giúp mình tăng trưởng
Tôi đã duy trì một module nhỏ và nhận được rất nhiều yêu cầu tính năng cũng như hỗ trợ trong nhiều năm. Cho đến khi kiếm đủ để trả tiền thuê nhà, tôi không hề thấy áy náy chút nào khi thu tiền cho những việc đó
Thậm chí ngay cả việc bấm nút merge Pull Request, nếu tốn của tôi dù chỉ 1 giây, tôi cũng tính phí. Tôi đã bỏ ra vài tháng, vài năm cho code, và đã công bố code đó miễn phí cho thế giới
Nếu cần tính năng bổ sung hoặc thời gian của tôi thì phải trả tiền
Việc nhiều công ty không làm được không có nghĩa là mô hình kinh doanh này không hoạt động; đúng hơn là nó cực kỳ khó làm cho đúng
Dù vậy, nếu nhìn chung cho rằng đa số con người về cơ bản là tốt, thì cũng đáng cân nhắc khả năng các công ty hoặc những người này đã tiếp cận thị trường sai cách. Có thể không phải ác ý mà là kém năng lực
Nếu ngay từ ngày đầu tiên họ minh bạch điều gì sẽ miễn phí mãi mãi và điều gì cuối cùng sẽ trở thành trả phí, tôi sẽ không xem đó là phản bội cộng đồng
Tất nhiên điều đó cần giả định rằng họ giữ đúng roadmap và điều chỉnh theo phản hồi cũng như đóng góp
Hỗ trợ trả phí hoặc các tính năng mở rộng dù sao cũng có thể để lại trong mảng thương mại, nơi phần mềm kiếm được phần lớn tiền
Nó sẽ không phù hợp với mọi use case, nhưng cũng không cần phải vậy. Phần lớn điện toán nên mang tính cá nhân
Có ý kiến rằng “MinIO là một lựa chọn thay thế tốt cho các công ty quan tâm ai có thể truy cập dữ liệu người dùng”, nhưng chẳng phải một công ty có thể tuyên bố rằng họ host bằng phần mềm mã nguồn mở, trong khi thực tế lại dùng phần mềm mã nguồn đóng nội bộ mô phỏng cùng API endpoint sao?
Khi đó vẫn cần cùng một kiểu niềm tin như với AWS
Không nên giả định rằng tự host đồng nghĩa với ý thức bảo mật cao. Ở hầu hết doanh nghiệp, IT on-premise bị đối xử như HVAC hay hệ thống điện, chỉ là phiền phức hơn
Bất kỳ ai mặc đồ bảo hộ lao động cũng có thể lừa quầy lễ tân để lấy chìa khóa phòng server
Nó chỉ có nghĩa là nhà cung cấp chia sẻ mã nguồn mà họ nói là đang chạy phía sau dịch vụ của họ
Ngay cả khi mã đó chính xác, khả năng nó là code duy nhất chạy phía sau dịch vụ “chính thức” cũng rất thấp. Và người dùng cũng không thể tự build rồi triển khai lên server của họ
Mã nguồn mở chỉ thực sự có ý nghĩa khi tự host; nếu không thì trên thực tế chẳng khác gì phần mềm độc quyền. Mọi thứ phụ thuộc vào niềm tin vào nhà cung cấp, và nếu có thể thì vào hợp đồng
Ví dụ, nếu hợp đồng ghi rằng dữ liệu đi vào và đi ra qua mã nguồn mở này, không đi nơi khác, đồng thời liệt kê các quy trình để bảo đảm điều đó, mà toàn bộ điều này lại là một lời nói dối trắng trợn, thì đó sẽ là một vấn đề lớn theo cách rõ ràng và có thể thực thi
Cũng khó che giấu với nhân viên nội bộ, và con người thì ra vào công ty. Nếu thực tế không phải vậy, họ khó có khả năng đưa ra tuyên bố như thế
Tác giả nói rõ rằng mình đang nói cụ thể về các giải pháp nguồn mở cạnh tranh với sản phẩm trả phí
Cá nhân tôi cho rằng trong bối cảnh này, chuyện nguồn mở có “thắng” hay không vẫn chưa có kết luận
Trong 10 năm qua, số sản phẩm nguồn mở đã tăng mạnh, và khoảng 5 năm gần đây tôi cũng thấy nhiều sản phẩm trong số đó dần rời xa nguồn mở. MongoDB, stack Hashicorp, Elastic, Red Hat, MinIO là những ví dụ
Không còn nhiều sản phẩm thực sự nguồn mở mà vẫn có sức cạnh tranh thương mại, và phần lớn trong số đó vẫn đang chật vật chứng minh rằng đây là một mô hình kinh doanh khả thi
Vài tuần trước tôi đã thuyết trình về chủ đề này tại một sự kiện nội bộ công ty, và vài tuần nữa sẽ trình bày lại ở GoWest
Tiền đề cốt lõi là giấy phép nguồn mở đúng nghĩa trao quyền tự do, nhưng không cung cấp những thứ khác mà công ty sẵn sàng trả tiền. Giấy phép độc quyền cung cấp thứ công ty cần, nhưng đánh đổi bằng tự do
Tôi tin rằng có một mô hình thứ ba hoạt động ở khoảng giữa mà không phải thỏa hiệp về tự do hay độ tin cậy. Nếu vẫn là nguồn mở và lấp khoảng trống mà công ty cần bằng tài trợ, điều đó có thể khả thi với một số dự án
Hiện chúng tôi đang thiết kế lại website Caddy theo thông điệp này, và hy vọng nó sẽ vận hành tốt
Khi nói MinIO “rời xa nguồn mở”, ý là chuyện đó à?
Tiêu đề ngu ngốc. Đương nhiên nguồn mở thắng vì rẻ hơn
Điều tác giả muốn nói là kinh doanh nguồn mở không thắng vì rẻ hơn
Codebase nguồn mở thì luôn thắng vì rẻ hơn. Không ai trả tiền cho thuật toán nén, daemon thời gian mạng, hay bộ chuyển mã media cả. Nguồn mở đã xóa sổ hoàn toàn những thị trường như vậy
Chỉ là tiêu đề sai theo nghĩa đen chỉ vì một từ, nên khá khó chịu
Tôi đã phải đọc lại các đoạn phía trước vì tưởng mình bỏ lỡ gì đó
Từ góc nhìn của một kỹ sư có ảnh hưởng đến việc áp dụng công nghệ, nguồn mở thắng nhờ có thể hiểu được
Nếu tôi và đồng nghiệp có thể xem mã nguồn, chúng tôi có thể đánh giá liệu sản phẩm đó có làm được những chức năng mà nó tuyên bố hay không
Khi gặp lỗi hoặc use case không lường trước trong quá trình sử dụng, ít nhất chúng tôi có thể điều tra cách xử lý rồi đề xuất trong báo cáo lỗi, hoặc thậm chí mở PR
Nhờ vậy có thể tạo workaround nhanh, và thường cũng có thể báo lỗi
Doanh nghiệp không quá quan tâm đến bản thân mã nguồn. Ngay cả khi có quan tâm, điều khoản bảo đảm tính liên tục kinh doanh cũng có thể giảm bớt phần lớn lo ngại về phần mềm đóng mã nguồn
Rốt cuộc có bao nhiêu công ty tài chính đã chuyển từ Excel sang OpenOffice Calc?
Chiến lược thâm nhập thị trường của AWS dựa vào việc thu hút startup và lập trình viên cá nhân bằng dịch vụ trả theo mức dùng với chi phí thấp, và phần này cực kỳ ăn khớp. Vì Airbnb, Stripe, Twitch, v.v. đã lớn lên thành các công ty lớn cùng với AWS
Không có nhiều thứ có thể cạnh tranh với chi phí thấp hoặc miễn phí. Sau này cứ đi lên phân khúc cao hơn là được. Cứ hỏi ARM và Intel thì biết
Với các startup công cụ phát triển, nguồn mở thực tế đã trở thành chiến lược thâm nhập thị trường mặc định. Dù như bài viết chỉ ra đúng, nó không phải là mô hình kinh doanh
Vì vậy, nếu không xuất sắc cỡ Snowflake và không thể đối đầu với phe tự do/nguồn mở như Databricks, thì mô hình open core sẽ tốt hơn
Nếu có thể tự biên dịch thì họ còn thích hơn nhiều
Nếu bạn đang tự chạy Postgres trên máy chủ vật lý, nhà đầu tư hoặc sẽ không quan tâm, hoặc sẽ đặt những câu hỏi khó về việc bạn đã lãng phí bao nhiêu thời gian. Khi đó bạn cần có một câu trả lời khá tốt, hoặc một nhà đầu tư biết đồng cảm
Thật ngạc nhiên là không nhắc đến khóa chân nhà cung cấp. Đây là một điểm bán hàng rõ ràng của nguồn mở
Tất nhiên còn tùy tổ chức và con người, và cũng có nhiều người không bận tâm chuyện bị khóa chân nếu đó là công ty họ tin tưởng, nhưng con số đó chắc chắn không phải là 0
Khi làm tư vấn OpenShift ở Red Hat, tôi đã gặp nhiều lãnh đạo lo ngại về khóa chân nhà cung cấp. Với họ, chọn OpenShift là quyết định hiển nhiên
Đây là chuyện chỉ hơi liên quan trong lĩnh vực bán phần mềm, nhưng ngày xưa tôi từng bán một bản cập nhật giao diện người dùng cho một trò chơi có thiết kế rất tệ
Tôi định giá nó gấp 2 lần giá của chính trò chơi, vậy mà mọi người vẫn mua. Vì nó được thiết kế một cách chuyên nghiệp
Là một nhà thiết kế chuyên nghiệp, tôi đã dành thời gian làm việc chính của mình để làm điều mà nhà phát triển kia có lẽ không làm được
Trong phần bình luận trên nền tảng phân phối số nơi tôi bán lúc đó, lời phàn nàn rõ ràng nhất là bản cập nhật quá đắt, và đương nhiên mọi người bình luận về cách định vị giá
Nhưng có một điều rất rõ ràng: bản thân trò chơi quá rẻ
Nếu người ta chỉ phàn nàn về giá mà vẫn tiếp tục mua, nghĩa là ngoài chuyện đó ra họ không còn gì đáng phàn nàn
Chim chóc lúc nào cũng muốn thức ăn miễn phí. Đừng chiều theo chim chóc
Nói thêm, bản cập nhật đó cũng bị phân phối lậu và lan khá rộng trong nhóm người dùng bản crack. Tôi lại thấy vui vì phần lớn khách hàng đã trả tiền
Ngoài ra, cũng rõ ràng là tôi đang đáp ứng một gói tính năng mà họ muốn nhưng không nơi nào khác cung cấp. Những vấn đề như vậy là triệu chứng khá tốt cho thấy bạn đã tạo ra thứ mà mọi người muốn
Nhiều dự án mã nguồn mở, theo tôi, trở thành mã nguồn mở vì nhu cầu, chứ không phải vì lựa chọn
Có những sản phẩm chỉ khi được làm mã nguồn mở thì mới có dù chỉ một chút khả năng được chấp nhận
Tác giả đang tập trung vào một số ít dự án mã nguồn mở tinh hoa, và chúng không đại diện cho đa số các dự án mã nguồn mở
Một số công ty có các mối quan hệ kinh doanh và chính phủ phù hợp, nên có thể dễ dàng bán giấy phép sản phẩm với giá cao, nhưng những nơi như vậy chỉ là thiểu số
Phần lớn mọi người và doanh nghiệp nhỏ không có mạng lưới như thế. Nếu không có mạng lưới kinh doanh phù hợp, rất khó kiếm được dù chỉ một chút tiền
Sản phẩm tốt đến đâu, có thể giảm chi phí cho ai đó nhiều thế nào cũng không quan trọng. Không ai tin, cũng không ai thử. Dù lợi ích dài hạn có thể rất lớn, rào cản chấp nhận vẫn quá cao
Biến sản phẩm thành mã nguồn mở là cách duy nhất để ít nhất cũng chen được một chân vào cửa. Vì nó cho sản phẩm một cơ hội rất nhỏ để được chú ý, và đôi khi như vậy là tất cả