Học Open Source Essentials qua 18 mục tiêu: phần mềm, giấy phép, nội dung, kinh doanh, cộng đồng và Git; lập hồ sơ bằng chứng, nhận biết SBOM và review mã AI.
Bạn nhận một công cụ có mã nguồn công khai, một bản build tải sẵn và vài ảnh minh họa trong README. Nhóm muốn dùng nội bộ, sửa lỗi rồi gửi bản tùy biến cho khách. Câu hỏi cần trả lời không chỉ là “chạy được không”: còn phải biết nguồn gốc phiên bản, giấy phép từng thành phần, trách nhiệm bảo trì và cách đóng góp thay đổi trở lại dự án.
Đây là lộ trình Open Source Essentials 050-100, dành cho người mới CNTT và IT Help Desk muốn phối hợp được với lập trình viên, người quản lý sản phẩm và bộ phận phụ trách giấy phép. Bài viết độc lập dựa trên khung PDF bạn đã gửi, đối chiếu mục tiêu LPI và nguồn chính thức ngày 23/10/2026. Nhánh có 18 bài mục tiêu, cộng bài lộ trình này.
Sau nhánh học, bạn nên lập được một hồ sơ nhỏ cho phần mềm đang dùng: đúng sản phẩm và phiên bản, nguồn tải, thành phần phụ thuộc, giấy phép, vòng đời hỗ trợ, cách báo lỗi và người chịu trách nhiệm cập nhật. Bạn cũng cần nhận ra lúc nào kết luận vượt quá bằng chứng, chẳng hạn chỉ nhìn nhãn GitHub “public” rồi cho rằng được phép phân phối mọi thứ bên trong.
Mục tiêu là hiểu và thực hành ở mức Essentials. Bạn không cần hoàn thành khóa lập trình trước khi đọc phần giấy phép hoặc cộng đồng. Với lab Git và công cụ phát triển, kỹ năng terminal, tệp và trình soạn thảo sẽ hữu ích; các bước sẽ được giải thích trong bài tương ứng. Bạn có thể dùng ví dụ giấy tờ trước rồi quay lại lab mã nguồn khi đã có nền tảng.
Các bài giấy phép trình bày khái niệm và cách đọc nguồn. Với một quyết định phân phối thực tế, kết quả còn phụ thuộc văn bản giấy phép chính xác, phiên bản, cách kết hợp và hành vi sử dụng. Hồ sơ học tập cần nêu phần chưa rõ để người có trách nhiệm xem xét, không biến một bảng so sánh ngắn thành phán quyết cho mọi sản phẩm.
PDF 050-100 tiếng Việt là khung tham chiếu để không bỏ sót chủ đề. Trang mục tiêu LPI đang công bố code 050-100, version 1 và thông tin phiên bản 1.0.0 tại ngày đối chiếu. Thực hành hiện hành bổ sung Git workflow, dependency inventory, SBOM và trách nhiệm khi dùng mã do AI hỗ trợ. Ba lớp này được ghi riêng để người học không nhầm phần mở rộng với thuật ngữ bắt buộc của kỳ thi.
Lộ trình không hứa đỗ và không dự đoán số câu của từng bài. Nếu định đăng ký thi, kiểm tra trực tiếp trang LPI ở thời điểm đăng ký. Một điểm chưa nhất quán trên trang được đọc là trọng số 052.1 ở heading khác bảng chi tiết; chuỗi không tự chọn một số rồi quảng bá là thông tin thi đã xác minh.
Các bài được viết mới cùng tình huống, lab, câu hỏi và hình ảnh độc lập. PDF mang CC BY-NC-ND; có thể dẫn nguồn và dùng làm khung kiến thức, nhưng không đăng lại một bản dịch sửa hoặc bản cải biên PDF như sản phẩm của chuỗi. Chính việc phân biệt tài liệu tham khảo với tác phẩm xuất bản là một bài thực hành về nội dung mở.
Chặng 051 tạo nền về phần mềm, kiến trúc và nơi vận hành. Hãy phân biệt source, executable, thư viện, linking và runtime; sau đó đọc quan hệ client/server, module/API và cloud. Chưa cần thiết kế microservices cho một công cụ Help Desk nhỏ. Một sơ đồ đơn giản chỉ ra nơi chạy mã và nơi lưu dữ liệu đã có giá trị chẩn đoán.
Chặng 052 dành cho giấy phép phần mềm. Bạn sẽ phân biệt miễn phí về giá với các quyền của phần mềm tự do/mã nguồn mở, rồi đọc copyleft và permissive. Có source để xem chưa đủ theo định nghĩa Open Source của OSI. Bài học ưu tiên quyền và nghĩa vụ của văn bản cụ thể, tránh gọi một giấy phép là “không có điều kiện” chỉ vì nó ngắn.
Chặng 053 chuyển sang nội dung: tài liệu, ảnh, dữ liệu và các loại tài sản khác. Giấy phép của code không tự bao phủ mọi hình trong repository. Bạn sẽ đọc các tổ hợp Creative Commons, nhận biết điều kiện ghi công, chia sẻ tương tự, phi thương mại và không phái sinh, rồi xem các giấy phép nội dung khác. Cần xác định đúng tài sản trước khi so điều kiện.
Chặng 054 xem mô hình kinh doanh và quản lý rủi ro. Mã nguồn mở có thể gắn với dịch vụ trả phí, hỗ trợ, phân phối hoặc các mô hình khác. “Mở” không đồng nghĩa không có chi phí vận hành. Quyết định mua hỗ trợ hay tự vận hành nên xét năng lực cập nhật, thời gian phục hồi và trách nhiệm cụ thể, không chỉ giá tải về bằng không.
Chặng 055 học cách dự án phát triển và quản trị sản phẩm/cộng đồng. Người đóng góp có thể sửa tài liệu, tái hiện bug, thử bản phát hành hoặc cải thiện bản dịch, không chỉ viết tính năng. Quyền merge, quyền phát hành và quyền sở hữu nhãn hiệu có thể thuộc những chủ thể khác nhau. Đọc chính sách trước khi cho rằng một maintainer phải chấp nhận mọi đề xuất.
Chặng 056 đưa kiến thức vào công cụ phát triển, quản lý mã và giao tiếp. Git commit, branch, tag, review và issue giúp lưu bằng chứng thay đổi. Một patch nhỏ với bước tái hiện thường dễ xử lý hơn một mô tả “không hoạt động” thiếu phiên bản. Các lab cục bộ không tự gửi thông báo hay pull request tới cộng đồng thật.
Dependency và nguồn gốc phần mềm nối từ 051 sang công cụ 056. Một ứng dụng không chỉ gồm tệp bạn tự viết; còn thư viện, công cụ build và thành phần đi kèm. Ghi tên cùng phiên bản, nguồn lấy và vai trò của chúng là bước đầu để hiểu phần mềm thực sự được phân phối. Một danh sách không có phiên bản rất khó đối chiếu khi có bản vá hoặc advisory.
SBOM là bản kê thành phần phần mềm theo phạm vi và thời điểm xác định, có thể trao đổi bằng tiêu chuẩn như SPDX. Nó giúp trả lời “trong bản này có gì”, không tự chứng minh phần mềm an toàn, giấy phép tương thích hoặc dữ liệu đã đầy đủ. Lab nhập môn bắt đầu bằng bảng kiểm kê có nguồn; bài sau phân biệt bảng đó với một tài liệu đúng schema tiêu chuẩn, tránh đặt nhãn SBOM cho mọi tệp CSV.
Vòng đời hỗ trợ xuất hiện ở quản lý phát hành. Một repository archive, một nhánh EOL và một release có bản vá mới là ba tín hiệu khác nhau cần đọc đúng. Đừng xem nhiều sao hoặc hoạt động mạng xã hội là cam kết hỗ trợ. Ghi thời điểm kiểm tra, chính sách dự án và phương án thay thế nếu thành phần ngừng bảo trì.
Mã do AI hỗ trợ tạo được xem như mã cần review. Người gửi vẫn phải kiểm tra tính đúng, nguồn gốc khi xác định được, giấy phép liên quan, dữ liệu đưa vào công cụ và chính sách dự án về sử dụng AI. Một đoạn mã trông hợp lý không phải bằng chứng nó đã chạy hoặc được quyền phân phối. Những điểm này bổ sung vào quy trình đóng góp, không biến Essentials thành khóa quản trị AI nâng cao.
Tạo một thư mục ghi chú riêng, dùng dữ liệu giả lập. Bắt đầu với inventory.md cho thành phần, evidence.md cho nguồn và ngày kiểm tra, decisions.md cho quyết định có điều kiện, cùng thư mục lab. Chưa cần cài một nền tảng quản trị phức tạp; yêu cầu đầu tiên là người khác đọc được điều gì đã quan sát và điều gì chỉ là giả định.
Mỗi ghi chép nên có tên sản phẩm, phiên bản/ref, URL nguồn chính thức, tệp LICENSE/NOTICE liên quan, cách dùng dự kiến và câu hỏi chưa giải quyết. Với tài sản có giấy phép khác nhau, tách dòng theo tài sản. Không đưa token, log có thông tin cá nhân hoặc database thật vào một issue công khai để làm bằng chứng.
Bạn có thể học theo sáu chặng liên tiếp, nhưng không cần ấn định số tuần giống nhau cho mọi người. Sau mỗi ba mục tiêu, dành một phiên để áp dụng vào hồ sơ. Nếu giải thích chưa được quyền phân phối hoặc cách tái hiện bug, quay lại đúng bài thay vì chỉ đánh dấu đã đọc. Tiêu chí là một sản phẩm nhỏ có thể kiểm tra, không phải số giờ ngồi trước tài liệu.
Tình huống: nhóm DEMO định dùng một tiện ích kiểm kê nội bộ, sửa một thông báo lỗi và gửi bản đóng gói cho một nhóm khác. Gói có source code, executable, dependency và một ảnh README. Chưa có quyết định phân phối thật hoặc repository cụ thể; đây là bài tập trên giấy để xác định câu hỏi cần thu thập trước.
Đầu tiên, vẽ source chuyển qua build thành artifact ở đâu, dependency nào được đóng gói và ai vận hành bản cuối. Tiếp theo ghi riêng giấy phép của code, dependency và ảnh. Nếu chưa có văn bản hoặc không biết phiên bản, ghi “chưa xác minh”, không chọn một giấy phép phổ biến để điền cho đủ. Cuối cùng lập hai đường công việc: kiểm tra kỹ thuật và kiểm tra quyền sử dụng/phân phối.
Một đầu ra đạt yêu cầu có ít nhất bốn nhóm tài sản, nguồn bằng chứng cần tìm cho từng nhóm, một người nhận trách nhiệm cập nhật và một phương án xử lý khi dự án upstream ngừng hỗ trợ. Với thay đổi thông báo lỗi, mô tả bước tái hiện, kết quả hiện tại, kết quả mong đợi và cách thử patch. Chưa gửi issue thật vì tình huống không có sản phẩm và người nhận xác định.
Đáp án không phải “được phân phối” hoặc “không được phân phối” từ vài dòng giả định. Đáp án tốt chỉ ra dữ liệu còn thiếu và cách tìm nó. Chẳng hạn cần bản LICENSE đúng release, danh sách dependency trong artifact và nguồn ảnh. Đây là cách tránh suy luận quá mức trước khi vào các bài giấy phép có nhiều điều kiện hơn.
Vì sao repository public chưa đủ để xác định quyền? Một bản kê dependency có thay việc đọc LICENSE không? Tại sao miễn phí tải về vẫn có chi phí vận hành? Người báo lỗi cần cung cấp gì để maintainer tái hiện? Khi dùng AI hỗ trợ patch, ai phải xác nhận kết quả test? Những câu hỏi này sẽ được trả lời dần qua 18 mục tiêu, với bằng chứng lưu trong hồ sơ học tập.
Bài định hướng này đã được rà soát như một tình huống trên giấy ngày 23/10/2026. Các lab Git, kiểm kê và review ở bài sau chưa được nhận là đã chạy tại đây. Khi hoàn thành nhánh, quay lại gói DEMO để thấy bạn có thể thay các ô “chưa xác minh” bằng nguồn, phép thử và quyết định có phạm vi rõ ràng.
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.