Mô hình kinh doanh phần mềm mã nguồn mở: thu tiền thế nào khi ai cũng tải được

Đăng ngày 23/10/2026

Tóm tắt và điều cần nhớ

Phần mềm mã nguồn mở (open-source software, OSS) là phần mềm công bố mã nguồn và cho phép người khác xem, sửa, phân phối lại theo một giấy phép. Bài trả lời hai câu hỏi: nếu ai cũng tải được thì thu tiền từ đâu, và bên bán lẫn bên dùng nên chọn cách nào, kèm tình huống tại Việt Nam.

• Mã nguồn mở là cách phát triển và phân phối, không tự nó là cách tính tiền. Khách trả cho thứ mã không tự mang lại: vận hành ổn định, trách nhiệm khi sự cố, tính năng cho tổ chức lớn và niềm tin.
• Cách thu tiền gom thành bốn nhóm: bán công sức, bán sự tiện lợi, bán tính năng và bán vị thế trung gian.
• Chỉ một phần nhỏ người dùng chịu trả, nên cần lượng người dùng lớn và vị thế là địa chỉ đầu tiên người ta tìm khi cần hỗ trợ.
• Giấy phép là quyết định kinh doanh: nhiều hãng đổi giấy phép khi nhà cung cấp đám mây bán lại sản phẩm, rồi phải chỉnh tiếp.
• Với bên dùng, không mất tiền bản quyền chưa có nghĩa là rẻ: còn nhân sự vận hành, bản vá, đào tạo và rủi ro giấy phép.
• Ở Việt Nam đã thấy cộng đồng, doanh nghiệp bản địa hóa, nhà cung cấp dịch vụ vận hành và chính sách ưu tiên trong cơ quan nhà nước.

Vì sao có người trả tiền cho thứ miễn phí

Một sản phẩm ai cũng tải được, đọc được mã và sửa được thì lấy doanh thu từ đâu? Trước hết cần tách hai cách hiểu. Theo nghĩa phát triển, mã nguồn mở là cách làm việc cộng tác, trong đó giấy phép quy định ai được làm gì với mã. Theo nghĩa kinh doanh, nó là cách doanh nghiệp tạo ra, phân phối và giữ lại giá trị từ phần mềm. Nhầm hai nghĩa này sinh ra nhiều quyết định sai.

Cách nhìn thứ ba là chuỗi cung ứng. Đội phát triển thường lắp sản phẩm từ các thành phần mở, nên có chỗ cho bên đứng giữa: chọn thành phần, kiểm thử, ghép nối, đóng gói thành bản có bảo hành rồi bán. Mua bản đó là mua một sản phẩm kèm cam kết; tự tải và tự lo thì đó chỉ là một dự án, mọi sự cố thuộc về bạn.

Mã nguồn mở không bán mã. Nó bán những thứ mã không tự có: thời gian, sự an tâm, quy mô và niềm tin.

Bốn thứ đó là thời gian (khỏi tự dựng và trông coi hệ thống), sự an tâm (có đơn vị cam kết xử lý lỗi), quy mô (quản trị, bảo mật, tích hợp cho tổ chức lớn) và niềm tin (chứng nhận, tuân thủ, uy tín). Mỗi mô hình ở các mục sau bán một hoặc vài thứ ấy.

Những thuật ngữ dễ bị nhầm

Mã nguồn mở khác phần mềm tự do (free software) ở trọng tâm: phần mềm tự do đề cao quyền tự do của người dùng như nguyên tắc đạo đức, mã nguồn mở đề cao lợi ích thực dụng của cộng tác. Open Source Initiative định nghĩa bằng mười tiêu chí, gồm phân phối lại tự do và không phân biệt lĩnh vực sử dụng [1]. Vì thế SSPL và Elastic License, vốn hạn chế cách dùng thương mại, không được công nhận là giấy phép mã nguồn mở [2]; loại này thường gọi là giấy phép có sẵn mã nguồn (source-available).

Mã nguồn mở cộng đồng do lập trình viên độc lập sở hữu và dùng miễn phí, nhưng chi phí ẩn nằm ở thời gian tự sửa lỗi. Mã nguồn mở thương mại do một pháp nhân sở hữu để tạo doanh thu, kèm tính năng trả phí và cam kết hỗ trợ. Freemium khác cả hai: sản phẩm đóng, nhà cung cấp nắm toàn quyền và chỉ cho dùng miễn phí ở mức giới hạn. Dự án là nơi cộng đồng cùng làm; sản phẩm là bản đóng gói có tài liệu và cam kết hỗ trợ, thứ công ty thực sự bán.

Về cấu trúc mã có hai mô hình hay bị lẫn. Open core (lõi mở) để lõi miễn phí dưới giấy phép mở, còn bản bổ sung cho doanh nghiệp là phần mềm độc quyền ở kho mã riêng. Giấy phép lai (hybrid licensing) đặt mã mở và mã độc quyền chung một kho; bản đầy đủ chỉ mở khóa khi có khóa cấp phép trả tiền.

Bán công sức và bán sự tiện lợi

Nhóm đầu tiên là bán công sức: triển khai, tích hợp, đào tạo, vá lỗi, bản đóng gói đã kiểm định và hợp đồng hỗ trợ. Đây là điểm xuất phát của nhiều công ty mã nguồn mở vì không cần đổi giấy phép, nhưng việc nặng sức người nên khó nhân bản, doanh thu khó dự báo và biên lợi nhuận thấp hơn công ty bán sản phẩm. Nghịch lý hơn, hỗ trợ chỉ có lãi khi sản phẩm đủ phức tạp, nên làm sản phẩm dễ dùng hơn lại làm giảm đơn hàng.

Khách lớn còn dần tự lo: doanh nghiệp dùng sâu một sản phẩm sẽ thuê kỹ sư hiểu nó để khỏi trả phí hỗ trợ mãi. Đào tạo dễ mở rộng hơn dịch vụ cầm tay chỉ việc. Biến thể khác là nhận làm tính năng theo đơn đặt hàng, hoặc xây trình kết nối, bộ công cụ lập trình (SDK) cho sản phẩm của khách.

Nhóm thứ hai là bán sự tiện lợi, chủ yếu qua lưu trữ hộ và dịch vụ trả theo kỳ (software as a service, SaaS): khách khỏi lo sao lưu, nâng cấp, gián đoạn. Điểm khó là định giá. Phải thấp hơn chi phí khách tự dựng hạ tầng, nếu cao hơn nhiều thì khách lớn có đội vận hành riêng sẽ tự chạy. Chính nhà cung cấp đám mây cũng có thể bán lại sản phẩm của bạn, nên lưu trữ hộ ít khi đứng một mình.

Bán tính năng và bán vị thế

Nhóm thứ ba là bán tính năng. Với open core, phần lớn mã là mở, một phần nhỏ nhắm tới doanh nghiệp lớn (quản lý người dùng nâng cao, tích hợp chuyên biệt) là độc quyền và trả phí. Cân bằng rất khó: cho quá nhiều thì mất nguồn thu, cho quá ít thì bản miễn phí thành thứ cắt xén không ai muốn dùng, và giữ hai nhánh mã đồng bộ cũng tốn công.

Giấy phép kép (dual licensing) cấp cùng một mã theo hai cách: giấy phép buộc chia sẻ lại cho người chấp nhận điều đó, và giấy phép thương mại trả phí cho doanh nghiệp không muốn bị ràng buộc. Giấy phép hạn chế (restrictive licensing) tạo lý do pháp lý để trả tiền: ai sửa mã rồi phân phối theo GPL phải chia sẻ lại, AGPL mở rộng nghĩa vụ sang cả việc cung cấp qua mạng, còn Commons Clause cấm bán sản phẩm. Mặt trái là điều khoản nặng làm giảm sự chấp nhận.

Giấy phép lai giảm bớt gánh nặng của open core: cả đội làm trên một kho mã, người ngoài có thể đóng góp cả cho tính năng trả phí, nâng cấp chỉ cần nhập khóa, nhưng bài toán cân bằng vẫn y nguyên. Business Source License là biến thể theo thời gian: hạn chế bán thành dịch vụ cạnh tranh, rồi tự chuyển sang giấy phép mở sau một số năm.

Nhóm cuối là bán vị thế. Dự án đông người dùng có thể đứng giữa người dùng và bên thứ ba để lấy hoa hồng giới thiệu (marketplace), hay nhận tài trợ định kỳ qua GitHub Sponsors, Patreon. Hai nguồn này hợp để bù chi phí hơn là nuôi cả công ty vì khó dự báo. Bán thêm sản phẩm độc quyền liên quan cũng là một cách, nhưng đội nhỏ dễ bỏ bê dự án mở.

Ba thế hệ công ty và vai trò của cộng đồng

Thương mại hóa mã nguồn mở đi qua ba thế hệ. Thế hệ đầu là các dự án cộng đồng ra đời để đối trọng với phần mềm độc quyền, bắt đầu từ hệ điều hành và cơ sở dữ liệu; Red Hat cho thấy có thể bán thuê bao hỗ trợ cấp doanh nghiệp trên nền đó [3]. Thế hệ hai gồm các công ty tự thuê kỹ sư viết sản phẩm, chỉ cho dùng miễn phí một phần và vấp cuộc đua cho không thêm tính năng. Thế hệ ba cung cấp sản phẩm dưới dạng dịch vụ đám mây ngay từ đầu, trộn mã mở với mã thương mại để khách khỏi bận tâm giấy phép.

Cộng đồng làm những việc công ty khó tự làm: thử sản phẩm mới, đánh giá, báo lỗi, chạy thử bản chưa ổn định, phản hồi để sản phẩm tiến hóa theo nhu cầu thật. Người dùng quan trọng nhất là lập trình viên: họ gắn sản phẩm vào bản mẫu của dự án và mang nó theo đến khi triển khai, lúc đó rất khó thay. Hệ quả là chu kỳ bán hàng thường ngắn hơn và chi phí tiếp thị thường thấp hơn công ty phần mềm đóng.

Khi nhu cầu bảo vệ doanh thu tăng, nhiều hãng chuyển sang giấy phép cho dùng miễn phí đến lúc triển khai thực tế hoặc mở rộng, nên ranh giới giữa mã nguồn mở và freemium ngày càng mờ. Đó là bối cảnh của các vụ đổi giấy phép ở mục ví dụ quốc tế.

Điều kiện để thu tiền được

Mô hình chỉ chạy khi có hai điều kiện, và cả hai thuộc về niềm tin chứ không thuộc về mã. Thứ nhất là sự chấp nhận rộng: phần lớn người dùng được đáp ứng đủ bằng bản miễn phí nên tỷ lệ thành khách trả tiền thường thấp, vì vậy cần cơ sở người dùng đủ lớn. Thứ hai là uy tín chính thống: công ty phải là địa chỉ đầu tiên người ta nghĩ tới khi cần hỗ trợ, nếu không sẽ phải cạnh tranh với những đơn vị khác cùng bán dịch vụ cho dự án.

Có ba tầng khớp cần đạt lần lượt. Khớp dự án và cộng đồng: dự án đủ hấp dẫn để lập trình viên đóng góp và xây thêm sản phẩm quanh nó. Khớp sản phẩm và thị trường: có người thật dùng và nhu cầu mạnh. Khớp giá trị và thị trường: tìm được lời hứa giá trị mà khách mục tiêu sẵn lòng trả tiền. Nhiều dự án dừng ở tầng một vì ngỡ lượt tải là doanh thu tương lai.

Mô hình hợp nhất ở năm hoàn cảnh: hạ tầng nằm sâu trong hệ thống của khách; công cụ cho lập trình viên cần đọc mã để gỡ lỗi; sản phẩm xử lý dữ liệu nhạy cảm, nơi mở mã giúp xây niềm tin; lĩnh vực an ninh hoặc tuân thủ, nơi người ngoài kiểm tra được mã; và sản phẩm có bậc miễn phí, nơi bậc cao là bản độc quyền. Chọn mô hình hiếm khi là chọn một: thường là xếp tầng, open core làm nguồn thu chính, lưu trữ hộ làm nguồn thứ hai, dịch vụ chuyên môn làm nguồn thứ ba.

Xây doanh nghiệp quanh một dự án mở

Quyết định đầu tiên là giấy phép, vì nó chi phối cách sản phẩm được dùng và chia sẻ. Giấy phép dễ dãi như MIT hay Apache dễ được doanh nghiệp lớn chấp nhận, nhưng cũng cho phép bên khác, kể cả nhà cung cấp đám mây, bán lại sản phẩm; giấy phép buộc chia sẻ lại hay hạn chế thương mại bảo vệ doanh thu nhưng làm chậm sự chấp nhận. Sau đó là làm sản phẩm thực thụ: tên, thương hiệu, tài liệu, quy trình phát hành. Công khai mã không đồng nghĩa công khai mọi thứ.

Hãy nói rõ với thị trường bạn cho không gì và bán gì. Thứ bán ra là phiên bản được chứng nhận, đóng gói, có bảo hành; sự mơ hồ gây hại hai chiều, vì cộng đồng nghĩ bạn lấy thứ họ đóng góp để thu lợi, còn khách doanh nghiệp không hiểu vì sao phải trả tiền. Một cách chia hợp lý là theo người mua: tính năng phục vụ lập trình viên cá nhân để mở, tính năng cho quản lý và lãnh đạo (phân quyền, kiểm toán, báo cáo) để trả phí, còn bản trả phí không giữ lại chức năng thiết yếu của lõi mở.

Nếu sản phẩm lắp từ nhiều thành phần mở, chọn thành phần là quyết định kinh doanh chứ không phải sở thích kỹ thuật: xét độ bền của dự án, giai đoạn phát triển, số người dùng và mức tham gia của chính đội phát triển vào hỗ trợ. Hãy đặt lịch thay những thành phần đã lỗi thời.

Phía người dùng: vì sao cần chính sách riêng

Với doanh nghiệp chỉ dùng phần mềm, lý do có chiến lược về mã nguồn mở rất thực tế: ngân sách bảo trì tăng, lệ thuộc nhà cung cấp độc quyền kéo theo chu kỳ nâng cấp tốn kém, được dùng thử trước khi chi tiền, được chỉnh mã theo nhu cầu và nhiều lỗi được cộng đồng vá sớm. Những lợi thế này chỉ nhận được khi quản trị có chủ đích.

Các rủi ro khi triển khai gom được thành năm cụm. Bảo mật và cập nhật: bản vá có thể do cộng đồng phát hành, nhưng không ai chịu trách nhiệm đưa nó vào hệ thống của bạn. Hỗ trợ và đào tạo: không có tổng đài, thường phải tìm lời giải trên diễn đàn. Tương thích: phần mềm độc quyền hiện có có thể không chạy cùng. Giấy phép và cộng đồng: phải đọc giấy phép khớp mục tiêu kinh doanh và chọn dự án còn người duy trì. Chi phí và chính sách: nhiều doanh nghiệp quên tính công quản trị và thiếu văn bản chính sách chung.

Mô hình cũng bị phê bình ở ba điểm. Doanh thu hạn chế nên hãng đầu tư cho đổi mới ít hơn đối thủ độc quyền. Sân chơi không cân vì hãng cạnh tranh với chính bản miễn phí của mình lẫn với sản phẩm độc quyền có doanh thu lớn hơn nhiều. Và nhiều hãng khó sống nổi bằng bán hỗ trợ, nên xu hướng là dùng mã mở làm nền cho dịch vụ trả theo kỳ; người mua cần cân nhắc sức bền của nhà cung cấp mình dựa vào.

Bản đồ các nhóm sản phẩm mở và phần cứng mở

Mã nguồn mở hiện diện ở hầu hết các tầng công nghệ: hạ tầng (hệ điều hành, máy chủ web, cơ sở dữ liệu, khung ứng dụng di động, phân tích dữ liệu lớn), ứng dụng (bộ văn phòng, kế toán, quản lý khách hàng, xây website, đồ họa, trò chơi, blockchain) và an ninh (quét lỗ hổng, mã hóa đĩa, quản lý mật khẩu).

Dùng danh mục này cần hai lưu ý. Nhãn mã nguồn mở bị dùng lỏng: nhiều tài liệu thương mại xếp cả phần mềm miễn phí vào nhóm này dù mã nguồn đóng, nên cách kiểm tra duy nhất là đọc giấy phép. Và một dự án có thể mở một phần: Android là dự án mở nhưng máy bán ra thường kèm nhiều phần mềm độc quyền. Ở hệ điều hành, bản mở rẻ, dễ tùy biến nhưng cần kiến thức kỹ thuật và ít hỗ trợ tức thời; bản đóng có hỗ trợ và trải nghiệm thống nhất nhưng nhiều hạn chế.

Phần cứng mã nguồn mở là phần cứng công bố thiết kế để ai cũng nghiên cứu, sửa, sản xuất và bán. Cách kiếm tiền chia ba hướng: bán thiết bị (tự làm, đặt gia công hoặc làm cùng đối tác), bán chuyên môn quanh thiết bị (thiết kế cho hãng khác, tư vấn, huấn luyện, hội thảo), và nhận tiền từ cộng đồng hoặc từ thỏa thuận sản xuất, phân phối với công ty lớn. Logic vẫn là bán sự tiện lợi, chuyên môn và vị thế.

Cách áp dụng từng bước

• Bước 1: Xác định vai của bạn: nhà cung cấp một dự án mở, doanh nghiệp dùng phần mềm mở, hay đơn vị tích hợp.
• Bước 2 (bên bán): Chỉ rõ sản phẩm đang đáp ứng thứ nào trong bốn thứ khách có thể trả tiền: thời gian, sự an tâm, quy mô, niềm tin.
• Bước 3 (bên bán): Chọn giấy phép theo chiến lược: dễ dãi nếu ưu tiên chấp nhận rộng, hạn chế hoặc kép nếu cần bảo vệ doanh thu.
• Bước 4 (bên bán): Đo lượt tải, người dùng thường xuyên và tổ chức chạy thật để biết tỷ lệ chuyển đổi và nút thắt.
• Bước 5 (bên bán): Thử nguồn thu ít vốn nhất (hỗ trợ, triển khai, lưu trữ hộ) với vài khách trước khi đầu tư bản doanh nghiệp.
• Bước 6 (bên dùng): Lập danh mục phần mềm mở đang chạy, ghi giấy phép, phiên bản và người phụ trách cập nhật.
• Bước 7 (bên dùng): Tính tổng chi phí sở hữu (nhân sự, hạ tầng, đào tạo, hỗ trợ) của cả phương án mở và thương mại, không chỉ so tiền bản quyền.
• Bước 8 (bên dùng): Viết chính sách ngắn về ai được đưa phần mềm mở vào hệ thống, tiêu chí chọn và cách xử lý bản vá.
• Bước 9: Đọc lại giấy phép sau mỗi lần nâng cấp lớn, vì nhà cung cấp có thể đổi điều kiện.

Ví dụ quốc tế: thuê bao ở quy mô lớn và con lắc giấy phép

Red Hat là minh họa kinh điển cho việc bán công sức và sự an tâm: công ty phát triển sản phẩm trên nền phần mềm mở của cộng đồng, kiểm thử chuyên nghiệp rồi bán thuê bao hỗ trợ, đào tạo và tích hợp [3]. IBM công bố mua Red Hat với giá 34 tỷ USD ngày 28/10/2018 và hoàn tất ngày 9/7/2019, sau đó Red Hat hoạt động như một công ty con độc lập [3]. Thương vụ là một mốc cho thấy mô hình thuê bao trên nền mã mở có thể đạt quy mô rất lớn, dù mã nguồn ai cũng tải được.

Chuyện giấy phép cho thấy áp lực từ nhà cung cấp đám mây. Elasticsearch dùng Apache 2.0 đến trước bản 7.11; tháng 1/2021 Elastic chuyển sang SSPL và Elastic License, vì cho rằng Amazon Web Services cung cấp sản phẩm thành dịch vụ mà thiếu sự cộng tác đủ mức. AWS tách nhánh, đến tháng 4/2021 đặt tên OpenSearch; tháng 8/2024 Elastic thêm AGPL làm lựa chọn thứ ba [2]. Redis đi vòng tương tự: tháng 3/2024 chuyển sang RSALv2 và SSPLv1, nhánh Valkey do Amazon, Google, Oracle lập ra đời, rồi ngày 1/5/2025 Redis 8 phát hành với AGPLv3 là một lựa chọn [4]. Đổi giấy phép là đòn mạnh nhưng có giá: đối tác lớn có thể tách đi, và hãng phải điều chỉnh lại.

Tình huống áp dụng tại Việt Nam

NukeViet là hệ quản trị nội dung (content management system) mã nguồn mở do người Việt phát triển. Theo bài trình bày năm 2013 của tổng giám đốc VINADES, công ty lập năm 2010 với ba thành viên sáng lập và dành 20% cổ phần cho cộng đồng; hệ sinh thái có hơn 50 doanh nghiệp làm gia công, sản phẩm, dịch vụ; từ tháng 2/2013 NukeViet còn được cung cấp dưới dạng dịch vụ trọn gói (SaaS), chạy song song việc phát hành phần mềm để hỗ trợ tài chính cho phát triển [5].

Năm 2019, chủ tịch VFOSSA, tổ chức cộng đồng phần mềm tự do nguồn mở Việt Nam, cho biết cộng đồng NukeViet có khoảng 60.000 thành viên và mô tả mô hình chung: phần mềm tải miễn phí, nhà cung cấp thu tiền từ triển khai, tùy biến, bảo trì [6]. Cả hai nguồn đều không công bố doanh thu nên bài không đánh giá hiệu quả tài chính.

Viindoo cho thấy bản địa hóa là khoảng trống có thể khai thác. Odoo, phần mềm quản trị doanh nghiệp, có bản Community miễn phí theo giấy phép LGPLv3 và bản Enterprise trả phí. Theo bài đăng năm 2022 (cập nhật 2023) của chính Viindoo, công ty xây trên bản Community, bổ sung phân hệ kế toán theo Thông tư 133 và 200 cùng quản lý nhân sự, tính lương theo đặc thù Việt Nam, và liệt kê các mảng dịch vụ gồm tư vấn triển khai, tùy chỉnh, điện toán đám mây, chợ ứng dụng [7]. Nội dung do nhà cung cấp tự đăng và không nêu cơ cấu doanh thu, nên nhận xét về hạn chế của Odoo gốc chưa được kiểm chứng.

Ở tầng vận hành, nhà cung cấp đám mây trong nước bán sự tiện lợi trên nền cơ sở dữ liệu mở. Trang sản phẩm vDB của VNG Cloud nêu hỗ trợ nhiều hệ quản trị như MySQL, PostgreSQL, kèm sao lưu tự động hằng ngày, sao lưu theo yêu cầu và khôi phục dữ liệu [8]. Khách trả cho phần vận hành chứ không cho mã; trang không hiển thị giá nên bài không so sánh với tự vận hành.

Về chính sách, Thông tư 20/2014/TT-BTTTT đặt tiêu chí cho phần mềm nguồn mở được ưu tiên mua sắm trong cơ quan nhà nước: phù hợp nghiệp vụ, tương thích hệ thống, bảo đảm quyền sử dụng, sửa đổi, phân phối lại, cung cấp mã nguồn và bản cài đặt miễn phí, ưu tiên có tài liệu tiếng Việt, và đạt ngưỡng bền vững theo hai thang điểm PoF (từ 50 điểm trở xuống) và OSMM (từ 60 điểm trở lên) [9]. Tại hội thảo ngày 14/12/2010 của Bộ Thông tin và Truyền thông, bốn phần mềm OpenOffice, Unikey, Firefox, Thunderbird được nêu là đã cài ở mức 30–50% trong cơ quan nhà nước (nguồn không nêu mẫu số), cùng các rào cản như thiếu chuẩn mở, cơ chế tài chính và định mức [10].

Sai lầm thường gặp, giới hạn và khi nào không nên dùng

Sai lầm lớn nhất của bên bán là coi lượt tải là doanh thu: người tải đông nhưng nếu không có kênh chuyển đổi và không có thứ gì đáng trả tiền hơn bản miễn phí thì tỷ lệ trả tiền gần bằng không. Tiếp theo là cân bằng sai: cho quá nhiều thì không còn lý do mua, cho quá ít thì cộng đồng rời đi, còn đổi giấy phép đột ngột hoặc không giải thích sẽ khiến họ sẵn sàng tách nhánh.

• Bên dùng chỉ so tiền bản quyền, bỏ qua nhân sự quản trị, đào tạo và thời gian khắc phục sự cố.
• Dùng thành phần mà không biết giấy phép: một số giấy phép yêu cầu công bố lại mã nếu bạn sửa đổi rồi phân phối.
• Chọn dự án sôi nổi nhất thay vì dự án còn người duy trì và có lịch cập nhật bảo mật đều.
• Giao hệ thống quan trọng cho một người duy nhất hiểu, rồi mất người đó.

Có những hoàn cảnh nên cân nhắc lại. Nếu lợi thế cạnh tranh nằm ở thuật toán hay dữ liệu nội bộ cần giữ kín, mở mã đồng nghĩa với trao nó cho đối thủ. Nếu khách hàng không có nhân sự kỹ thuật, dịch vụ trọn gói hợp hơn việc phát hành mã. Nếu bạn không có người cập nhật bản vá hoặc không chấp nhận gián đoạn, hãy mua gói có cam kết mức dịch vụ (SLA) của một nhà cung cấp.

Kế hoạch thử nghiệm 2–4 tuần và câu hỏi tự kiểm

• Tuần 1: Kiểm kê phần mềm mở đang chạy (website, cơ sở dữ liệu, công cụ nội bộ), ghi giấy phép, phiên bản, người phụ trách.
• Tuần 2: Chọn một hệ thống quan trọng, tính tổng chi phí sở hữu ba năm cho phương án mở và phương án thương mại.
• Tuần 3: Soạn chính sách một trang về lựa chọn, cập nhật, xử lý sự cố phần mềm mở, rồi nhờ bộ phận IT và pháp chế góp ý.
• Tuần 4 (nếu là bên bán): Chào gói hỗ trợ hoặc lưu trữ hộ cho ba khách đang dùng bản miễn phí và ghi lại lý do họ trả tiền hay không.

Sau bốn tuần, hãy tự trả lời ba câu hỏi dưới đây. Câu nào chưa trả lời được cho biết chỗ cần làm tiếp: thiếu số liệu về chuyển đổi, thiếu người phụ trách bản vá hoặc chưa hiểu điều khoản giấy phép đang dùng.

• Sản phẩm của tôi bán thứ gì mà mã nguồn miễn phí không tự mang lại?
• Nếu nhà cung cấp đám mây bán lại sản phẩm của tôi, phần nào của doanh thu còn lại?
• Nếu nhà cung cấp phần mềm mở tôi đang dùng đổi giấy phép vào tháng sau, tôi có phương án nào?

Kết luận

Mã nguồn mở đã thành lựa chọn chiến lược cho cả bên bán lẫn bên mua, nhưng không có mô hình thần kỳ. Doanh nghiệp thành công thường xếp tầng nhiều nguồn thu, đo được chuyển đổi từ người dùng sang khách và thận trọng với giấy phép; doanh nghiệp dùng nên coi phần mềm mở là tài sản cần quản trị, không phải món quà. Ở Việt Nam các mảnh ghép đã xuất hiện, nhưng các nguồn đã kiểm chưa cho thấy số liệu doanh thu công khai, nên mọi so sánh hiệu quả vẫn cần thêm dữ liệu.

Nguồn và phương pháp

Bài là tổng hợp và phân tích có hỗ trợ AI, diễn đạt lại bằng lời riêng, không phải bản dịch. Bài dựa trên tài liệu Open-Source Business Models (Super Guide của Daniel Pereira, toàn bộ tài liệu 134 trang); dàn ý, so sánh, nhận định và ví dụ là của bài này. Một số ví dụ và nhãn phân loại trong tài liệu nguồn không khớp thông tin công khai nên không được dùng. Các dữ kiện về Việt Nam và ví dụ quốc tế lấy từ nguồn web đánh số trong bài, truy cập ngày 20/10/2026.

Điều chưa kiểm chứng: số liệu NukeViet là lời trình bày năm 2013 của người điều hành công ty nên có thể đã cũ; tỷ lệ 30–50% năm 2010 không rõ mẫu số; nội dung Viindoo do nhà cung cấp tự đăng; mô tả các giấy phép (GPL, AGPL, Commons Clause, Business Source License) và ví dụ Android chỉ là tóm lược kiến thức chung, cần đọc văn bản giấy phép và hỏi luật sư trước khi quyết định. Bạn nên tìm tài liệu gốc để đọc đầy đủ.