Cách đối xử với chính phủ như một dự án nguồn mở

Thứ sáu - 20/06/2014 06:49

How to treat government like an open source project

Posted 02 Jun 2014 by Ben Balter

Theo: http://opensource.com/government/14/5/open-collaborative-government

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

letrungnghia.foss@gmail.com