Nhìn vào chính sách phác thảo của Mỹ về 'nguồn liên bang'

A fresh look at the U.S. draft policy on 'federal sourcing'

Posted 28 Apr 2016 by Mark Bohannon

Theo: https://opensource.com/government/16/4/draft-policy-federal-sourcing

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

Trong bài báo gần đâytrong Government Computer News (Tin tức Máy tính của Chính phủ), tôi đã nhìn vào thách thức của việc định hình lại CNTT liên bang với nguồn mở không thấy có các tiếp cận đi một mình và dùng ngay được của chính phủ đối với phần mềm nguồn mở. Trong bài báo đó, tôi đã lưu ý rằng sử dụng ngày một gia tăng của chính phủ các phần mềm nguồn mở đã dịch chuyển từ “liệu có sử dụng” sang “triển khai thế nào”. Bằng chứng mới nhất cho điều này là phác thảo Chính sách Nguồn của Liên bang được Văn phòng Quản lý và Ngân sách Liên bang Mỹ (OMB) công bố, nó dẫn dắt chính sách CNTT và mua sắm của chính phủ Mỹ. Đây là chính sách nhìn trước trong nhiều lĩnh vực. Và với vài sự làm sáng tỏ, nó có thể thậm chí còn tốt hơn.

Một chút ngữ cảnh

Chính sách đó vừa khẳng định lại và vừa mở rộng mục tiêu được đưa ra trong Kế hoạch Hành động Quốc gia của Chính phủ Mở lần thứ 2 về “truy cập được cải thiện cho mã phần mềm tùy biến được phát triển cho Chính phủ Liên bang”. Kế hoạch đó đã nhấn mạnh sử dụng phần mềm nguồn mở (PMNM) (và đóng góp trở ngược lại) để nuôi dưỡng sự đổi mới, các chi phí thấp hơn, và lợi ích cho công chúng. Nó cũng đi xa hơn mục tiêu 'mặc định là mở' dài lâu đi ngược về những ngày đầu của Chính quyền.

Chính sách phác thảo đó đặc trưng vài thành phần. Trước hết, nó đưa ra “3 bước quy trình” được khuyến cáo về cân nhắc mua sắm phần mềm để tối thiểu hóa mua sắm các phần mềm được phát triển tùy biến. Thứ 2, nó thiết lập các yêu cầu cho việc phát hành mã trong phạm vi công cộng hoặc như là PMNM, nhân bản sớm các nỗ lực của các cơ quan có rồi tại chỗ các chính sách phát hành mã được phát triển trong nội bộ.

Cuối cùng, các cơ quan được đề cập tới phải phân phối mã tùy biến sử dụng lại được sản xuất trong sự thực thi thỏa thuận của chính phủ liên bang và, tuân theo các ngoại lệ nhất định, làm cho nó sẵn sàng rộng rãi khắp chính phủ. Như được nêu rộng rãi, từng cơ quan được đề cập tới sẽ tham gia trong dự án thí điểm để “phát hành ít nhất 20% mã tùy biến được phát triển mới của nó mỗi năm như là nguồn mở”, sử dụng các giấy phép của Sáng kiến Nguồn Mở (Open Source Initiative), những để chừa chỗ cho các giấy phép bổ sung thêm như là cần thiết.

“Phân tích 3 bước”

Trong khi các báo cáo phương tiện đã tập trung vào khoản mục cuối cùng, thì đây là “phân tích 3 bước” bắt mắt tôi. Nó dường như cố tuyên bố lại chính sách hiện hành. Nhưng liệu sự xây dựng bản phác thảo có vô tình gây rủi ro cho việc khuyến khích các giải pháp phần mềm dùng ngay được trong chính phủ - GOTS (Government Off The Shelf) hơn là các phần mềm thương mại dùng ngay được - COST (Commercial Off The Shelf) chăng?

Nó đòi hỏi việc đọc cẩn thận. Như là bước đầu tiên, “các cơ quan được đề cập tới phải tiến hành trước hết phân tích lựa chọn thay thế và trình bày ưu tiên cho sử dụng các giải pháp phần mềm đang tồn tại theo đó Chính phủ nắm giữ các quyền giấy phép đúng phù hợp hoặc khả năng sử dụng lại. Điều này có thể bao gồm các dịch vụ được Liên bang chia sẻ hoặc mã được phát triển trước sẵn sàng để sử dụng lại rộng khắp Chính phủ” (được nhấn mạnh thêm). Chỉ khi phân tích kết luận “rằng không giải pháp đang tồn tại nào của Liên bang và đáp ứng được có hiệu quả các nhu cầu vận hành và nhiệm vụ của nó, cơ quan được đề cập tới sau đó phải khai thác liệu giải pháp COTS đúng thích hợp có sẵn hay không” (một lần nữa, nhấn mạnh được bổ sung). Đây là bước thứ 2. (Chỉ khi không tồn tại giải pháp 'Liên bang' và/hoặc COTS nào được tìm thấy thì có quan sẽ đi tới bước 3, và cân nhắc mua sắm phần mềm tùy biến).

Sự xây dựng phân tích 3 bước này tương phản với các sáng kiến và chính sách cải cách CNTT đang tồn tại tránh GOTS và các tiếp cận tùy biến. Ví dụ, Chiến lược các Dịch vụ được Chia sẻ của Chính quyền đã nhấn mạnh vai trò chính của các tổ chức thương mại trong việc cung cấp dịch vụ CNTT được chia sẻ cho các cơ quan, với sử dụng ngày càng gia tăng CNTT hàng hóa, module hóa, và “các giải pháp mở”, trong khi giảm sự hỗ trợ có tính đúp bản. Yếu tố chủ chốt đó sẽ được phản ánh trong phân tích bước đầu tiên.

Và nó cũng tương phản với tiếp cận từ lâu của Thông tư A-130, nó chỉ dẫn các cơ quan trao ưu tiên như là bước đầu tiên “để sử dụng các hệ thống thông tin, phần mềm, công nghệ và dịch vụ được chia sẻ và/hoặc các tiện ích xử lý thông tin của Liên bang đang tồn tại phù hợp và có sẵn rồi”, và nhấn mạnh vào phiên bản mới nhất của nó rằng “tất cả các hệ thống và dịch vụ CNTT vận hành chỉ các giải pháp được các nhà cung cấp hỗ trợ”.

Dù có ý định hay không, thì sự nhấn mạnh về “các giải pháp của Liên bang” gợi ý rằng chính sách có thể nghiêng về GOTS hơn là COTS. Điều này có thể là lo ngại lớn cho các cộng đồng nguồn mở, và các nhà cung cấp giải pháp, và cũng cho các cơ quan chính phủ mà đã ôm lấy nguồn mở được chứng minh có hỗ trợ thương mại.

Tôi và những người khác đã viết rằng một trong những lợi ích của nguồn mở được hỗ trợ thương mại, được kiểm thử liên tục là nó là COTS. Nó có thể được hỗ trợ bởi sự đa dạng các nhà cung cấp và chào tiếp cận lanh lẹ, sử dụng lại được, theo module cho các cơ quan. Báo cáo gần đây của Bộ An ninh Nội địa Mỹ đã thấy rằng “một rẽ nhánh dự án thường đắt giá hơn nhiều cho chính phủ để duy trì về lâu dài vì chính phủ phải trả tiền cho mọi thay đổi (thay vì việc chia sẻ các chi phí bền vững với những người khác), và bản rẽ nhánh cũng cắt khỏi những đổi mới trong tương lai trong dự án nguồn mở chính”. Phát hiện này thường nhất quán với các giáo lý của nguồn mở “khuyến cáo mạnh mẽ tránh tạo ra rẽ nhánh dự án bất kỳ ở đâu có thể”. Vâng chính phủ và các nhà thầu của nó thường không nhất thiết khuyến khích tạo ra các rẽ nhánh dự án. Việc giải quyết vấn đề này rõ ràng trong chính sách phác thảo có thể là một bước quan trọng tiến lên phía trước.

Làn gió đó là ở sau lưng của sử dung nguồn mở, cả trong chính phủ và trong khu vực thương mại. Chính sách phác thảo này là ví dụ mới nhất về điều, tập trung không vào 'liệu' phần mềm nguồn mở có nên được sử dụng hay không, mà thay vào đó vào 'làm thế nào' để triển khai nó. Đây là cách nhìn về phía trước, và sẽ cải thiện với những điều làm rõ cần thiết, vài điều được nêu ở trên. Không có chúng thì sẽ có rủi ro thúc đẩy GOTS hơn COTS, rẽ nhánh các dự án nguồn mở, và sự hỗ trợ kiểu 'đi một mình'.

In a recent article in Government Computer News, I looked at the challenge of reshaping federal IT with open source without go-it-alone government-off-the-shelf approaches to open source software. In that article, I noted that the growing use of open source software by governments has shifted from "whether to use" to "how to deploy." The latest evidence for this is a draft Federal Sourcing Policy announced by the U.S. Office of Management and Budget (OMB), which drives U.S. government (USG) procurement and IT policy. It is a forward-looking policy in many respects. And with some clarifications, it could even be better.

A little context

The policy both reaffirms and broadens a goal laid out in the Administration’s Second Open Government National Action Plan for "improved access to custom software code developed for the Federal Government."The Plan emphasized use of (and contributing back to) open source software to fuel innovation, lower costs, and benefit the public. It also furthers a long-standing 'default to open' objective going back to the early days of the Administration.

The draft policy features several components. First, it provides a recommended "3-step process" on software procurement considerations to minimize procurement of custom-developed software. Second, it establishes requirements for releasing code in the public domain or as open source software, replicating early efforts by agencies to have in place policies to release code developed in-house.

Finally, covered agencies must deliver for reuse custom code produced in the performance of a federal government agreement and, subject to certain exceptions, make it broadly available government-wide. As widely reported, each covered agency will participate in a pilot program to "release at least 20 percent of its newly-developed custom code each year as open source," using existing Open Source Initiative licenses, but leaves room for additional licenses as necessary.

The "3-step analysis"

While the media reports have focused on the last item, it's the "3-step analysis" that caught my eye. It appears to attempt a restatement of current policy. But does the draft's formulation inadvertently risk encouraging government-off-the-shelf (GOTS) solutions over commercial-off-the-shelf (COTS)?

It requires a careful reading. As a first step, "covered agencies must first conduct an alternatives analysis and demonstrate a preference for the use of existing software solutions for which the Government holds appropriate license rights or ability to reuse. This may include Federal shared services or previously developed code available for Government-wide reuse." (emphasis added) Only when the analysis concludes "that no existing Federal solution efficiently and effectively meets its operational and mission needs, a covered agency must subsequently explore whether an appropriate COTS [commercial-off-the-shelf] solution is available." (again, emphasis added) This is the second step. (Only when no existing ‘Federal’ and/or COTS solutions is found should an agency go to step 3, and consider procurement of custom software.)

This formulation of the 3-step analysis contrasts with existing IT reform initiatives and policies to avoid GOTS and custom approaches. For example, the Administration's Shared Services Strategy emphasized the key role of commercial organizations in providing IT shared service to agencies, with growing use of commodity IT, modularity, and "open solutions,"while reducing duplicative support. That key element should be reflected in first step analysis.

And it also contrasts with the long-standing approach of Circular A-130 which directs agencies to give priority as a first step "to use of available and suitable existing Federal information systems, software, technologies, and shared services and/or information processing facilities,"and emphasizes in its latest version that "all IT systems and services operate only vendor-supported solutions."

Whether intentional or not, the emphasis on "Federal solutions"suggests that the policy may lean toward GOTS over COTS. This would be of great concern for open source communities, and solution providers, and also for government agencies that have embraced proven commercially-supported open source.

I and others have written that one of the benefits of road-tested, commercially-supported open source is that it is COTS. It can be supported by a variety of vendors and offers an agile, reusable, modular approach to agencies. A recent report by the U.S. Department of Homeland Security found that "a project fork is typically far more expensive for the government to maintain in the long term because the government must pay for every change (instead of sharing sustainment costs with others), and the fork is also cut off from the future innovations in the main open source project." This finding is consistent generally with the tenets of open source literature which "strongly recommends avoiding creating a project fork wherever possible." Yet the government and its contractors often unnecessarily encourage creating project forks. Addressing this issue clearly in the draft policy would be an important step forward.

The wind is at the back of open source use, both in government and the commercial sector. This draft policy is the latest example of that, focusing not on 'whether' open source should be used, but rather the 'how' of doing it. It is forward-looking, and will improve with needed clarifications, some noted above. Without them there is real risk of promoting GOTS over COTS, forking of open source projects, and 'go it alone' support.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com