Vài nét về giấy phép nguồn mở mới của Zimbra Collaboration Suite

Giữa năm 2014, Zimbra Inc. chính thức công bố phiên bản 8.5 mới, phát hành theo giấy phép GPL v2 (phía server platform) và CPAL v1 (phía web application). Đây là một bước tiến lớn so với trước đây, khi Zimbra được phát hành theo giấy phép Zimbra Public License, không được cả Free Software Foundation lẫn Open Source Initiative thừa nhận, mang Zimbra CS tới gần với cộng đồng hơn, qua đó, mang lại cơ hội lớn cho người sử dụng, các nhà phát triển, tích hợp hệ thống và cung cấp dịch vụ.

Gần 1 năm trôi qua, phiên bản 8.6 đã được phát hành, sắp tới sẽ là các phiên bản 8.7, 9.0… chúng tôi hy vọng bài viết này sẽ giúp quí vị tìm hiểu những kiến thức cơ bản về CPAL v1 nói chung và áp dụng cụ thể trong trường hợp Zimbra. Qua đó, thực hiện đúng và đủ các quyền và nghĩa vụ của mình, tôn trọng những đóng góp của cộng đồng phát triển Zimbra nói riêng cũng như cộng đồng phần mềm tự do nguồn mở nói chung.

Một trong những nội dung quan trọng trong giấy phép CPAL v1 là cho phép (nhóm) tác giả có phần mềm phát hành theo giấy phép này được quyền yêu cầu người sử dụng, các nhà phát triển, tích hợp hệ thống và cung cấp dịch vụ cũng như toàn thể thành viên trong cộng đồng, khi tải phần mềm về sử dụng hoặc cung cấp dịch vụ, giữ lại nguyên trạng một số các thông tin quan trọng, liên quan đến tác giả gốc, bao gồm: tuyên bố về quyền tác giả (Attribution Copyright Notice), tuyên bố chung (Attribution Phrase) không quá 10 từ, đường link đến website của (nhóm) tác giả (Attribution URL) và logo kèm theo (Graphic Image provided in the Covered Code as file)

Trong trường hợp cụ thể của Zimbra, các thông tin này được yêu cầu như sau:

Các thông tin này được yêu cầu giữ nguyên trên giao diện người dùng cuối (GUI). Trong trường hợp đoạn chương trình chạy không thể hiện trên một giao diện người dùng cuối thì tên và đường link đến website công ty Zimbra Inc. phải được ghi trong từng file mã nguồn.

Bạn có thể tải toàn văn giấy phép phát hành của Zimbra tại: https://files.zimbra.com/website/docs/Zimbra-Open-Source-Edition-License.pdf

Nghiên cứu PMNM trong hệ thống Thư điện tử và Cộng tác: Quan điểm về An toàn và An ninh thông tin ở Mỹ và châu Âu

A Ponemon Institute Study – November 2014

Hơn 70% các chuyên gia IT Mỹ ưu tiên lựa chọn phần mềm nguồn mở (PMNM) bởi tính liên lục và khả năng kiểm soát.

Tiết kiệm chi phí không còn là chỉ số vàng duy nhất cho PMNM.

Viện Ponemon đã khảo sát 1,398 chuyên gia IT để xây dựng báo cáo “Nghiên cứu PMNM trong hệ thống Thư điện tử và Cộng tác: Quan điểm về An toàn và An ninh thông tin ở Mỹ và châu Âu” với mục tiêu tìm hiểu mức độ sử dụng các giải pháp thư điện tử và cộng tác nguồn mở trong các công ty và quan điểm của họ về an toàn và bảo vệ thông tin riêng tư.

Một số kết quả chính:

  • Phần mềm nguồn mở thương mại vượt trội so với phần mềm sở hữu độc quyền về tính liên tục, khả năng kiểm soát, chất lượng và giá thành – 66% các chuyên gia IT ở Mỹ đồng ý rằng PMNM thương mại ít lỗi hơn.
  • Đội ngũ nhân viên làm tăng các rủi ro về an toàn và an ninh thông tin – 89% nhân viên không tuân thủ các qui tắc của công ty khi chia sẻ tài liệu mật.
  • Sự không hài lòng với phần mềm sở hữu độc quyền của các chuyên gia IT là cơ hội cho PMNM – 55% chuyên gia IT tại Mỹ lên kế hoạch thay thế hệ thống thư điện tử và cộng tác trong vòng 2 năm tới.

Còn tổ chức của bạn thế nào? Tải về toàn bộ báo cáo miễn phí tại đây.

The first APAC Ambassadors FAD for annual budget planning

We have finished the first ever FAD for APAC Ambassadors for annual budget planning in Phnom Penh at the last weekend.

As other participants like Sirko or Siddesh wrote some nice summary reports (day 0, 1 and 2), I would not like to repeat those more. Instead of those, I would like to tell you some stories behind this FAD.

You may know, EMEA region have done some successful FADs for EMEA Ambassadors for annual budget planning for two years: 2012, 2013; and this year, they are planning for the third one in Leverkusen, Germany on December 5th, 2014. The past FADs were quite successful as all their main goals have been done. Budget plans for the last two fiscal years are quite good with almost events, activities and swags were analyzed and estimated. Each year, the total expense was close to the plan (!).

That’s why I thought about how to do the similar event in APAC. Last year, I discussed with some other members in region and tried to make the first APAC FAD in Manila, Philippines. However, preparation time was too short so finally, we could not make it.

This year, with a lot of support from other members (thanks to Sirko from EMEA for helping us, and thanks to Somvannda and Nisa Ban for hosting the event and doing all the facilitating jobs), we have been able to make it. I do not say that it was really successful but it was fine enough for us. All the main goals have been done. We got a list of events and swags with fully estimated budget in APAC during the next FY2016; we distributed all requested Ambassadors polo shirts; and last but not least, we had got a good time to meet face to face to discuss a lot of things and get understandings each other better.

It was just our first time and we would make it better and better in the future. We will have some more small adjustments and push these results to the next budget allocation phase (originally organized by FAmSCo and OSAS) in January-February, 2015. Hope we can do events and activities much better in the next FY2016.

Thanks again for all participants and see you next year.

MHST 2014 – vẫn lối mòn cũ

Nhân sự kiện cuộc thi MHST 2014 khép lại và các giải được công bố chính thức, xin được có vài lời nhận xét với hy vọng BTC sẽ lắng nghe, điều chỉnh và hoàn thiện qui chế cũng như cách thức tổ chức để có được những mùa thi hiệu quả, đúng với mục tiêu chung đặt ra ban đầu, đáp ứng mong đợi của cộng đồng xã hội.

Điểm qua cả 5 dự án lọt vào chung khảo, có thể dễ dàng nhận thấy những lỗi sơ đẳng đối với 1 dự án muốn được gọi là PMTDNM:

  • Các vấn đề về giấy phép phát hành như: không thông báo giấy phép phát hành, không kèm theo bản sao toàn văn giấy phép…
  • Vấn đề về tổ thức cộng đồng (dù là sơ khai): không thấy các dự án tổ chức kênh liên lạc tối thiểu (hoặc ít nhất là không thấy thông báo công khai trên kho mã nguồn chính).
    Không rõ các dự án này giao tiếp công khai với các thành viên trong cộng đồng cũng như end-user như thế nào?
  • Vấn đề về phát hành: 4/5 dự án chưa thấy phát hành phiên bản nào?! (sử dụng tagged trên git)
    Không lẽ BGK chấm trên phiên bản zero?
  • … và còn nhiều nữa nếu đem xem xét kỹ & chấm điểm PoF cẩn thận.

Trong ba mặt cơ bản bắt buộc của một dự án PMTDNM (theo thông lệ quốc tế): i. mã nguồn sẵn sàng và có thể tải về trên Internet, ii. phát hành theo giấy phép được OSI approved (căn cứ theo giấy phép được thông báo trên kho mã nguồn) và iii. tổ chức cộng đồng (dù chỉ sơ khai, đủ thể hiện mong muốn thực hiện tổ chức), các dự án trên mới chỉ đạt được một. Nếu xem xét kỹ các tiêu chí và tổ chức chấm điểm PoF, nhiều vấn đề khác sẽ xuất hiện và đòi hỏi dự án cần được hoàn thiện để có thể chính thức được cộng đồng nhìn nhận là một PMTDNM.

Có thể thấy, những nền tảng nguyên lý cơ bản của nhất của mô hình phát triển PMTDNM đều không được quan tâm đầy đủ và trên thực tế bị break hoàn toàn. Ở đây, lỗi xuất phát từ phía đội phát triển, là các bạn SV. Tuy nhiên, nguyên nhân sâu xa phải kể đến sự thiếu kinh nghiệm và/hoặc sâu sát của mentors và đặc biệt là BGK cũng như BTC.

Chúng ta đang từng bước hoàn thiện mình, nhưng những vẫn đề cơ bản mang tính nguyên lý cần phải được tuân thủ sớm từ đầu. Việc một cuộc thi “SV viết PMNM” như MHST, được tổ chức bởi một tổ chức mang tính đại diện cho cộng đồng PMTDNM VN như VFOSSA lại không lấy tiêu chí phát triển đúng mô hình PMTDNM lên hàng đầu có thể coi là một bước “cải lùi”, khiến cho những nỗ lực khuyến khích tham gia đóng góp phát triển PMTDNM trong toàn thể cộng đồng, đặc biệt là giới trẻ, các bạn SV, có nguy cơ bị ảnh hưởng ít nhiều.

Kiến nghị chung: đưa vào tiêu chí một dự án tham gia MHST bắt buộc phải được phát triển theo mô hình PMTDNM (nếu không, sẽ buộc phải loại bỏ tại thời điểm chấm giải).

P.S. bài viết thể hiện quan điểm cá nhân của tác giả, không phải quan điểm chính thức của VFOSSA cũng như bất cứ tổ chức, cá nhân nào khác.

Fedora Join workshop at Nha Trang IT Day 2014

Sunday, October 26th, 2014, at Nha Trang university, Nha Trang, Vietnam, the Nha Trang IT Day 2014 was taken place. During that day, the Fedora Join workshop was held to introduce about Fedora Project to professors, teachers and students who work and study at NTU and nearby universities and to help them to join into.

In the morning, I had got a keynote about some free and open source software principals and the community world-wide as well as in Vietnam. In fact, university students in Nha Trang had not got much information about FOSS and most of them do not know what Fedora exactly is. The talk made people to pay more attention on FOSS and Fedora.

My keynote in the morning session

At the end of morning session, there were a round table to discuss more and answer questions to attendees. We talked a lot about open source, how they built and how to contribute to them.

Round table

In the afternoon, I held a workshop particular in Fedora to introduce about Fedora and help people to join into the project. There were over 20 attendees and they were really excited to earn new things.

Attendees were asked to introduce themselves one by one and put their names into a PiratePad.

I talked briefly about the Fedora Project and Fedora community world-wide as well as in Vietnam; then I shown some slides to let people know how to contribute to Fedora with and without coding.

During the workshop, I answered a lot of questions about Fedora and Linux/FOSS in general.

At the mostly end of the workshop, helped people to do some initial tasks to join into Fedora project: register their FAS account, read and sign FCLA, create their personal wiki page, join into some mailing lists and connect to IRC channels. People were also asked to put their FAS account into the PiratePad and connect to IRC channels to keep in touch later.

I will keep in touch with them, especially, the teachers. Hopefully, we will have more FOSS and Fedora activities in Nha Trang in the future.

Some other pictures (taken by myself): Facebook album link here.

An article by organizers (in Vietnamese): http://ntu.edu.vn/kcntt/ViewTin.aspx?idcd=13&idnews=5589

Zimbra Collaboration 8.5 is here!

The Zimbra team is proud to announce that Zimbra Collaboration 8.5 is now available. Our tagline is “Anytime, Anywhere, Any Device,” because it’s built on an open platform, including support for the broadest range of mobile, browser and desktop clients available in the market today. Read all about it in this blog post from our CTO Rob Howard: Zimbra Collaboration 8.5: Anytime, Anywhere, Any Device :: Zimbra :: Blog

Please note that it is the first version released under OSI-approved licenses, GNU Public License version 2 for the server platform and the Common Public Attribution License version 1 for the web application.

 

My 2nd Flock

It’s really excited. And I am back to work now.

I got an awesome Flock although it was not good from start because of an issue in my flight ticket which delayed me a day to meet fantastic friends in Fedora community.

Because my flight was delayed, my talk was delayed too but it was still in a good time, in the morning of 2nd day. There were many participations and they contributed more to my topic “Improving Mentors program”. In general, I would like to create a basic set of guidelines for mentors to work with their candidates. Although mentoring strategies are different among regions and even among mentors, I still believe there are some basic stuffs which every mentors need/should do for their candidates from beginning.

I had made some notes here: https://fedoraproject.org/wiki/User:Tuanta/Mentor_Guidelines_Draft and hope other mentors to contribute more before, during as well as after Flock.

Honestly, there were not many contributions before Flock. During my talk at Flock, I got some value ideas and comments. They took me to a new (not really new) direction that we should have specific guidelines for each regions since knowledge and experience of candidates are not equal among regions. Additionally, there may be more specific ones per country or mentor but they should be managed separately.

Other talks brought to participants a lot of value information and updates. Flock also made a good chance for people to meet and do other activities like key signing party, discuss some hot topics face to face, etc. I also loved joined dinners where I could drink beer, make friends and chat with other nice people in Fedora community. It would be much easier for me to work with other members after face-to-face meetings, especially for my work in FAmSCo and Server WG teams.

Frankly speaking, I prefer topics related to governance and community than technical ones. Most of technical ones could be easily accessible over the Internet while people-related ones are more complicated and should be discussed in person. However, I were still appreciated all people who contributed their time to make Fedora as well as this Flock succeed.

This would be another unforgettable event for us and I hope I can work and contribute to Fedora more and more.

IMHO, in the future, we should have more volunteers to support people to arrange their flights, accommodation, visa application etc. to avoid any potential issues. I am, of course, ready to join into that team.

Also, before and during the Flock, there were some discussions about subsidy’s criteria. In the future, I think, beside having accepted talks, people should show their more interests in other talks and activities in Flock. And to save money for supporting more people come, Flock could provide partially fund support instead of almost fully support as present. People may ask for support for flight, accommodation or both but it would effect to acceptance possibility of their requests. IMO, supporting for flight is enough, people can group up themselves to look for suitable hotels (it also would be better for collaboration).

Openroad technical workshop lần đầu tại Hà Nội

Thứ 7, ngày 14/6 vừa qua, dự án Openroad đã tổ chức sự kiện Technical Workshop đầu tiên tại Hà Nội, nhằm hỗ trợ, tập huấn cho các thành viên mới tham gia những kiến thức cơ bản về dự án, bao gồm:

  1. Tổng quan về dự án Openroad
  2. Hướng dẫn sử dụng Git SCM và chiến lược áp dụng đối với kho mã nguồn Openroad trên GitHub
  3. Tổng quan về công nghệ đăng nhập một lần (SSO – Single Sign On) Jasig CAS
  4. Hướng dẫn cách thức trao đổi, liên lạc giữa các thành viên trong dự án Openroad

Buổi Workshop tổ chức tại phòng học của Viện tin học Nhân dân, thuộc Hội Tin học Việt Nam, đã thu hút sự tham gia tại chỗ của trên dưới 20 thành viên dự án và gần 10 thành viên qua Phần mềm hội nghị truyền hình TrueConf được hỗ trợ bởi công ty HaproInfo, bao gồm cả các thành viên mới và các thành viên đã tham gia từ các giai đoạn trước, đến từ các đơn vị: Viện Đại Học Mở Hà Nội, Đại học Đại Nam, Đại Học Thăng Long, Đại học Dân lập Hải Phòng, công ty Netnam, công ty Lạc Tiên, công ty Nacencomm, công ty Vinades, công ty iWay, công ty D&L, công ty EcoIT, Sở TTTT Bắc Giang.

Các thành viên tham dự workshop đã chăm chú lắng nghe các chia sẻ của những thành viên đi trước đã có kinh nghiệm và trao đổi hết sức tích cực. Phần hướng dẫn về Git và GitHub được thực hiện trong 3 tiếng buổi sáng của anh Vũ Văn Thảo đã cho một cái nhìn tổng quan về Git và áp dụng với GitHub, giúp cho các thành viên có được kỹ năng cơ bản có thể sử dụng được Git và làm việc với GitHub. Thêm vào đó, anh Trương Anh Tuấn cũng đã trình bày sơ bộ về chiến lược áp dụng các công cụ branch, tag… của Git trong Openroad. Các thành viên được hướng dẫn thực hành fork, init một kho git mới, add/commit các thay đổi, push/pull lên kho chứa trên GitHub…

Slide: https://speakerdeck.com/tuanta/git-and-github-for-beginners

Trong 3 tiếng buổi chiều, các thành viên tham dự được nghe anh Hoàng Chí Linh chia sẻ tổng quan về CAS và tích hợp trong dự án Openroad. Nhiều vấn đề mới của CAS đã được đem ra trao đổi rất sôi nổi, với sự chia sẻ thêm từ các thành viên đã có kinh nghiệm làm việc trên CAS như anh Nguyễn Năng Thắng (công ty iWay), anh Tạ Quang Thái (công ty EcoIT). Ngay trong buổi workshop, đội NukeViet đã thực hành ngay việc tích hợp NukeViet với CAS thành công (dĩ nhiên sẽ cần fine-tuning thêm nhiều khi quay trở về làm việc).

Slide: https://speakerdeck.com/tuanta/cas-overview

Chốt đầu giờ là phần giới thiệu tổng quan về dự án Openroad, giúp các thành viên mới tham gia có cái nhìn cơ bản về Openroad là gì, những gì đang được phát triển và cần có thêm các đóng góp mới… và cuối giờ là phần hướng dẫn các phương tiện trao đổi, liên lạc trong Openroad bao gồm IRC và Mailing lists của anh Trương Anh Tuấn. Sau khi được nghe giới thiệu sơ lược, các thành viên tham dự được thực hành đăng ký luôn vào mailing list Openroad-devel và kênh IRC #openroad trên Freenode.net. Kể từ đây, các phương thức liên lạc cơ bản trong các dự án PMTDNM là Mailing lists và IRC đã kết nối tới được các thành viên trong đội phát triển Openroad. Đội phát triển tiếp tục chào đón các thành viên mới, các thành viên vì những điều kiện cụ thể chưa đăng ký được vào mailing list, IRC… tiếp tục đăng ký vào để giữ liên lạc thông suốt với Dev team cũng như toàn bộ Dự án.

Slide: https://speakerdeck.com/tuanta/openroad-project-overview-1

Xem thêm về dự án Openroad và các phương thức liên lạc tại: https://github.com/Openroadvietnam/openroad/wiki

Xen giữa giờ nghỉ trưa là buổi giao lưu Pizza tại chỗ, với nhiều bình luận viên của cả PMTDNM, World Cup và mọi mặt trong cuộc sống. Kết thúc workshop, các thành viên lại tiếp tục tham dự buổi liên hoan Beer tại nhà hàng Trâm Bầu đối diện bên đường :). Chỉ có một thành viên, như thương lệ, không tham gia các hoạt động “bia bọt” là anh Tạ Quang Thái 😉

19h30 tất cả ra về, kết thúc một ngày dài (~12h) làm việc cật lực của BTC và tất cả thành viên tham gia (chưa kể mấy tuần cùng nhau chuẩn bị nội dung cũng như logistics cho workshop).

BTC xin chân thành cảm ơn Hội tin học Việt Nam đã hỗ trợ phòng học; cảm ơn công ty HaproInfo đã hỗ trợ Phần mềm hội nghị truyền hình TrueConf và cử cán bộ kỹ thuật trực hỗ trợ; cảm ơn anh Vũ Văn Thảo, công ty Vinades, thành viên tích cực trong core team của NukeViet và anh Hoàng Chí Linh, công ty EcoIT đã tham gia chia sẻ kinh nghiệm và hướng dẫn về Git/GitHub và CAS; cảm ơn chị Đỗ Thị Thanh Thủy, công ty iWay, các chị Nguyễn Xuân Hương, Nguyễn Trang Nhung, hội Tin học Việt Nam, đã hỗ trợ chuẩn bị chu đáo về logistics.

Và đặc biệt cảm ơn tất cả các bạn thành viên đã tham dự và tích cực thảo luận, góp phần quan trọng vào thành công của Openroad technical workshop đầu tiên.

Một vài hình ảnh của buổi workshop đầu tiên:

Tại lớp học:

Và từ xa, qua Phần mềm hội nghị truyền hình TrueConf:

Hẹn gặp lại ở các workshop tiếp theo.

Chào thân ái và quyết thắng!

13 đặc điểm của một nhân viên cần sa thải ngay lập tức

Đuổi việc nhân viên không phải lúc nào cũng là quyết định dễ dàng với các nhà quản lý. Thế nhưng, với một nhân viên có những đặc điểm dưới đây, việc sa thải là thật sự cần thiết.

1. Thường xuyên phàn nàn

Những nhân viên tệ thường xuyên phàn nàn và đối với họ chẳng có gì đủ tốt để hài lòng cả.

2. Luôn bào chữa

Họ không bao giờ chịu trách nhiệm cho hành động của mình, thay vào đó là tìm mọi lý do để bào chữa.

3. Thiếu nhiệt huyết

Khi một dự án mới được triển khai, họ thường tỏ ra không mấy hứng thú.

4. Không giúp đỡ những người khác

Câu cửa miệng của những người này là ‘Đó chẳng phải việc của tôi’ khi đồng nghiệp hoặc ai đó đề nghị sự giúp đỡ.

5. Chuyên ngồi lê đôi mách

Những người hay ngồi lê đôi mách, nói xấu người này với người kia sẽ ảnh hưởng xấu đến tinh thần đoàn kết của các nhân viên cũng như văn hóa của công ty.

6. Nói dối

Một nhân viên hay nói dối và thích bịa chuyện là mối nguy hiểm rất lớn cho công ty của bạn.

7. Thể hiện như mình biết tất cả mọi thứ

Họ thể hiện giống như mình biết hết mọi thứ và những điều bạn nhắc đến chẳng có gì là mới với họ cả.

8. Không có tinh thần làm việc theo nhóm

Một nhân viên chỉ khăng khăng làm theo ý mình mà không để ý đến ý kiến của các thành viên khác trong nhóm sẽ ảnh hưởng đến lợi ích của công ty.

9. Thiếu trách nhiệm

Những nhân viên thiếu trách nhiệm thường đi làm muộn, không hoàn thành kế hoạch và chẳng bao giờ giữ lời hứa của mình.

10. Thiếu sáng tạo

Một nhân viên tốt sẽ luôn suy nghĩ, tìm tòi những cái mới trong khi một nhân viên tệ chỉ ngồi một chỗ và chờ xem người khác nói phải làm gì tiếp theo.

11. Không bao giờ đặt câu hỏi

Họ không hứng thú với việc đặt câu hỏi và học thêm những điều mới.

12. Thiếu tập trung

Những nhân viên kiểu này thường dễ dàng bị sao nhãng trong công việc.

13. Không phát triển

Một nhân viên không bao giờ cố gắng để trở nên tốt hơn sẽ chẳng thể giúp ích gì nhiều cho công ty của bạn.

-st-

Tại sao ra quyết định đồng thuận tốt hơn cho các dự án PMTDNM

Nhiều người trong chúng ta sử dụng mô hình ra quyết định đồng thuận (Consensus-based decision making) trong các dự án PMTDNM như Apache’s lazy consensus model, nhưng phần lớn chúng ta thực hiện hay thậm chí đặt thành qui định cuối cùng theo qui trình biểu quyết theo đa số (Majority-based decision making).

Trong mô hình biểu quyết theo đa số, những người bất đồng quan điểm bị gạt sang một bên — nhóm đa số buộc phải đặt nhóm bất đồng thiểu số vào vị trí những kẻ thua trong cuộc biểu quyết. Trong mô hình ra quyết định đồng thuận, trách nhiệm của cả nhóm là luôn lưu tâm đến các mối lo ngại của những người bất đồng quan điểm.

Nhìn chung, các quyết định đồng thuận bắt buộc nhóm phải tập trung dàn xếp một giải pháp tốt nhất có thể. Khi mọi người bị đặt vào vị trí thắng/thua, họ có xu hướng suy nghĩ cứng nhắc vào một hoặc hai đầu, thứ mà chưa chắc đã đại điện cho giải pháp tốt nhất có thể (rất có thể nằm đâu đó ở giữa).

Thông thường, để đạt được sự đồng thuận, chỉ cần làm rõ một số ý hiểu nhầm hoặc thực hiện một số điều chỉnh nhỏ so với đề xuất ban đầu. Tuy nhiên, sự xuất hiện phiếu trắng (-0) , kể cả khi không có phiếu chống (-1) nào, cũng cho thấy, đề xuất ban đầu nên được suy nghĩ thêm. Phiếu trắng từ những người lãnh đạo nhóm càng khuyến khích những người khác cân nhắc khả năng cần phải bổ sung thêm để đề xuất nhận được sự ủng hộ hoàn toàn.

Hiện tại, những dự án, cộng đồng PMTDNM lớn như CentOS, Fedora đã và đang áp dụng mô hình ra quyết định đồng thuận này.