Phân biệt phát triển trả phí, hỗ trợ, subscription, SaaS và open core; lập phạm vi dịch vụ, tính chi phí DEMO và đọc SLI, SLO, SLA bằng bằng chứng.
Một nhóm triển khai công cụ nguồn mở cho văn phòng. Mã tải không mất tiền, nhưng việc cài đặt, chuyển dữ liệu, hỗ trợ người dùng và xử lý sự cố vẫn cần người làm. Khi công cụ trở thành dịch vụ cho khách hàng, nhóm còn phải xác định họ đang bán điều gì, hứa hỗ trợ tới đâu và ai chịu trách nhiệm khi yêu cầu ngoài giờ xuất hiện.
Bài 054.1, Mô hình kinh doanh phát triển phần mềm, tham chiếu Open Source Essentials 050-100 trang in 151–163, viết độc lập và đối chiếu ngày 23/10/2026. Bạn cần hiểu giấy phép, dependency và mô hình cloud. Sau bài, bạn nên phân biệt nguồn doanh thu với quyền phần mềm, nhận diện chi phí và tách SLI, SLO, SLA qua bài tập DEMO. Các số là giả định học tập, không phải báo giá hay dự báo lợi nhuận.
Có thể thu phí công việc phát triển, bản phân phối, hỗ trợ, đào tạo hoặc vận hành trong phạm vi quyền và điều kiện áp dụng. Không nên dạy rằng doanh nghiệp nguồn mở chưa bao giờ có thể kinh doanh bằng việc cấp quyền theo lựa chọn thương mại. Dual licensing là một khả năng nếu bên cung cấp có đủ quyền để đưa ra các lựa chọn; từng hợp đồng và phần mã cần được xem riêng.
Cũng không thể khẳng định phần mềm độc quyền bán license luôn hết lợi nhuận hoặc mọi người dùng đều chỉ muốn trả một khoản nhỏ. Ở mức Essentials, hãy hỏi giá trị mà khách hàng nhận được và công việc cần duy trì, thay vì học một kết luận chung về thành công của cả ngành.
Nguồn mở có thể giúp khách hàng xem mã, thuê đơn vị khác sửa hoặc tiếp tục dùng theo license. Nhưng khả năng đó còn đòi hỏi source, dependency, kỹ năng và nguồn lực phù hợp. Một dự án bị bỏ bảo trì không tự sinh nhóm kế nhiệm. Kế hoạch tiếp nhận phải xét cả khả năng kỹ thuật lẫn người sẽ thực hiện.
Phát triển có trả phí nghĩa là khách hàng chi trả cho một tính năng, tích hợp hoặc sửa lỗi có phạm vi được thỏa thuận. Cần xác định tiêu chí nghiệm thu, quyền với phần đóng góp và chi phí bảo trì sau bàn giao. “Đã lập trình xong” chưa trả lời ai xử lý khi dependency cập nhật làm tích hợp lỗi.
Hỗ trợ có trả phí tập trung vào khả năng tiếp cận chuyên gia, phạm vi sản phẩm và thời gian phục vụ. Đào tạo hoặc tư vấn giúp khách hàng vận hành, chuyển đổi quy trình và hiểu hệ thống. Red Hat mô tả subscription của mình gắn với hỗ trợ, tài nguyên bảo mật và vòng đời; đây là ví dụ về giá trị dịch vụ, không phải khuyến nghị mua một gói cụ thể.
Dịch vụ hosting hoặc SaaS thu phí việc vận hành một ứng dụng cho người dùng. Khách hàng có thể tiết kiệm một phần công quản trị hạ tầng, nhưng vẫn cần quản lý dữ liệu, tài khoản và cấu hình theo phạm vi dịch vụ. Giấy phép ứng dụng và điều khoản dịch vụ là hai tài liệu cần phân biệt khi lập hồ sơ.
Phần mở rộng trả phí, phiên bản community/enterprise và freemium có thể xuất hiện cùng nhau. Freemium nói về phần dùng không thu phí và phần có thu phí; một bản dùng thử hết hạn không phải cùng hành vi với tier miễn phí lâu dài. Tên “enterprise” cũng không tự cho biết license hoặc chức năng nào mở. Hãy xem từng thành phần, giới hạn và điều kiện.
Nội dung mở có thể đi cùng dịch vụ in ấn, hướng dẫn hoặc tài trợ; phần mềm cũng có thể được phát triển để phục vụ sản phẩm khác. Đừng suy ra không thu tiền trực tiếp từ một repository thì không có mô hình kinh tế. Thời gian của nhân sự và hạ tầng vẫn cần được tài trợ theo cách nào đó.
Open core thường kết hợp phần lõi nguồn mở với các phần có điều kiện khác. GitLab tự mô tả mô hình của họ gồm mã nguồn mở, tính năng source-available và subscription trả phí. Phần có thể xem source chưa chắc là phần mềm nguồn mở theo định nghĩa OSI. Không gọi toàn bộ gói “mở hoàn toàn” nếu bằng chứng chỉ cho thấy lõi mở.
Ngược lại, cũng không kết luận open core luôn không đem lại lợi ích nguồn mở hoặc chắc chắn không tạo cộng đồng. Cần hỏi phần nào dùng được, sửa được, phân phối được và phần nào cần thỏa thuận riêng.
Một bảng đánh giá hữu ích ghi chức năng bắt buộc, bản cung cấp, license và đường chuyển đổi. Nếu tính năng xuất dữ liệu hoặc xác thực cần tier khác, ghi nó vào phương án; không dùng tên community/enterprise để suy đoán. Việc tổ chức chọn mô hình nào cần dựa trên nhu cầu và bằng chứng, chưa thể quyết định từ bài nhập môn này.
Google SRE phân biệt ba khái niệm: SLI là chỉ số được định nghĩa để đo chất lượng dịch vụ; SLO là mục tiêu của chỉ số trong phạm vi đã nêu; SLA là thỏa thuận có các hệ quả liên quan mức dịch vụ. Không chỉ ghi “99%” mà thiếu cách tính, cửa sổ đo và yêu cầu được đưa vào.
Ví dụ DEMO: tỷ lệ yêu cầu tra cứu hợp lệ trả kết quả thành công trong bộ 1.000 yêu cầu là một SLI; mục tiêu ít nhất 99% trên bộ đó là SLO giả định. Nó không tự tạo hợp đồng bồi thường. Thời gian phản hồi yêu cầu hỗ trợ cũng khác thời gian khắc phục xong hoặc tỷ lệ khả dụng của ứng dụng.
Khi xem một cam kết, ghi nguồn đo, phạm vi giờ phục vụ, cách phân cấp sự cố và trách nhiệm hai phía. Đừng hứa giải quyết mọi lỗi trong cùng một khoảng chỉ vì có mục tiêu phản hồi ban đầu. Bài tập không tạo SLA pháp lý hoặc kiểm thử độ sẵn sàng production.
Chi phí ban đầu có thể gồm khảo sát, tích hợp, chuyển dữ liệu, kiểm thử và tài liệu. Chi phí định kỳ gồm hosting, giám sát, cập nhật, hỗ trợ, sao lưu và diễn tập phục hồi. Nếu duy trì nhánh sửa riêng, còn có công áp lại patch hoặc giải quyết xung đột khi nâng bản gốc. Đưa các công việc này vào hồ sơ trước khi so giá.
Đóng góp upstream có thể giảm gánh duy trì riêng khi thay đổi được chấp nhận, nhưng vẫn cần thời gian chuẩn bị, review và phản hồi. Không có bảo đảm mọi patch sẽ được nhận hoặc theo lịch khách hàng. Hướng dẫn khởi đầu dự án của GitHub nhấn mạnh tài liệu, hướng dẫn đóng góp và các công việc chuẩn bị cộng đồng. Chỉ đưa mã lên mạng chưa tạo đội ngũ bảo trì sẵn sàng.
Bảo mật và quyền riêng tư cũng là công việc vận hành: phân loại dữ liệu, quản lý quyền, review dependency và xử lý thông tin trong ticket hỗ trợ. Khi khách hàng gửi log, cần quy trình giới hạn người xem và loại bí mật không cần thiết. Không yêu cầu họ đăng token hoặc dữ liệu cá nhân vào issue công khai để đổi lấy hỗ trợ.
Giả định nhóm cung cấp cài đặt và hỗ trợ một công cụ tra cứu nội bộ. Tạo hồ sơ riêng gồm giá trị, phạm vi, chi phí và bằng chứng nghiệm thu. Không lựa chọn nhà cung cấp thật hoặc chào giá ra ngoài. Mục tiêu là làm rõ công việc, không tối ưu lợi nhuận cho một doanh nghiệp thực tế.
Ghi ba đầu ra: bộ cài chạy trong môi trường đã nêu, tài liệu vận hành và một đầu mối hỗ trợ trong giờ thỏa thuận. Ghi riêng phần khách hàng làm: cung cấp môi trường, cấp tài khoản theo quy trình và xác nhận dữ liệu mẫu. Một yêu cầu phát triển tính năng mới được ghi ngoài phạm vi hỗ trợ ban đầu.
Tiêu chí đạt là mỗi đầu ra có cách xác nhận. Chẳng hạn, cài đặt cần ca tra cứu DEMO với kết quả xác định, còn tài liệu cần người nhận làm được bước phục hồi đã nêu.
Dùng DEMO làm đơn vị học tập. Giả định 12 giờ triển khai và 3 giờ review, đều có mức 2 DEMO/giờ. Tổng ban đầu là 30 DEMO. Mỗi tháng có 4 giờ hỗ trợ với cùng mức và 5 DEMO cho hạ tầng giả định, tổng 13 DEMO/tháng. Ba tháng đầu, gồm công ban đầu, là 69 DEMO.
Phép tính được kiểm lại bằng Python Decimal; không lấy số từ bảng giá thị trường. Nó chưa có thuế, dự phòng, công trực đêm hoặc các hạng mục ngoài giả định. Nếu số giờ hỗ trợ tăng, tính lại chi phí thay vì mặc định mã nguồn miễn phí sẽ bù mọi công việc phát sinh. Không gọi 69 DEMO là giá bán bắt buộc hoặc lợi nhuận.
Giả định 980 trong 1.000 yêu cầu tra cứu hợp lệ thành công. Tỷ lệ là 98%, chưa đạt mục tiêu DEMO 99%. Bản kiểm chứng chỉ tính số học từ fixture, không phát sinh 1.000 request hoặc đo dịch vụ thật. Ghi rõ loại dữ liệu này trong báo cáo để người đọc không hiểu đó là kết quả load test.
Đặt câu hỏi trước khi sửa: yêu cầu nào được tính thành công, nguồn ghi nhận ở đâu, lỗi nào bị loại và khoảng thời gian nào được xét? Nếu chưa định nghĩa, chưa thể dùng con số để tranh luận một cam kết. Không đổi mẫu số nhằm làm kết quả đẹp hơn mà không sửa định nghĩa và lưu lý do.
Giả định khách hàng thêm yêu cầu hỗ trợ cuối tuần và tích hợp một hệ thống khác. Ghi công việc, nhân sự và bằng chứng cần bổ sung; đánh dấu phải xem lại phạm vi, thời gian và chi phí.
Cuối cùng thêm tình huống upstream ngừng phát hành. Ghi phương án xem xét fork, nhà cung cấp thay thế hoặc chuyển công cụ, cùng kỹ năng và dữ liệu cần giữ. Có source là một lợi thế cho lựa chọn, nhưng không phải bằng chứng đã có đội tiếp quản. Kết quả mong đợi là danh sách hành động có điều kiện.
Hồ sơ DEMO được rà soát logic và số học, chưa khảo sát khách hàng, ký hợp đồng, mua dịch vụ hay đo sản phẩm thực tế. Bài tiếp theo sẽ dùng cách phân tích này để đánh giá nhà cung cấp mà vẫn giữ rõ trách nhiệm nội bộ.
Chọn chat, email, issue, ticket và tài liệu theo mục tiêu; hiểu federation, wiki, CMS, DMS, rồi lập báo cáo, ghi chú quyết định và dàn ý tài liệu DEMO.
Phân biệt Git với nền tảng hosting, working tree, index, commit, branch và tag; thực hành nhánh, fast-forward, tag và revert trong repository riêng.
Phân biệt IDE, build, linter, debugger, các loại test và môi trường CI/CD; chạy lab Node để thấy cú pháp hợp lệ vẫn có thể sai hành vi rồi khôi phục.
Nhận diện maintainer, contributor, quản trị và tài trợ; đọc DCO, CLA, quy tắc ứng xử, rồi soạn phản hồi đóng góp tài liệu qua tình huống DEMO riêng.