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