A
fresh look at the U.S. draft policy on 'federal sourcing'
Posted
28 Apr 2016 by Mark Bohannon
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
