Tình trạng của PostgreSQL: Không dễ giết

The State of PostgreSQL: Not So Easy to Kill

by Joe Brockmeier - Jan. 07, 2010

Theo: http://ostatic.com/blog/the-state-of-postgresql-not-so-easy-to-kill

Bài được đưa lên Internet ngày: 07/01/2010

Lời người dịch: Một số người lo PostgreSQL cũng có thể có chung số phận bị mua như MySQL. Nhưng mô hình phát triển cộng đồng rất phân tán của PostgreSQL giúp bảo vệ nó tốt hơn nhiều so với của MySQL.

Nếu bạn dõi theo thông tin về nguồn mở, thì đã thấy khá khó khăn để bỏ qua MySQL những tháng vừa qua. Với một chiến dịch tuyệt vọng để dừng Oracle nuốt MySQL, thì cơ sở dữ liệu hàng đầu của FOSS này đã nằm ở tuyến đầu và trung tâm. Như thường lệ, cộng đồng PostgreSQL vẫn âm thầm lập trình và làm việc trên phiên bản 8.5 dự kiến cho quý I/2010.

Tuy nhiên, một trong những lý lẽ của Monty Widenius về tính có thể bị tổn thương của PostgreSQL đã gây sự chú ý của cộng đồng PostgreSQL. Trong một bình luận trên Ostatic, Widenius nói rằng “PostgreSQL cũng có thể bị giết” bởi một công ty như Oracle:

Vâng, PostgreSQL cũng có thể bị giết; Để chứng minh cho trường hợp này, hãy nghĩ tới những gì có thể xảy ra nếu ai đó định đảm bảo rằng 20 lập trình viên hàng đầu cốt lõi của PostgreSQL có thể không phát triển PostgreSQL nữa hoặc nếu mỗi người trong số các lập trình viên này có thể rẽ nhánh dự án PostgreSQL của riêng họ.

Greg Sabino Mullane, viết bài trên End Point Blog, chỉ ra rằng lý lẽ đó là ngu ngốc làm sao:

Sự nắm bắt này tới từ khả năng thực sự dùng 20 người này khỏi công việc trên PostgreSQL. Về cơ bản có 2 cách để làm điều này: Oracle có thể mua một công ty, hoặc họ có thể thuê (mua ngoài) một người. Vấn đề đầu là việc cộng đồng PostgreSQL là rất phân tán rộng. Nếu bạn nhìn vào những người trong trang những người đóng góp của cộng đồng này, thì bạn sẽ thấy rằng 32 người làm việc cho 24 công ty khác nhau. Hơn nữa, không một công ty nào thống trị: trung bình là mỗi người ở một công ty, và chỗ lớn nhất có 3 lập trình viên. Tất cả điều này là tốt hơn nhiều so với nhiều năm trước, theo tổng số và theo sự phân tán.

If you follow open source news at all, it's been pretty hard to ignore MySQL the last few months. With a desperate campaign to stop Oracle gobbling up MySQL, the FLOSS poster database has been front and center. As usual, the PostgreSQL community has been quietly coding away and working on the 8.5 release scheduled for the first quarter of 2010.

However, one of Monty Widenius' arguments about the vulnerability of PostgreSQL has caught the attention of the PostgreSQL community. In a comment on OStatic, Widenius says that "PostgreSQL can also be killed" by a company like Oracle:

Yes, PostgreSQL can also be killed; To prove the case, think what would happen if someone managed to ensure that the top 20 core PostgreSQL developers could not develop PostgreSQL anymore or if each of these developers would fork their own PostgreSQL project.

Greg Sabino Mullane, posting on the End Point Blog, points out how silly that argument is:

The catch comes from being able to actually stop 20 of those people from working on Postgres. There are basically two ways to do this: Oracle could buy out a company, or they could hire (buy out) a person. The first problem is that the Postgres community is very widely distributed. If you look at the people on the community contributors page, you'll see that the 32 people work for 24 different companies. Further, no one company holds sway: the median is one company, and the high water mark is a mere three developers. All of this is much better than it was years ago, in the total number and in the distribution.

Trên thực tế, PostgreSQL như một dự án là khá lành mạnh, và chỉ ra vì sao các dự án có thể bị tổn thương như MySQL là sự đổi gió. PostgreSQL có thể chết ngày mai, nếu một nhóm lớn những người đóng góp bỏ vì một lý do nào đó và những người còn lại của cộng đồng bê trễ. Nhưng điều đó cực kỳ không chắc. Mô hình hiện tại cho việc phát triển PostgreSQL đảm bảo rằng không một thực thể duy nhất nào có thể kiểm soát nó, nó không thể bị mua và nếu ai đó quyết định rẽ nhánh dự án này, thì sự khác biệt là việc cộng đồng còn lại có thể đủ mạnh để tiếp tục mà không có một trục trặc nghiêm trọng nào.

Không nói là mỗi dự án FLOSS mà nó được kiểm soát bởi một thực thể duy nhất sẽ ra đi theo cách của MySQL. Nhưng những gì đã xảy ra với MySQL có thể xảy ra với các dự án khác nơi mà một công ty giữ kiểm soát dự án. Thứ gì đó để nghĩ khi quyết định những dự án nào để làm việc với, áp dụng và phụ thuộc vào năm 2010.

Về tác giả: Joe 'Zonker' Brockmeier là một người bảo vệ FLOSS lâu năm, và hiện làm việc cho Novell như là giám đốc cộng đồng cho openSuSE. Trước khi ra nhập Novell, Brockmeier đã làm việc như một nhà báo công nghệ viết về nguồn mở cho một số nhà xuất bản, bao gồm cả Linux Magazine, Linux Weekly News, Linux.com, UnixReview.com, IBM developerWorks và nhiều tạp chí khác.

In fact, PostgreSQL as a project is pretty healthy, and shows how vulnerable projects like MySQL are to the winds of change. PostgreSQL could die tomorrow, if a huge group of its contributors dropped out for one reason or another and the remainder of the community didn't take up the slack. But that's exceedingly unlikely. The existing model for PostgreSQL development ensures that no single entity can control it, it can't be purchased and if someone decides to fork the project, the odds are that the remaining community would be strong enough to continue without a serious glitch.

It's not to say that every FLOSS project that's controlled by a single entity will go the way of MySQL. But what's happened to MySQL could happen to other projects where one company holds control over the project. Something to think about when deciding what projects to work with, adopt, and depend on in 2010.

Joe 'Zonker' Brockmeier is a longtime FLOSS advocate, and currently works for Novell as the community manager for openSUSE. Prior to joining Novell, Brockmeier worked as a technology journalist covering the open source beat for a number of publications, including Linux Magazine, Linux Weekly News, Linux.com, UnixReview.com, IBM developerWorks, and many others.

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com