Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Các bên liên quan
  3. /Elasticsearch đổi giấy phép (2021) và nhánh Open…
Số 205Quản lý Các bên liên quan

Elasticsearch đổi giấy phép (2021) và nhánh OpenSearch: khi lợi ích của công ty chủ quản và cộng đồng mã nguồn mở xung đột

Tháng 1/2021, Elastic chuyển Elasticsearch và Kibana khỏi giấy phép Apache 2.0 vì lo các nhà cung cấp đám mây bán dịch vụ mà không đóng góp lại. AWS đáp lại bằng việc phát hành nhánh OpenSearch từ phiên bản 7.10, sau này chuyển sang quỹ độc lập thuộc Linux Foundation, còn Elastic thêm lại AGPL năm 2024. Phân tích quản lý các bên liên quan trong một hệ sinh thái mở.

HP
Nguyễn Thu Hà, PMP
24/09/2026
4 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Elasticsearch và Kibana là hai phần mềm tìm kiếm và trực quan hoá dữ liệu mã nguồn mở rất phổ biến, do công ty Elastic phát triển. Công ty kiếm tiền từ đăng ký, tính năng trả phí và dịch vụ đám mây của chính mình. Cùng lúc, các nhà cung cấp đám mây lớn, trong đó có Amazon, cung cấp Elasticsearch dưới dạng dịch vụ quản lý.

Theo bài đăng của Elastic ngày 14/1/2021, công ty cho rằng một số nhà cung cấp đám mây bán các sản phẩm mã nguồn mở của họ như dịch vụ mà không đóng góp lại, làm lệch nguồn tiền dành cho phát triển. Từ phiên bản 7.11, mã nguồn chuyển từ Apache 2.0 sang giấy phép kép SSPL và Elastic License. Elastic nhấn mạnh phần lớn người dùng không bị ảnh hưởng và việc phát triển vẫn công khai.

Phản ứng của các bên liên quan:

  • AWS cho rằng thay đổi chấm dứt tư cách mã nguồn mở của hai sản phẩm, cam kết giữ một bản được cấp phép Apache 2.0 và phát hành nhánh dựa trên phiên bản 7.10. Ngày 12/4/2021 OpenSearch ra mắt, kèm cam kết tương thích API và xây dựng quản trị chung với cộng đồng.
  • Một số công ty (Logz.io, CrateDB, Red Hat…) bày tỏ quan tâm tham gia duy trì nhánh mới.
  • Tháng 9/2024, Elastic bổ sung AGPLv3 như một lựa chọn cho phần lõi của Elasticsearch; cùng tháng, Linux Foundation và AWS thông báo thành lập Quỹ phần mềm OpenSearch, chuyển quyền sở hữu từ Amazon sang quỹ.

Phân tích nguyên nhân theo chuẩn PMP

  • Mâu thuẫn lợi ích giữa các bên liên quan không được giải quyết từ đầu

    Công ty chủ quản cần doanh thu, nhà cung cấp đám mây muốn dùng miễn phí, cộng đồng muốn mã nguồn mở thật sự. Sổ đăng ký bên liên quan phải ghi rõ xung đột này như một rủi ro có xác suất cao, thay vì để nó tự bùng phát sau nhiều năm.

  • Thay đổi quản trị đơn phương làm mất niềm tin của cộng đồng đóng góp

    Người đóng góp ngoài công ty đã đầu tư công sức dựa trên một giấy phép nhất định. Đổi giấy phép mà không có quy trình tham vấn khiến họ cảm thấy cam kết bị thay đổi, và tạo cơ hội để đối thủ có ngân sách lớn nắm quyền kể chuyện "ai là mã nguồn mở thật".

  • Thiếu cơ chế quản trị trung lập (governance)

    Khi một công ty đơn lẻ sở hữu thương hiệu, kho mã và giấy phép, mọi bên khác đều có quyền lực thấp hơn. Nhánh OpenSearch cuối cùng chuyển sang quỹ trung lập, cho thấy các bên đều cần một cơ cấu quản trị mà không ai sở hữu một mình.

  • Phản ứng của bên có quyền lực lớn gây phân mảnh hệ sinh thái

    Hai nhánh song song tạo chi phí cho người dùng cuối (chọn nhánh nào, tương thích tới đâu) và cho các nhà tích hợp. Đây là hệ quả của việc không đạt được thoả thuận về tham gia và quyền lợi giữa các bên mạnh nhất.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Lập bản đồ bên liên quan của hệ sinh thái, không chỉ của công ty

      Tách nhóm người đóng góp, nhà cung cấp đám mây, đối tác tích hợp, khách hàng trả phí và khách hàng dùng miễn phí; xác định lợi ích, quyền lực và mức độ tham gia mong muốn của từng nhóm.

    2. 2

      Bước 2: Thiết kế mô hình bền vững đàm phán trước khi khủng hoảng

      Đối thoại sớm với các nhà cung cấp lớn về cách đóng góp (tài trợ, nhân lực, thương hiệu), trước khi cân nhắc thay đổi giấy phép:

      • Thoả thuận đạt được

        Nhà cung cấp lớn đóng góp theo cam kết thỏa thuận (tài chính hoặc kỹ sư) và giấy phép giữ nguyên.

      • Đàm phán kéo dài

        Các bên đồng ý nguyên tắc nhưng chưa thống nhất mức đóng góp; đặt mốc thời gian và người điều phối trung lập.

      • Đổi giấy phép

        Chỉ cân nhắc khi đối thoại thất bại; kèm tham vấn cộng đồng, thời gian chuyển tiếp và cam kết rõ về những gì giữ mở.

    3. 3

      Bước 3: Đưa quản trị sang cơ cấu trung lập khi hệ sinh thái đủ lớn

      Ban kỹ thuật có đại diện nhiều tổ chức, quy trình đóng góp công khai, thương hiệu thuộc tổ chức trung lập.

    4. 4

      Bước 4: Công bố lộ trình tương thích để giảm chi phí phân mảnh

      Nếu có nhánh song song, cam kết giữ giao diện lập trình tương thích đến một mốc và công bố cách di chuyển để người dùng cuối không bị bắt buộc chọn phe.

    PM Takeaway (Bài học rút ra)

    Trong dự án mã nguồn mở, nhà tài trợ, người đóng góp và đối thủ cạnh tranh cùng nằm trong một hệ sinh thái. Xung đột lợi ích cần được đàm phán sớm và quản trị trung lập; thay đổi đơn phương có thể giải quyết bài toán doanh thu nhưng làm phân mảnh cộng đồng.

    Nguồn tham khảo

    • Elastic — Doubling down on open, Part II
    • AWS Open Source Blog — Stepping up for a truly open source Elasticsearch
    • Wikipedia — OpenSearch (software)
    #Quản lý bên liên quan#Mã nguồn mở#Elastic#AWS#Giấy phép phần mềm#Quản trị cộng đồng

    Nguồn: Elastic — Doubling down on open, Part II (thông báo đổi giấy phép tháng 1/2021) ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Bạn là PM của một dự án mã nguồn mở do công ty bạn bảo trợ. Một nhà cung cấp đám mây lớn đang bán dịch vụ dựa trên dự án mà không đóng góp, trong khi cộng đồng đóng góp lo ngại thay đổi giấy phép. Bước đầu tiên hợp lý là gì?

    Bạn chọn phương án nào?

    Nếu bạn là PM của dự án mã nguồn mở có nhà tài trợ chính và một nhà cung cấp đám mây khổng lồ đang hưởng lợi, bạn chọn hướng nào để giữ dự án bền vững?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Số 201Quản lý Các bên liên quan

    Digg v4 (2010): viết lại toàn bộ sản phẩm trong một lần ra mắt và cuộc nổi dậy của chính người dùng nòng cốt

    Tháng 8/2010, mạng tin xã hội Digg ra mắt phiên bản 4 với nền tảng viết lại và nhiều tính năng quen thuộc bị gỡ bỏ. Người dùng nòng cốt tổ chức "ngày bỏ Digg", nhà xuất bản báo cáo lượng truy cập giới thiệu giảm, và lưu lượng mất hơn một phần tư chỉ sau một tháng. Phân tích dưới góc nhìn quản lý các bên liên quan: ai là người tạo ra giá trị của nền tảng, và họ được tham vấn đến đâu.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Số 202Quản lý Các bên liên quan

    Netflix và Qwikster (2011): tăng giá, tách dịch vụ thành hai trang và bài học về thông điệp tới khách hàng

    Năm 2011, Netflix tăng giá gói kết hợp DVD và phát trực tuyến, rồi vài tuần sau công bố tách DVD thành dịch vụ riêng Qwikster với trang web và tài khoản riêng. Khách hàng coi đó là tăng giá và gây bất tiện, hàng trăm nghìn thuê bao rời đi. Ngày 10/10/2011, Netflix huỷ Qwikster. Phân tích về cách giải thích thay đổi, kiểm tra phản ứng của khách hàng trước khi cam kết.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận09/10/2026
    Số 200Quản lý Các bên liên quan

    Wikipedia VisualEditor (2013): đưa trình soạn thảo trực quan thành mặc định và phản ứng của cộng đồng biên tập viên

    Wikimedia Foundation phát triển VisualEditor để hạ rào cản cho người mới. Tháng 7/2013, bản beta trở thành trình soạn mặc định cho người dùng đăng nhập trên Wikipedia tiếng Anh, nhưng cộng đồng phàn nàn về lỗi và độ ổn định; đến tháng 9/2013 phải chuyển sang chế độ tự chọn. Nghiên cứu 2015 không thấy lợi ích năng suất. Bài học về quản lý bên liên quan khi người dùng chính cũng là người đóng góp nội dung.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận05/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)