Google: Nguồn mở cho phép chúng tôi kiểm soát được số phận của mình

By Chris Duckett, Builder AU | 2008/12/03 17:23:01

Theo: http://www.builderau.com.au/strategy/businessmanagement/soa/Google-Open-sourc...

Bài được đưa lên Internet ngày: 03/12/2008

Lời người dịch: Bạn hãy đọc bài này để tự khẳng định với chính mình rằng Google thực sự là một công ty nguồn mở, rằng nguồn mở thực sự đã giúp cho Google kiểm soát được chính họ, kiểm soát được hạ tầng thông tin khổng lồ của họ, rằng theo Google thì không thể kiểm soát được những gì người ta làm với các phần mềm thương mại nguồn đóng vì vô số những hạn chế của các phần mềm thương mại nguồn đóng này. Còn chúng ta thì sao? Có lẽ phải thừa nhận rằng, chúng ta kém toàn diện tới mức không có đủ khả năng để sử dụng các phần mềm nguồn mở chăng? Nên chúng ta phó mặc cho (các) công ty nguồn đóng quyết định số phận không chỉ công ty, mà còn cả chính phủ của chúng ta chăng?

Bằng việc sử dụng nguồn mở, Chris DiBona của Google nói hãng có khả năng kiểm soát đưọc số phận của chính mình mà không có các vấn đề với các nhà cung cấp hoặc dựa dẫm vào bên ngoài cho sự phát triển và cho phép hãng này tuỳ biến với mã nguồn của riêng hãng.

DiBona, giám đốc chương trình nguồn mở của Google, đã đưa ra bài phát biểu mở màn chính tại Hội nghị các nhà lập trình phát triển nguồn mở năm 2008 tại Sydney hôm nay. Builer AU đã chộp được với Dibona sau bài phát biểu chính của ông để thảo luận vì sao Google sử dụng nguồn mở, làm thế nào hãng mở nguồn các phần mềm của mình và những gì sẽ giống như một ký tự sách hài hước.

Làm thế nào Google kiểm soát được số phận của mình với nguồn mở?

DiBona: Về cơ bản, chúng tôi sử dụng nó.

Vấn đề với các phần mềm thương mại là nói chung chúng tôi không thể kiểm soát được những gì bạn làm với nó.

Có những khái niệm rất đặc thù xung quanh cách mà bạn sử dụng nó, ở đâu bạn sử dụng nó, làm thế nào b ạn có thể xuất nó hay không xuất nó ra, làm thế nào bạn có thể sử dụng nó hay không sử dụng nó trên web – ai bạn có thể trình bày một website.

Tôi chắc đang ở Úc rằng bạn đã thấy một website mà nói: “Tôi xin lỗi, bạn đang ở Úc, tôi không thể chỉ cho bạn điều đó”.

Phần mềm nguồn mở không có những hạn chế kiểu như vậy.

Nếu bạn là một công ty, thì việc sử dụng các phần mềm nguồn mở là một khởi đầu tuyệt với cho việc làm những gì bạn muốn với máy tính của bạn – và đó là những gì chúng tôi làm với nó.

By utilising open source, Google's Chris DiBona says the company is able to control its own destiny without having issues with vendors or relying on external parties for development and allowing the company to tinker with its own code.

DiBona, Google's open source program manager, gave the opening keynote at the Open Source Developers' Conference 2008 in Sydney today. Builder AU caught up with DiBona after his keynote to discuss why Google uses open source, how the company open sources its software and what it is like to be a comic book c-haracter.

How does Google control its destiny with open source?

DiBona: Basically, we use it.

The problem with commercial software is that generally you can't control what you do with it.

There's very specific terms around how you use it, whe-re you use it, how you can ship it or not ship it, how you can use it or not use it on the web -- who you can show a website to.

I'm sure being in Australia that you've seen a website that says: "I'm sorry, you're in Australia, I can't show you that".

Open source software doesn't have that kind of restrictions.

If you're a company, using open source software is a great start for doing what you want with your computer -- and that's what we do with it.

As the licence guy for Google, do you spend much time looking at proprietary licences?

Như là người cấp phép cho Google, ông có bỏ ra nhiều thời gian để xem xét các giấy phép sở hữu độc quyền không?

Đúng là tôi mất nhiều thời gian và điều này gây kinh hoàng cho tôi. Việc gây kinh hoàng có lẽ quá mạnh không thể nói lên lời được.

Các phần mềm thương mại thường có những hạn chế trong nó mà rất, rất khó để theo dõi. Không chỉ những hạn chế đối với người sử dụng hay những hạn chế kết nối với máy trạm, mà những thứ như những hạn chế theo mạch logic, hoặc những hạn chế về máy/CPU, hoặc những hạn chế lưu trữ dữ liệu.

Tất cả những thứ dạng này là rất gây phiền cho chúng tôi.

Vì các trung tâm dữ liệu của chúng tôi là lớn một cách kinh ngạc, và vì thế có giá thành dựa trên số lượng những thứ cốt lõi mà bạn có thể chạy thứ gì đó là rất nguy hiểm đối với chúng tôi.

Chúng tôi phải có vài phần mềm bản quyền thương mại, tuyệt đối đúng vậy, nhưng chúng tôi cố giữ những thứ đó là tối thiểu.

Khó mà theo dõi được và đó là thứ gì đó mà tôi không thèm muốn các tổ chức thương mại một chút nào.

Actually I do and it's horrifying to me. Horrifying is probably too strong a word.

Commercial software often has restrictions on it that are very, very difficult to track. Not just user limits or client connection limits, but things like thread limits, or machine/CPU limits, or data storage limitations.

All sorts of things that are very troubling for us.

Because our datacentres are incredibly large, and so having [costs] based on the number of cores that you might run something on is very dangerous for us.

We do have some commercially licensed software, absolutely, but we try to keep that to a minimum.

It's hard to track and it's something that I don't envy commercial organisations on at all.

How important do you consider tracking as an issue for Google, as you mentioned in the keynote that that is why you don't like reciprocal licensing agreements?

Ông xem việc theo dõi quan trọng như thế nào đối với một vấn đề đối với Google, như ông đã nhắc tới trong bài nói rằng vì sao ông không thích những thoả thuận cấp phép qua lại?

Khi bạn xuất một sản phẩm mà là phần mềm theo giấy phép GPL hoặc LGPL, bạn cần duy trì một bản sao trên site của bạn ở đâu đó.

Chúng tôi duy trì những thứ nayhf cho công ty và chúng tôi đã viết tất cả các phần mềm để theo dõi việc sử dụng các phần mềm nguồn mở, nên điều này không khó khăn đối với chúng tôi để thực hiện, nhưng nó là mất thời gian. Đó là những gì khó khăn về những thứ này.

Với các phần mềm thương mại thì đó là đúng là mọi thứ bạn làm và nó sẽ nhân lên sau một thời gian.

Đây không phải là thứ mà chúng tôi muốn các thoả thuận giấy phép [nguồn mở] có đi có lại, chúng tôi đưa ra hàng tấn các phần mềm theo nó, nó chỉ dễ dàng hơn khi chúng tôi tung ra các phần mềm theo dạng giấy phép Apache và BSD.

Chúng tôi có thể nói cho bạn: “Xin hãy nhận lấy, chỉ nhận lấy thôi”, điều này thực sự là rất dễ chịu.

When you ship a product that has GPL or LGPL software, you need to maintain a mirror on your site somewhe-re.

We maintain those for the company and we have written all the software for tracking the use of open source software, so it's not that hard for us to do it, but it is time-consuming. That's what's hard about those things.

With commercial software that's true of everything you do [and] it multiplies after a while.

It's not that we don't like reciprocal [open source] licence agreements, we release tons of software under it, it's just that it's easier when we release software to release it under Apache and BSD style licences.

We can say to you: "Take it, please, just take it", it's really very nice.

When a piece of Google software reaches the stage of being released as open source, what is the process for that?

Khi một mẩu phần mềm của Google đạt được mức độ để được tung ra như một phần mềm nguồn mở, thì quá trình đó là như thế nào?

Thì họ tới chúng tôi và họ nói: “Hey, tôi muốn tung ra các phần mềm này của Google”, và phụ thuộc vào vị trí của chu kỳ phát triển của chúng, điều này sẽ là dễ dàng hoặc khó khăn.

Đôi khi mọi người nói “Tôi muốn tung ra thứ gì đó” và họ có một vài sự phụ thuộc mà họ đã không nhận thức được và chúng tôi nói “bạn có thể và đây là những gì nó sẽ trông giống như đối với bạn”.

Hầu hết các phiên bản, đặc biệt là những phần mềm nhỏ hơn, 3 đến 4 ngày sau đó chúng sẽ được trao quyền từ chúng tôi và chúng tôi chạy nó thông qua những thứ pháp lý và khác nhau như thế đó. Vì thế nó rất, rất dễ cho mọi người để tung ra các phần mềm.

Các bản vá còn dễ dàng hơn, chúng tôi thường phê chuẩn chúng trong vòng 1 giờ đồng hồ.

Hầu hết các dự án mới sẽ được phê chuẩn trong vòng 2 hoặc 3 ngày.

Đối với những dự án lớn hơn như Android và Chrome, thì chúng sẽ phức tạp hơn, chúng lớn hơn và chúng có nhiều những thành phần phụ và dạng những thứ như vậy. Chúng tôi phải đưa ra một mức hạ tầng cho chúng.

Đối với Android chúng tôi duy trì 150 kho Gitg cho chúng. Chúng tôi có nhiều phần mềm phải duy trì các kho và dạng như vậy.

Chúng đòi hỏi nhiều việc hơn, nhưng đó là những gì mà chúng tôi ở đây. Nhưng nó tất cả có thể đo đếm được trong vài ngày qua vòng đời có thể đo đếm được của sản phẩm.

So they come to us and they say: "Hey, I want to release this Google software", and depending on whe-re they are on their cycle of development, it's easy or hard.

Sometimes people say "I want to release something" and they have some dependencies that they didn't realise and we say "You can and here's what it'll look like for you".

Most releases, especially the smaller ones, three or four days later they've been given permission f-rom us and we run it through legal and different stuff like that. So it's very, very easy for people to release software.

Patches are even easier, we usually approve those within the hour.

Most of the new projects are approved within two or three days.

For the larger projects like Android and Chrome, they're more complicated, they're bigger and they have a lot of sub-components and that kind of thing. We have to provide a level of infrastructure for them.

For Android we maintain 150 Git repositories for them. We have a lot of software to maintain the repositories and that kind of thing.

They are a bit more work, but that's what we are here for. But it can all be measured in days over the measurable lifetime of the product.

Why did Google cre-ate Google Code? Why does the world need another SourceForge?

Vì sao Google đã tạo ra Google Code (mã nguồn của Google)? Vì ao thế giới cần một SourceForge khác để làm gì?

Chúng tôi cảm thấy rằng chỉ một nơi, còn đâu đó nữa cho mọi người tới, là một vấn đề.

Tôi nghĩ SourceForge là khá tuyệt vời, và tôi đã làm việc tại VA Linux Systems khi nó mới được khởi tạo. [Mà] một công ty có quá nhiều hạ tầng nguồn mở trong nó, là sức mạnh.

Đó là vì sao tôi hạnh phúc để trở thành một sự sao lưu, mọi người có thể giữ gìn việc phát triển trên SourceForge hoặc bất kỳ thứ gì. Tôi nghĩ nó quá quan trọng không thể để bất kỳ một công ty nào duy trì hạ tầng nhiều như thế cho nguồn mở được.

We felt that just one place, with nowhe-re else for people to go, was a problem.

I think SourceForge is pretty wonderful, and I worked at VA Linux Systems when it was started.

[But] one company having so much of the infrastructure of open source in it, is power.

Which is why I am happy to become a backup, people can keep developing on SourceForge or whatever. I think it is too important to let any one company maintain that much infrastructure for open source.

Is Apache the default licence for Google?

Có phải Apache là giấy phép mặc định cho Google phải không?

Đúng vậy.

Yep.

So when something isn't Apache, what is the reason for that?

Thế khi nào có thứ gì đó không phải là Apache không, vì lý do gì lại như vậy?

Nó thường là những phụ thuộc hoặc những dự án mà chúng tôi muốn phải áp dụng các phần mềm đó theo các giấy phép khác.

Khi chúng tôi đã tung ra dự án libjingle, các dự án mà chúng muốn sử dụng nó là GPL và BSD, và vì thế chúng tôi đã tung ra theo các giấy phép đó như là đối nghịch lại với giấy phép Apache. Như bây giờ, GPL có thể không dùng các phần mềm Apache.

Những gì chúng tôi thường làm trong các trường hợp đó là chúng tôi sẽ thường là một mệnh đề bằng sáng chế cùng với nó mà nói rằng bất kỳ bằng sáng chế nào của Google mà nằm trong phần mềm này, chúng tôi sẽ trao một giấy phép cho b ạn và bất kỳ người sử dụng nào trong số các bạn.

Bằng sáng chế là thực sự quan trọng cho nhóm chúng tôi, và chúng tôi cố gắng mang nó tới cho các giấy phép khác một cách thoải mái bất kỳ khi nào chúng tôi có thể.

Không thông thường khi chúng tôi chọn ra một giấy phép, chúng tôi muốn sẽ có thể tương thích được. Khi chúng tôi tung ra những thứ cho Firefox, việc tung ra theo BSD sẽ có ý nghĩa – và cứ như thế.

Chúng tôi tung ra theo CPL, EPL, BSD, GPL v2 và GPL v3 và một loạt các giấy phép khác.

It's usually dependencies or the projects that we want to have adopt that software are under different licences.

When we released the libjingle project, the projects that wanted to consume it were GPL and BSDs, and so we released under those licences as opposed to the Apache licence. As at the time, the GPL could not consume Apache software.

What we often do in those cases is we will often do a patent clause along with it that says that any Google patents that are in this software, we will give a licence to you and any of your users.

The patent stuff is really important to our group, and we try to bring it to the other licences permissively whenever we can.

Usually when we pick up a licence, we want to be compatible. When we release things for Firefox, releasing under the BSD makes sense -- and so forth.

We release under CPL, EPL, BSD, GPL v2 and GPL v3 and a variety of others.

You mentioned in the keynote that Australia has a lot of mentors and not many students in the Google Summer of Code, is this due to Summer of Code being held during the northern hemisphere summer?

Ông đã nhắc tới trong bài nói rằng nước Úc có nhiều người thông thái và không nhiều sinh viên trong Google Summer of Code (một chương trình viết cho các dự án nguồn mở danh cho sinh viên trong 3 tháng nghỉ hè), có phải là vì Summer of Code đang được giữ trong thời gian là mùa hè của bắc bán cầu không?

Đây là một vấn đề. Sự thay đổi mùa là rất trái khoáy cho chúng tôi, nêu bạn nhìn vào số lượng các sinh viên công nghệ thông tin tại bán cầu bắc so với bán cầu nam – thật khó cho chúng tôi để xác minh việc có phiên bản bán cầu nam của nó.

Đối với một quốc gia có 20 triệu dân, thì bạn có một sự trình bày quá cỡ các nhà thông thái và khoảng kích cỡ thông thường trình diễn các sinh viên trên đầu người. Vì thế bạn sẽ làm tốt từ một quan điểm số lượng sinh viên tham gia Summer of Code theo đầu người, sao cho điều đó có thể dẫn tôi tới sự tin tưởng rằng trong thời gian làm phiên bản bán cầu nam của nó, thì nó sẽ không tạo ra một sự khác biệt.

Nói thế, phiên bản hướng tới trường trung học của Summer of Code mà chúng tôi làm là theo thời gian của bán cầu nam, nó được làm thường trong mùa đông của chúng tôi trong khoảng thời gian tháng 12- tháng 1. Điều đó chạy khá tốt.

Một thứ mà chúng tôi đã lưu ý khi chúng tôi nhìn vào nó, là các trường đại học ở bán cầu nam không có thời gian nghỉ dài như các trường đại học ở bán cầu bắc vào mùa hè, tính theo trung bình. Nó ngắn hơn một chút, và bạn có một kỳ nghỉ giữa các quý dài hơn.

This is a problem. The change of seasons is tricky for us, if you look at the number of computer science students in the northern vs. southern hemispheres -- it's hard for us to justify having a southern hemisphere version of it.

For a country of about 20 million people, you have an oversized representation of mentors and about a regular size representation of students per capita. So you're doing OK f-rom a Summer of Code students/per capita point of view, so that would lead me to believe that during a southern hemisphere version of it, it wouldn't make a difference.

That said, the high school orientation version of the Summer of Code that we do is southern hemisphere timed, it's done usually in our winter during December-January. That works out pretty good.

One thing we noticed when we looked at it, was that southern hemisphere universities don't have as long a break as the northern hemisphere universities over summer, on average. It's a little shorter, and you have a longer inter-quarter break.

It's a cunning world.

What is your stance on the AGPL after your previous kerfuffle over the licence?

Quan điểm của ông là gì về AGPL sau sự ồn ào trước đó của ông về giấy phép này?

AGPL như bạn biết là một mệnh đề web, nên chúng tôi không sử dụng nó trong Google, chúng tôi không cho phép nó vì nó đôi khi là rất khó để theo dõi những tương tác.

Chúng tôi đã có một vài dự án AGPL trong Summer of Code, nên đây là một giấy phép tốt, nhưng nó không phải là để cho chúng tôi.

The AGPL as you know is a web clause, so we don't use it inside Google, we don't allow it because it is very hard to track interactions sometimes.

We've had some AGPL projects in the Summer of Code, so it's a fine licence, but it's not for us.

You've become a comic book c-haracter, is that a tick off the nerd dream list?

Ông đã trở thành một tính cách của sách khôi hài, liệu điều đó có là một sự đánh dấu danh sách trong mơ không?

Ông sẽ cười, nhưng nhiều người đọc sự khôi hài đó, thưa ông. Tôi không bao giờ mong đợi rằng nhiều người sẽ đọc sách khôi hài đó, nó nói cho mọi người chúng tôi đã có một trình duyệt web.

Ông có thấy sự nhại lại mà mọi người đã làm, như sự nhại lại chúa trời không? Chúng rất buồn cười.

Nhưng chúng tôi yêu nó, và chúng làm cho tôi mỏng đi một chút.

You'll laugh, but a lot of people read that comic, man. I never expected that many people to read that comic book, it's telling people we've got a web browser.

Did you see the parodies that people did, like the Godfather parody? They were so funny.

But we love it, and they made me a little thinner.

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

letrungnghia.foss@gmail.com