Thách thức Accumulo, Phần II

The Accumulo Challenge, Part II 

July 5, 2012 in frontpage by Gunnar Hellekson

Theo: http://opensourceforamerica.org/2012/07/the-accumulo-challenge-part-ii-2/

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

Những người quan tâm nhiều tới nguồn mở

These guys care a lot about open source.

Lời người dịch: “Khi mà chính phủ ngày càng tiện lợi hơn với nguồn mở, thì chính phủ sẽ không thể tránh khoải tạo ra nhiều hơn các dự án của riêng họ, và cộng tác với các dự án đang tồn tại. Vì thế thay vì nghĩ về Accumulo một cách hẹp, thì đây đúng là lúc để nghĩ bao quát hơn về cách mà chính phủ tạo ra các dự án nguồn mở, cách mà chính phủ chọn phần mềm được hỗ trợ hoặc không được hỗ trợ, và những gì nên xảy ra khi các dự án của chính phủ bắt đầu cạnh tranh với khu vực tư nhân”. Để tránh việc các cơ quan chính phủ tạo ra các dự án “rẽ nhánh” từ các dự án nguồn mở gốc ban đầu và cạnh tranh với khu vực tư nhân, các cơ quan chính phủ nên trả lời một số câu hỏi trước khi quyết định thực hiện sự rẽ nhánh: (1) Liệu điều đó có là sống còn cho nhiệm vụ? (2) Bạn có chắc là không có giải pháp thương mại hay không? (3) Bạn có chắc là không có lựa chọn thay thế nào không? (4) Nếu bạn rẽ nhánh, nó là cần thiết hay không? (5) Liệu bạn có tính tới tất cả các chi phí chưa? (6) Liệu các giả thiết của bạn có còn đúng hay không?

Trong Phần I, chúng ta đã thảo luận ý định của Ủy ban các Dịch vụ Vũ trang của Thượng viện (SASC) buộc chằng dự án Accumulo vào Bộ Quốc phòng (DoD). Họ đã chỉ thị cho CIO của Bộ nhảy qua một vài vòng báo cáo trước khi Accumunlo có thể được phép trong DoD, và đã chỉ thị cho đội Accumulo ngược lên dòng trên công việc của họ vào trong các dự án nguồn mở có liên quan. Dường như sẽ là một ý định để tháo dỡ các dự án với giả định rằng nó đang cạnh tranh với các sản phẩm và dự án từ khu vực tư nhân.

Trường hợp của Accumulo không phải là lần đầu, và cũng sẽ không phải là lần cuối, dự án bắt gặp ở dạng phản kháng này. Khi mà chính phủ ngày càng tiện lợi hơn với nguồn mở, thì chính phủ sẽ không thể tránh khoải tạo ra nhiều hơn các dự án của riêng họ, và cộng tác với các dự án đang tồn tại. Vì thế thay vì nghĩ về Accumulo một cách hẹp, thì đây đúng là lúc để nghĩ bao quát hơn về cách mà chính phủ tạo ra các dự án nguồn mở, cách mà chính phủ chọn phần mềm được hỗ trợ hoặc không được hỗ trợ, và những gì nên xảy ra khi các dự án của chính phủ bắt đầu cạnh tranh với khu vực tư nhân.

Đây là ví dụ của tôi, được làm sống động phần lớn bằng Thông tư Circular A-130 §8b1(b) của Văn phòng Quản lý Ngân sách (OMB) mà tôi đã nhắc tới ở Phần I. Dù A-130 hầu hết là vô hại, thì nó bao gồm cả một số thực tiễn CNTT có ý nghĩa chung và nó là tốt như một khung công việc như bất kỳ câu trả lời nào cho một số câu hỏi đó. Bây giờ là thời điểm tốt để đọc lại phần đó nếu bạn còn chưa quen với nó.

In Part I, we discussed the Senate Armed Services Committee (SASC)’s attempt to hobble the open source Accumulo project in the DOD. They directed the Department’s CIO to jump through a number of reporting hoops before Accumulo would be allowed inside the DOD, and directed the Accumulo team to upstream their work into related open source projects. It appears to be an attempt to dismantle the project on the assumption that it was competing with products and project from the private sector.

The Accumulo case isn’t the first, and will not be the last, project to encounter this kind of resistance. As the government gets more comfortable with open source, it will inevitably create more of its own projects, and collaborate with existing projects. So rather than think about Accumulo narrowly, this is a good time to think more generally about how the government creates open source projects, how it chooses supported or unsupported software, and what should happen when government projects begin to compete with the private sector.

Here’s my take, animated largely by OMB Circular A-130 §8b1(b) which I mentioned in Part I. Though A-130 is mostly toothless, it does embody a number of common-sense IT practices and it’s as good a framework as any to answer some of these questions. Now’s a good time to re-read that section if you’re not already familiar with it.

Do government-sponsored open source projects automatically compete with the private sector?

Các dự án nguồn mở do chính phủ đỡ đầu có tự động cạnh tranh với khu vực tư nhân hay không?

Không.

Đây là một sự thí điểm có suy nghĩ: điều gì xảy ra nếu Accumulo từng là sản phẩm của một dự án chuyển giao công nghệ thông qua một chương trình như CRADA, IRAD hay SBIR? Trong các chương trình đó, chính phủ cộng tác với khu vực tư nhân để phát triển công nghệ, và thường cung cấp cho người sáng tạo công nghệ đó các quyền đặc biệt nhất định cho sản phẩm làm việc nên họ có thể kiếm tiền trên nó. Nguồn mở là y hệt, ngoại trừ sở hữu trí tuệ là sẵn sàng cho mọi người, chứ không chỉ cho nhà thầu đầu tiên. Nên không có gì vốn dĩ là chống cạnh tranh ở đây cả về nguồn mở. Trên thực tế, việc sử dụng nguồn mở như một chiến lược chuyển giao công nghệ có thể đóng góp cho đổi mới và tăng trưởng của khu vực phần mềm của Mỹ.

Về lịch sử, các dự án của chính phủ đã giúp, chứ không làm hại, cho khu vực tư nhân. Từ điện toán hiệu năng cao cho tới an ninh, các dự án nguồn mở của chính phủ đã tiến bộ về công nghệ, đã tạo ra những doanh nghiệp và thường dỡ bỏ tất cả các tàu thuyền. Tôi sẽ đi đủ xa để nói rằng nguồn mở sẽ là phương pháp được ưu tiên của chuyển giao công nghệ, và tôi không đơn độc.

Điều này không để nói rằng bất kỳ dự án nguồn mở nào cũng đáng làm. §8b1(b)(iii) của A-130 nói cho chúng ta rằng chính phủ sẽ không tạo ra các dự án đúp banr khi một dự án đã tồn tại trong thế giới thương mại: (iii) Công việc hỗ trợ xử lý điều nó đã đơn giản hóa hoặc nếu không đã thiết kế lại để giảm chi phí, cải thiện tính hiệu quả và thực hiện sử dụng tối đa công nghệ thương mại, dùng ngay được.

Miễn là dự án theo yêu cầu không dư thừa, nguồn mở là một cách tuyệt vời để phát triển các công nghệ mới và đảm bảo rằng chúng sẵn sàng một cách rộng rãi cho cả khu vực chính phủ vả tư nhân.

No.

Here’s a thought experiment: what if Accumulo were the product of a technology transfer project via a CRADA, an IRAD or SBIR program? In these, the government collaborates with the private sector to develop technology, and often provides the creator of that technology with certain special rights to the work product so they can make money on it. Open source is the same, except the intellectual property is available to everyone, not just the prime contractor. So there’s nothing inherently anti-competitive about open source. In fact, using open source as a technology transfer strategy can contribute to the innovation and growth of the US software sector.

Historically, the government’s projects have helped, not hurt, the private sector. From high-performance computing to security, the government’s open source projects have advanced technology, created businesses, and generally lifted all boats. I’ll go so far as to say that open source should be the preferred method of technology transfer, and I’m not the only one.

This isn’t to say that any open source project is worth doing. §8b1(b)(iii) of A-130 tells us that the government should not create duplicative projects when one already exists in the commercial world:

(iii) Support work processes that it has simplified or otherwise redesigned to reduce costs, improve effectiveness, and make maximum use of commercial, off-the-shelf technology;

Provided the project in question isn’t redundant, open source is a great way of developing new technologies and ensuring that they’re widely available to both the government and the private sector.

Is it fair for the government to support open source with staff and money?

Liệu có công bằng khi chính phủ hỗ trợ nguồn mở bằng các nhân viên và tiền của mình?

Vì chính phủ có thể đỡ đầu cho các dự án đổi mới, miễn là có nhu cầu theo nhiệm vụ rõ ràng. Điều đó đặt chúng ta vào với câu hỏi về những người đóng góp do chính phủ bảo trợ Nhiều người duy trì của Accumulo đang cung cấp các tài nguyên cho một dự án phần mềm thương mại mà có thể (cuối cùng) cạnh tranh trực tiếp với các bản chào thương mại có sẵn khác. Nó có là tồi tệ không?

Nếu một chương trình của chính phủ thấy một nhu cầu nhiệm vụ không được thế giới thương mại làm cho thỏa mãn, thì chính phủ có lý để bỏ ra các tài nguyên để làm thỏa mãn nhu cầu đó. Ví dụ, Trung tâm Tích hợp Mạng của Không quân Mỹ, tạo ra hệ điều hành “An ninh Khả chuyển hạng Nhẹ” - LPS (Lightweight Portable Security) cho phép các nhà truyền thông kết nối một cách an toàn tới các mạng của DoD. Nó dựa trên Linux. Dù có nhiều phát tán Linux thương mại có sẵn, thì không phát tán nào làm thỏa mãn được những yêu cầu của LPS một cách chính xác. Quan trọng là, AFNIC không đơn giản là việc đóng gói lại Linux. Họ đang sử dụng lại các phần mềm thương mại có sẵn càng nhiều càng tốt, và bỏ ra thời gian và tiền bạc của họ để bổ sung giá trị có thể phân biệt được, thực tiễn cho một phát án Linux chung. Điều này có nghĩa là LPS là tuân thủ với §8b1(b)(iv) của A-130:

(iv) Làm giảm rủi ro bằng việc tránh hoặc cô lập các thành phần được thiết kế tùy biến, có sử dụng các thành phần mà có thể được kiểm thử hoặc làm mẫu đầy đủ trước khi sản xuất, và đảm bảo sự liên can và hỗ trợ những người sử dụng;

Trường hợp của Accumulo, ít nhất lúc ban đầu, đã là khác rồi. An ninh mức nhân (cell) và các tính năng khác làm cho Accumulo duy nhất từng không phải là sẵn có một cách thương mại cho NSA. Giống như LPS, họ đã xây dựng những gì họ cần trên các thành phần thương mại có sẵn. Điều này là rất phổ biến, và thực tế là NSA đã thể hiện tâm trí để phát hành công việc đó như là một dự án nguồn mở nên được khen thưởng.

Thực tế là Accumulo đã bắt đầu như là phần mềm được chính phủ phát triển và bây giờ là phần mềm thương mại có sẵn không mang theo khả năng của chính phủ để tiếp tục làm việc tiếp và cải tiến phần mềm đó. Việc cải tiến phần mềm là, sau tất cả, hoàn toàn được khuyến khích theo “Bản ghi nhớ Nguồn Mở” của DoD năm 2009:

(ii) Khả năng không bị hạn chế để sửa đổi mã nguồn phần mềm cho phép Bộ phản ứng được nhanh hơn đối với các tình huống thay đổi và cá mối đe dọa trong tương lai.

Đã nói tất cả điều đó: chỉ vì chính phủ có thể tùy biến phần mềm cho các nhu cầu của mình không có nghĩa là họ sẽ nên. Đừng quên rằng §8b1(b)(i) và §8b1(b)(ii) của A-130 cũng phải được làm cho thỏa mãn. Nếu một dự án bỗng nhiên đúp bản hoặc không theo nhiệm vụ của một cơ quan, thì dự án đó nên sử dụng một thành phần thương mại đang có sẵn.

So the government can sponsor innovative projects, provided there’s an obvious mission need. That leaves us with the question of government-sponsored contributors. Many of the Accumulo maintainers are government employees or contractors. We’re now in a strange gray area where the government is providing resources to a commercial software project that may (eventually) compete directly with other commercially available offerings. Is this bad?

If a government program finds a mission need unfulfilled by the commercial world, it makes sense to spend resources to satisfy that need. The US Air Force Network Integration Center, for example, produces the “Lightweight Portable Security” operating system that allows telecommuters to safely connect to DOD networks. It’s based on Linux. Although there are many commercial Linux distributions available, none satisfy LPS’ requirements exactly. Crucially, AFNIC is not simply repackaging Linux. They are re-using as much commercially available software as possible, and spending their time and money adding real, differetiated value to an otherwise generic Linux distribution. This means that LPS is consistent with §8b1(b)(iv) of A-130:

(iv) Reduce risk by avoiding or isolating custom designed components, using components that can be fully tested or prototyped prior to production, and ensuring involvement and support of users;

The Accumulo case, at least at the start, was no different. Cell-level security and the other features that make Accumulo unique were not commercially available to the NSA. Like LPS, they built what they needed on commercially available components. This is very common, and the fact that the NSA had the presence of mind to release that work as an open source project should be rewarded.

The fact that Accumulo began as government-developed software and is now commercially available software has no bearing on the government’s ability to continue working on and improving that software. Improving software is, after all, explicitly encouraged by the DOD “Open Source Memo” of 2009:

(ii) The unrestricted ability to modify software source code enables the Department to respond more rapidly to changing situations, missions, and future threats.

Having said all that: just because the government can customize software for its needs doesn’t mean that they should. Don’t forget that §8b1(b)(i) and  §8b1(b)(ii) of A-130 also have to be satisfied. If a project is suddenly duplicative or not in keeping with an agency’s mission, the project should use an existing, commercial component.

So what happens when a project becomes duplicative?

Điều gì sẽ xảy ra khi một dự án trở thành đúp bản?

SASC từng lo lắng rằng Accumulo bằng cách nào đó can thiệp vào các dự án HBase và Cassandra, các dự án cũng giải quyết nhiều, dù không phải tất cả, các vấn đề y hệt mà Accumulo đang làm. Nếu HBase hoặc dự án khác bắt đầu đáp ứng được các nhu cầu của chính phủ và làm cho các tính năng giống như của Accumulo sẵn sàng, thì A-130 gợi ý rằng chính phủ sẽ xem xét sát sao hơn vào những chào mời thương mại có sẵn hoặc ngược lên dòng trên mã nguồn của nó để loại bỏ xung đột. §8b1(b)(v) và các cách thức tốt của nguồn mở đồng ý về điều này:

(v) Thể hiện một sự hoàn vốn đầu tư có kế hoạch mà rõ ràng ngang bằng hoặc tốt hơn so với những sử dụng theo các lựa chọn thay thế các tài nguyên nhà nước có sẵn...

Tất nhiên, những người của Accumulo đã phát hành rồi dự án của họ cho công chúng, và đã làm thế khi không có sự cạnh tranh về giải pháp mà họ đã đưa ra. Khi họ đã làm điều đó, thì Accumulo đã trở thành phần mềm thương mại theo các điều khoản của FAR và DFAR. Điều đó làm thay đổi hoàn toàn hoàn cảnh. Accumulo bây giờ giống hệt như bất kỳ chào mời thương mại nào khác, và có thể thắng hoặc thua về giá trị của nó. Như chúng ta đã thảo luận trước đó, chính phủ sẽ tự do để hỗ trợ dự án đó miễn là nó thúc đẩy nhiệm vụ của chính phủ theo một cách thức có hiệu quả về chi phí. Không có sự thiệt hại nào ở đây cả. Trong thực tế, điều tuyệt vời là Accumulo đang cải thiện sự phát triển trong lĩnh vực này của phần mềm và khuyến khích các dự án như HBase và Cassandra tiến bộ. Đây là một ví dụ về thị trường làm việc, mà không có sự can thiệp của SASC.

SASC was worried that Accumulo was somehow interfering with the HBase and Cassandra projects, which solve many, though not all, of the same problems Accumulo does. If HBase or another project begin to respond to the government’s needs and make Accumulo-like features available, A-130 suggests that the government to take a close look at those commercially available offerings or upstream its code to eliminate the conflict. §8b1(b)(v) and good open source manners agree on this:

(v) Demonstrate a projected return on the investment that is clearly equal to or better than alternative uses of available public resources…

Of course, the Accumulo folks already released their project to the public, and did so when there was no competition for the solution they provided. When they did that, Accumulo became commercial software under the terms of the FAR and DFAR. That changes the situation entirely. Accumulo is now just like any other commercial offering, and can win or lose on its merits. As we discussed earlier, the government should be free to support that project as long as it’s advancing its mission in a cost-effective manner. No harm done, here. In fact, it’s great that Accumulo is advancing development in this area of software and encouraging projects like HBase and Cassandra to keep up. This is an example of the market working, without SASC’s intervention.

Can the government fork an open source project?

Chính phủ có thể rẽ nhánh một dự án nguồn mở không?

“Rẽ nhánh”, mà có nghĩa là tạo ra phiên bản của riêng bạn đối với một dự án thay vì cộng tác với cộng đồng dòng chính thống, là khác phức tạp hơn. Rẽ nhánh được hiểu một cách rộng rãi như một phương cách cuối cùng, lựa chọn hạt nhân trong cộng đồng nguồn mở vì nó tạo ra sự mắc nợ về kỹ thuật và cướp đi của dự án dòng chính thống sự chú ý có giá trị.

Nếu chính phủ tạo ra phiên bản của riêng mình đối với một dự án đang hoạt động đang có sẵn mà không có lý do rõ ràng, thì điều này không chỉ là một quyết định tồi về kỹ thuật, mà còn tồi về chính sách. Đây không phải là nhiệm vụ của một cơ quan, ví dụ, để tạo ra một hệ điều hành hoặc trình soạn thảo văn bản mục đích chung. Có nhiều những thứ sản phẩm thương mại có sẵn như vậy, và không có lý do gì chính phủ lại sẽ làm xói mòn nền công nghiệp phần mềm Mỹ bằng việc chèn ép những lựa chọn thay thế có khả năng sống được đang tồn tại rồi đối với công chúng.

Các chiến lược tốt hơn là sẵn sàng. Chính phủ (giống hệt như một công ty tư nhân) có thể thực hiện mọi nỗ lực để sử dụng mã nguồn thương mại có sẵn, đang tồn tại hơn là nhận lấy trách nhiệm cho phiên bản của riêng họ đối với toàn bộ dự án đó. Điều này có thể có nghĩa việc sử đổi bổ sung các module đặc thù mà họ cần hoặc việc duy trì một tập hợp các bản vá tùy chọn đối với dự án dòng chính thống. §8b1(b)(iv) là rõ ràng về điều này, như chúng ta đã thảo luận, và đã có một chính sách cho kho mã nguồn do DoD vận hành, forge.mil. Những người của forge.mil không tích cực khuyến khích mã nguồn thương mại đang được đặt chỗ ở đó, sợ rằng chúng sẽ - thậm chí không cố ý - tạo ra một rẽ nhánh của dự án chỉ dành cho chính phủ. Nếu chính phủ cần phải sửa đổi các phần mềm thương mại cho các mục đích của riêng họ, thì họ nên đóng khung hoạt động của họ vào những thay đổi cụ thể mà họ cần hơn là tạo ra toàn bộ một tác phẩm mới.

Không có gì về điều này có nghĩa rằng một rẽ nhánh bị cấm cả. Nó có nghĩa là quyết định rẽ nhánh là nghiêm túc, và có quan mà rẽ nhánh nên được chuẩn bị với một phân tích các lựa chọn thay thế, các chứng minh chi phí, một kế hoạch hỗ trợ và duy trì, cũng như một chiến lược giảm nhẹ rủi ro. Như là vấn đề thực tiễn, dễ hơn nhiều để tránh một rẽ nhánh ngay từ đầu.

“Forking,” which means creating your own version of a project rather than collaborating with its mainstream community, is slightly more complicated. Forking is widely understood as a last-resort, nuclear option in the open source community because it creates technical debt and robs the mainstream project of valuable attention.

If the government created its own version of an existing, functional project without a clear reason, it’s not just a bad technical decision, it’s also bad policy. It’s not an agency’s mission, for instance, to create a general-purpose operating system or word processor. There are plenty of these available as commercial products, and there’s no reason the government should undermine the US software industry by crowding out viable alternatives already available to the public.

Better strategies are available. The government (just like a private company) can make every effort to use existing, commercially available code rather than assume responsibility for their own version of the whole project. This may mean adding specific modules that they need or maintaining an optional set of patches to the mainstream project.  §8b1(b)(iv) is explicit about this, as we already discussed, and it’s already policy for the DOD-operated source repository, forge.mil. The forge.mil folks actively discourage commercial code from being hosted there, for fear that they’ll – even inadvertently – create a government-only fork of the project. If the government needs to alter commercial software for their own purposes, they should confine their activity to the specific changes they need rather than create a wholly new work.

None of this means that a fork is forbidden. It means that the decision to fork is serious, and the agency who forks should be prepared with an analysis of alternatives, cost justifications, a support and maintenance plan, as well as a risk mitigation strategy. As a practical matter, it’s far easier to avoid a fork in the first place.

So when should the government merge a project? Who gets to decide?

Khi nào thì chính phủ trộn một dự án? Ai sẽ phải quyết định?

Một người có thể tưởng tượng bất kỳ số lượng lý do pháp lý nào vì sao Cơ quan được bầu lại xây dựng và hỗ trợ cho một lựa chọn thay thế cho HBase hoặc Cassandra. Liệu họ có đang đưa ra một quyết định tồi hay không? Điều đó hoàn toàn có khả năng. Tôi nghĩ, dù, rằng các cơ quan nên được phép tự do làm theo ý mình thế này. Miễn là họ đang tạo ra thứ gì đó phù hợp với nhiệm vụ và thực sự là mới - thứ gì đó đúng về Accumulo một cách không bàn cãi - dạng tự do như vậy, một cách công bằng, là một lợi ích.

Tôi có thể tưởng tượng thời điểm khi dự án Accumulo của Apache có thể quyết định rằng việc cạnh tranh với các dự án khác là quá tốn kém. Những người cầm đầu dự án có thể sau đó bầu chọn để gửi một số tính năng đặc thù của Accumulo cho các dự án ngược lên dòng trên khác, với hy vọng làm giảm nhẹ bớt gánh nặng duy trì của họ. Một lần nữa, điều này xảy ra tất cả mọi lúc và là một trong những khả năng lớn của qui trình nguồn mở.

Nó cũng có thể làm việc theo cách khác: những người duy trì HBase có thể quyết định rằng các tính năng của Accumulo là có giá trị, và chọn để kéo vài tính năng trong số chúng từ Accumulo ngược lại vào HBase. Họ tự do tuyệt vời để làm thế, và đây cũng là thứ gì đó xảy ra mọi thời gian trong các dự án nguồn mở.

Buồn thay, SASC đã quyết đinhj rằng đủ tư cách tốt hơn để quản lý dự án Accumulo hơn những người duy trì của dự án. Đây là một tiền lệ nguy hiểm cho tất cả các dự án nguồn mở. Ý định đằng sau sự làm luật là tốt: những rẽ nhánh thường là tồi, và chính phủ nên tránh cạnh tranh với khu vực tư nhân. Cùng lúc, Accumulo là nguồn mở. Điều đó tiêm chungr cho Accumulo chống lại những chỉ trích đó, và trong trường hợp điều §8b1(b) và bản ghi nhớ về nguồn mở của DoD năm 2009 đưa ra khá nhiều chỉ dẫn cho người quản lý chương trình có thể sử dụng để đưa ra dạng quyết định này. Bổ sung thêm từ ngữ cho NDAA năm 2013 là hoàn toàn không cần thiết và có lẽ phản tác dụng.

One can imagine any number of legitimate reasons why the Agency elected to build and support an alternative to HBase or Cassandra. Are they making a bad decision? That’s entirely possible. I think, though, that agencies should be permitted this discretion. As long as they’re creating something relevant to the mission and genuinely new – which was indisputably true of Accumulo – this kind of freedom is, on balance, a benefit.

I can imagine a time when Apache’s Accumulo project would decide that competing with the other projects is too costly. Project leaders would then elect to send some Accumulo-specific features to other upstream projects, in hopes of relieving their maintenance burden. Again, this happens all the time and is one of the great possibilities of the open source process.

It could work the other way, too: the HBase maintainers may decide that Accumulo’s features are valuable, and choose to drag some of them from Accumulo back into HBase. They’re perfectly free to do so, and this is also something that happens all the time in open source projects.

Sadly, SASC has decided that it’s better-qualified to manage the Accumulo project than the project maintainers. This is a dangerous precedent for all open source projects. The intention behind the legislation is good: forks are generally bad, and the government should avoid competing with the private sector. At the same time, Accumulo is open source. That inoculates Accumulo against these criticisms, and in any case §8b1(b) and the DOD open source memo of 2009 provide plenty of guidance the program manager can use to make this kind of decision. Adding language to the 2013 NDAA is completely unnecessary and probably counterproductive.

So what’s to be done?

Cái gì đã được thực hiện?

Nếu mã nguồn là đóng, bạn có thể viện lý rằng Accumulo đang làm phí các tài nguyên của chính phủ và can thiệp vào khu vực tư nhân. May thay, điều đó không phải thế - nó là tự do cho bất kỳ ai, bao gồm cả các dự án Cassandra hay HBase, để sử dụng. Là hữu dụng để nghĩ về Accumulo như một chiến lược khôn ngoan của chính phủ để cải tiến hướng tới sự hiện đại. Biết rằng chính phủ có quan tâm về những thứ như an ninh mức cốt lõi, Accumulo đã khuyến khích các dự án tương tự khác giải quyết các câu hỏi y hệt. Theo cách này, sự cạnh tranh giữa Accumulo và HBase hoàn toàn khác nhau so với dạng cạnh tranh mà chúng ta thấy trong nghiên cứu khoa học: nhiều bên, tất cả hướng tới sự hiện đại hóa, vì lợi ích của tất cả mọi người. Chúng ta sẽ không mơ tưởng về việc ứng xử với nghiên cứu do chính phủ cấp vốn như một mối đe dọa cho nghiên cứu do tư nhân cấp vốn, thì cái gì làm cho các dự án phần mềm đó khác nhau chứ?

If the code was closed, you could argue that Accumulo is squandering government resources and interfering with the private sector. Fortunately, that’s not the case – it’s free for anyone, including the Cassandra or HBase projects, to use. It’s useful to think about Accumulo as a shrewd government strategy to advance the state of the art. Knowing that the government is concerned about things like cell-level security, Accumulo has already encouraged other, similar, projects to address these same questions. In this way, the competition between Accumulo and HBase is not altogether different than the kind of competition we see in scientific research: many parties, all advancing the state of the art, to the benefit of everyone. We wouldn’t dream of treating government-funded research as a threat to privately funded research, so what makes these software projects different?

However.

Tuy nhiên

Trong khi tôi không cảm thấy sự can thiệp của Quốc hội là cần thiết, thì rõ ràng là chúng ta cần nói về các cách thức để tinh chỉnh các chính sách để làm cho các tình huống đó ít không chắc chắn hơn. Đặc biệt, cách mà chúng ta sẽ biết khi nào các dự án của chính phủ là được phép, và không can thiệp vào công việc tốt lành của khu vực tư nhân? Tôi sẽ đưa ra một vài câu hỏi mà mỗi dự án phần mềm của chính phủ nên tự hỏi mình để trả lời cho câu hỏi quan trọng đó:

• Liệu điều đó có là sống còn cho nhiệm vụ? Rõ ràng, các cơ quan chính phủ không nên phí phạm thời gian tạo ra các dự án mà là thừa không cần thiết đối với nhiệm vụ của họ. Điều này là dễ dàng, và được đề cập tới trong §8b1(b)(i) của A-130.
• Bạn có chắc là không có giải pháp thương mại hay không? Có tất cả các dạng công cụ có sẵn cho những người quản lý các dự án chính phủ có thể giúp họ học được nhiều hơn về thị trường đối với vấn đề của họ. Thông qua RFIs, các Ngày cùa Giới công nghiệp, và giao tiếp thường xuyên với giới công nghiệp, bạn có thể chắc chắn rằng bạn đã vắt kiệt các lựa chọn thương mại của bạn trước khi nhảy vào một qui trình phức tạp và đắt đỏ của việc duy trì dự án phần mềm của riêng bạn. Trong Phần 929, SASC chỉ cho CIO của DoD để đảm bảo công việc nhà này được thực hiện, mà những qui định và qui trình để làm điều này là rất rõ ràng rồi theo §8b1(b)(ii) và §8b1(b)(iii).
• Bạn có chắc là không có lựa chọn thay thế nào không? Tôi ngụ ý, thực sự có chắc không? Đừng chỉ dựa vào giới công nghiệp để nói cho bạn những gì có ngoài đó. Nhiều giải pháp của bạn có thể sẵn sàng như các dự án nguồn mở mà không có lợi từ một thực thể thương mại mà có thể trả lời cho RFIs hoặc tham gia vào những ngày công nghiệp. Hãy thận trọng về điều này: thật dễ để làm một tìm kiếm nhanh trên Google và công bố sự hiếm hoi của thị trường. Cũng rất dễ để đặt ra rào cản cao không thể tưởng, và nói rằng vì không có máy biến đổi XML đáng tin cậy nào với các máy chủ nhúng IMAP, nên bạn phải xây dựng phần mềm riêng cho bạn. Hãy là hợp lý.
• Nếu bạn rẽ nhánh, nó là cần thiết hay không? Có tất cả các dạng tài liệu về quyết định này, bao gồm cả §8b1(b)(iv), mà tôi sẽ không đề cập tới ở đây, nhưng quyết định rẽ nhánh là một quyết định nghiêm trọng. Liệu các yêu cầu của bạn có được làm cho thỏa mãn thay vì một bản vá hay không? Liệu bạn có được chuẩn bị để ôm những gánh nặng duy trì cho tương lai có thể dự đoán trước được hay không? Quyết định đó là một quyết định phức tạp, và một văn phòng chương trình sẽ không ra chúng một cách đơn giản. Một rẽ nhánh dường như dễ dàng hơn lúc ban đầu, nhưng nó sẽ là nặng, nặng gánh hơn nhiều về lâu dài qua thời gian.
• Liệu bạn có tính tới tất cả các chi phí chưa? Điều này là khó khăn hơn nhiều, nhưng hãy bớt chút thời gian đọc §8b1(b)(v) và chỉ ra chính xác bạn đã làm cho cuộc sống của bạn phức tạp tới mức nào. Vì bạn đang sử dụng dự án của riêng bạn, liệu bạn có một gánh nặng duy trì lớn hơn hay không? Liệu các chi phí hỗ trợ có cao hơn không? Thế còn về sự chứng nhận hoặc sự tin cậy bổ sung có làm việc hay không? Thế còn chi phí để thoát ra của bạn thì sao - sẽ là nặng nề hơn để chuyển sang một lựa chọn thay thế tốt hơn trong tương lai vì bạn đang sử dụng một mẩu phần mềm đặc thù của chính phủ, liệu có hay không?
• Liệu các giả thiết của bạn có còn đúng hay không? Đây là điều quan trọng nhất, và câu hỏi được trường hợp của Accumulo đặt ra. Bạn có thể đọc §8b1(b)(vii), thực hiện Phân tích các Lựa chọn thay thế của bạn, nghiên cứu thị trường của bạn, xác định các yêu cầu của bạn, nhưng điều đó là 2 năm về trước. Có đúng là không có lựa chọn thay thế nào khác nữa hay không? Liệu có thể có dự án nào khác mà bạn có thể làm việc cùng để giảm được gánh nặng của bạn hay không? Có một sự đánh giá lại chân thực, thường xuyên những giả thiết của bạn sẽ giữ cho bạn khỏi đi lang thang quá xa khỏi sự bảo lưu.

Bây giờ tới lượt bạn: điều gì nữa các cơ quan sẽ nghĩ tới nhỉ?

While I don’t feel Congressional intervention is necessary, it’s obvious that we need to talk about ways to refine policies to make these situations less uncertain. Specifically, how will we know when government projects are permissible, and do not interfere with the good work of the private sector? I’ll offer a few questions every government software project should ask itself to answer that important question:

• Is it critical to the mission? Obviously, the government agencies shouldn’t be wasting their time creating projects that are superfluous to their mission. This one’s easy, and covered by §8b1(b)(i) of A-130.
• Are you sure there’s no commercial solution? There are all kinds of tools available to government project managers that can help them learn more about the market for their problem. Through RFIs, Industry Days, and regular communication with industry, you can make sure that you’ve exhausted your commercial options before embarking on the complex and expensive process of maintaining your own software project. In Section 929, SASC directs the DOD CIO to ensure this homework has been done, but the rules and process for doing this are already very clear under §8b1(b)(ii) and §8b1(b)(iii).
• Are you sure there are no alternatives? I mean, really sure? Don’t just rely on industry to tell you what’s out there. Many of your solutions may be available as open source projects that don’t benefit from a commercial entity that can respond to RFIs or attend industry days. Be deliberate about this: it’s easy to do a quick Google search and declare the market barren. It’s also easy to raise the bar impossibly high, and say that because there are no accredited XML transformation engines with embedded IMAP servers, you have to build your own. Be reasonable.
• If you fork, is it necessary? There’s all kinds of literature on this decision, including §8b1(b)(iv), which I won’t cover here, but the decision to fork is a serious one. Can you get your requirements fulfilled with a patch instead? Are you prepared to carry the maintenance burden for the foreseeable future? The decision is a complicated one, and a program office shouldn’t take them lightly. A fork may seem easier at first, but it will be much, much harder over the long term.
• Have you accounted for all the costs? This is notoriously difficult, but take a moment to read §8b1(b)(v) and figure out exactly how complicated you’ve made your life. Because you’re using your own project, do you have a greater maintenance burden? Higher support costs? What about the additional certification or accreditation work? What about your exit costs – will it be harder to move to a better alternative in the future because you’re using a government-specific piece of software?
• Are your assumptions still true? This is the most important, and the question demanded by the Accumulo case. You may read §8b1(b)(vii), done your Analysis of Alternatives, your market research, determined your requirements, but that was two years ago. Is there still no alternative? Maybe there’s another project you could work with to reduce your burden? Having a regular, honest re-evaluation of your assumptions will keep you from wandering too far off the reservation.

Now it’s your turn: what else should agencies be thinking about?

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Thách thức Accumulo, Phần I

The Accumulo Challenge, Part I

June 18, 2012
Theo: http://atechnologyjobisnoexcuse.com/2012/06/the-accumulo-challenge-part-i/
Bài được đưa lên Internet ngày: 18/06/2012

Lời người dịch: Khi các cơ quan nhà nước tham gia phát triển các dự án nguồn mở, nếu làm không đúng, họ sẽ biến dự án đó thành một bản rẽ nhánh của dự án ban đầu, gây đúp bản một cách không cần thiết và dẫm chân lên các công việc của giới công nghiệp, của các công ty, làm bóp méo thị trường. Sẽ là nguy hiểm hơn, nếu họ lại đưa ra các văn bản pháp qui để bảo vệ cho những sai lầm đó. Bài viết này nói về một dự án nguồn mở như vậy tại Cơ quan An ninh Quốc gia Mỹ, NSA. Cũng từ vụ việc này, một loạt các câu hỏi đã được đặt ra, ví dụ như: “Liệu chính phủ có làm hại cho khu vực tư nhân khi họ phát hành các dự án nguồn mở hay không? Làm thế nào chúng ta có thể biết khi nào nguồn mở là một cách thức phù hợp cho chính phủ để phát triển phần mềm? Làm thế nào chính phủ điều hành được các bản rẽ nhánh?”

Hàng tá các dự án phần mềm được tung ra trong sự bừng tỉnh của các tài liệu Big Table và Map Reduce của Google đã thay đổi cách thức chúng ta điều khiển các tập hợp dữ liệu lớn. Giống như nhiều tổ chức, NSA đã bắt đầu trải nghiệm với các công cụ của “các dữ liệu lớn” và đã nhận ra rằng những triển khai nguồn mở đang tồn tại lúc này từng không đề cập tới một số nhu cầu đặc biệt của họ. Họ đã quyết định bắt tay vào dự án của riêng họ: Accumulo. Họ từng hạnh phúc với các mà Accumulo làm việc, họ làm đúng thứ cần làm và đã đưa ra Accumulo cho thế giới thông qua Quỹ Apache.

Đây là thứ tuyệt vời cho nguồn mở và người đóng thuế. Chính phủ thấy một yêu ầu không được khu vực tư nhân làm thỏa mãn, và thay vì để công việc của họ phai tàn bên trong các bức tường của mình, hoặc trả tiền cho một nhà thầu để phát triển một giải pháp sở hữu độc quyền, họ đã chia sẻ những gì họ đã có với thế giới. Đây là những gì những người bảo vệ nguồn mở đã từng kêu gọi và với sáng kiến Chia sẻ Trước tiên (Shared First) tại Văn phòng Quản lý Ngân sách OMB và các chính sách nguồn mở đổi mới như tại Văn phòng Bảo vệ Tài chính Người tiêu dùng, thì đây chắc chắn là điều chúng ta sẽ thấy nhiều hơn về dạng chia sẻ này của công việc được những người đóng thuế cung cấp tiền.

Dù đây là một mẻ đánh bắt. Khi nó được tung ra, Accumulo đã tham gia vào một không gian các công cụ của đám đông ngày một gia tăng mà quản lý các dữ liệu lớn. Khi những người mới phất đó cạnh tranh - bằng chứng và thành công lạ thường của MongoDB từ các triển khai cài đặt của 10 gen, Hadoop từ Cloudera và HortonWorks, các công cụ như Hadapt, Hbase, Cassandra, MapR, và nhiều, nhiều dự án khác – Accumulo thể hiện một mối đe dọa. Một số trong những sản phẩm và dự án đó cạnh tranh với nhau, và khu vực tư nhân không thích nó khi chính phủ cạnh tranh cùng với họ, vì lý do tốt.

The dozens of software projects launched in the wake of Google’s Big Table and Map Reduce papers have changed the way we handle large datasets. Like many organizations, the NSA began experimenting with these “big data” tools and realized that the open source implementations available at the time were not addressing some of their particular needs. They decided to embark on their own project: Accumulo. Once they were happy with how Accumulo was working, they did the right thing and released Accumulo to the world through the Apache Foundation.

This is great for open source and the taxpayer. The government found a requirement not being fulfilled by the private sector, and rather than letting their work languish inside its walls, or paying a contractor to develop a proprietary solution, they shared what they had with the world. This is what open source advocates have been clamoring for, and with the Shared First initiative at OMB and innovative open source policies like those at the Consumer Financial Protection Bureau, it’s certain we’ll see more of this kind of sharing of taxpayer-funded work.

There’s a catch, though. Since it was launched, Accumulo has joined an increasingly crowded space for tools that manage big data. As these upstarts compete – witness the extraordinary success of MongoDB from 10gen, Hadoop implementations from Cloudera and HortonWorks, tools like Hadapt, HBase, Cassandra, MapR, and many, many others – Accumulo presents a threat. Some of these products and projects already compete with each other, and the private sector doesn’t like it when the government competes alongside them, for good reason.

There’s a frequently-ignored policy called OMB Circular A-130 which says that the government shouldn’t build something already available from the private sector. In the language of the policy, the government should:

…acquire off-the-shelf software from commercial sources, unless the cost effectiveness of developing custom software is clear and has been documented through pilot projects or prototypes

So there’s a tension here: we want the government to share its innovations, but we don’t want the government to crowd out the private sector. That’s the thinking behind this recent language in Section 929 of S.3254, the 2013 Defense Authorization as reported out by the Senate Armed Services Committee:

Có một chính sách thường xuyên bị bỏ qua gọi là Thông tư A-130 của OMB mà nói rằng chính phủ sẽ không xây dựng thứ gì đã có sẵn rồi từ khu vực nhà nước. Theo ngôn từ của chính sách đó, chính phủ sẽ:

… mua sắm các phần mềm sử dụng được ngay từ các nguồn thương mại, trừ phi tính hiệu quả về chi phí của phần mềm tùy biến đang phát triển là rõ ràng và đã được làm thành tài liệu thông qua các dự án thí điểm hoặc các dự án mẫu. Vì thế có sự căng thẳng ở đây: chúng ta muốn chính phủ chia sẻ đổi mới, nhưng chúng ta không muốn chính phủ đẩy khu vực tư nhân ra. Đó là tư duy đằng sau ngôn từ gần đây này trong Phần 929 của S.3254, Sự ủy quyền Quốc phòng như được Ủy ban các Dịch vụ Vũ trang Thượng viện báo cáo.

(a) Hạn chế về Sử dụng Cơ sở dữ liệu của NSA -

(1) HẠN CHẾ - Không thành phần nào của Bộ Quốc phòng có thể sử dụng cơ sở điện toán đám mây được Cơ quan An ninh Quốc gia (NSA) phát triển được gọi là Accumulo sau ngày 30/09/2013, trừ phi Giám đốc Thông tin của Bộ Quốc phòng chứng thực một trong những điều sau đây:

(A) Rằng không có các cơ sở dữ liệu nguồn mở thương mại nào có khả năng tồn tại được với sự hỗ trợ tăng cường của giới công nghiệp (như các cơ sở dữ liệu HBase và Cassandra của Quỹ Linux) mà có các tính năng an ninh có khả năng so sánh được với cơ sở dữ liệu Accumulo được xem là cơ bản đối với Giám đốc Thông tin vì những mục đích chứng thực theo đoạn này.

(B) Rằng cơ sở dữ liệu Accumulo đã trở thành một cơ sở dữ liệu nguồn mở thành công của Quỹ Apache với sự hỗ trợ và đa dạng hóa phù hợp của giới công nghiệp, dựa vào các tiêu chí được Giám đốc Thông tin thiết lập cho những mục đích chứng thực theo đoạn này và được đệ trình cho các ủy ban phù hợp của Nghị viện không muộn hơn ngày 01/01/2013.

(2) XÂY DỰNG - Hạn chế trong đoạn (1) sẽ không áp dụng cho NSA.

(b) Áp dụng các Tính năng An ninh của Accumulo cho Cơ sở dữ liệu HBase - Giám đốc NSA sẽ tiến hành những hành động phù hợp để đảm bảo rằng các công ty và tổ chức phát triển và hỗ trợ nguồn mở và các phiên bản nguồn mở thương mại của các cơ sở dữ liệu HBase và Cassandra của Quỹ Apache, hoặc các hệ thống tương tự, nhận được sự hỗ trợ kỹ thuật từ chính phủ và các lập trình viên của các nhà thầu cho mã nguồn phần mềm đối với cơ sở dữ liệu Accumulo để cho phép thích nghi và tích hợp các tính năng an ninh của cơ sở dữ liệu Accumulo.

(a) Limitation on Use of NSA Database-

(1) LIMITATION- No component of the Department of Defense may utilize the cloud computing database developed by the National Security Agency (NSA) called Accumulo after September 30, 2013, unless the Chief Information Officer of the Department of Defense certifies one of the following:

(A) That there are no viable commercial open source databases with extensive industry support (such as the Apache Foundation HBase and Cassandra databases) that have security features comparable to the Accumulo database that are considered essential by the Chief Information Officer for purposes of the certification under this paragraph.

(B) That the Accumulo database has become a successful Apache Foundation open source database with adequate industry support and diversification, based on criteria to be established by the Chief Information Officer for purposes of the certification under this paragraph and submitted to the appropriate committees of Congress not later than January 1, 2013.

(2) CONSTRUCTION- The limitation in paragraph (1) shall not apply to the National Security Agency.

(b) Adaptation of Accumulo Security Features to HBase Database- The Director of the National Security Agency shall take appropriate actions to ensure that companies and organizations developing and supporting open source and commercial open source versions of the Apache Foundation HBase and Cassandra databases, or similar systems, receive technical assistance from government and contractor developers of software code for the Accumulo database to enable adaptation and integration of the security features of the Accumulo database.

Trước hết: Wow. Ủy ban các Dịch vụ Vũ trang của Thượng viện đề xuất để DoD dừng sử dụng Accumulo, và chỉ thị cho NSA giúp thúc đẩy mã nguồn Accumulo trở ngược lại cho các dự án khác, đặc biệt gọi ra HBase và Cassandra. Mức độ phức tạp được yêu cầu cho ngôn ngữ lập pháp như thế này là đáng ngạc nhiên. Theo những hoàn cảnh khác nhau, tôi đã thấy rằng sự phức tạp đang khuyến khích. Thay vào đó, tôi có quan tâm rằng SASC cảm thấy bị cưỡng bách vào danh sách đen một dự án nguồn mở cho DoD. Chắc chắn có một câu trả lời tốt hơn so với điều này chứ?

Hãy đặt lý do của Ủy ban sang một bên một lúc, và hãy nhìn vào biện pháp mà họ đã đề xuất. Điều gì sẽ xảy ra nếu nó không phải là Accumulo, mà là một mẩu phần mềm khác nhỉ? Hãy tưởng tượng rằng chúng ta đang nói về Máy chủ Web Apache, Red Hat Enterprise Linux, Microsoft SharePoint, hay Adobe Acrobat. Nếu Quốc hội đặt bất kỳ gói phần mềm nào trong số đó vào một danh sách đen, thì giới công nghiệp có thể không hiểu nổi. Accumulo là không khác gì: một khi nó từng được mở nguồn, thì Accumulo đã trở thành phần mềm thương mại theo FAR và DFAR rồi. Quốc hội không được can thiệp theo cách này.

Còn hơn nữa. Yêu cầu rằng Accumulo được chứng thực như “một cơ sở dữ liệu nguồn mở thành công của Quỹ Apache với sự hỗ trợ và đa dạng hóa của giới công nghiệp, dựa vào các tiêu chí được Giám đốc Thông tin thiết lập” là cực kỳ nguy hiểm cho Accumulo và cho nguồn mở nói chung. Là không đủ rằng phần mềm sẽ là thương mại, có chức năng và sẵn sàng ở chi phí hợp lý. Nó bây giờ phải có “sự hỗ trợ và đa dạng hóa phù hợp của giới công nghiệp”.

Nếu CIO của DoD bị cưỡng bức phải tạo ra những tiêu chí như vậy cho Accumulo, thì nó không có nhiều sự tưởng tượng để thấy rằng “những tiêu chí phù hợp” y hệt như vậy được áp dụng cho tất cả các dự án phần mềm nguồn mở. Có một dự án nguồn mở ưa thích trong chương trình DoD của bạn, nhưng không có nhà cung cấp thương mại nào chăng? Không phù hợp. Chỉ một nhà cung cấp cho gói phần mềm đó chăng? Thiếu sự đa dạng. Phần mềm sở hữu độc quyền không có gánh nặng như thế này.

First of all: Wow. The Senate Armed Services Committee proposes to order the DOD to stop using Accumulo, and direct NSA to help push Accumulo’s code back to other projects, specifically calling out HBase and Cassandra. The level of sophistication required for legislative language like this is astonishing. Under different circumstances, I’d find that sophistication encouraging. Instead, I’m concerned that SASC feels compelled to blacklist an open source project for the DOD. Surely there’s a better response than this?

Let’s put the Committee’s reasoning to the side for a moment, and look Adoat the remedy proposed. What if it wasn’t Accumulo, but another piece of software? Imagine that we’re talking about the Apache Web Server, Red Hat Enterprise Linux, Microsoft SharePoint, or Adobe Acrobat. If Congress put any of those software packages on a blacklist, industry would lose its mind. Accumulo is no different: once it was open sourced, Accumulo became commercial software under the FAR and DFAR. Congress has no business intervening in this way.

There’s more. The requirement that Accumulo be certified as “a successful Apache Foundation open source database with adequate industry support and diversification, based on criteria to be established by the Chief Information Officer” is extremely dangerous for Accumulo and for open source in general. It’s not sufficient that the software be commercial, functional and be available at reasonable cost. It must now have “adequate industry support and diversification.”

If the DOD CIO is compelled to create such criteria for Accumulo, it doesn’t take much imagination to see that same “adequacy criteria” applied to all open source software projects. Got a favorite open source project on your DOD program, but no commercial vendor? Inadequate. Only one vendor for the package? Lacks diversity. Proprietary software doesn’t have a burden like this.

The last clause of Section 929 is bewildering. SASC directs Accumulo to help other projects that want to use the Accumulo security code, and singles out HBase and Cassandra. There’s nothing wrong with the desire to spread Accumulo’s technology, but doesn’t an act of Congress seem like an extraordinarily, comically inappropriate tool for that? Wouldn’t the Accumulo team, like all open source developers, be generally helpful with folks who want to integrate their code? Perhaps more importantly, why is Congress so interested in HBase and Cassandra?

I think the Committee (and whoever provided them this legislative language) is right to be concerned about the government unnecessarily maintaining a duplicative software project. It’s bad for the private sector, and it’s bad for the government to maintain its own codebase when there are perfectly good alternatives elsewhere.

Mệnh đề cuối cùng của Phần 929 là gây hoang mang. SASC chỉ thị cho Accumulo giúp các dự án khác muốn sử dụng mã an ninh của Accumulo, và tách bạch khỏi HBase và Cassandra. Không có gì sai với mong muốn lan rộng công nghệ Accumulo, nhưng không phải là một hành động của Quốc hội được xem như một công cụ không phù hợp một cách khôi hài và lạ thường cho điều đó? Đội Accumulo, giống như tất cả các lập trình viên nguồn mở, thường hữu ích vói các đám người muốn tích hợp mã nguồn của họ chứ? Có lẽ quan trọng hơn, vì sao Quốc hội lại quá quan tâm tới HBase và Cassandra thế?

Tôi nghĩ Ủy ban (và bất kỳ ai cung cấp cho họ ngôn ngữ lập pháp này) là đúng có quan tâm về việc duy trì không cần thiết của chính phủ một dự án phần mềm bị đúp bản. Điều đó là tồi tệ cho khu vực tư nhân, và là tồi tệ cho chính phủ để duy trì kho mã nguồn của riêng mình khi có những lựa chọn thay thế tốt tuyệt với ở đâu đó.

Cùng lúc, đám người của Accumulo hiển nhiên đã làm đúng bằng việc phát hành mã nguồn của họ, và thậm chí đi xa hơn khi tham gia vào Quỹ Apache, nó không phải là một nỗ lực nhỏ. Họ sẽ được tưởng thưởng vì cương vị quản gia tuyệt vời cua họ đối với tiền của những người đóng thuế. Thông qua nỗ lực của họ, mỗi người có thể có lợi từ công việc mà họ đã làm - dù có hay không có các lệnh pháp lý phải làm thế - và họ có khả năng tuyệt vời để thắng hoặc thua về thị phần theo những giá trị của riêng họ, chỉ giống như bất kỳ ai khác.

Vấn đề của Accumulo này mở ra cánh cửa cho một đống các câu hỏi về vai trò của chính phủ trong các dự án nguồn mở. Trong phần 2, chúng ta sẽ đặt dự luật đặc biệt này sang một bên và đưa ra các câu hỏi đằng sau sự làm luật: Liệu chính phủ có làm hại cho khu vực tư nhân khi họ phát hành các dự án nguồn mở hay không? Làm thế nào chúng ta có thể biết khi nào nguồn mở là một cách thức phù hợp cho chính phủ để phát triển phần mềm? Làm thế nào chính phủ điều hành được các bản rẽ nhánh? Tôi cũng sẽ xem xét một số biện pháp có khả năng có thể loại bỏ được nhu cầu cho một công cụ thô thiển nguy hiểm như Phần 929.

Trong khi chờ đợi, xin hãy để nghị sỹ của bạn biết bạn cảm thấy thế nào về điều này.

[Được cập nhật lúc 17:37ET ngày 18/06/2012 để làm nhẹ bớt một số ngôn từ gây sợ hãi hơn và phân biệt rõ hơn Quốc hội với SASC].

[Được cập nhật lúc 09:37ET ngày 19/06/2012 để bổ sung thêm một số sự làm rõ, sửa một số lỗi chính tả; và chuẩn bị chung cho việc đưa lên opensource.com.]

At the same time, the Accumulo folks indisputably did the right thing by releasing their code, and even went so far as to join the Apache Foundation, which is no small effort. They should be rewarded for their excellent stewardship of taxpayer money. Through their effort, everyone can already benefit from the work that they’ve done – with or without legislative orders to do so – and they’re perfectly capable of winning or losing market share on their own merits, just like everyone else.

This Accumulo issue opens the door to a host of valid questions about the role of government in open source projects. In part two, we’ll put this specific bill aside and ask the questions behind the legislation: does the government harm the private sector when they release open source projects? How can we know when open source is an appropriate way for the government to develop software? How should the government handle forks? I’ll also examine some possible remedies that could eliminate the need for a dangerously crude tool like Section 929.

In the meantime, please let your Senator know how you feel about this.

[Updated 18 June 2012 17:37ET to soften some of the more alarmist language and more clearly distinguish Congress from SASC.]

[Updated 19 June 2012 09:37ET to add some clarity, fix some grammar, and generally prepare for posting on opensource.com.]

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Shuttleworth: Năm sau 5% PC toàn thế giới sẽ xuất xưởng có cài sẵn Ubuntu Linux

Shuttleworth: Next year 5 percent of the world's PCs will ship with Ubuntu pre-installed #Linux

By Sean Michael Kerner | July 19, 2012

Theo: http://www.internetnews.com/blog/skerner/shuttleworth-nxt-year-5-percent-of-the-worlds-pcs-will-ship-with-ubuntu-pre-installed-linux.html

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

Lời người dịch: Shuttleworth, người sáng lập ra hãng Canonical và hệ điều hành GNU/Linux Ubuntu nói: “Năm sau, 5% PC trên thế giới sẽ xuất xưởng có cài đặt sẵn Ubuntu”, nhiều nhất là ở Ấn Độ, Trung Quốc và các máy tính mới tinh của Dell. Chúng ta hãy chờ xem.

Từ hồ sơ 'Đẹp hơn của Apple':

Trở lại năm 2008, tôi dự OSCON khi Mark Shuttleworth đặt ra mục tiêu táo bạo làm cho máy tính để bàn Linux đẹp hơn của Apple.

Hôm nay, 4 năm sau, Shuttleworth đã quay lại OSCON để công bố chiến thắng.

Theo quan điểm của ông thì máy tính để bàn Ubuntu bây giờ tốt hơn Apple. Theo quan điểm của ông cũng dễ dàng hơn cho những người sử dụng Apple chuyển sang Ubuntu.

Ông đã lưu ý rằng nỗ lực máy tính để bàn Unity của Ubuntu là một quá trình không phổ biến một cách sâu sắc, nhưng đây là một quá trình đã cho kết quả.

Shuttleworth đã trình bày những biến đổi ứng dụng một cách dễ dàng và ông đã trình bày HUD sắp tới trong phiên bản Ubuntu 12.10 vào cuối năm nay.

Sự thành công cũng đang chuyển thành tuyên bố mới nhấn mạnh từ Shuttleworth:

“Năm sau, 5% PC trên thế giới sẽ xuất xưởng có cài đặt sẵn Ubuntu”, Shuttleworth nói.

Đó là con số dựa vào các thị trường đang nổi lên, như Trung Quốc và Ấn Độ cũng như những máy tính cá nhân mới tinh từ Dell.

Shuttleworth luôn là một nói lớn, với những ý tưởng lớn và công bằng mà nói, Ubuntu đã tiến bộ trong 4 năm qua. Unity (dù thích hay không) là một môi trường đồ họa máy để bàn rất khác so với chúng ta đã có 4 năm về trước. Ubuntu TV và Ubuntu for Android sẽ mang Ubuntu (và Linux) tới nhiều yếu tố mẫu hơn so với trước kia.

Với Windows 8 sắp ra, người sử dụng có khả năng tìm kiếm được những lựa chọn thay thế (đáng kể) nên điều này có thể sẽ tốt … (chờ đợi nó) là Năm của máy tính để bàn Linux chăng?

From the 'More Beautiful than Apple' files:

Back in 2008, I was at OSCON when Mark Shuttleworth set out the audacious goal to make the Linux desktop more beautiful than Apple.

Today, four years later, Shuttleworth returned to the OSCON stage to claim victory.

In his view Ubuntu's desktop is now better than Apple. In his view it's also easy for existing Apple users to move to Ubuntu as well.

That said he noted that Ubuntu's Unity desktop effort was a deeply unpopular process, but it is one that has delivered results.

Shuttleworth demonstrated easy applications transitions and he showed off the upcoming HUD (Heads Up Display) coming in the Ubuntu 12.10 release later this year.

The success is also translating into a bold new claim from Shuttleworth:

"Next year, 5 percent of the world's PCs will ship with Ubuntu pre-installed," Shuttleworth said.

That's a number based on emerging markets, like India and China as well as brand news PCs from Dell.

Shuttleworth has always been a big talker, with big ideas and to be fair, Ubuntu has progressed over the last four years. Unity (love it or hate it) is a very different desktop than we had four years ago. Ubuntu TV and Ubuntu for Android will bring Ubuntu (and Linux) to more form factors then ever before too.

With Windows 8 coming, users are likely to be looking for alternatives (potentially) so this could well be....(wait for it...) the Year of the Linux Desktop?

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Một tỉnh khác của Ý bắt buộc sử dụng nguồn mở nhiều hơn

Another Italian province mandates more use of open source

19 July 2012, 18:02

Theo: http://www.h-online.com/open/news/item/Another-Italian-province-mandates-more-use-of-open-source-1648018.html

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

Chỉ trong tháng 07/2012 đã có 2 tỉnh của Ý thông qua luật bắt buộc rằng khu vực nhà nước sử dụng nhiều phần mềm nguồn mở hơn, là Trentino và Puglia. Việc “chuyển sang phần mềm nguồn mở là quan trọng cho vùng vì, đặc biệt trong lĩnh vực nghiên cứu, “dạng phần mềm này sẽ loại bỏ được các rào cản, và sẽ trao cho tất cả những người sử dụng cùng mức độ truy cập và các quyền””.

Theo Joinup, cổng nguồn mở của Ủy ban châu Âu (EC), tỉnh Trentino của Ý đã phê chuẩn một luật chỉ thị cho các cơ quan hành chính nhà nước chuẩn bị các kế hoạch chuyển đổi để chuyển sang phần mềm nguồn mở. Bổ sung thêm, hội đồng vùng muốn các cơ quan hành chính nhà nước để sử dụng các tiêu chuẩn mở ở bất kỳ nơi nào có thể.

Michele Nardelli, một trong những ủy viên hội đồng đã giới thiệu dự luật này, nói rằng chuyển sang phần mềm nguồn mở là quan trọng cho vùng vì, đặc biệt trong lĩnh vực nghiên cứu, “dạng phần mềm này sẽ loại bỏ được các rào cản, và sẽ trao cho tất cả những người sử dụng cùng mức độ truy cập và các quyền”. Luật này bao gồm các điều khoản cho các trường học để chuyển sang nguồn mở cũng như khuyến khích các nhân viên chính phủ tham gia vào sự phát triển phần mềm nguồn mở.

Đây là lần thứ 2 trong tháng này một tỉnh của Ý đã thông qua một luật bắt buộc rằng khu vực nhà nước sử dụng nhiều phần mềm nguồn mở hơn. Trước đó, vùng Puglia đã thông qua một luật tương tự.

According to Joinup, the European Commission's open source portal, the Italian province of Trentino has approved a law that instructs public administrations to prepare migration plans to switch to open source software. Additionally, the region's council wants public administrations to use open standards wherever possible.

Michele Nardelli, one of the councillors who introduced the bill, says that the move to open source software is important for the region since, especially in the area of research, "this type of software will eliminate barriers, and will give all users the same level of access and rights." The law includes provisions for schools to switch to open source as well and encourages employees of the government to participate in the development of open source software.

This is the second time this month that an Italian province has passed a law mandating that the public sector use more open source software. Earlier, the region of Puglia passed a similar law.

(fab

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Giúp Nghị viện châu Âu xuất bản phần mềm tự do của riêng mình

Helping the European Parliament to release its own free software

Posted 18 Jul 2012 by Karsten Gerloff

Theo: http://opensource.com/government/12/7/helping-european-parliament-release-its-own-free-software

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

Lời người dịch: Chúng ta đã biết việc Nhà Trắng ở nước Mỹ đóng góp mã nguồn trở ngược lại cho cộng đồng nguồn mở Drupal, còn bây giờ có nhiều khả năng Nghị viện châu Âu sẽ mở nguồn các phần mềm của riêng mình. “Lần đầu tiên, Nghị viện châu Âu sắp phát hành một trong những chương trình của riêng mình như là Phần mềm Tự do. Chương trình theo yêu cầu này được gọi là AT4AM, ngắn gọn là “Cộng cụ Tự động cho những Sửa đổi bổ sung”. Nghị viện theo nghiệp vụ là làm các luật, và AT4AM tự động hóa nhiều thứ chính thống có liên quan tới qui trình sản xuất”.

Lần đầu tiên, Nghị viện châu Âu sắp phát hành một trong những chương trình của riêng mình như là Phần mềm Tự do. Chương trình theo yêu cầu này được gọi là AT4AM, ngắn gọn là “Cộng cụ Tự động cho những Sửa đổi bổ sung”. Nghị viện theo nghiệp vụ là làm các luật, và AT4AM tự động hóa nhiều thứ chính thống có liên quan tới qui trình sản xuất.

Để hiểu được AT4AM có nghĩa là gì đối với các nghị sỹ quốc hội châu Âu (MEP) và các nhân viên của họ, hãy ngó qua cách mà những sửa đổi bổ sung đã được đệ trình trước đó, và cách mà nó làm việc bây giờ. (Vimeo, Flash cần tới, xin lổi). Nhân viên Nghị viện Erik Josefsson đã so sánh sự giới thiệu của AT4AM với sự ra đời của sự kiểm soát phiên banr cho các lập trình viên Nó từng được sử dụng trong nghị viện khoảng 18 tháng, và nó là một công cụ khá cơ bản cho mọi người làm việc ở đây.

Vì thế chúng tôi đã hạnh phúc đọc trong tháng 5 rằng Nghị viện đã định phát hành AT4AM như là phần mềm tự do. Tuần trước, nhóm người sử dụng Phần mềm Tự do của nghị viện đã tổ chức sự kiện để thảo luận về giấy phép phù hợp theo đó để xuất bản AT4AM. Tham dự không chỉ là đám đông những người từ bên ngoài Nghị viện, mà còn cả đội phát triển AT4AM riêng của Nghị viện nữa. (Các bài trình bày và video được ghi lại ở đây).

(Tuy thế, bạn được chào đón để tham gia trong Nhóm Người sử dụng Phần mềm Tự do của Nghị viện châu Âu!). Tôi đã tới đó để nói về phần mềm tự do và dân chủ. AT4AM mã hóa một phần lớn qui trình về cách mà các luật được xây dựng - theo nghĩa đen thì đây là một công cụ sức mạnh. Nghị viện châu Âu bị ràng buộc tới các tiêu chuẩn minh bạch cao nhất, và việc phát hành AT4AM có nghĩa là mỗi người có thể có một sự xem xét cách mà các luật châu Âu được làm. Trong khi điều này chính xác không phải là một cuộc cách mạng, thì nó là tốt lành để thấy Nghị viện cuối vùng cũng tham gia vào với Phần mềm Tự do.

Ủy viên hội đồng Chung của FSFE (và là luật sư nổi tiếng về phần mềm tự do) Carlo Piana đã đi xuống các doanh nghiệp để chọn ra giấy phép phù hợp cho AT4AM. Đội phát triển muốn những người khác trong nghị viện cũng sử dụng, nghiên cứu, chia sẻ và cải thiện cho chương trình, nuôi dưỡng cho những cải tiến được quay ngược trở về vào nhánh chính. AT4AM là một ứng dụng dựa vào máy chủ, và sử dụng trên một máy chủ không tính tới như sự “phân phối” theo GPL. Đưa ra những đầu vào đó, việc chọn giấy phép không khó. Ông đã khuyến cáo rằng Nghị viện nên phát hành công cụ đó theo AGPLv3 hoặc bất kỳ phiên bản nào sau này của giấy phép. Bằng cách này, mỗi người có thể lấy phần mềm và làm những gì họ muốn. Cùng lúc, một khi chương trình được phát hành, sẽ không có cách gì để lấy đi khỏi công chúng một lần nữa.

For the first time, the European Parliament is about to release one of its own programs as Free Software. The program in question is called AT4AM, short for "Automatic Tool for Amendments". The Parliament is in the business of making laws, and AT4AM automates a lot of the formal stuff associated with the production process.

To understand what AT4AM means for MEPs and their staff, have a look at how amendments were filed before, and how it works now. (Vimeo. Flash required, sorry.) Parliament staffer Erik Josefsson compared the introduction of AT4AM to the arrival of version control for developers. It's been in use inside the parliament for about 18 months, and it's a pretty fundamental tool for the people working there.

So we were happy to read in May that the Parliament was going to release AT4AM as Free Software. Last week, the parliament's Free Software user group held an event to discuss the right license under which to publish AT4AM. Attending were not only a crowd of people from outside the Parliament, but also the Parliament's own AT4AM development team. (Presentations and video recordings here.)

(By the way, you're welcome to participate in the European Parliament Free Software User Group!)

I went there to talk about Free Software and democracy. AT4AM encodes a large part of the process of how laws are made - it's literally an instrument of power. The European Parliament is bound to the highest standards of transparency, and releasing AT4AM means that everyone can have a look at the way Europe's laws are made. While this isn't exactly a revolution, it's good to see the Parliament finally engage with Free Software.

FSFE General Counsel (and genius Free Software lawyer) Carlo Piana got down to the business of picking the right license for AT4AM. The development team wants other parliaments to use, study, share and improve the program, and feed their improvements back into the main branch. AT4AM is a server-based application, and using it on a server doesn't count as "distribution" under the GPL. Given those inputs, picking the license wasn't hard. He recommended that the Parliament should release the tool under AGPLv3 or any later version of the license. This way, everyone could take the software and do as they please.At the same time, once the program is released, there would be no way to take it away from the public again.

Hơn nữa, các lập trình viên có thể cân nhắc sử dụng EUPL như một giấy phép thứ 2. Nó không tương thích với GPLv3, và mở một cửa hậu cho những phiên bản được làm trong tương lai của chương trình sở hữu độc quyền một lần nữa. Nhưng vì giấy phép này được Ủy ban châu Âu phát triển, nó đôi khi giúp vượt qua những sợ hãi của những người ra quyết định trong khu vực nhà nước đang nhúng ngón chân của họ vào nước của Phần mềm Tự do lần đầu tiên.

Thái độ của Nghị viện đối với Phần mềm Tự do vẫn vừa yêu vừa ghét. Đối mặt với nó, việc phát hành AT4AM là một bước tiến tốt, nhưng khó là một cuộc cách mạng được. Những nền tảng của khu vực nhà nước như Joinup và các kho có liên quan của nó hiện có chỗ cho hơn 400 chuonwg trình được các cơ quan nhà nước phân phối theo các giấy phép của phần mềm tự do. Một số chính phủ, gần đây nhất tại vùng Xứ Basque của Tây Ban Nha, đã phát hành các phần mềm được nhà nước cấp vốn thành thủ tục mặc định.

Mặt khác, có cơ quan hành chính của Nghị viện, chọi lại theo bản năng từ bất kỳ điều gì mà nhìn khác với các cách thức thông thường của họ. Khi Nick Stenning đã đệ trình một yêu cầu Tự do Thông tin cho mã nguồn và cơ sở dữ liệu của AT4AM hôm 01/04, đx có một cuộc thảo luận mà hiện kết thúc với một câu trả lời “không” dài từ Tổng Thư ký Nghị viện. Chúng tôi hiện cũng đang chờ hành chính của Nghị viện báo cáo về sử dụng và phát triển phần mềm tự do của nó.

Và có quá nhiều hơn chúng ta muốn thấy từ Nghị viện châu Âu về sự minh bạch. Vì sao không trao cho công chúng đọc sự truy cập tới hệ thống AT4AM nội bộ của các nghị sỹ, sao cho chúng ta có thể tuân theo được các luật đang được làm trong thời gian thực? Vì sao không trao cho mỗi nghĩ sỹ quốc hội châu Âu và nhân viên một máy để bàn Phần mềm Tự do cho công việc hàng ngày của họ? Và khi Nghị viện, và mỗi cơ quan châu Âu khác sẽ thế, thì cuối cùng trao cho công chúng những gì họ có trách nhiệm phải, và phát hành tất cả các chương trình mà đã được phát triển bằng tiền ngân sách như là Phần mềm Tự do?

In addition, the developers might consider using the EUPL as a second license. This isn't compatible with GPLv3, and opens a back door towards making future versions of the program proprietary again. But since the license is developed by the European Commission, it sometimes helps to overcome the fears of public-sector decision makers who are dipping their toe into the Free Software waters for the first time.

The Parliament's attitude to Free Software remains ambivalent. On the face of it, releasing AT4AM is a nice step forward, but hardly a revolutionary one. Public-sector platforms like Joinup and its associated forges currently host more than 4000 programs released by public bodies under Free Software licenses. Some governments, most recently in Spain's Basque Country region, have made releasing publicly funded software the default procedure.

On the other hand, there's the Parliament administration, which instinctively recoils from anything that looks different from their usual ways. When Nick Stenning filed a Freedom of Information request for AT4AM's source code and database on April 1, there was a drawn-out discussion, which currently ends with a lengthy "no" from the Parliament's Secretary General.We're currently also waiting for the Parliament's administration to report on its use and development of Free Software.

And there's so much more we'd like to see from the European Parliament in terms of transparency. Why not give the public read access to the EP's internal AT4AM system, so that we could follow laws being made in real time? Why not give every MEP and staffer a Free Software desktop for their daily work? And when will the Parliament, and every other European institution, finally give the public what they're due, and release all programs that were developed with public funds as Free Software?

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Chính phủ Đức & Thụy Sỹ cấp vốn hỗ trợ OOXML trong các bộ phần mềm văn phòng nguồn mở

German and Swiss public administrations fund OOXML support in open source office suites

Submitted by Gijs HILLENIUS on July 18, 2012

Theo: https://joinup.ec.europa.eu/news/german-and-swiss-public-administrations-fund-ooxml-support-open-source-office-suites

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

Các thành phố Munich, Freiburg và Jena, Tòa án Liên bang Thụy Sỹ và Trung tâm hỗ trợ CNTT cho vùng Waadt của Thụy Sỹ đang đỡ đầu cho sự hỗ trợ được cải thiện cho định dạng tài liệu OOXML của Microsoft trong LibreOffice và OpenOffice. Vụ thầu 140.000 euro của họ, được ký mới đầu năm nay, đã được trao cho 2 công ty, Suse, làm việc trong phát tán SuSE Linux, và Lanedo, một chuyên gia dịch vụ CNTT nguồn mở.

The German cities of Munich, Freiburg and Jena, the Swiss Federal Court and the IT support centre for the Swiss canton of Waadt are sponsoring the improved support for Microsoft's document format OOXML in LibreOffice and OpenOffice. Their 140 000 euro tender, renewed earlier this year, was just awarded to two firms, Suse, working on the Suse Linux distribution, and Lanedo, an open source IT service specialist.

Lời người dịch: Đây là bài học mà Việt Nam nên làm. Thay vì ngồi chờ sung rụng và kêu ca vì không có sự tương hợp với các định dạng OOXML “MỞ RỞM” trong các bộ phần mềm văn phòng của Microsoft, các cơ quan nhà nước Việt Nam, đặc biệt là Bộ Giáo dục Việt Nam, nên vận động Chính phủ bỏ tiền chung vào với Chính phủ Đức và Thụy Sỹ để có được tính tương hợp tốt hơn cho các tài liệu văn phòng của mình trong các bộ phần mềm văn phòng nguồn mở như LibreOffice và OpenOffice. Trích đoạn: “Việc cải tiến trên cơ sở Định dạng tài liệu mở ODF là một bước quan trọng trên con đường cải thiện tính tương hợp của các định dạng tài liệu. Nó bước trên con đường vì cơ hội ngang bằng nhau và vì sự hợp tác trơn tru giữa tất cả những người sử dụng”. Lưu ý rằng OOXML không phải là .doc, .xls, .ppt. Vì thế chúng ta NÊN nghĩ rằng các bộ phần mềm văn phòng của M$ từ 2007 cho tới nay và trong tương lai là thứ ra sau, và theo lý luận của nhiều fan cuồng của M$ thì cái gì ra trước thì cái sau phải theo thì điều này đồng nghĩa với ở Việt Nam mọi người nên theo ODF chứ không phải OOXML như những gì Đức và Thụy Sỹ đang làm.

5 cơ quan hành chính nhà nước đã tổ chức mua sắm trong sự hợp tác với Liên minh Doanh nghiệp Nguồn Mở, một nhóm thương mại.

Năm ngoái nhóm này đã làm việc về một đặc tả kỹ thuật các tính năng mà nó muốn thấy trong LibreOffice và OpenOffice mà hiện tại trong các tài liệu được làm với các ứng dụng văn phòng sở hữu độc quyền của Microsoft. Nhóm này hy vọng rằng điều này sẽ cải thiện tính tương hợp của các tài liệu. Những vấn đề chính là làm cho các khung và hình ảnh, các bảng và các danh sách bullet trong các tài liệu văn bản và bảng tính.

Trong một thông cáo báo chí được xuất bản hôm nay, Liên minh OSB nói nó vẫn đang tìm kiếm 30.000 euro, mà nó nói sẽ giúp chi trả cho việc có hỗ trợ cho việc nhúng các phông chữ vào các tài liệu.

Trong thông cáo báo chí Jutta Kreyss, kiến trúc sư CNTT của dự án Linux tại thành phố Munich gọi hợp đồng này là một bước tiến. “Việc cải tiến trên cơ sở Định dạng tài liệu mở ODF là một bước quan trọng trên con đường cải thiện tính tương hợp của các định dạng tài liệu. Nó bước trên con đường vì cơ hội ngang bằng nhau và vì sự hợp tác trơn tru giữa tất cả những người sử dụng”.

Nó cũng trích lời Bernd Mutter, người chịu trách nhiệm về hỗ trợ CNTT tại thành phố Freiburg, người nhấn mạnh tầm quan trọng của tính tương hợp của các tài liệu. Ông nói rằng các tài liệu được làm trong các ứng dụng sở hữu độc quyền của Microsoft phải làm việc và nhìn chính xác giống như khi được mở trong hoặc LibreOffice hoặc OpenOffice.

Matthias Stuermer, một người bảo vệ sử dụng nguồn mở trong các cơ quan hành chính nhà nước, bổ sung thêm: “Sự quan tâm chính của chúng tôi bây giờ là để tìm ra 30.000 euro còn lại”.

The five public administrations organised the procurement in cooperation with the Open Source Business Alliance, a trade group.

Last year the group worked on a technical specification of features it would like to see in LibreOffice and OpenOffice that are present in documents made with Microsoft's proprietary office applications. The group hopes that this will improve document interoperability. The main problems are getting frames and images, tables and bullet lists correct in text and spreadsheet documents.

In a press release published today, the OSB Alliance says it is still looking for 30 000 euro, which it says will help pay for getting support for embedding fonts in documents.

In the press release Jutta Kreyss, IT architect of the Limux project at the city of Munich calls the contract awarding a milestone. "Improving on the basis of the Open Document Format ODF is an important step on the way to enhance the interoperability of document formats. It paves the way for equal opportunity and for smooth cooperation between all users."

It also quotes Bernd Mutter, responsible for IT support at the city of Freiburg, who stresses the importance of document interoperability. He says that documents made in Microsoft's proprietary applications must work and look exactly alike when opened in either OpenOffice or LibreOffice.

Matthias Stuermer, a Swiss advocate of the use of open source in public administrations, added: "Our main concern now is to find the remaining thirthy thousand euro."

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com