Vì sao tất cả các phần mềm của chính phủ lại không phải là nguồn mở nhỉ?

Why isn't all government software open source?

Posted 14 Aug 2014 by Ben Balter

Theo: http://opensource.com/government/14/8/why-isnt-all-government-software-open-source

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

letrungnghia.foss@gmail.com