How
to treat government like an open source project
Posted
02 Jun 2014 by Ben Balter
Bài
được đưa lên Internet ngày: 02/06/2014
Lời
người dịch: Hãy làm cho chính phủ của bạn vận hành
như một dự án phần mềm nguồn mở. Có 3 khuyến cáo
cho việc này: (1) Hãy chỉ ra sự thay đổi tiềm tàng cho
các nhân viên trong chính phủ mà những nỗ lực của họ
sẽ được tưởng thưởng; (2) Hãy sử dụng đúng các
công cụ như các tiêu chuẩn mở và bộ phần mềm văn
phòng nguồn mở; (3) Hãy khuyến khích họ thực hiện
bước đầu của họ (hãy là người sử dụng nguồn
mở, xuất bản, hoặc cộng tác với công chúng), hãy
dạy họ điều đó có ý nghĩa gì khi làm việc theo mở,
và khi họ thúc đẩy mã ra bên ngoài bức tường, trên
hết tất cả, hãy ủng hộ. “Khi công nghệ làm cho điều
đó dễ dàng hơn để làm việc cùng nhau, thì những
người hiểu biết về CNTT có thể giúp chính phủ của
chúng ta không chỉ mở, mà trong thực tế còn cộng tác.
Chính phủ là dự án nguồn mở đang chạy lớn nhất và
dài nhất thế giới (các lỗi, các quỷ lùn, và tất
cả). Đã tới lúc chúng ta bắt đầu đối xử với nó
như là một dự án nguồn mở”.
Chính
phủ mở là tuyệt vời. Ít nhất, đó từng là một ít
vòng bầu cử trước đó. FOIA đòi hỏi, các dữ liệu
mở, xem cách mà chính phủ của bạn làm việc - còn tranh
cãi về ánh sáng được mang lại cho nhiều thực tiễn
chưa thật tuyệt vời, và trong nhiều trường hợp, đã
thúc đẩy sự đổi mới hướng tới công dân mà không
tưởng tượng được trước khi phát hành thông tin.
Thường
là quen việc chia sẻ thông tin từng thực sự, thực sự
khó khăn. Chính phủ mở thậm chí từng không là một khả
năng vài trăm năm trước. Qua lịch sử các công cụ giao
tiếp - từng là báo chí in, máy fax, hoặc các đĩa mềm -
các công cụ mới nói chung đã làm được 3 điều: làm
giảm chi phí truyền thông tin, làm gia tăng số người mà
thông tin được làm sẵn sàng cho họ, và làm gia tăng
cách thưc nhanh chongs thông tin có thể được phân phối.
Nhưng, các báo chí in và các máy fax có 2 hạn chế: chúng
là đường một chiều và không đối xứng. Chúng cho phép
bạn yêu cầu dễ hơn nhiều, và cuối cùng thấy cách mà
chiếc xúc xích được làm nhưng không cho phép bạn thực
sự tham gia vào việc làm ra cái xúc xích đó. Bạn có thể
có khả năng thấy những gì là sai, nhưng bạn không có
cơ hội để làm cho nó tốt hơn. Vào thời điểm bạn
tìm ra, thì đã quá muộn.
Khi
công nghệ cho phép chúng ta giao tiếp với tần số lớn
hơn và sự trung thực lớn hơn, thì chúng ta có cơ hội
làm cho chính phủ của chúng ta không chỉ minh bạch, mà
còn thực sự cộng tác.
Tiến
trình nguồn mở
Phần
mềm nguồn mở (PMNM) - phần mềm mà mã nguồn nằm bên
dưới không chỉ được làm cho sẵn sàng cho công chúng,
mà theo đó những người sử dụng phần mềm được
khuyến khích đệ trình các lỗi và đề xuất các cải
tiến - đã bắt đầu con đường y hệt. Ban đầu, nguồn
mở từng chỉ là nguồn được xuất bản, hầu hết vì
những hạn chế của công nghệ. Mỗi người đã có sự
truy cập tới mã, nhưng nó từng được xuất bản trong
các vật trung gian một chiều - bằng thư, thông qua giao
thức truyền tệp FTP hoặc qua một website chỉ đọc.
Trong vòng 2 thập kỷ qua, nguồn mở đã chuyển sang một
tiến trình phân tán hơn, một tiến trình mà mở ra qui
trình, vòng đời cả sống và chết với URL, và cho phép
bất kỳ ai trên thế giới đệ trình các cải tiến được
đề xuất, có hoặc không có sự đồng ý của tác giả.
Ngày nay, ngược lại, công nghệ cho phép nguồn mở trở
thành cộng tác bẩm sinh.
Tiến
trình ban đầu của nguồn mở có thể là quen thuộc. Nếu
tôi đã có một câu hỏi về một mẩu phần mềm đặc
biệt nào đó, thì tôi có thể muốn gửi thư điện tử
cho tác giả. Nếu một mẩu phần mềm tôi sử dụng có
một lỗi, thì tôi muốn gửi thư điện tử cho tác giả.
Nếu tôi có một sửa lỗi muốn đề xuất, thì tôi phỏng
đoán nó, tôi muốn gửi thư điện tử cho tác giả. Tiến
trình này không quá khác biết đối với việc gọi của
các công dân cho văn phòng các đại biểu quốc hội địa
phương của họ với một yêu cầu các dịch vụ theo hiến
pháp, hoặc người vận động hành lang đặt lịch cho một
cuộc gặp với một nhà điều chỉnh pháp luật để bảo
vệ cho một vấn đề đặc thù khi họ làm ngày nay.
Dù
là mã phần mềm hay bộ luật, khi bạn không có khả năng
tự bạn đệ trình sự thay đổi được đề xuất ngược
lên trên, thì bạn bị ép phải đi thẳng tới nhà xuất
bản theo một tương tác một-một tù mù.
Vượt
ra ngoài đĩa nan hoa
Có
2 vấn đề với mô hình đĩa nan hoa của sự cộng tác
được biết trước. Đầu tiên, các hội thoại một lần
đó thường xảy ra riêng tư. Không URL, không lịch sử
thay đổi, không cách gì để lần vết ngược về các
đầu ra cuối cùng đối với sự thúc đẩy ban đầu của
nó. Trong nguồn mở, điều này có nghĩa là banj luôn biết
một phả hệ hoặc ý định của mã. Ai biết mã này và
ai tôi nên hỏi về lỗi này? Trong chính phủ, kịch bản
y hệt là khó khăn hơn nhiều, với các phòng ở đằng
sau toàn khói thuốc lá và những chiếc cặp tiền. Ai là
tác giả của luật này? Lợi ích của họ là gì?
Thứ
2, khi các hội thoại được giao dịch qua thư điện tử
(hoặc lưu ý và bình luận) hoặc các phương tiện không
đồng bộ cao, một - đối - một khác, thì sẽ có một
cơ hội cho giao tiếp theo hàng dọc (tôi và chính phủ của
tôi), nhưng không có cơ hội cho giao tiếp theo chiều ngang
(tôi và các công dân bạn bè của tôi), ít nhất là không
chính thức. Trong thế giới phần mềm, điều này thường
có nghĩa là nhiều người sử dụng trải nghiệm cùng lỗi
y hệt nhau đưa ra câu hỏi y hệt hoặc đệ trình báo cáo
lỗi y hệt nhiều lần, không phải để nhắc, không có
một hệ thống tự giúp, nó tạo ra một sự tắc ngẽn
trong kho của dự án. Không có cơ hội cho một người sử
dụng bạn để nói, “tôi đã có vấn đề vào tuần
trước, đây là những gì tôi đã làm”, như chúng ta
thường thấy bằng việc google nhiều vấn đề chung. “Đây
là một đống các ý tưởng cho chính phủ, banj hãy đưa
chúng ra” là ít hiệu quả hơn trong việc giải quyết
các vấn đề được chia sẻ sau đó một hội thoại liên
tục giữa các công dân xây dựng một sự đồng thuận
thô.
Học
từ nguồn mở
Vì
thế, cách mà chúng ta khuyến khích những người làm
chính sách và các công chức chuyển từ chính phủ mở
sang chính phủ cộng tác, để học các bài học nguồn mở
về tính mở và sự cộng tác có qui mô? Đối với người
ta, chúng ta những người hiểu biết CNTT có thể giúp tạo
ra một văn hóa minh bạch và tính mở bên trong chính phủ
bằng việc dẫn dắt phía yêu cầu của một phương
trình. Có sự đồng thanh, đòi hỏi các dữ liệu, kỳ
vọng thấy qui trình, và một khi được đưa ra, sẽ giúp
xây dựng các ứng dụng hạng nhẹ.
Hãy
chỉ ra sự thay đổi tiềm tàng cho các nhân viên trong
chính phủ mà những nỗ lực của họ sẽ được tưởng
thưởng.
Thứ
2, đó là vấn đề sử dụng công cụ. Chúng ta có những
công cụ tốt ở đó - những thứ như Git có thể lần
vết ai đã thực hiện những thay đổi nào khi nào và các
tiêu chuẩn mở như CSV hoặc JSON mà không đòi hỏi các
phần mềm sở hữu độc quyền - mà đa số chúng là một
khái niệm ngoại trong chính phủ, ít nhất trong số những
người được trang bị để thực hiện sự thay đổi.
Các giao diện dòng lệnh với các nền màu đen và văn bản
màu xanh có thể là việc bắt chước cho những công chức
chính phủ quen với các công cụ xuất bản máy tính để
bàn. Hãy làm cho nó dễ dàng hơn cho chính phủ để làm
đúng việc và chọn các tiêu chuẩn mở hơn các tiêu
chuẩn đóng khi sử dụng các công cụ.
Cuối
cùng, hãy là một đại sứ nguồn mở tốt. Hãy giúp
thành phố hoặc bang quê nhà của bạn tham gia vào với
nguồn mở. Hãy khuyến khích họ thực hiện bước đầu
của họ (hãy là người sử dụng nguồn mở, xuất bản,
hoặc cộng tác với công chúng), hãy dạy họ điều đó
có ý nghĩa gì khi làm việc theo mở, và khi họ thúc đẩy
mã ra bên ngoài bức tường, trên hết tất cả, hãy ủng
hộ. Chúng tôi cũng sẽ cùng với bạn.
Khi
công nghệ làm cho điều đó dễ dàng hơn để làm việc
cùng nhau, thì những người hiểu biết về CNTT có thể
giúp chính phủ của chúng ta không chỉ mở, mà trong thực
tế còn cộng tác. Chính phủ là dự án nguồn mở đang
chạy lớn nhất và dài nhất thế giới (các lỗi, các
quỷ lùn, và tất cả). Đã tới lúc chúng ta bắt đầu
đối xử với nó như là một dự án nguồn mở.
Open
government is great. At least, it was a few election cycles ago. FOIA
requests, open data, seeing how your government works—it's arguably
brought light to a lot of not-so-great practices, and in many cases,
has spurred citizen-centric innovation not otherwise imagined before
the information's release.
It
used to be that sharing information was really, really hard. Open
government wasn't even a possibility a few hundred years ago.
Throughout the history of communication tools—be it the printing
press, fax machine, or floppy disks—new tools have generally done
three things: lowered the cost to transmit information, increased who
that information could be made available to, and increase how quickly
that information could be distributed. But, printing presses and fax
machines have two limitations: they are one way and asynchronous.
They let you more easily request, and eventually see how the sausage
was made but don't let you actually take part in the sausage-making.
You may be able to see what's wrong, but you don't have the chance to
make it better. By the time you find out, it's already too late.
As
technology allows us to communicate with greater frequency and
greater fidelity, we have the chance to make our government not only
transparent, but truly collaborative.
The
open source workflow
Open
source software—software for which the underlying source code is
not only made available to the public, but to which users of the
software are encouraged to submit bugs and proposed
improvements—started out the same way. Originally, open source was
merely published source, mostly due to the limitations of technology.
Everyone had access to the code, but it was published in a one-way
medium—by mail, via FTP, or via a read-only website. Over the past
two decades, open source has moved to a more distributed workflow,
one that exposes process, lives and dies by the URL, and allows
anyone in the world to submit proposed improvements with or without
the author's consent. Today, in contrast, technology allows open
source to be inherently collaborative.
Open
source's original workflow may sound familiar. If I had a question
about a particular piece of software, I'd email the author. If a
piece of software I use had a bug, I'd email the author. If I had a
proposed fix, you guessed it, I'd email the author. This workflow
isn't too disimilar from citizens calling their local
congressperson's office with a constituent services request, or
lobbyist scheduling a meeting with a regulator to advocate for a
particular issue as they do today.
Whether
software code or legal code, when you don't have the ability to
submit a proposed change upstream yourself, you're forced to go
directly to the publisher in an opaque, one-to-one interaction.
Beyond
hub and spoke
There
are two problems with this hub-and-spoke model of bespoke
collaboration. First, those one-off conversations generally happen in
private. No URL, no change history, no way to trace back the eventual
outcome to its original impetus. In open source, this means you don't
always know a code's pedigree or intent. Who knows this code and who
should I ask about this bug? In government, the same scenario is
stereotypically more nefarious, with quintessential smoke-filled back
rooms and briefcases of money. Who authored this law? What was their
interest?
Second,
when conversations are transacted via email (or notice and comment)
or other one-to-one, highly asynchronous means, there's an
opportunity for vertical communication (me and my government), but no
opportunity for horizontal communication (me and my fellow citizens),
at least not officially. In the software world, this often means that
multiple users experiencing the same bug ask the same question or
file the same bug report multiple times, not to mention, absent a
system of self help, it creates a bottleneck in the project
maintainer. There's no opportunity for a fellow user to say, "I
had the problem last week, here's what I did," as we often see
by Googling many common problems. In government that's also true,
with the added harm of hindering the marketplace of ideas. "Here's
a bunch of ideas government, you figure them out" is a lot less
effective at solving shared problems then an ongoing dialog between
citizens building towards a rough consensus.
Learning
from open source
So,
how do we encourage policy makers and bureaucrats to move from open
government to collaborative government, to learn open source's
lessons about openness and collaboration at scale?
For
one, we geeks can help to create a culture of transparency and
openness within government by driving up the demand side of the
equation. Be vocal, demand data, expect to see process, and once
released, help build lightweight apps. Show potential change agents
in government that their efforts will be rewarded.
Second,
it's a matter of tooling. We've got great tools out there—things
like Git that can track who made what change when and open standards
like CSV or JSON that don't require proprietary software—but
by-and-large they're a foreign concept in government, at least among
those empowered to make change. Command line interfaces with black
background and green text can be intimidating to government
bureaucrats used to desktop publishing tools. Make it easier for
government to do the right thing and choose open standards over
proprietary tooling.
Last,
be a good open source ambassador. Help your home city or state get
involved with open source. Encourage them to take their first step
(be it consuming open source, publishing, or collaborating with the
public), teach them what it means to do things in the open, And when
they do push code outside the firewall, above all, be supportive.
We're in this together.
As
technology makes it easier to work together, geeks can help make our
government not just open, but in fact collaborative. Government is
the world's largest and longest running open source project (bugs,
trolls, and all). It's time we start treating it like one.
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.