Why I fought for open source in the Air Force
Posted 08 Feb 2016 by John Allison
Bài được đưa lên Internet ngày: 08/02/2016
Tôi từng đóng quân ở một cơ sở nhỏ bên ngoài Cơ sở Không quân Mỹ Hanscom ở Massachusetts từ năm 2008 tới 2012, nơi tôi từng có trách nhiệm về các chương trình phần mềm chính của Không quân. Công việc của tôi là nắm lây trung tâm chỉ huy đang tồn tại, một con vật kếch xù được biết tới như là Trung tâm Điều hành hàng Không và Vũ trụ - AOC (Air and Space Operations Center), và hiện đại hóa nó.
Về một vài ngữ cảnh, AOC là một trung tâm kết hợp dữ liệu và vận hành. Có khoảng hàng tá các trung tâm chính như vậy nằm rải rác khắp thế giới. Mỗi trung tâm có trách nhiệm về việc lên kế hoạch cho các hoạt động của Không quân ở một khu vực đặc biệt nhất định của thế giới.
AOC đã phát triển vượt ra khỏi một trò chơi nhặt nhạnh linh tinh giữa những người sử dụng (các nhân viên Không quân) và các nhà cung cấp (các chương trình thương mại và chính phủ). Những người sử dụng đơn giản đã mua những gì họ muốn, và các nhà cung cấp hạnh phúc lấy tiền của họ và cài đặt các hệ thống. Kết quả từng là một bộ sưu tập các hệ thống đứng một mình; mỗi hệ thống đã được cài đặt với phần cứng và phần mềm của riêng nó, và đã có rất ít việc chia sẻ các tài nguyên giữa chúng. Khi đội đó làm cho nó làm việc được với một ý chí khổng lồ, thì nó từng là thiếu kinh khủng, một cơn ác mộng của việc duy trì, không thân thiện với người sử dụng, và sự lanh lẹ đã được đo đếm hàng thập niên.
Công việc của chúng tôi từng là ôm ấy đống hổ lốn đó và sửa nó. Ý tưởng từng là xây dựng một nền tảng phần cứng và phần mềm tiêu chuẩn, rồi chuyển các ứng dụng đã có trước đó sang các nền tảng mới. Cùng lúc, chúng tôi cần xác định các nền tảng đó như là các nền tảng đích cho bất kỳ dự án phần mềm mới nào. Vì thế chúng tôi đã bắt đầu xem xét các lựa chọn khác nhau, bao gồm cả JBoss, WebSphere, WebLogic, GlassFish, và các lực chọn khác. Tối thiểu, chúng tôi đã muốn một máy chủ ứng dụng tiêu chuẩn và một hành lang (bus) dịch vụ chuyên nghiệp.
Đây từng là kinh nghiệm đầu tiên của tôi về thử bằng cách đốt (trial-by-fire) mà đã chỉ ra sự kháng cự đích thực trong Không quân và Bộ Quốc phòng - DoD (Department of Defense) đối với phần mềm nguồn mở (PMNM).
Điều quan trọng để hiểu rằng vào thời điểm này, PMNM từng chưa phổ biến trong chính phủ Mỹ, và nó thường bị những người ra chính sách chủ chốt hiểu nhầm. DoD có chính sách mà mọi tứ được mua phải có khả năng hỗ trợ được, điều đó là thứ tốt lành. Đối với phần mềm, điều này ngụ ý phải có cách để sửa các lỗi và các vấn đề khác - đặc biệt về khía cạnh an toàn - theo cách thức đúng lúc. Theo truyền thống, điều này ngụ ý việc sử dụng các phần mềm sở hữu độc quyền mà đã có các hợp đồng duy trì thường niên đắt giá. Đây là mô hình mà tôi đã từng cố gắng để thay đổi.
Tôi đã không đơn độc. Đã có vài kỹ sư và quản lý chương trình nổi tiếng ở Hanscom, những người cũng đã từng cố gắng kết hợp nguồn mở vào trong các chương trình của họ. Từng rõ ràng đối với chúng tôi rằng nguồn mở đã là cách đúng để đi. Chúng tôi đã không thích ý tưởng bị khóa trói vào một nhà cung cấp mà có thể lấy bất kỳ thứ gì họ muốn trong tương lai, hoặc tệ hại hơn, bỏ mặc sản phẩm của họ trong sự trục trặc và bỏ mặc chúng tôi mà không có sự hỗ trợ. Phần mềm của chúng tôi từng được sử dụng cho các hoạt động sống còn, và chúng tôi nghĩ các rủi ro của phần mềm sở hữu độc quyền từng là quá cao biết rằng đã có các lựa chọn thay thế nguồn mở.
Tôi đã muốn một giải pháp nguồn mở và đã đối mặt với một sức phản kháng khá lớn từ các luật sư của chúng tôi, quản lý lãnh đạo, những người sử dụng, và các nhà cung cấp sở hữu độc quyền. Từng là khó để vật lộn khi đó, và đã không xong cho tới tận khi DoD đã xuất bản chỉ dẫn chính thức đầu tiên về sử dụng phần mềm nguồn mở mà chúng tôi đã bắt đầu giành được sức kéo. Cuối cùng, vào giữa tất cả các vở kịch, lãnh đạo Bộ Quốc phòng (DoD) đã đưa ra chính sách cập nhật rõ ràng nói rằng phần mềm nguồn mở là chấp nhận được miễn là có sự hỗ trợ cho nó, và rằng sự hỗ trợ có thể tới ở dạng của các lập trình viên của chính phủ, nếu cần.
Bản ghi nhớ này từng là người thay đổi trò chơi, nhưng đã phải mất nhiều hơn so với chỉ một bản cập nhật chính sách để có được xung lượng dịch chuyển hướng tới nguồn mở.
Đâu là những lý lẽ chống lại nguồn mở?
Các luật sư: “Chính sách của bộ đòi hỏi rằng phần mềm có hỗ trợ kỹ thuật”
Trước khi có chỉ dẫn rõ ràng của Bộ Quốc phòng (DoD) về nguồn mửo, đã có nhiều tranh luận về việc liệu nguồn mở có được xem là phần mềm thương mại dùng được ngay cho các mục đích mua sắm hay không. Để tránh bất kỳ rủi ro về nhận thức nào, phòng pháp lý đã yêu cầu rằng tất cả phần mềm được mua đi với sự hỗ trợ kỹ thuật. Hơn nữa, các luật sư đã muốn cách công ty đứng đằng sau phần mềm chào sự hỗ trợ đó. Chúng tôi đã phải giải thích rằng không chỉ có các công ty đứng đằng sau các sản phẩm nguồn mở, mà rằng chúng tôi có thể tự hỗ trợ mình được nếu cần - thứ gì đó chúng tôi đã không thể làm nếu một công ty phần mềm sở hữu độc quyền biến mất khỏi kinh doanh.
Lãnh đạo quản lý: “Có quá nhiều rủi ro, thậm chí nếu tôi không thể giải thích vì sao”.
Chúng tôi đã giải thích rằng tất cả phần mềm có vài rủi ro có liên quan tới nó, nhưng chúng tôi có khả năng nhặt PMNM với ít rủi ro hơn so với phần mềm thương mại tương ứng. Chúng tôi đã có khả năng cãi lý rằng PMNM có thể có ít rủi ro hơn vì nhiều lập trình viên hơn nhìn vào mã, và rằng chất lượng có thể dễ dàng thấy được. Nhiều công ty thương mại lớn đã dựa thành công vào PMNM cho các nhu cầu sống còn nhất của họ, và chúng tôi cũng có thể lắm chứ. Đó không phải là về việc chọn PMNM vì các lý do triết học - nó phải làm được công việc và làm tốt công việc.
Người sử dụng: “Chúng tôi thấy thuận tiện với các nhà cung cấp chúng tôi có”.
Là hợp lý tuyệt vời để ở lại với những gì đang làm việc được. Tuy nhiên, khi bạn đơn giản không có tiền để tiếp tục mua và hỗ trợ tất cả các phần mềm sở hữu độc quyền tại chỗ, thì tới lúc phải cân nhắc tới PMNM. Các giải pháp nguồn mở có thể không luôn có tất cả các những cái chuông và tiếng huýt sáo của các phần mềm tương ứng sở hữu độc quyền, nhưng phần mềm đó làm việc chỉ tốt cho cách mà những người sử dụng thực sự đang sử dụng nó mà thôi.
Các nhà cung cấp: “Của chúng tôi là tốt hơn!”
Trong một số trường hợp, điều đó là đúng. Tuy nhiên, câu hỏi thực tế để hỏi trong nhiều trường hợp là, “Các giải pháp phần mềm nào là đủ tốt?”, chứ không phải, “Giải pháp phần mềm nào là tốt nhất?”. Các lựa chọn rất tốt thường là quá đắt để được sử dụng khắp một tổ chức lớn. Chúng tôi đã cố gắng duy trì quy tắc rằng nếu một mẩu phần mềm sở hữu độc quyền đáp ứng được các yêu cầu và đã không có PMNM tương ứng, thì chúng tôi có thể có thiện chí trả một hóa đơn và đi với giải pháp sở hữu độc quyền. Tuy nhiên, nhiều giải pháp đã có các lựa chọn nguồn mở tương tự.
Vì sao tôi đã phải đấu tranh quá cật lực?
Trước hết, tôi tin tưởng rằng khi chính phủ mua thứ gì đó, chúng tôi mang ơn thứ gì đó phải trả về cho công chúng. Việc đầu tư vào nguồn mở là đầu tư vào thứ gì đó mà công chúng có thể sử dụng mà không phải trả tiền 2 lần. Tôi không thể có lương tâm thoải mái để trả tiền cho một nhà cung cấp sở hữu độc quyền để sửa đổi hệ thống của họ cho chúng tôi sao cho họ có thể bán sự cải tiến đó cho những người khác, dù tôi đã không có sự lựa chọn nào khác ngoài phải làm chính xác điều này trong sự nghiệp của tôi.
Điều này thường là vấn đề của việc duy trì khả năng vận hành. Tôi có thể không có cơ hội mà các AOC của chúng tôi có thể phải dừng các vận hành vì một trong những giấy phép của nó đã hết hạn. Tôi đã có một nhà cung cấp phần mềm yêu cầu rằng chúng tôi dừng các vận hành vì vi phạm giấy phép được lĩnh hội. (Chúng tôi đã từng tuân thủ). Chúng tôi đã có một nhà cung cấp khác mà các giấy phép của hãng đó từng quá đắt mà chúng tôi đã không thể giữ được đối với tất cả các AOC. Chúng tôi đã phải giảm ở 1 AOC để tăng ở chỗ khác, vì thế chúng tôi đã phải biết trước thời gian khi cuộc khủng hoảng có thể nổ ra và nơi để tái phân bổ các giấy phép (điều mất ít nhất 3-4 ngày).
Lý do của tôi để chiến đấu cho nguồn mở từng không chỉ là về việc cấp phép. Nếu một giải pháp phần mềm thương mại đã không làm việc như chúng tôi muốn, thì chúng tôi đã phải làm việc với nhà cung cấp để cập nhật phần mềm. Điều này giải thiết rằng chúng tôi đã có đủ ảnh hưởng để cơ hội được thực hiện, điều thường là không đúng. Với PMNM, chúng tôi đã có khả năng để rẽ nhánh mã và thực hiện những thay đổi cần thiết nếu nó đã không làm việc.
Tôi đã chiến đấu cho nguồn mở vì chúng tôi đã cần tạo ra môi trường đổi mới và lanh lẹ. Đây từng là nơi mà từ đó hầu hết sự đam mê của tôi đã tới.
Chúng tôi có hơn 46 ứng dụng chính trong AOC và hàng trăm ứng dụng chuyên dụng nhỏ hơn. Theo truyền thống, có thể phải mất tới 5 năm sau khi chúng tôi đã hoàn thành việc phát triển các phần mềm của chúng tôi để nó được cài đặt trong AOC. Đó là chu kỳ vòng đời trong phần mềm, và tôi đã muốn giảm chu kỳ đó xuống tới thứ gì đó thực sự hữu ích cho những người vận hành.
Kế hoạch của tôi từng là truyền ra Nền tảng - như - một - Dịch vụ - PaaS (Platform-as-a-Service) của AOC tới các lập trình viên tiềm năng cùng với những gì có thể có hiểu lực như là một bộ phát triển của AOC. Nó có thể bao gồm các giao diện lập trình ứng dụng API (Application Programming Interface) và kiểm tra các dịch vụ sao cho những người khác có thể hầu như tích hợp được với phần mềm mà họ đã không có trong tay. Trong thực tế, tôi đã muốn đặt chỗ cho điều này lên Internet và để các công ty tải nó về. Hy vọng của tôi từng đưa ra trước khi công ty bỏ ra các đồng tiền để phát triển việc kinh doanh thì hãy bay tới gặp tôi và gõ cửa phòng tôi, họ nên có khả năng tự họ thấy liệu phần mềm của họ có thể làm việc được trong môi trường của chúng tôi hay không.
Thế thì bạn làm điều này thế nào nếu PaaS của bạn là sở hữu độc quyền? Tôi có thể trả tiền vì một giấy phép chuyên nghiệp, tôi có thể sử dụng một giải pháp nguồn mở, hoặc tôi có thể ép tất cả các công ty đó mua PaaS sở hữu độc quyền (không dễ cho các cửa hàng phần mềm nhỏ mà tôi đã nhắm vào). Vì thế, câu trả lời dễ dàng là nguồn mở. (Và thậm chí là đã có vài thách thức). Một khi một công ty có thể chỉ ra rằng phần mềm của họ đã làm việc với nền tảng tham chiếu của chúng tôi, thì chúng tôi có thể có thảo luận nghiêm túc về những gì nó có thể lấy để tích hợp chính thức chúng vào chương trình đó. Sau khi phần mềm qua được rào cản tạm thời đó, thời gian trên thực địa đã được giảm từ hàng năm xuống còn hàng tháng.
Các nhà chính trị mức cao hơn và các vấn đề cấp tiền đã làm trệch đường các nỗ lực của tôi, và toàn bộ chương trình hiện đại hóa đã bị chậm lại. May thay, chương trình PaaS nguồn mở mà chúng tôi đã bắt đầu sống sót và bây giờ là cơ sở cho vài phát triển ứng dụng khác nhau mà cuối cùng sẽ thay thế cho các ứng dụng chính của AOC. Tôi đã bắt đầu nỗ lực này từ hôm nay, tôi có thể thúc đẩy OpenStack, OpenShift, và Dockerthay vì một giải pháp được tùy biến thích nghi nửa vời.
Về tác giả: John Allison là một sỹ quan quân đội đã nghỉ hưu mà đã từng bỏ ra hơn 20 năm làm quản lý chương trình và kỹ sư hệ thống. Ông đã từng sống ở California, Ohio, New Mexico, Colorado, Hàn Quốc, Virginia, Massachusetts, Florida. Ông vừa chuyển tới Bắc Carolina và đang làm việc như một Quản lý Dự án. Hầu hết công việc của ông khi còn phục vụ từng là về thiết kế, xây dựng, kiểm thử, và triển khai phần mềm.
I was stationed at a small base outside of the Hanscom U.S. Air Force Base in Massachusetts from 2008 to 2012, where I was responsible for the majority of the Air Force's software programs. My job was to take the existing command center, a behemoth known as the Air and Space Operations Center (AOC), and modernize it.
For some context, the AOC is a combined data and operations center. There are about a dozen of these major centers scattered around the world. Each is responsible for planning the Air Force operations in a specific area of the world.
The AOC grew up out of a pick-up game of sorts between the users (Air Force personnel) and the vendors (commercial and government programs). The users simply bought what they wanted, and the vendors happily took their money and installed the systems. The result was a collection of standalone systems; each came installed with its own hardware and software, and there was very little sharing of resources between them. While the team made it work through sheer willpower, it was horribly inefficient, a maintenance nightmare, not user friendly, and agility was measured in decades.
Our job was to take that mess and fix it. The idea was to build a standard hardware and software platform, then migrate the legacy applications to the new platforms. At the same time, we needed to define those platforms as the target platforms for any new software projects. So we started looking at various options, including JBoss, WebSphere, WebLogic, GlassFish, and others. At a minimum, we wanted a standard application server and enterprise service bus.
This was my first trial-by-fire experience that showed the true resistance within the Air Force and Department of Defense (DoD) to open source software.
It is important to understand that at this point in time, open source software was not popular in the U.S. government, and it was often misunderstood by key decision makers. The DoD has a policy that everything purchased must be supportable, which is a good thing. For software, this means there must be a way to fix bugs and other issues—especially in regards to security—in a timely manner. Traditionally, this meant using proprietary software that had expensive annual maintenance contracts. This is the model that I was trying to change.
I wasn't alone. There were several outstanding engineers and program managers at Hanscom who were also attempting to incorporate open source into their programs. It was clear to us that open source was the right way to go. We just didn't like the idea of being locked to a vendor that could charge whatever they wanted in the future, or worse, abandon their product on a whim and leave us without support. Our software was used for critical operations, and we thought the risks of proprietary software were too high given that there were open source alternatives.
I wanted an open source solution and faced a fair amount of resistance from our lawyers, management, users, and proprietary vendors. It was a difficult struggle at times, and it wasn't until the DoD published their first official guidance on the use of open source software that we started to gain traction. Finally, in the middle of all of the drama, the DoD leadership issued a policy update explicitly stating that open source software was acceptable as long as there was support for it, and that the support could come in the form of government programmers, if necessary.
This memo was a game changer, but it took more than just a policy update to get momentum to shift toward open source.
What were the arguments against open source?
Lawyers: "Department policy requires that software has technical support."
Before the DoD's clarifying guidance on open source, there was a great deal of debate over whether open source could be considered commercial off-the-shelf software for procurement purposes. To avoid any perceived risk, the legal department required that all software purchased came with technical support. Further, the lawyers wanted the company behind the software to offer this support. We had to explain that not only were there companies behind open source products, but that we could do the support ourselves if needed—something we couldn't do if a proprietary software company went out of business.
Management: "There's too much risk, even if I can't explain why."
We explained that all software has some risk associated with it, but we'd be able to pick open source software with less risk than a commercial equivalent. We were able to argue that open source software may have less risk because many more programmers look at the code, and that the quality can be easily seen. Many of the largest commercial companies have relied successfully on open source software for their most critical needs, and we could too. It wasn't about choosing open source software for philosophical reasons—it had to do the job and do it well.
Users: "We are comfortable with the vendors we have."
It is perfectly reasonable to stay with what is working. However, when you simply don't have the budget to continue to buy and support all of the proprietary software on board, it's time to consider open source software. Open source solutions may not always have all the bells and whistles of their proprietary equivalents, but the software works just fine for how the users are actually using it.
Vendors: "Ours is better!"
In some cases, that was true. However, the real question to ask in many cases is, "Which software solutions are good enough?", not, "Which are the best?". The very best options are often too expensive to be used throughout an enterprise. We strived to maintain the rule that if a proprietary piece of software met the requirements and there was not an open source software counterpart, we would be willing to pay the bill and go with the proprietary solution. However, many had similar open source options.
Why did I fight so hard?
First of all, I believe that when government pays for something, we owe something back to the public. Investing in open source invests in something that the public can use without paying twice for. I can't in good conscience pay a proprietary vendor to modify their system for us so they can sell that improvement to others, although I've had no choice but to do exactly this in my career.
It is often a matter of maintaining operational capability. I could not take the chance that our AOCs would have to shut down operations because one of its licenses expired. I had one software vendor demand that we stop operations because of a perceived license violation. (We were in compliance.) We had another vendor whose licenses were so expensive that we kept a pool for all of the AOCs. We had to decrease at one AOC to increase at another, so we had to know ahead of time when a crisis would break out and where in order to reallocate the licenses (which took a minimum of three to four days).
My reason for fighting for open source wasn't just about licensing. If a commercial software solution did not work like we wanted it to, we had to work with the vendor to update the software. This assumed that we had sufficient clout to get a change made, which often was not the case. With open source software, we had the ability to fork the code and make the necessary changes if it didn't work.
I fought for open source because we needed to create an environment of innovation and agility. This was where most of my passion came from.
We have over 46 major applications in the AOC and hundreds of smaller, specialized applications. Traditionally, it could take up to five years after you finished developing your software for it to be installed in the AOC. That is a lifetime in software, and I wanted to bring that down to something actually useful for the operators.
My plan was to pass out the AOC's Platform-as-a-Service (PaaS) to potential developers along with what would effectively be an AOC development kit. It would include APIs and test stub services so others could virtually integrate with software they didn't have on hand. In fact, I wanted to host this on the internet and let companies download it. My hope was that before a company spent the business development dollars flying up to meet me and knock on my door, they would be able to see for themselves if their software would work in our environment.
So how do you do this if your PaaS is proprietary? I could pay for an enterprise license, I could use an open source solution, or I could force all of these companies to buy the proprietary PaaS (not easy for the small software shops I wanted to target). So, the easy answer was open source. (And even that had some challenges.) Once a company could show that their software worked with our reference platform, we would have a serious discussion on what it would take to formally integrate them into the program. After the software passed that first hurdle, the fielding time was reduced from years to months.
Higher-level politics and funding issues derailed my efforts, and the entire modernization program was delayed. Thankfully, the open source PaaS program we started survived and is now the basis for several different application developments that will eventually replace major AOC applications. Had I started this effort today, I would be pushing OpenStack, OpenShift, and Docker instead of a semi-customized solution.
About the author: John Allison is a retired military officer that has spent over 20 years doing program management and systems engineering. He's lived in California, Ohio, New Mexico, Colorado, Korea, Virginia, Massachusetts, Florida. He just moved to North Carolina and is working as a Project Manager. Most of his work while active duty has been on designing, building, testing, and deploying software.
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét