Nguồn mở: Mô hình kinh doanh duy nhất có thể trụ vững được (Phần 1)

Theo: http://opensolutionsalliance.org/osa/osaalert(apr09)-tiemann.html?x_lf_kt=2&_x_lf_kvid=b63e6e94-dd3f-4d5f-905b-9ea79a559ad8

Bài được đưa lên Internet ngày: 09/04/2009

Lời người dịch: Có lẽ bài viết này là dành cho tất cả những ai có liên quan tới ngành công nghệ thông tin, và nhất là những người có liên quan tới việc làm phần mềm, phải đọc và suy ngẫm. Đây là cách nhìn của Michael Tiemann, Phó chủ tịch của Red Hat đồng thời là Chủ tịch của tổ chức Sáng kiến Nguồn mở, nơi đưa ra định nghĩa và phê chuẩn tất cả các giấy phép nguồn mở trên thế giới. Theo Tiemann thì: “Chúng ta có một vấn đề khủng khiếp trong đó chúng ta đã và đang phát triển phần mềm sai cách đã 40 năm nay”.

Ảnh Michael Tiemann: http://opensolutionsalliance.org/osa/images/tiemann_michael-redhat.jpg

Được biết tới như một nhà lãnh đạo về tư duy và người đi đầu về nguồn mở, Michael Tiemann ngày nay làm việc như là Phó Chủ tịch, Các công việc về nguồn mở tại Red Hat. Ông hiện cũng là Chủ tịch của tổ chức Sáng kiến Nguồn mở (OSI) và tổ chức quỹ GNOME Foundation. Trong năm 1989, ông đã đồng sáng lập công ty nguồn mở vì lợi nhuận đầu tiên, Cygnus Solution. Trong một bài phát biểu gần đây, ông đã đưa ra sự hỗ trợ chi tiết, có giải thích rõ cho tính siêu việt của mô hình phát triển nguồn mở, và đã kết thúc với việc nhấn mạnh tất cả 5 lợi ích hướng tới sự phát triển của nguồn mở trong danh sách 10 thứ hàng đầu của Liên minh các Giải pháp Nguồn mở OSA.

Known as a thought leader and open source pioneer, Michael Tiemann today works as Vice President, Open Source Affairs at Red Hat. He also currently serves as President of the Open Source Initiative and the GNOME Foundation. In 1989, he co-founded the first profitable open source company, Cygnus Solutions. In a recent speech, he gave detailed, annotated support for the superiority of the open source development model, and ended up highlighting all five development-oriented benefits of open source on OSA's top ten list.

OSA Alert: Tôi đã nghe nhiều thứ to tát về “Exonovation – Việc thúc đẩy đổi mới sáng tạo từ tính sắc”, mà ông đã đưa ra như một bài phát biểu chủ chốt tại hội nghị ETE2009. Ông có thể giải nghĩa cho tôi được không?

Michael Tiemann: Chắc rồi. Khái niệm “exonovation” sử cho đúng một tính năng bị hiểu lầm của ngôn ngữ tiếng Anh. Khái niệm “đổi mới sáng tạo” tạo ra một sự suy nghĩ về những thứ mà chúng xảy ra bên trong các bức tường... bên trong tổ chức. Quả thực, nhiều tổ chức nghĩ về đổi mới sáng tạo như một khả năng cốt lõi. Tuy nhiên, trong một cuốn sách mà đã được xuất bản năm 2005 bởi John Hagel và John Seely Brown có tên là “Sự sắc duy nhất có thể chứng minh được”, họ đã tranh luận – tôi nghĩ rất hiệu quả – rằng sự phấn khích thực sự trong nền kinh tế mới của thế giới tới từ các mối quan hệ mà các công ty xây dựng trong tính sắc đó. Các mối quan hệ B2B thực sự. Khái niệm “exonovation” làm cho nó rõ ràng rằng cái mới thú vị tới từ bên ngoài, chứ không phải bên trong một tổ chức.

Hãy để tôi giải thích lý do vì sao chúng ta phải thật lưu tâm về cách mà chúng ta đối xử với cái mới theo ngữ cảnh sa sút của cái cũ. Như chúng ta nhìn vào những gì các công ty bị thách thức với thứ tiếp sau trong nền kinh tế mới này, mọi người nói về tầm quan trọng của sự đổi mới sáng tạo, và quan trọng làm sao việc sử dụng công nghệ để cắt giảm chi phí và đạt tới được những thị trường mới và cải thiện dịch vụ khách hàng và vân vân. Vâng khi chúng ta nhìn vào triển vọng vĩ mô – và tôi ngụ ý là triển vọng siêu vi mô – nhiều nhà phân tích công nghiệp đã ước lượng chi phí toàn cầu cho công nghệ thông tin và truyền thông (ICT) là 3.4 ngàn tỷ USD mỗi năm. Rất nhiều tiền.

Vâng, quả thực vậy.

OSA Alert: I've heard a lot of great things about “Exonovation – Leveraging Innovation f-rom the Edge,” which you gave as a keynote at the ETE2009 conference. Can you give me a rundown?

Michael Tiemann: Sure. The term “exonovation” corrects a misfeature of the English language. The term “innovation” makes one think of things that happen within the walls … inside the organization. Indeed, a lot of organizations think of innovation as a core capability. However, in a book that was published in 2005 by John Hagel and John Seely Brown called “The Only Sustainable Edge,” they argued – I think very effectively – that the real excitement in the new world economy comes f-rom the relationships that company build at the edges. The real B2B relationships. The term “exonovation” makes it clear that the interesting new comes f-rom outside, not inside an organization.

Let me address the reason why we must be so mindful about how we treat the new in the decaying context of the old. As we look at what companies are challenged with to succeed in the new economy, people talk about the importance of innovation, and how important it is to use technology to cut costs and reach new markets and improve customer service et cetera. Yet when we look at the macro perspective – and I mean the super macro perspective – multiple industry analysts have estimated the global spend for Information and Communication Technology (ICT) at 3.4 trillion US dollars per year. A lot of money.

Yes, indeed.

Phần gây sốc của con số đó là việc nó có thể được tranh luận rằng 1 ngàn tỷ USD một năm đang bị lãng phí hoặc trên các ứng dụng mà sẽ bị bỏ quên trước khi chúng khi nào đó đi được vào sản xuất, hoặc chi cho các ứng dụng mà chúng sẽ thiếu các tính năng chủ chốt hoặc sẽ bị muộn so với thời điểm làm gián đoạn khả năng vận hành hoặc cả hai. Ngược về năm 2006 khi tôi đã bắt đầu đặt các con số này cùng nhau, một trong những thách thức mà tôi đã đối mặt là việc nhiều người đã không quan tâm về 1/3 của mỗi USD mà đã bị bỏ phí trên công nghệ tồi tệ phải chi ra vì họ đã quá hạnh phúc với cách mà 2/3 kia tăng trưởng nhanh thế nào. Sự năng động đó hoàn toàn ra đi trong năm 2009. Ý tưởng về việc chi 1 USD vào ICT và có trở ngược lại – tốt nhất – 66 xu về giá trị là hoàn toàn vô lý, đặc biệt ngày nay khi mà bạn xem xét mỗi ngàn tỷ USD là quan trọng làm sao đối với nền kinh tế toàn cầu.

Liệu điều đó có không phải là khá phổ biến chăng? Liệu có phải là hầu hết hoang phí công nghiệp không?

Nếu là đúng, thì đó là một tình trạng công việc đáng sợ khủng khiếp, và là một tình trạng mà có thể phải chữa trị. Trên thực tế, phần còn lại của bài trình bày của tôi nói đặc biệt về cách mà mô hình nguồn mở đột ngột chữa được khoảng cách này. Chúng ta nhìn vào giá thành của mô hình phần mềm sở hữu độc quyền về việc đúp bản những nỗ lực, về việc chất lượng trung bình của phần mềm, về việc những chiến thuật mà một số nhà cung cấp phần mềm hàng đầu sử dụng để phá huỷ sự cạnh tranh của chúng, ngay cả việc làm hại chính bản thân để làm hại cho những người khác. Điều này không phù hợp với ý tưởng về xây dựng giá trị.

The shocking part of that number is that it can be argued that one trillion US dollars a year are being wasted either on applications that are abandoned before they ever go into production, or spent on applications that are missing key features or are late to the point of interrupting operational capability or both. Back in 2006 when I started putting these numbers together, one of the challenges I faced was that a lot of people were not all that concerned about the one-third of every dollar that was being wasted on bad technology spend because they were so happy with how fast the two-thirds was growing. That dynamic is completely gone in 2009. The idea of spending a dollar on ICT and getting back – at best – 66 cents in value is unconscionable, especially today when you consider how important nowadays every trillion dollars is to the global economy.

Isn't that fairly common? Aren't most industries wasteful?

If true, that's a terrible state of affairs, and one that could be subject to remedy. In fact, the rest of my presentation talks about specifically how the open source model dramatically remedies this gap. We look at the cost of the proprietary software model in terms of duplication of effort, in terms of average software quality, in terms of the tactics some of the top software vendors use to destroy their competition, even harming themselves in order to do damage to other people. This is not consonant with the idea of building value.

Để đưa ra cho bạn một ví dụ, trong năm 2004, 2005 và 2006 một công ty gọi là Coverity, mà làm việc dò tìm lỗi của phần mềm, đã phân tích số lượng trung bình của các lỗi cho 1000 dòng lệnh trong phần mềm sở hữu độc quyền chứa từ 20-30 lỗi cho 1000 dòng lệnh. Khi họ lần đầu đo nhân Linux vào năm 2004, thì nhân này đã chứa 5.3 triệu dòng mã nguồn. (Để so sánh, Windows XP được cho là nặng ký với khoảng 35 triệu dòng mã lệnh). Nếu Linux là trung bình của nền công nghiệp, thì người ta có thể dự đoán giữa 100,000 đến 150,000 lỗi trên tổng số 5.3 triệu dòng mã lệnh, và vâng việc quét kiểm tra của Coverity đã chỉ tìm thấy có 985 lỗi. Cộng đồng Linux có được báo cáo và đã xuất bản một thông điệp nói rằng, “Ê, chỉ có 985 lỗi để xem xét, hãy làm sạch các lỗi này đi!”. Trong vòng 6 tháng, từng lỗi mà cộng đồng để lại đã được chỉnh sửa một cách chính đáng. Đối nghịch lại, nếu Microsoft đã viết mã trung bình của công nghiệp, thì 35 triệu dòng mã lệnh có thể chứa hơn 7 triệu lỗi! Bạn có thể thấy vấn đề chứ.

To give you an example, in 2004, 2005 and 2006 a company called Coverity, which does software defect detection, analyzed the average number of defects per thousand lines of code in proprietary software and compared it to open source software. The average, which has remained consistent, is that proprietary software contains 20-30 defects per thousand lines of code. When they first measured the Linux kernel back in 2004, the kernel consisted of 5.3 million lines of source code. (For comparison, Windows XP is reported to weigh in at around 35 million lines of code.) If Linux were industry average, one would expect between 100,000 and 150,000 bugs or defects across 5.3 million lines of code, and yet the Coverity scanners were only able to find 985. The Linux community got the report and published a message saying, “Hey, there's only 985 bugs to look at, let's clean this up!” Within six months, every single defect that the community felt was legitimate was corrected. By contrast, if Microsoft wrote industry average code, their 35 MLOC code base would contain more than 7 million defects! You can see the problem.

Vì sao lại có một sự khác biệt lớn như vậy trong tỷ lệ lỗi?

Hãy để tôi bắt đầu với Fred Brooks, người viết một cuốn sách gọi là “Người Tháng Thần thoại” về những kinh nghiệm của ông quản lý dự án OS360 của IBM, mà nó từng – khi đó – là một dự án công nghiệp đắt nhất từ trước tới nay (nó còn đắt hơn cả chi tiêu của chính phủ vào việc phát triển bom nguyên tử). Cuốn sách đã là một lời giải thích muộn mằn cho ông chủ của ông ta – Thomas Watson, Jr. - về việc vì sao có nhiều người thông minh nhất trên thế giới và làm việc với số tiền như vậy như IBM lại có thể được nuôi trong kênh đó, rằng hệ điều hành đó đã quá trễ và không có nhiều tính năng như được mong đợi. Fred Brooks đã không có một câu trả lời cho câu hỏi đó trong năm 1964 khi ông bị hỏi, nhưng tới năm 1975 thì ông đã phát triển được một câu trả lời tổng thể. Đầu đề cuốn sách của ông dựa trên sự tương tự rằng mang thai một đứa trẻ người phụ nữ cần 9 tháng, bất kể có bao nhiêu người phụ nữ được chỉ định nhiệm vụ này. Ông đã tranh luận rằng sự phát triển của phần mềm là một quá trình có tổ chức không tuân thủ logic công nghiệp. Ông đã quan sát rằng việc bổ sung thêm nhiều người cho một dự án bị muộn chỉ làm cho nó muộn hơn, và rằng việc chỉ định thêm nhiều người để sửa các lỗi mà chúng không kiểm soát được thực sự sẽ bổ sung thêm nhiều lỗi hơn là loại bỏ nó.

Bây giờ hãy nhìn vào sự đối nghịch rõ ràng giữa việc có thể quản lý được 985 lỗi xuống còn 0 lỗi, đối nghịch với tình trạng mà chúng ta thấy với Windows XP, mà cuối cùng đã trở thành Vista, và chúng ta tất cả đều biết Microsoft đã khó khăn như thế nào trong việc quản lý dự án này. Tính năng bền vững duy nhất mà nó đã xuất xưởng là một tính năng mà không một doanh nghiệp nào muốn – Các giao thức kiểm soát các phương tiện bắt buộc đối với Hollywood và nền tảng máy tính tin cậy. Về cơ bản, chúng đã chắc rằng Hollywood có thể tin tưởng máy tính của bạn ngay cả nếu bạn không thể.

Why is there such a big difference in error rates?

Let me begin with Fred Brooks, who wrote a book called the “Mythical Man Month” about his experiences managing the IBM OS360 Project, which was – at the time-- the most expensive single industrial project ever (it even cost more than the government spent on developing the atomic bomb). The book was a belated explanation to his boss – Thomas Watson, Jr. – about why having so many of the smartest people in the world and working with as much money as IBM could feed into that channel, that the operating system was so late and didn't have so many of the features that were expected. Fred Brooks didn't have an answer for that question in 1964 when he was asked it, but by 1975 he had developed a comprehensive answer. The title of his book is based on the analogy that the bearing of a child takes a woman nine months, no matter how many women are assigned the task. He argued that the development of software is an organic process that's not subject to industrial logic. He observed that adding more people to a late project only makes it later, and that assigning more people to fix bugs that are out of control actually adds more bugs than it removes.

Now look at the stark contrast between being able to manage 985 bugs down to none, versus the situation we see with Windows XP, which ultimately became Vista, and we all know how much difficulty Microsoft had in managing that project. Vista shipped horribly late, and it shipped without a single feature that was advertised for enterprises. The only substantial feature it shipped with was one that no enterprise wanted – the Hollywood-mandated media control protocols and trusted computing platform. Basically, they made sure that Hollywood can trust your computer even if you cannot.

Và nó đầy những lỗi.

Chính xác. Được chứng minh rằng việc bổ sung thêm người vào một hệ thống đầy lỗi chỉ làm cho hệ thống tồi tệ hơn mà thôi.

Trong năm 2005, Coverity đã đo nhân Linux, mà nó đã tăng lên tới 5.7 triệu dòng mã lệnh, và đã tìm thấy rằng mật độ lỗi đã thực sự được giảm. Vì thế một số người đã ngạc nhiên liệu có thể nhân Linux đã không được kiểm tra một cách công bằng chăng. Có thể có gì đó trong nước làm cho những người của nhân Linux thông minh vượt bậc chăng. Nên họ đã xem 32 ứng dụng nguồn mở khác, từ ngôn ngữ scripting PHP cho tới trình biên dịch GNU C, và những gì họ đã thấy là những thứ tồi tệ nhất mà 32 chương trình này chỉ 50 lần tốt hơn các phần mềm sở hữu độc quyền trung bình.

Mô hình phát triển nguồn mở là gì mà lại tạo ra nhiều sự đổi mới sáng tạo như vậy và ít lỗi như vậy được?

Trong bài trình bày của tôi, tôi đã chỉ ra một nghiên cứu năm 2001 của James Herbsleb, Roy Fielding và Audris Mockus về máy chủ Web Apache. (“2 trường hợp điển hình về phát triển phần mềm nguồn mở: Apache và Mozilla” được xuất bản trong TOSEM, tháng 07/2002). Họ đã so sánh một số sự phát triển giữa các phần mềm sở hữu độc quyền – một ít công ty đã tình nguyện cho truy cập vào các kho mã nguồn của họ – và các kho mã nguồn mở. Họ đã đo đếm – cho công việc của từng lập trình viên trong dự án – số lượng dòng lệnh mà họ đã bổ sung, số lượng mà họ đã xoá, số lượng mà họ đã thay đổi, và có bao nhiêu bao cáo lỗi họ đã trả lời, và vân vân. Họ đã xếp hạng chúng bằng hoạt động nơi mà Lập trình viên 1 đã làm nhiều nhất. Trong cả 2 trường hợp của sở hữu độc quyền và nguồn mở, Lập trình viên 1 đã làm khoảng 20% của mọi thứ. Nếu đúng là các phần mềm được làm theo logic công nghiệp, thì mọi chương trình có thể đã được sản xuất ra bởi 5 lập trình viên. Nhưng tất nhên chúng toio biết điều đó là không đúng. Khi bạn nhìn vào đồ thị, 5 lập trình viên làm cho bạn được khoảng 40% mọi thứ. Khi bạn có tới 10-15 lập trình viên, bạn bò lên được khoảng 75-80% của mọi thứ.

And it was full of bugs.

Exactly. Proof that adding more people to a buggy system only makes the system worse.

In 2005, Coverity remeasured the Linux kernel, which had grown to 5.7 million lines of code, and found that the defect density had actually decreased. So some people wondered if maybe the Linux kernel was not a fair test. Maybe something in the water makes the Linux kernel people off-the-c-harts smart. So they looked at 32 other open source applications, ranging f-rom the PHP scripting language to the GNU C compiler, and what they found was that the worst of these 32 open source programs was only 50 times better than the average proprietary software.

What is it about the open source development model that generates so much innovation and so few bugs?

In my presentation, I showed a 2001 study by James Herbsleb, Roy Fielding and Audris Mockus about the Apache Web Server. (“Two case studies of open source software development: Apache and Mozilla,” published in TOSEM, July 2002.) They compared some development metrics between proprietary software – a few companies volunteered access to their code repositories – and open source code repositories. They measured – for each developer working on the project – the number of lines they added, the number they de-leted, the number they changed, and how many bug reports they responded to, and so on. They ranked them by activity whe-re the Developer 1 did the most. In both the proprietary and the open source cases, Developer 1 did approximately 20% of everything. If it were true that software worked according to industrial logic, any of the programs could have been produced by five developers. But of course we know that's not true. When you look at the graph, five developers get you to about 40% of everything. When you get out to 10-15 developers, you climb up to about 75-80% of everything.

Hoá ra là trong thế giới sở hữu độc quyền, kích thước dự án có xu hướng khoảng 25-35 lập trình viên, và các dự án đã phô bày những gì chúng ta gọi là một “cái đuôi ngắn”. Bạn thấy đồ thị tuyến tính tương đối này (theo phép lôga) từ Lập trình viên 1 qua Lập trình viên 25. Vâng, với Apache ngược về năm 2001, họ đã có 388 lập trình viên. Bạn thấy những đặc tính của cái đuôi ngắn lên khoảng 10-15 lập trình viên, nhưng sau đó bạn có được cái đuôi dài khó tin nổi này đối với 388 lập trình viên này. Những gì báo chí tranh luận là việc “sự tham gia của các đuôi dài” này dẫn tới nhiều tính năng hơn, được triển khai sớm hơn với ít lỗi hơn.

Làm thế nào điều đó xảy ra trong thế giới thực được?

Sau khi xem xét rằng kết quả được trình bày bởi giáo sư Herbsleb vào năm 2003, tôi đã phát triển một quan niệm mới trong nghiên cứu này. Hãy tưởng tượng rằng bạn là Lập trình viên 388, được tin tưởng với việc thay đổi một dòng lệnh duy nhất. Kinh nghiệm thực tế nào đối với lập trình viên này? Liệu họ có giống người chơi cái tam giác cho bản giao hưởng không, khi mà việc chờ cho cả một buổi tối chỉ để gõ có một nốt nhạc duy nhất, và sau đó được trả tiền đầy đủ vì những lo lắng của họ? Hoặc liệu chúng ta có tin tưởng – như tôi – rằng Lập trình viên 388 còn không nhận thức được về chính bản thân họ như một lập trình viên của Apache? Có lẽ họ đang làm việc trên một hệ thống khác mà nó tương tác với Apache và trong quá trình của nó, thứ gì đó không được mong đợi đã xảy ra. Sau khi đi qua mỗi dòng lệnh mà họ đã viết, họ nhận thức được rằng vấn đề này là với Apache. Họ đi tới mã nguồn của Apache và thấy chính xác những gì họ dự kiến – đó là một dòng lệnh mà nó cần được sửa đổi … một điều kiện đã được đảo ngược trong một lệnh NẾU (IF) hoặc một kiểm tra đã được bỏ qua, hoặc bất kỳ thứ gì. Họ sửa dòng này và gửi một bản vá tới Apache (mà, này, là nơi mà cái tên này được đặt ra … “một máy chủ được vá”) và bây giờ họ có một máy chủ mà làm việc sao cho họ có thể tiếp tục việc phát triển được dự án riêng của họ.

It turns out that in the proprietary world, project size tended to be about 25-35 developers, and projects exhibited what we call a “short tail.” You see this relatively linear graph (on logarithmic paper) f-rom Developer 1 up through Developer 25. Well, with Apache back in 2001, they had 388 developers. You do see the c-haracteristics of the short tail up through about 10-15 developers, but after that you get this incredibly long tail out to Developer 388. What the paper argues is that this “long tail of participation” leads to more features, implemented sooner with fewer bugs.

How does that play out in the real world?

After seeing that result presented by Professor Herbsleb in 2003, I have developed a new insight into the study. Imagine that you are Developer 388, credited with changing a single line of code. What is the real experience of that developer? Are they like the person playing the triangle for the symphony, waiting the whole night to strike a single note, and then getting paid full uni-on scale for their troubles? Or do we believe – as I do – that Developer 388 does not even conceive of themselves as an Apache developer? Perhaps they are working on another system that interacts with Apache and in the course of it, something unexpected happened. After going through every line of code that they wrote, they realize that the problem is with Apache. They go to the Apache code and find exactly what they expect – that one line of code that needs to be modified … a condition has been reversed in an IF statement or a test has been omitted, or whatever. They fix the line and send a patch off to Apache (which, by the way, is whe-re the name comes f-rom … “a patchy server”) and now they have a server which works so they can continue developing their own project.

Bây giờ, hãy nhìn vào thế giới của phần mềm sở hữu độc quyền. Giả sử bạn là một lập trình viên đang làm việc trong một dự án mà sử dụng một cơ sở dữ liệu sở hữu độc quyền … Oracle, Microsoft SQL Server, hãy tự chọn cái của bạn. Bạn kết luận rằng sẽ phải có một lỗi trong phần mềm cơ sở dữ liệu, nên bạn gọi nhà cung cấp và nói, “Tôi vừa tìm thấy một lỗi trong cơ sở dữ liệu của các ông”. Bạn có thể hãy tưởng tượng sự phản ứng. Sau khi tiếng cười lắng xuống, nhà cung cấp có thể nói, “Vâng, có thể bạn có, nhưng chúng tôi sẽ không sửa nó”. Hoặc có thể chúng tôi sẽ sửa nó, hoặc đã sửa nó rồi, nhưng bạn không thể có nó cho tới phiên bản tiếp sau. Vâng, vấn đề của bạn là hôm nay, nên bạn có động lực để đặt sự khắc phục vào trong mã nguồn của bạn để làm việc với vấn đề này, thứ gì đó hoàn toàn sai và không cần thiết. Ví dụ, bạn có thể gọi điện và nói, “Khi tôi yêu cầu cơ sở dữ liệu 2+2 bằng mấy và nó nói là bằng 5, thì hãy đổi 5 thành 4”. Cực kỳ khó để duy trì sự nói dối, nhưng đây chính xác là những gì xảy ra vì họ không được truy cập tới mã nguồn. Với thời gian, hàng trăm nhà cung cấp cuối cùng sẽ có một kho phần mềm sở hữu độc quyền mà tất cả đều tự họ tìm đặt sự khắc phục trong những thứ không đúng và không thể duy trì được. Tôi tin tưởng điều này giải thích cho một lý do vì sao phần mềm sở hữu độc quyền sẽ trở nên rất dễ vỡ, rất khó để duy trì, rất sớm sau khi triển khai nó.Ngược lại, nó giải thích vì sao phần mềm nguồn mở là rất mềm dẻo. Nó không đầy những rác rưởi như thế.

Mọi thứ mà chúng có ở đó là vì một lý do tốt lành.

Chính xác. Nếu chúng ta đi ngược về thực tế rằng chúng ta đang lãng phí 1.000 tỷ USD một năm, và nhìn vào thực tế rằng mô hình phát triển sở hữu độc quyền đang gây ra cho mỗi lập trình viên sở hữu độc quyền để đặt bản thân họ vào một lớp đặc biệt tồi tệ bởi việc bị ép phải đặt những ý nghĩ sai lầm vào trong mã nguồn của bản thân họ hơn là làm việc trực tiếp với chủ đề, tôi nghĩ điều này giải thích nhiều về những gì đã được quan sát bởi các khách hàng của phần mềm nguồn mở như Thị trường Chứng khoá New York và Cơ quan An ninh Quốc gia. Ấy là, phần mềm nguồn mở đó là tốt hơn, nhanh hơn và rẻ hơn vì trong cốt lõi nó làm việc và có thể được sửa. Những gì bạn nghe trong thế giới sở hữu độc quyền là, “Bạn không thể sửa nó. Có thể chúng tôi sẽ sửa nó, có thể chúng tôi sẽ không”. Những gì là vô cùng lớn lao về cộng đồng nguồn mở là việc “bất kỳ ai” không có nghĩa là “bất kỳ ai ở Red Hat” mà là bất kỳ ai trong cộng đồng của nhiều triệu lập trình viên. Khi bạn nhìn vào những so sánh về chất lượng, rõ ràng rằng hiệu ứng mạng đã trở thành sự sử dụng chung.

Now, let's look at the world of proprietary software. Say you are a developer working on a project that uses a proprietary database … Oracle, Microsoft SQL Server, take your pick. You conclude that there must be a bug in the database software, so you call up the vendor and say, “I've found an error in your database.” You can just imagine the reaction. After the laughter subsides, the vendor might say, “Well, maybe you have, but we're not going to fix it.” Or maybe they will fix it, or have already fixed it, but you can't have it until the next release. Well, your problem is today, so you are motivated to put a workaround into your code to deal with the problem, something completely false and unnecessary. For example, you might put in a line that says, “When I ask the database what 2+2 equals and it says 5, change the 5 to a 4.” It is extremely difficult to maintain a lie, but this is exactly what happens because they don't have access to the code. Over time, the hundreds of vendors who ultimately comprise a proprietary software stack all find themselves putting workarounds in that are unmaintainable and untrue. I believe this explains one reason why proprietary software becomes so brittle, so difficult to maintain, so soon after its implementation. Conversely, it explains why open source software is so flexible. It is not full of such garbage.

Everything that's there is there for a good reason.

Exactly. If we go back to the fact that we're wasting a trillion dollars a year, and look at the fact that the proprietary development model is causing every proprietary developer to put themselves into a special class of hell by being forced to put falsehoods into their own code rather than dealing directly with the subject, I think it explains a lot of what has been observed by open source software customers like the New York Stock Exchange and the National Security Agency. Namely, that open source software is better, faster and cheaper because at the core it works and can be fixed. What you hear in the proprietary world is, “You can't fix it. Maybe we'll fix it, maybe we won't. Depends on how we feel.” In the open source world, the mantra is, “If anybody can fix it, somebody will.” What is fantastic about the open source community is that “anybody” does not mean “anybody at Red Hat” but anybody in the community of multiple millions of developers. When you look at the quality comparisons, it is obvious that the network effect has come into common use.

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

letrungnghia.foss@gmail.com