Why
isn't all government software open source?
Posted
14 Aug 2014 by Ben Balter
Bài
được đưa lên Internet ngày: 14/08/2014
Lời
người dịch: Trích đoạn kết: “Vì
sao tất cả các phần mềm của chính phủ không phải là
nguồn mở? Vì bạn có toàn bộ
chuỗi giá trị được thiết kế để sản xuất ra phần
mềm nguồn đóng, một hệ
thống ở trạng thái cân bằng, với ít sự khuyến khích
để tự nó nghĩ lại. Công
nghệ đã làm cho việc cộng tác trong mở dễ dàng hơn
trong những năm gần đây, và kết quả là, hệ sinh thái
nguồn mở đã bùng nổ. Vâng,
giống như tất cả công nghệ, chính phủ vẫn còn đi sau
một ít năm so với những người áp dụng dòng chính
thống”.
Chính
phủ liên bang là người mua mã lớn duy nhất trên thế
giới. Vì thế tại sao mã này - do người đóng thuế trả
và là phần không thể thiếu trong công việc hàng ngày
của nền dân chủ của chúng ta - là thường xuyên quá là
bí ẩn khỏi tầm nhìn của công chúng nhỉ? Có 2 phía cho
việc trả lời câu hỏi này: Vì sao chính phủ quá thường
xuyên xây dựng trên các nền tảng đóng, và một khi đã
được xây dựng, thì vì sao mã đó không được phát
hành công khai?
Sử
dụng nguồn mở
Dễ
dàng hơn nhiều để đóng góp cho nguồn mở khi bạn đang
xây dựng trên một nền tảng mở. Trong khi có khả năng
mở nguồn một VBScript
(Visual Basic for Applications), thì bạn có khả năng muốn có
xung lượng nhiều hơn để nhận một sự chấp nhận ấm
áp hơn từ một nền tảng với một cộng đồng trực
tuyến lành mạnh hơn như Ruby hoặc Python. Vâng thường
xuyên hơn là không, mặc định trong chính phủ là để
nhìn vào “độ chuyên nghiệp”, các nền tảng sở hữu
độc quyền ngay từ đầu, nó được gửi cho chính phủ
theo một quỹ đạo nguồn đóng.
Yêu
cầu về các giải pháp “chuyên nghiệp”
Có
một sự việc về FUD - viết tắt tiếng Anh của các từ
gây sợ hãi, không chắc chắn và nghi ngờ - trong các cửa
hàng các CIO chính phủ rằng nguồn mửo là ít an ninh hơn,
nhiều lỗi hơn, hoặc chi phí lớn hơn, và rằng bạn sẽ
đau đớn cả đời nếu bạn không đầu tư vào “một
giải pháp thực sự chuyên nghiệp”. Đối với nó, nếu
một cơ quan viết một tờ séc cho một nhà bán hàng phần
mềm, thì họ biết họ có được cái gì. Hợp đồng nêu
ra các tính năng, các lịch trình nâng cấp, và phân bổ
trách nhiệm giải trình trong trường hợp mà thứ gì đó
đi sai. Quan trọng hơn, nhà bán hàng cung cấp một số
điện thoại mà cơ quan có thể gọi nếu họ cần sự
trợ giúp. “Bài viết trong các diễn đàn hỗ trợ và ai
đó sẽ trả lời” có thể là một đề nghị gây sợ
hãi đối với một CIO (Lãnh đạo Thông tin).
Có
ít bộ com lê hơn đằng sau nguồn mở
Trước
khi giao dịch đó thậm chí xảy ra, nền tảng nguồn đóng
có khả năng có một trang và một cán bộ marketing hào
nhoáng từ những người bán hàng liên bang gọi cơ quan đó
và trải bàn ở các cuộc hội nghị, những điều mà các
nền tảng nguồn mở không làm, như Red Hat và một vài
hãng khác. Và khi văn phòng CIO yêu cầu các tính năng
“chuyên nghiệp” như những cái đuôi kiểm toán hoặc
cuộc gặp nhất định nào đó tuân thủ các yêu cầu,
thì bạn có thể đánh cược rằng giải pháp nguồn đóng
sẽ chắc chắn những tính năng đó làm cho nó nằm trong
chu kỳ phát hành tiếp sau.
Các
nhà thầu nguồn đóng
Cuối
cùng, các nền tảng nguồn đóng là những gì các nhà
thầu của chính phủ biết, vì nó là những gì được
dạy trong các chương trình khoa học máy tính và những gì
họ luôn được yêu cầu cung cấp. Nếu một hãng phát
triển có kinh nghiệm có một đống các lập trình viên
ColdFusion, thì khi họ đấu thầu trong một hợp đồng họ
sẽ khuyến cáo rằng mọi điều sẽ được xây dựng
trong ColdFusion. Không nhắc tới, RFP của chính phủ có thể
nằm trong phạm vi có lợi cho công nghệ đã có trước đó
mà họ đã biết rồi. Tất cả điều này có nghĩa là
trước khi dòng mã đầu tiên bao giờ đó được viết
ra, những điều kỳ dị được gói lại để chống lại
dự án khỏi việc nhòm ngó từ bên ngoài bức tường lửa
của cơ quan đó.
Nhưng
thậm chí nếu việc sử dụng một nền tảng nguồn đóng
của cơ quan đó như vậy, thì không có lý do nào mã tùy
biến của họ vẫn không thể được mở
mã nguồn.
Việc
đóng góp cho nguồn mở
Với
ngoại lệ của 18F (các dịch
vụ số), Văn phòng Bảo vệ Tài chính Người tiêu dùng -
CFPB (Consumer Financial
Protection Bureau), và một ít những dịch vụ khác, chính
phủ thực sự không viết mã. Trong thực tế, hiếm khi có
người nào biết cách để làm thế nếu nó muốn. Thay
vào đó, cơ quan thường đóng vai trò một người quản
lý chương trình không am hiểu kỹ thuật, đưa ra các đặc
tả cho các yêu cầu chức năng và lựa chọn một nhà
thầu để phân phối chức năng cuối cùng. Các điểm mấu
chốt của hợp đồng trong cơ quan giám sát hợp đồng
hiếm khi tham gia vào với cộng đồng nguồn mở, để lại
một mình say sưa về nguồn mở. Kết quả là, nguồn mở
theo truyền thống thậm chí không là một phần của cuộc
thảo luận. Vì sao nó lại như thế?
Tiến
trình của nguồn đóng
Về
cơ chế phát triển phần mềm thực sự, hợp đồng có
khả năng kêu gọi một tiến trình ném qua hàng rào, nơi
mà cơ quan thậm chí không thấy mã cho tới khi nó được
làm xong, nếu có - khác với nguồn mở. Thậm chí nếu
được yêu cầu, các nhà thầu có thể không có kinh
nghiệm với các tiến trình nguồn mở, hiện đại hơn,
hoặc với việc tham gia trong cộng đồng nguồn mở, tạo
ra một kinh nghiệm xấu cho tất cả các bên tham gia và
làm nhụt chí tiếp tục các nỗ lực nguồn mở khắp
chính phủ.
Sáng
chế lại chiếc bánh xe như một mô hình kinh doanh
Tôi
cũng đồ rằng các nhà thầu liên bang có một sự thoái
chí đối với công việc của họ về nguồn mở, cân
nhắc rằng các yêu cầu kỹ thuật có khả năng không
biến đổi nhiều từ cơ quan này tới cơ quan khác. Một
đòi hỏi của Luật Tự do Thông tin - FOIA (Freedom of
Information Act) là một yêu cầu FOIA và một thông cáo báo
chí là một thông cáo báo chí, bất kể liệu nó là tờ
giấy viết thư FAA hay FDA. Việc mở nguồn các giải pháp
đó lần đầu có thể làm giảm đáng kể yêu cầu đối
với mã y hệt đang được viết lần thứ 2 bằng tiền
của người đóng thuế.
Văn
hóa của “không”
Một
khi được xây dựng, nó lấy những người mang mã đó
với tốc độ thoát ra cần thiết để vượt qua sức ỳ
được bảo vệ của cơ quan đó. An ninh sẽ có khả năng
nói không. Pháp lý sẽ có khả năng nói không. Bạn sẽ
phải có nền tảng đặt chỗ cho mã được phê chuẩn.
Bạn sẽ phải mua hợp đồng duy trì liên tục để rà
soát lại các yêu cầu thêm. Bạn sẽ phải tạo một
chính sách tham gia của các lập trình viên cho cách mà bạn
chấp nhận chúng. Nói theo cách các ưu tiên cạnh tranh,
các nhân viên chính phủ có khả năng sẽ chọn đi tiếp
sang dự án khác đối mặt với công dân, hơn là khả
năng bỏ nhiều tháng đấu tranh với hệ thống miễn
nhiễm quan liêu để thay đổi.
Đổ
vỡ văn hóa
Thậm
chí nếu cơ quan định mở mã nguồn, thì cộng đồng
nguồn mở đi theo một tập hợp các chỉ tiêu đa phần
khác với tôn ti trật tự cứng nhắc của chính phủ. Các
cơ quan chính phủ luôn không biết cách tốt nhất tham gia
vào cộng đồng nguồn mửo hoặc cách tích hợp một tiến
trình nguồn mở vào trong văn hóa mệnh lệnh và kiểm
soát của riêng họ. Việc hỗ trợ một cộng đồng nguồn
mở là mất thời gian, thứ gì đó các nhân viên chính
phủ thường không có. Và khi cơ quan không tuân theo các
chỉ tiêu không được nói thành lời của cộng đồng
nguồn mở, thì nỗi sợ hãi tồi tệ nhất của người
hay nói không thể được sẽ trở thành một lời tiên
đoán tự thực hiện.
Sự
minh bạch như một trách nhiệm giải trình
Việc
mở mã nguồn mở ra cho cơ quan tới tiềm năng cho bình
luận từ hàng triệu con mắt có kỹ thuật cao, sống còn,
với một chút sự đảo lộn từ triển vọng của cơ
quan. Đội phi kỹ thuật của cơ quan có thể không có khả
năng đánh giá được sự lành nghề của mã trong nội
bộ, và thường thích quét mọi thứ dưới cái thảm, hơn
là không khí tiềm tàng mà đồ giặt bẩn của họ cho
một vài người trong số những quỷ lùn có kỹ năng nhất
trên Internet. Không phải nhắc, những lợi ích của nguồn
mở mà những người ủng hộ tán thành thường không
được thừa nhận và vì thế không thể phục vụ như
một sự làm ngang bằng nếu mã đó được xây dựng quá
có mục đích tới nỗi trả nó về không sử dụng được
bên ngoài chính phủ, vì thế không lôi cuốn được những
người đóng góp từ bên ngoài, hoặc nếu dự án được
quản lý quá kém, tới nỗi sợ những người đóng góp
ra đi.
Trong
khi chờ đợi, mã nguồn không được phát hành đặt ra
trách nhiệm giải trình tuyệt đối bằng không (0) trong
môi trường chính trị ngày nay. Thứ nào bạn muốn chọn?
Điều
gì cần phải thay đổi
Lật
bỏ sự mặc định, 3 điều cần thay đổi:
- Trước hết, các nhân viên chính phủ cần phải được trang bị với một sự hiểu biết tốt hơn và đánh giá cao công dụng của nguồn mở. Các cơ quan nào mà đã mở mã nguồn rồi làm thế vì những người ủng hộ cá nhân đứng mũi chịu sào được. Các dự án thành công được đặt mục tiêu từ ngày đầu tiên với ý định sẽ mở nguồn và phục vụ để định hình lại yêu cầu thị trường. Các sáng kiến như 18F và chương trình PIF có thể tìm cách truyền cảm hứng và giáo dục cho thế hệ tiếp sau những người bảo vệ nguồn mở bên trong chính phủ.
- Thứ 2, thậm chí khi cơ quan không hoàn toàn gọi nó, như các chuyên gia theo vấn đề chủ đề, thì các nhà thầu của chính phủ có trách nhiệm khai thác các lựa chọn thay thế là nguồn mở và giáo dục thị trường như đối với các thực tiễn phát triển tiêu chuẩn công nghiệp hiện đại. Bất kỳ nhà quan sát ngẫu nhiên nào cũng có thể thấy đường hướng dẫn dắt của thị trường, và các hãng khôn ngoan có một cơ hội vượt lên trước. Hãy tạo ra những năng lực nội bộ xung quanh các công nghệ nóng nhất ngày nay và làm gia tăng yêu cầu của chính phủ. Hãy làm cho thực tế hơn cho chính phủ để làm điều đúng, thay vì điều nó đã luôn làm.
- Cuối cùng, cộng đồng nguồn mở cần bước tiếp trong cuộc chơi của nó, cả về những gì nó đưa ra - đi vượt qua nhận thức rằng nguồn mở được những người có thú vui riêng viết - và sự thừa nhận đối với mã chính phủ nhận. Ở phía cung, có một mô hình kinh doanh khổng lồ bên trong những bộ đồ đằng sau bất kỳ một trong những dự án nguồn mở phổ biến nhất nào trên Internet. Automattic, GitHub, và Red Hat đang là một ít những ví dụ - đấu tranh chống lại FUD và đưa ra sự hỗ trợ “chuyên nghiệp”. Ở phía cầu, cộng đồng cần làm cho nó thành trách nhiệm giải trình không phải phát hành mã (“bạn đang dấu điều gì?”), và làm cho sự hoàn vốn đầu tư của cơ quan là rõ ràng, bằng việc phân thành trí lực “của chúng ta so với của họ”, và việc hỗ trợ, chứ không phải chỉ trích, các nỗ lực của chính phủ để học nguồn mở.
Vì
sao tất cả các phần mềm của chính phủ không phải là
nguồn mở? Vì bạn có toàn bộ chuỗi giá trị được
thiết kế để sản xuất ra phần mềm nguồn đóng, một
hệ thống ở trạng thái cân bằng, với ít sự khuyến
khích để tự nó nghĩ lại. Công nghệ đã làm cho việc
cộng tác trong mở dễ dàng hơn trong những năm gần đây,
và kết quả là, hệ sinh thái nguồn mở đã bùng nổ.
Vâng, giống như tất cả công nghệ, chính phủ vẫn còn
đi sau một ít năm so với những người áp dụng dòng
chính thống.
Hy
vọng, với sự giúp đỡ của bạn, điều đó có thể
thay đổi.
The
federal government is the single largest purchaser of code in the
world. So why is this code—taxpayer-funded and integral to the
day-to-day working of our democracy—so often hidden from public
view? There are two sides to answering that question: Why does the
government so often build on closed platforms, and once built, why
isn't the code released to the public?
Using
open source
It's
a lot easier to contribute to open source when you're building on an
open platform. While it's possible to open source a VBScript
(Visual Basic for Applications), you'd likely have more momentum and
receive a warmer reception from a platform with a more vibrant online
community like Ruby or Python. Yet more often than not, the default
in government is to look to "enterprise-grade," proprietary
platforms from the onset, which send the government on a
closed-source trajectory.
The
demand for "enterprise" solutions
There's
a good deal of FUD—fear, uncertainty, and doubt—in government CIO
shops that open source is less secure, buggy, or more costly, and
that you'll be in for a lifetime of pain if you don't invest in a
real "enterprise solution." For one, if an agency writes a
check to a software vendor, they know what they're getting. The
contract spells out features, upgrade schedules, and allocates
liability in the event that something goes wrong. More importantly,
the vendor provides a phone number that the agency can call if they
need help. "Post in the support forums and someone will reply"
can be a scary proposition for a CIO (Chief Information Officer).
There
are fewer suits behind open source
Before
that transaction even occurs, the closed-source platform likely has a
flashy marketing page and a cadre of federal salespeople calling up
the agency and tabling at conferences, things open source platforms
traditionally don't do, save Red Hat and a few others. And when the
CIO's office asks for "enterprise" features like audit
trails or meeting certain compliance requirements, you can bet that
the closed-source solution will make sure those features make it into
the next release cycle.
Closed
source contractors
Last,
these closed source platforms are what government contractors know,
because it's what is taught in computer science programs and what
they've always been asked to supply. If an experienced development
firm has a bunch of ColdFusion developers, when they bid on a
contract they're going to recommend that the thing be built in
ColdFusion. Not to mention, the government's RFP may be scoped to
favor the legacy technology they already know. All this means that
before the first line of code is ever written, the odds are stacked
against the project from ever seeing the outside of the agency's
firewall.
But
even if the agency's using a closed-source platform, there's no
reason their custom code can't still be open
sourced.
Contributing
to open source
With
the exception of 18F (digital
services), the Consumer Financial Protection Bureau (CFPB),
and a few others, government doesn't actually write code. In fact, it
rarely has the human know how to do so if it wanted. Instead, the
agency traditionally plays the role of a non-techincal program
manager, providing specs for the functional requirements and
selecting a contractor to deliver the end functionality. The points
of contact at the agency overseeing the contract are rarely engaged
with the open source community, let alone passionate about open
source. As a result, open source traditionally isn't even part of the
conversation. Why would it be?
Closed
source workflows
In
terms of the actual software development mechanics, the contract
likely calls for a throw-it-over-the-fence workflow, where the agency
doesn't even see the code until it's already in production, if at
all—a long way from open source. Even if asked, the contractors may
not have experience with more modern, open source workflows, or with
participating in the open source community, creating a bad experience
for all involved and further chilling open source efforts across
government.
Reinventing
the wheel as a business model
I
also suspect that federal contractors have a disincentive to open
source their work, considering that technical requirements likely
don't vary much from agency to agency. A FOIA (Freedom of Information
Act) request is a FOIA request and a press release is a press
release, regardless of whether it's on FAA or FDA letterhead. Open
sourcing these solutions the first time around could potentially
decrease the demand for that same code being written a second time at
the taxpayer's expense.
A
culture of "no"
Once
built, it takes humans to bring that code to the escape velocity
necessary to overcome the agency's guarded inertia. Security is going
to likely say no. Legal is going to likely say no. You'll have to get
the code hosting platform approved. You'll have to procure an ongoing
maintenance contract to review pull requests. You'll have to create a
developer engagement policy for how you accept them. In a world of
competing priorities, government employees will likely choose to move
on to the next citizen-facing project, rather than spend potentially
months combating the bureaucracy's immune system to change.
Clash
of cultures
Even
if the agency manages to open source the code, the open source
community follows a set of norms vastly different than the rigid
hierarchy of government. Government agencies don't always know how
best to engage the open source community or how to integrate an
open-source workflow within their own command-and-control culture.
Supporting an open source community takes time, something government
employees are traditionally short on. And when the agency doesn't
follow the open source community's unspoken norms, the naysayer's
worst fears become a self-fulfilling prophecy.
Transparency
as a liability
Open
sourcing code exposes the agency to the potential for criticism from
millions of highly-technical, critical eyes, with little perceived
upside from the agency's perspective. The non-technical agency team
may not have the ability to evaluate the craftsmanship of the code
internally, and it's often preferable to sweep things under the rug,
rather than potentially air their dirty laundry to some of the
Internet's most skilled trolls. Not to mention, the benefits of open
source that advocates espouse are often not realized and thus cannot
serve as a counterbalance if the code is so purpose built so as to
render it unusable outside of government, thus attracting no outside
contributors, or if the project is poorly managed, so as to scare
those contributors away.
Meanwhile,
unreleased source code poses absolutely zero liability in today's
political climate. Which one would you choose?
What
needs to change
To
flip the default, three things needs to change:
- First, government employees need to be empowered with a better understanding of and appreciation for the virtues of open source. Those agencies who have open sourced code do so because of individual cheerleaders spearheading the charge. Successful projects are scoped from day one with the intention of being open source and serve to reshape market demand. Initiatives like 18F and the PIF program can seek to inspire and educate the next generation of open source advocates within government.
- Second, even when the agency doesn't explicitly call for it, as subject matter experts, government contractors have a duty to explore open source alternatives and to educate the market as to modern industry standard development practices. Any casual observer can see the direction the market's heading, and the smart firms have an opportunity to get in front of it. Create internal competencies around today's hottest technologies and grow government demand. Make it more practical for government to do the right thing, rather than the thing it's always done.
- Last, the open source community needs to step up its game, both in terms of what it offers—moving past the perception that open source is written by hobbyists—and the reception government code receives. On the supply side, there's a tremendous business model in being the suits behind any one of the Internet's most popular open source projects—Automattic, GitHub, and Red Hat being a few examples—combating the FUD and providing "enterpise" support. On the demand side, the community needs to make it a liability not to release code ("what are you hiding?"), and make the agency's return on investment clear, by breaking down the "us vs. them" mentality, and supporting, not criticizing, government efforts to learn open source.
Why
isn't all government software open source? Because you've got an
entire value chain designed to produce closed source software, a
system at equilibrium, with few incentives to rethink itself.
Technology has made collaborating in the open easier in recent years,
and as a result, the open source ecosystem has exploded. Yet, like
all technology, government is still a few years behind mainstream
adopters.
Hopefully,
with your help, that can change.
Dịch:
Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.