Otd lessons-learned-and-best-practices-for-military-software-vi

666 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
666
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Otd lessons-learned-and-best-practices-for-military-software-vi

  1. 1. Phát triển Công nghệ Mở Những bài học học được và những thực tiễn tốt nhất cho các phần mềm quân sựĐược Trợ lý Bộ trưởng Quốc phòng (Các mạng Tích hợp Thông tin)NII/DoD, Giám đốc Thông tin (CIO) và Thứ trưởng Bộ Quốc phòng về Mua sắm, Công nghệ và Hậu cần (AT&L) bảo trợ Dịch sang tiếng Việt: Lê Trung Nghĩa; letrungnghia.foss@gmail.com Dịch xong: 31/05/2011Bản tiếng Anh: http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf Open Technology Development (OTD) Lessons Learned And Best Practices For Military Software Sponsored by the Assistant Secretary of Defence (Networks Information Integration) NII/DoD Chief Information Officer (CIO) and the Under Secretary of Defence for Aquisition, Technology and Logistics (AT&L)
  2. 2. 2011 - Các bài học học được về công nghệ mở Phát triển Công nghệ Mở (OTD): Các bài học học được và các thực tiễn tốt nhất cho các phần mềm quân sự 16/05/2011 Được Trợ lý Bộ trưởng Quốc phòng (Các mạng Tích hợp Thông tin) NII/DoD, Giám đốc Thông tin (CIO) và Thứ trưởng Bộ Quốc phòng về Mua sắm, Công nghệ và Hậu cần (AT&L) bảo trợ.Tài liệu này được tung ra theo giấy phép Creative Commons Attribution ShareAlike 3.0 (CCBY-SA). Bạn được tự do để chia sẻ (để sao chép, phân phối và truyền tác phẩm) và để trộn (để s ửa tácphẩm cho phù hợp), theo điều kiện thẩm quyền được trao (bạn phải trao thẩm quyền tác phẩm nàytheo cách thức được tác giả hoặc người cấp phép chỉ định (nhưng không theo bất kỳ cách nào màgợi ý rằng họ chứng thực cho bạn hoặc việc sử dụng của bạn đối với tác phẩm)). Để có thêm thôngtin, hãy xem http://creativecommons.org/licenses/by/3.0/.Chính phủ Mỹ có các quyền không hạn chế đối với tài liệu này theo DFARS 252.227-7013.Các phần của tài liệu này ban đầu được xuất bản trong Thông tin Kỹ thuật Ph ần m ềm (SoftwareTech News), tập 14, số 1, tháng 01/2011. Xem See https://softwaretechnews.thedacs.com/ đ ể cóthêm thông tin. Phiên bản – 1.0Dịch sang tiếng Việt: Lê Trung Nghĩa, letrungnghia.foss@gmail.com; Dịch xong: 31/05/2011Bản tiếng Anh: http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software 2011-05-16 Sponsored by the Assistant Secretary of Defense (Networks & Information Integration) (NII) / DoD Chief Information Officer (CIO) and the Under Secretary of Defense for Acquisition, Technology, and Logistics (AT&L)This document is released under the Creative Commons Attribution ShareAlike 3.0 (CCBY-SA)License. You are free to share (to copy, distribute and transmit the work) and to remix (to adapt thework), under the condition of attribution (you must attribute the work in the manner specified by theauthor or licensor (but not in any way that suggests that they endorse you or your use of the work)).For more information, see http://creativecommons.org/licenses/by/3.0/ .The U.S. government has unlimited rights to this document per DFARS 252.227-7013.Portions of this document were originally published in the Software Tech News, Vol.14, No.1,January 2011. See https://softwaretechnews.thedacs.com/ for more information. Version - 1.0Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 2/77
  3. 3. 2011 - Các bài học học được về công nghệ mởThừa nhậnSự phát triển của tài liệu này đã được Dan Risacher, Trợ lý Bộ trưởng Quốc phòng (Các mạng Tíchhợp Thông tin) NII/DoD, Giám đốc Thông tin (CIO) và Fritz Schulz, Thứ trưởng Bộ Quốc phòng vềMua sắm, Công nghệ và Hậu cần (AT&L), Ban Lãnh đạo Lĩnh vực hoạt động Nhanh, Nhóm Nghiêncứu Chéo AT&L và Heather Burke của Trung tâm các Hệ thống SPAWAR Đại Tây dương (SSCLANT) bảo trợ.Tác giả của tài liệu này là John Scott, David A. Wheeler, Mark Lucas, và J.C. Herz.Các tác giả mong muốn cảm ơn các nhóm và cá nhân sau vì s ự biên so ạn, cung c ấp thông tin đ ầuvào, trợ giúp và chỉ dẫn: John Weathersby, Kane McLean, Gunnar Hellekson, Josh Davis, DebBryant, Scott Goodwin, nhóm làm việc MIL-OSS (http://mil-oss.org &http://groups.google.com/group/mil-oss) và nhiều người khác.Người đệ trình: ________________________________________________Tên: John Scott, Ngày Hợp đồngChức danh: Sr. Kỹ sư Hệ thống & Lãnh đạo các Công nghệ Mở, RadiantBlue Technologies, Inc.Người phê chuẩn: ________________________________________________Tên: Fritz Schultz, Chính phủ Mỹ ngàyChức danh: Điều hành Giám sát, OASD Research & Engineering, Rapid Field DirectorateNgười phê chuẩn: ________________________________________________Tên: Dan Risacher, Chính phủ Mỹ ngàyChức danh: Giám đốc Liên kết, Văn phòng Giám đốc Thông tin (CIO) của Bộ Qu ốc phòng, Tíchhợp & các Dịch vụ Doanh nghiệpVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 3/77
  4. 4. 2011 - Các bài học học được về công nghệ mởMục lụcChương 1. Giới thiệu............................................................................................................................6 1.1 Phần mềm là một tài nguyên có thể thay mới được của quân sự...............................................6 1.2 Phát triển Công nghệ Mở (OTD) là gì.......................................................................................9 1.3 Các tiếp cận phát triển phần mềm dùng ngay được OTS (Off-the-shelf), bao gồm cả OTS của Chính phủ Mở (OGOTS) và PMNM.............................................................................................10 1.4 Những điều kiện tiên quyết chủ chốt đối với OTD..................................................................11 1.4.1 Các quyền trí tuệ..............................................................................................................11 1.4.2 Tính đơn giản...................................................................................................................13Chương 2. Điều hành các dự án OTD................................................................................................14 2.1 Thiết lập một chương trình OTD.............................................................................................14 2.1.1 Bước 1: Xác định các lựa chọn sử dụng lại......................................................................14 2.1.2 Bước 2: Xác định dự án để thiết lập.................................................................................15 2.1.3 Bước 3: Chọn và áp dụng một giấy phép chung..............................................................16 2.1.4 Bước 4: Thiết lập sự điều hành........................................................................................16 2.1.4.1 Tính có thể rẽ nhánh.................................................................................................16 2.1.4.2 Các mô hình điều hành.............................................................................................17 2.1.5 Bước 5: Thiết lập sự cộng tác...........................................................................................18 2.1.6 Bước 6: Tạo ra đường lối kỹ thuật của dự án...................................................................18 2.1.7 Bước 7: Công bố..............................................................................................................19 2.1.8 Tiếp tục rà soát lại các bước từ 1-7..................................................................................19 2.2 Hạ tầng kỹ thuật cho sự cộng tác.............................................................................................19 2.2.1 Các chức năng mấu chốt..................................................................................................20 2.2.2 Truy cập, công khai, bí mật và kiểm soát xuất khẩu........................................................21 2.2.3 Hosting.............................................................................................................................22 2.3 Giao tiếp truyền thông.............................................................................................................23 2.3.1 Hãy là người tham gia......................................................................................................23 2.3.2 Tránh các thảo luật riêng tư.............................................................................................24 2.3.3 Sử dụng các cơ chế truyền thông hiệu quả......................................................................24 2.3.4 Thực tế rà soát mã nguồn dễ thấy.....................................................................................25 2.3.5 Sự khiếm nhã là không nên .............................................................................................25 2.3.6 Tính tới những người độc hại...........................................................................................25 2.3.7 Hãy nhận thức được về các vai trò...................................................................................25 2.4 Quản lý kỹ thuật/Các tiêu chí kỹ thuật....................................................................................26 2.4.1 Các mục tiêu.....................................................................................................................26 2.4.2 Sử dụng lại và cộng tác trong các thành phần OTD.........................................................27 2.4.3 Không rẽ nhành PMNM chỉ vì sử dụng của Chính phủ...................................................27 2.4.2 Các tiêu chuẩn mở............................................................................................................28 2.4.5 Quản lý các đóng góp......................................................................................................28 2.5 Đưa ra liên tục..........................................................................................................................29 2.5.1 Quản lý các quyền trí tuệ.................................................................................................29Chương 3. Lập trình OTD: Các chiến thuật, công cụ và thủ tục........................................................31 3.1 Khởi tạo và/hoặc chuyển sang OTD........................................................................................31 3.1.1 Phân tích các lựa chọn thay thế (AoA)............................................................................32 3.1.2 Yêu cầu thông tin (RFI)...................................................................................................33Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 4/77
  5. 5. 2011 - Các bài học học được về công nghệ mở 3.2 Yêu cầu đề xuất (RFP).............................................................................................................34 3.2.1 Tuyên bố về các mục đích (SOO) & ý định.....................................................................34 3.2.2 Các quyền trí tuệ..............................................................................................................35 3.2.3 Các định dạng dữ liệu, các tiêu chuẩn & các giao diện...................................................35 3.2.4. Các công nghệ OTS........................................................................................................36 3.2.5 Các thực tiễn của OTD.....................................................................................................36 3.2.6 Các phân phối...................................................................................................................37 3.3 Lựa chọn nguồn: Đánh giá các đề xuất....................................................................................37 3.3.1 Đánh giá cách mà đề xuất tốt đáp ứng RFP.....................................................................38 3.3.2 Các tiêu chí chấp nhận/phê chuẩn đối với các phân phối................................................38 3.3.3 Các cạm bẫy phải tránh....................................................................................................39Chương 4. Phát triển & Phân phối liên tục.........................................................................................40 4.1 Các chu kỳ phát triển nhanh....................................................................................................40 4.2 Kiểm thử, chứng thực và làm cho tin tưởng.............................................................................40 4.3 Chuyển sang các hoạt động & duy trì......................................................................................41 4.4 Khả năng tìm kiếm..................................................................................................................41 4.5 Các bài học học được...............................................................................................................42 4.6 Danh sách chọn các thành công của OTD...............................................................................42Phụ lục A: Chính sách và chỉ dẫn của chính phủ Mỹ về tính mở.......................................................44 A.1 Các tiêu chuẩn và các giao diện mở (bao gồm các định dạng dữ liệu mở).............................45 A.1.1 Chính phủ Mỹ.................................................................................................................46 A.1.1.1 Các tiêu chuẩn đồng thuận tự nguyện.....................................................................46 A.1.1.2 Gắn thẻ (Biểu 70)....................................................................................................48 A.1.2 Bộ Quốc phòng...............................................................................................................48 A.2 PMNM....................................................................................................................................50 A.2.1 Gần như tất cả PMNM là thương mại và thương mại dùng được ngay (COTS)............51 A.2.2 PMNM không bị cấm vì các kiểm soát thông tin trong Freeware, Shareware và các đảm bảo....................................................................................................................................52 A.3 Văn hóa cộng tác/phân tán và các công cụ hỗ trợ trực tuyến..................................................53 A.4 Tính lanh lẹ của công nghệ (Các hệ thống mở và kiến trúc mở) ...........................................54Phụ lục B: Các yêu cầu pháp lý cho PMNM đưa ra cho công chúng của chính phủ hoặc các nhà thầu............................................................................................................................................................55Phụ lục C: Những điều cơ bản về PMNM.........................................................................................66 C.1 Định nghĩa PMNM..................................................................................................................66 C.2 Luật về các quyền trí tuệ.........................................................................................................68 C.2.1 Bản quyền & Giấy phép..................................................................................................68 C.2.2 Các bằng sáng chế...........................................................................................................68 C.2.3 Thương hiệu.....................................................................................................................69 C.3 Các dạng và các tổ hợp giấy phép của PMNM.......................................................................69Phụ lục D: Chọn một giấy phép PMNM như thế nào.........................................................................71 D.1 Các tiêu chí cấp phép chủ chốt...............................................................................................71 D.2 Qui trình chọn giấy phép đơn giản.........................................................................................72Các tham chiếu...................................................................................................................................75Bảng chú giải.....................................................................................................................................77Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 5/77
  6. 6. 2011 - Các bài học học được về công nghệ mởChương 1. Giới thiệuMục đích của tài liệu này là để giúp cho cá nhân và các nhà thầu của chính phủ M ỹ tri ển khai pháttriển công nghệ mở (OTD) cho các phần mềm bên trong các dự án của chính phủ, đặc biệt trongquốc phòng.OTD là một tiếp cận đối với sự phát triển phần mềm/hệ thống trong đó những người phát triển trongcác tổ chức khác nhau về quân sự, liên bang, thương mại và có khả năng là công chúng có th ể c ộngtác phát triển và duy trì phần mềm hoặc một hệ thống theo một cách th ức phi t ập trung. OTD ph ụthuộc vào các tiêu chuẩn và các giao diện mở, các phần mềm nguồn mở (PMNM) và các thiết k ếmở, các công cụ trực tuyến cộng tác và phân tán, và sự lanh lẹ về công nghệ. [OTD2006].Vào tháng 04/2006, Thứ trưởng Bộ Quốc phòng về các Hệ thống Tiên tiến và các Khái niệm(AS&C) đã xuất bản Lộ trình Phát triển Công nghệ Mở [OTD2006]. Kế hoạch Lộ trình OTD đã t ậptrung vào các bước và các khuyến cáo để triển khai các thực tiễn này bên trong Bộ Quốc phòng.Tài liệu này được chia thành 4 chương. Chương đầu ngắn gọn giải thích ngữ c ảnh đối v ới OTD vàvì sao nó quan trọng đối với quân đội Mỹ. Chương 2 đ ưa ra nh ững b ước c ụ th ể cho vi ệc thi ết l ập,quản lý và phân phối các dự án OTD bên trong chính phủ. Chương 3 xác đ ịnh các th ủ t ục ch ươngtrình cho OTD, bao gồm các phân tích những lựa chọn thay thế, qui trình Yêu c ầu Thông tin/Yêucầu Đề xuất (RFI/RFP), đánh giá các đề xuất, chọn nguồn, ngôn ngữ làm hợp đồng, và các tiêu chíchấp nhận/phê chuẩn cho việc phân phối. Chương 4 làm việc với quản lý vòng đời: sự chuyển tiếp,các hoạt động và bảo trì, và khuyến khích một cộng đồng những người phát tri ển cho s ự phát tri ểnhiện đang diễn ra.1.1 Phần mềm là một tài nguyên có thể thay mới được của quân sự “Nước Mỹ không thể rút lui ra đằng sau một đường Maginot của các tường lửa hoặc nếu không nó sẽ gặp rủi ro bị xéo qua. Chiến tranh không gian mạng giống như là chiến tranh dùng mẹo, trong đó tốc độ và sự linh hoạt là quan trọng nhất”. ― William J. Lynn III. [Lynn2010]Phần mềm đã trở thành trung tâm đối với cách mà một chiến binh th ực hi ện các nhi ệm v ụ. Vì s ự tincậy vào phần mềm sẽ là một sức mạnh, Bộ Quốc phòng (DoD - Department of Defense) ph ải tuântheo một chiến lược tích cực để quản lý hồ sơ phần mềm của mình và thúc đẩy một văn hóa nội bộđối với các giao diện, module hóa và sử dụng lại mở [Scott2010]. Đ ặc biệt, DoD ph ải có ph ần m ềmmà dễ dàng có thể áp dụng được cho việc thay đổi các nhu c ầu nhi ệm v ụ và có th ể đ ược ti ến hóa vàđược phân phối nhanh chóng ở chi phí thấp để đáp ứng được các yêu cầu nhiệm vụ một cách đúnglúc. Sự tiến hóa về công nghệ đi sau một sự tiến hóa song song trong các phương pháp luận muasắm và thái độ của các tập đoàn để tạo điều kiện cho sự mở ra, sử dụng lại, và sửa đổi các ph ầnmềm xuyên khắp DoD và Chính phủ Mỹ.Phần mềm là kết cấu xúc tác cho việc lên kế hoạch, các vũ khí và các hệ thống h ậu c ần hi ện đ ạihoạt động. Nó có thể là tài nguyên quân sự có khả năng thay mới đ ược m ột cách vô t ận. Các kh ảnăng tiến hóa khi phần mềm mới được tạo ra một lần nữa ho ặc xây d ựng d ựa trên ph ần m ềm hi ệnđang tồn tại. Từ những cảm biến mặt đất tới các vệ tinh, phần mềm là ở khắp mọi nơi; nó là sự thểhiện cuối cùng của tri thức quân sự được truyền vào mã nguồn và được triển khai trên chiến địa.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 6/77
  7. 7. 2011 - Các bài học học được về công nghệ mởChúng ta cần một cách thức phát triển bất kể ngày tháng, triển khai và cập nh ật các h ệ th ống ph ầnmềm cường độ lớn mà sẽ đáp ứng được nhịp độ và các yêu cầu nhiệm vụ bất kể thay đổi thế nào củacác tác chiến quân sự.Hãy tưởng tượng nếu chỉ nhà sản xuất của một rãnh xoắn (trong súng) được phép làm s ạch, s ửa l ỗi,sửa đổi hoặc nâng cấp rãnh xoắn đó. Quân đội thường nhận ra bản thân mình trong tình huống nàyvới người đóng thuế, nhà thầu phát triển phần mềm: một nhà thầu với một sự độc quyền về tri thứccủa một hệ thống phần mềm quân sự và kiểm soát mã nguồn phần mềm. Điều này chỉ hợp lý đối vớinhà thầu độc quyền, nhưng tạo ra sự thiếu khả năng và tính không hiệu quả đối với chính phủ, giảmcác cơ hội cho cơ sở công nghiệp, hạn chế nghiêm trọng sự cạnh tranh đối với những cập nh ật ph ầnmềm, làm rỗng các tài nguyên có thể được sử dụng để có hiệu quả tốt hơn và lãng phí ti ền mànhững người đóng thuế cung cấp.Để giải quyết được vấn đề này, một chế độ sở hữu trí tuệ phần mềm hiện đại mở r ộng mà c ơ sởcông nghiệp quốc phòng cần phải xác định để xúc tác cho sự truy cập một cách rộng rãi đ ối v ới n ềncông nghiệp để bảo vệ tri thức, bao gồm cả mã nguồn phần mềm, tài liệu, các thi ết kế phần cứng vàcác giao diện. Kết quả sẽ làm gia tăng sự cạnh tranh và một chi phí thu ần th ấp đ ối v ới s ự đ ổi m ớisáng tạo. Thời gian trôi đi, quân đội có thể tiến hóa các kiến trúc phần mềm chung và các nền tảngcơ bản rộng lớn của nền công nghiệp để làm gia tăng khả năng thích nghi, tính mau lẹ và, quantrọng nhất, khả năng đáp ứng được với những mối đe dọa mới, biến động một cách nhanh chóng.Những lợi ích chính của OTD là: • Tính mau lẹ/Tính mềm dẻo gia tăng: Vì chính phủ có sự truy cập và các quy ền không h ạn chế đối với mã nguồn được phát triển bằng tiền của người đóng thuế, nên mã ngu ồn có th ể được thực hiện một cách có thể nhận biết được và có thể truy cập được đối với nh ững ng ười quản lý, các nhân viên dân sự và các nhà thầu chương trình tương tự nh ư nhau, làm gia tăng tiềm năng đáp ứng được nhu cầu hoặc yêu cầu mới đối với cơ sở mã nguồn đang tồn tại mà nó cung cấp một phần lớn của giải pháp có thể được nhập vào hoặc được cải tiến để đáp ứng một nhiệm vụ mới. Cũng thế, các thành phần được chính phủ cấp tiền đang tồn tại trước đó từ các chương trình khác nhau có thể được lắp ráp mà không có các chi phí và nh ững s ự chậm trễ không cần thiết gỡ rối cho các quyền sở hữu trí tuệ để xác định cái gì là đ ược phép và không được phép. Thay vì phải bắt đầu từ không có gì để phát triển hoặc cải tiến một khả năng, chính phủ có thể sử dụng lại những gì chính phủ đã trả tiền và làm việc và thiết kế từ một cơ sở rộng lớn các lập trình viên và các nhà thầu mà họ quen với mã nguồn và thành phần và có thể nhanh chóng lắp ráp, trộn và sửa đổi các hệ th ống và các thành ph ần đang có sẵn với mã nguồn khác đang tồn tại. • Đưa ra nhanh hơn: Vì các lập trình viên chỉ cần tập trung vào nh ững thay đ ổi, và s ự tích h ợp của các khả năng phần mềm hiện đang có thay vì phải phát triển lại toàn bộ các hệ thống, họ có thể giảm được đáng kể thời gian đưa ra các khả năng mới. Thậm chí khi m ột module hoặc thành phần được phát triển từ không có gì để thay thế một thành ph ần đã l ỗi th ời, thì những lợi ích phát triển lại như vậy từ các giao diện và tiêu chuẩn mở đã được chứng minh trong các hệ thống mà mà module đó tương tác được với chúng. Việc xúc tác để sinh ra các mã nguồn có sở hữu từ tiền của những người đóng thuế đã trả, thì thời gian để phát triển và triển khai có thể giảm đáng kể. • Đổi mới sáng tạo gia tăng: Với sự truy cập tới mã nguồn đ ối v ới các kh ả năng hi ện đang t ồn tại, các lập trình viên và các nhà thầu có thể tập trung vào sự đổi mới sáng tạo và các yêu cầu mới mà chúng còn chưa đáp ứng được bằng các khả năng của mã nguồn đang tồn tại.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 7/77
  8. 8. 2011 - Các bài học học được về công nghệ mở Tính lanh lẹ này là đặc biệt quan trọng vì một sự thâm hụt đ ược đ ưa ra v ề s ố l ượng các công dân Mỹ với các học vị về khoa học máy tính và kỹ thuật có thể sẽ là rõ ràng để làm việc trong các dự án quân sự trong các thập niên tiếp theo [Viện Hàn lâm Khoa h ọc Qu ốc gia 2008]. Khi một tỷ lệ lớn hơn các học vị kỹ thu ật phần mềm đ ược các qu ốc gia n ước ngoài nắm giữ, và các chương trình của Mỹ là hấp dẫn bởi sự đổi mới sáng tạo và công việc có sinh lợi trong khu vực tư nhân, thì quân đội sẽ đối mặt với sự thiếu hụt dài hạn các kỹ s ư phần mềm để làm việc trong các hệ thống đặc chủng của quân đội. Bộ Quốc phòng vì thế phải tập trung vào thách thức dài hạn đối với việc thu thập các mức đổi mới sáng tạo cao hơn ngoài kho tài năng và kỹ năng con người bị hạn chế hơn. Sẽ là quan trọng đ ể thúc đ ẩy sự đầu tư của con người bằng việc để các kỹ sư tập trung vào 10% mã nguồn cải thi ện một cách tích cực một hệ thống mà cũng không cần phải đòi hỏi phải tạo lại 90% khả năng đã có sẵn rồi. • Giảm thiểu rủi ro: việc tạo ra các khả năng mới từ không có gì là r ủi ro h ơn so v ới vi ệc s ử dụng lại các khả năng đang tồn tại mà chúng đã được chứng minh và được hiểu tốt rồi. Bằng việc sử dụng lại các khả năng ở dạng mã nguồn, các giao di ện và các h ệ th ống do chính ph ủ sở hữu, các lập trình viên có thể bỏ ra nhiều thời gian và tài nguyên hơn trong các phần r ủi ro nhất của triển khai. • Bảo hiểm và an ninh thông tin: Một trong những giá trị lớn nhất của phát triển nguồn mở là việc xúc tác cho sự truy cập của cộng đồng rộng lớn hơn tới nguồn phần mềm. Theo cách này các lỗi sẽ cạn và vì thế thấy dễ dàng hơn. Sự truy cập r ộng rãi h ơn t ới mã ngu ồn ph ần mềm cũng là chìa khóa cho việc hình thành và duy trì một dáng vẻ an ninh phần mềm từ việc có khả năng rà soát lại mã nguồn phần mềm cho tới việc xem những gì thực s ự hiện diện bên trong phần mềm đó. • Chi phí thấp hơn: Chi phí đầu tiên sẽ giảm được có lợi cho OTD là ti ền thu tô t ừ s ự đ ộc quyền mà chính phủ trả cho các nhà thầu để họ đã xây dựng một bức tường có tính loại trừ xung quanh các khả năng mà họ được trả tiền từ chính Chính phủ để phát triển. Họ có thể đã phát triển mã nguồn một cách nội bộ (nghiên cứu và phát triển nội bộ – IRAD – Internal Research And Development) mà nó là có giá trị, nhưng trong một hệ th ống OTD mà mã nguồn đã được module hóa sao cho chính phủ có thể thực hiện được một quyết định h ợp lý về việc liệu họ có muốn cấp phép lại cho mã nguồn đối với một d ự án m ới hay tr ả ti ền đ ể phát triển một sự thay thế. Toàn bộ giá trị đầu tư của chính phủ đã không bị làm rỗng bởi việc trộn lẫn IRAD vào một hệ thống do chính phủ đã đầu tư như một ph ương ti ện đ ảm b ảo cho sự khóa trói vào một nhà cung cấp cụ thể. Với các quyền và sự truy cập không hạn chế tới mã nguồn do chính phủ cấp tiền, chính phủ có thể vẽ ra trong một kho r ộng l ớn h ơn những đề xuất cạnh tranh đối với những cập nhật phần mềm và các khả năng mới mà chúng thúc đẩy các hệ thống hiện hành. Sự hạn chế thu tô từ sự độc quyền, kết hợp với sự cạnh tranh lớn hơn, sẽ làm giảm chi phí và cải thiện chất lượng của kết quả phân phối, vì bất kỳ nhà thầu nào làm việc trong một hệ thống đều biết họ có thể bị thay thế bằng một đối thủ cạnh tranh có sự truy cập đầy đủ tới mã nguồn và tài liệu.Như Bộ trưởng Quốc phòng Robert Gates đã nói “Giếng dầu phun [tiền] đã và đang tắt và sẽ ở trạngthái tắt trong một giai đoạn thời gian”. DoD cần một hệ sinh thái phát triển ph ần mềm có hi ệu qu ảhơn – đổi mới sáng tạo với chi phí thấp hơn. OTD vắt ép sự lãng phí tài chính ra kh ỏi s ự cân b ằngbằng việc giảm sự khóa trói và gia tăng sự cạnh tranh.Bằng việc triển khai OTD, DoD có thể giúp làm cho mã nguồn phần mềm thành một tài nguyên cóthể thay mới được của quân sự một cách vô hạn.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 8/77
  9. 9. 2011 - Các bài học học được về công nghệ mở1.2 Phát triển Công nghệ Mở (OTD) là gì “Trong một thế giới thực với các tài nguyên và kỹ năng hạn chế, các cá nhân và nhóm hình thành, tan rã và cải biên tình thế cộng tác hoặc cạnh tranh của h ọ trong m ột cu ộc v ật l ộn liên tục để loại bỏ hoặc vượt qua được những trở ngại của môi trường xã h ội và v ật lý. Sự lanh lẹ về công nghệ nên là một thước đo”. ― Col John Boyd (USAF) [Boyd1976]Như được nêu ở trên, OTD là một tiếp cận đối với s ự phát triển ph ần m ềm/h ệ th ống trong đó nh ữnglập trình viên (bên ngoài chính phủ và quân đội) phát triển và duy trì một cách cộng tác ph ần m ềmhoặc hệ thống theo một cách thức phi tập trung. OTD phụ thuộc vào các tiêu chuẩn và giao diệnmở, phần mềm nguồn mở và các thiết kế mở, các công cụ trực tuyến cộng tác và phân tán, và sựlanh lẹ về công nghệ. [OTD2006]Những thực tiễn này được chứng minh và được sử dụng trong thế giới thương mại. Các tiêu chu ẩnvà các giao diện mở cho phép các hệ thống và các dịch vụ tiến hóa trong một thị trường biến động.Việc sử dụng, cải tiến, và phát triển phần mềm nguồn mở (PMNM) làm gi ảm t ới m ức t ối thi ểu thi ếtkế kỹ thuật phần mềm dư thừa và xúc tác cho sự phát triển lanh lẹ c ủa các h ệ th ốn g. Các công cụtrực tuyến cộng tác và phân tán bây giờ được sử dụng một cách r ộng rãi trong phát tri ển ph ần m ềm.Khu vực tư nhân cũng thường đấu tranh để tránh bị khóa trói vào một nhà cung c ấp ho ặc công ngh ệduy nhất và thay vào đó cố gắng giữ các lựa chọn công nghệ của mình là m ở (nghĩa là, b ằng vi ệcgắn vào các tiêu chuẩn mở). Các nghiên cứu trước đây đã ghi thành tài liệu rằng PMNM hiện đượcsử dụng trong nhiều ứng dụng sống còn của DoD và bây giờ là một ph ần không th ể tách r ời đ ượccủa hạ tầng quân sự [MITRE2003] [OTD2006].Các phương pháp luận của OTD dựa vào khả năng của một cộng đồng phần mềm có quan tâm truycập vào mã nguồn phần mềm hoặc các giao diện ứng dụng xuyên khắp doanh nghi ệp. S ự truy c ậptới mã nguồn, các tài liệu thiết kế và tới các nhà lập trình khác và những người sử dụng đầu cuốixúc tác cho sự phát triển phi tập trung các khả năng mà chúng thúc đẩy cho các tài s ản ph ần m ềmhiện đang tồn tại. Các phương pháp luận OTD đã và đang được sử dụng trong phát tri ển ngu ồn m ở,các kiến trúc của các tiêu chuẩn mở, và thế hệ gần đây nhất các công nghệ cộng tác d ựa trên web.Mô hình phát triển PMNM là thành công vì các cộng đồng lợi ích tham gia vào là c ả nh ững l ậptrình viên và những người sử dụng.OTD đưa vào những sáng kiến nguồn mở nhưng không bị hạn chế đối với sự phát triển và các ch ếđộ cấp phép của PMNM, mà chúng làm cho sự phân phối lại mã nguồn có hi ệu lực. Đi ều quantrọng, trong ngữ cảnh của báo cáo này và tạo ra những thảo lu ận về chính sách, đ ể phân bi ệt gi ữaPMNM và OTD, khi mà OTD có thể đưa vào mã nguồn mà sự phân phối của nó có th ể b ị h ạn ch ếđối với DoD, và quả thực chỉ có thể truy cập được trong các mạng bí mật. S ự thúc đ ẩy OTD bêntrong DoD không vi phạm tình trạng pháp lý của phần mềm được phát tri ển b ằng ti ền c ủa khu v ựctư nhân bởi các nhà cung cấp thương mại.Nói chung, điều quan trọng phải đơn giản hóa sử dụng, sửa đổi, và phân phối. Nếu mà lấy một độicác luật sư để xác định liệu có các quyền phù hợp để sửa đổi hay không cho một chương trình, thì sẽkhông làm được.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 9/77
  10. 10. 2011 - Các bài học học được về công nghệ mở1.3 Các tiếp cận phát triển phần mềm dùng ngay được OTS (Off-the-shelf), bao gồm cả OTS của Chính phủ Mở (OGOTS) và PMNM.Một chiến lược OTD cho phép các tổ chức phát triển và duy trì ph ần m ềm theo m ột cách th ức c ộngtác. Để tối đa hóa sự cộng tác, phần mềm nên được phát triển để sử dụng các thành ph ần OTS vàbản thân nó trở thành OTS ở một mức độ thực tiễn tối đa.Phần mềm OTS đơn giản là phần mềm mà nó được làm sẵn rồi và s ẵn sàng đ ể s ử d ụng. S ự h ợp lýcho việc phát triển phần mềm OTS là để tạo ra phần mềm mà nó có th ể được sử dụng cho nhiềumục đích, thay vì sử dụng phần mềm được xây dựng tùy biến cho một mục đích và s ử dụng đ ơnnhất. Phần mềm OTS có tiềm năng tiết kiệm được thời gian, tiết kiệm ti ền, làm gia tăng ch ất l ượng,và làm gia tăng sự đổi mới sáng tạo thông qua việc gộp các tài nguyên. Thậm chí khi một h ệ th ốngcủa khách hàng là cần thiết, thì việc xây dựng nó từ nhiều thành phần OTS sẽ có nhiều ưu điểm.Có nhiều cách thức khác nhau mà phần mềm OTS có thể được duy trì. M ột s ố OTS có th ể đ ược gi ữvà được duy trì bên trong chính phủ Mỹ (nghĩa là, vì nó là bí mật hoặc được kiểm soát xu ất kh ẩu);như những phần mềm OTS được chính phủ chỉ định (GOTS). Các điều khoản OTS mà là các đi ềukhoản thương mại (như, để được bán, được cấp phép, hoặc được đưa ra công khai để s ử d ụng khôngtrong chính phủ) là các OTS thương mại. Lưu ý là theo luật và qui định, ph ần m ềm đ ược c ấp phépcho công chúng và được sử dụng cho ít nhất một mục đích không phải của chính phủ là phần mềmthương mại, thậm chí nếu nó được chính phủ duy trì. Hình 1 miêu tả các dạng tiếp cận duy trì OTSkhác nhau này. Hình 1. Các chiến lược duy trì OTSCó 2 dạng phần mềm OTS thương mại: PMNM và phần mềm s ở h ữu đ ộc quy ền. Trong c ả 2 tr ườnghợp chúng đều có thể được một người duy trì duy nhất hoặc một cộng đồng duy trì. Trong s ự duy trìcủa cộng đồng sẽ thường có một tổ chức duy nhất xác định liệu các đề xuất có nên được chấp nhậnhay không, nhưng mấu chốt ở đây là công việc này có xu hướng được phân trong số những người cóảnh hưởng.Ngày nay, ở những nơi có phần mềm GOTS, thì nó có xu hướng sẽ được một người duy trì duy nh ấtphát triển và duy trì. Điều này có xu thế làm giảm tính có thể áp dụng được c ủa GOTS. Nhi ềuchương trình của chính phủ có thể sử dụng một cách tiềm tàng một thành phần GOTS nếu nhữngthay đổi chắc chắn nào đó đã được thực hiện, nhưng không thể thực hiện đ ược nh ững thay đ ổi đ ốivới thành phần GOTS này một cách trực tiếp, và thậm chí nếu chúng đã được thực hiện, thì s ẽVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 10/77
  11. 11. 2011 - Các bài học học được về công nghệ mởkhông có cấu trúc nào với nó cho những thay đổi có thể được trộn ngược trở lại vào s ản phẩmGOTS chính để tất cả cùng sử dụng. Ngược lại, hầu hết các dự án PMNM được cộng đồng duy trì,nơi mà các tổ chức khác nhau làm việc một cách tích cực cùng nhau để phát triển phần mềm hữu íchcho tất cả họ. Dự án PMNM một người duy nhất duy trì có tồn tại, nhưng chúng là ít phổ biến hơn.Một dự án GOTS mở (OGOTS) là một dự án GOTS sử dụng các ti ếp cận phát triển cộng tác c ủanhiều tổ chức để phát triển và duy trì phần mềm, theo cách tương tự đ ối v ới PMNM. M ột d ự án nh ưvậy bên trong DoD đôi lúc bị giới hạn như là “phần mềm nguồn cộng đồng DoD” hoặc “PMNMcủa Chính phủ” (GOSS). Một mục tiêu của tài liệu này là để làm gia tăng s ố lượng các d ự án GOTSmà chúng là các dự án OGOTS. Một dự án có thể trở thành OGOTS thay vì PMNM vì các nhà lãnhđạo của nó muốn sự đổi mới sáng tạo, tốc độ phát triển, và chi phí th ấp có th ể t ới t ừ s ự đ ồng pháttriển của nhiều bên tham gia: 1. Chính phủ thiếu các quyền về trí tuệ để làm cho nó mở hơn (như, chính phủ có th ể có các quyền theo mục đích của chính phủ GPR ( government-purpose rights) và không có các quyền không hạn chế), và/hoặc 2. Chính phủ mong muốn duy trì một ưu thế an ninh quốc gia bằng việc không làm cho ph ần mềm đó sẵn sàng đối với các kẻ địch tiềm tàng (đặc biệt những phần mềm như vậy s ẽ là bí mật và/hoặc xuất khẩu bị kiểm soát).Bổ sung thêm, các dự án GOTS nên xác định khi nào chúng nên tr ở thành COTS (nh ư, khi các d ựán PMNM do cộng đồng hỗ trợ). Đặc biệt, các dự án GOTS nên xem xét nghiêm túc vi ệc chuy ểnsang duy trì như PMNM sau khi một hệ thống đã được tri ển khai. Có m ột lo ạt nh ững lý do vì saochính phủ nên giữ các phần mềm chắc chắn nào đó trong nội bộ, như, vì s ự sở hữu duy nh ất đ ối v ớiphần mềm trao cho chính phủ Mỹ một ưu thế khác biệt đối với các kẻ đ ịch c ủa mình. Tuy nhiên, ưuthế về công nghệ thường là trôi nổi. Thường có một điều khoản được phát triển thương mại sẵn sàngcho công chúng mà nó bắt đầu để thực thi các chức năng tương tự. Khi nó chín mu ồi, các c ơ quankhác bắt đầu sử dụng giải pháp không phải GOTS này, làm cho giải pháp GOTS có ti ềm năng tr ởthành lỗi thời. Những trường hợp như vậy thường đặt ra những quyết định khó khăn, khi mà chínhphủ phải xác định liệu có trả chi phí không đối xứng rất nặng đ ể chuy ển hay không, hay n ếu s ẽ ti ếptục “như thường” với các hệ thống GOTS bây giờ đã lỗi thời của mình (v ới các chi phí hàng nămcao và những hạn chế có thể gây rủi ro cho cuộc sống và các nhiệm vụ). Điều này có nghĩa là có r ủiro đáng kể đối với chính phủ nếu chính phủ cố giữ riêng phần mềm GOTS đó bên trong chính ph ủquá lâu.OTD liên quan tới sự phát triển của cộng đồng trong số những người sử dụng của chính ph ủ, và vìthế bao gồm cả PMNM và OGOTS.1.4 Những điều kiện tiên quyết chủ chốt đối với OTD1.4.1 Các quyền trí tuệTheo định nghĩa, một dự án OTD được xây dựng trong sự cộng tác. Sự cộng tác như vậy ch ỉ có thểkhi mà một khung pháp lý cho phép nó (bao gồm các quyền trí tu ệ c ần thi ết) và khi các c ơ s ở c ủakhung này có thể hiểu được đối với những người thường.Khái niệm “các quyền trí tuệ” có nghĩa là một tập hợp các quyền đối với một tác phẩm trí tuệ đượcgiữ bởi hàng loạt các cá nhân thông qua các luật, qui định, giấy phép, hợp đồng, ... phù hợp. Cácluật phù hợp bao gồm bản quyền, bằng sáng chế, và luật về thương hiệu. Luật bản quyền là đ ặc biệtVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 11/77
  12. 12. 2011 - Các bài học học được về công nghệ mởquan trọng; những người giữ bản quyền tác phẩm, hoặc có các quyền chủ chốt mà một người giữcác quyền có, có thể đặt ra các điều kiện khi nào thì tác phẩm đó có thể được sử dụng, được sửa đổi,hoặc được phân phối lại. Vì những mục đích của tài liệu này, tất cả các luật và qui định đụng chạmtới cách mà các tác phẩm có thể được chia sẻ và được sử dụng s ẽ ảnh h ưởng t ới các quy ền trí tu ệ;bao gồm cả các luật và các qui định đối với sự bí mật và kiểm soát xuất khẩu.Vấn đề chính trong bất kỳ dự án OTD nào là để thực hiện các quy ền trí tu ệ sao cho ph ần m ềm cóthể được sử dụng, được xem xét, được sửa đổi, và được phân phối lại trong cộng đồng.Khi được thực hiện đúng, việc đòi hỏi các quyền trí tuệ cần thiết cho một ti ếp c ận OTD s ẽ khôngxung đột với chính sách của DoD. Qui định Mua sắm Liên bang (FAR) c ủa DoD B ổ sung (DFARS)227.7203 có thể bị hiểu lầm như việc đấu thầu một tiếp cận OTD, nhưng khi được xem xét kỹ thì nóhoàn toàn không cấm OTD. DFARS 227.7203-1(c) (được rà soát lại vào ngày 20/01/2011) nói rằng“Những người chào hàng sẽ không bị yêu cầu, hoặc như một điều kiện có trách nhiệm đối với sự nàixin hoặc như một điều kiện để trao thưởng, sẽ bán hoặc nếu khác từ bỏ bất kỳ quy ền nào cho Chínhphủ trong phần mềm máy tính được phát triển chỉ bằng chi phí của tư nhân ngo ại tr ừ các ph ần m ềmđược xác định tại 227.7203-5(a)(3) tới (6)”. Tương tự, DFARS 227.7203-1(d) nói r ằng “Nh ữngngười chào hàng và các nhà thầu sẽ không bị cấm hoặc không được khuy ến khích đ ối v ới vi ệc cungcấp hoặc chào để cung cấp phần mềm máy tính được phát triển chỉ bằng chi phí của tư nhân chỉ vìcác quyền của Chính phủ để sử dụng, sửa đổi, đưa ra, tái sản xuất, thực thi, hiển thị, hoặc mở phầnmềm ra có thể bị hạn chế”. Tuy nhiên, lưu ý rằng những chính sách này chỉ áp dụng cho phần mềmđược phát triển chỉ bằng chi phí của tư nhân. Chính phủ có thể yêu cầu rằng chính phủ nhận cácquyền đối với phần mềm mà người đóng thuế đã trả để phát triển (một phần hoặc toàn phần), vàphần mềm như vậy là sự tập trung của tài liệu này.Việc có được các quyền trí tuệ rộng rãi (cũng như bản thân các sản phẩm trí tu ệ) h ạn ch ế đ ược m ộtrào cản chính đối với sự cạnh tranh, một rào c ản mà GAO và nh ững c ơ quan khác đã l ưu ý nhi ềunăm và đang được tích cực giải quyết: • Báo cáo của Văn phòng Kiểm toán Liên bang GAO (Government Accountability Office) GAO-06-839 tháng 07/2006 [GAO 2006] đã nói rằng “Sự thiếu hụt các quyền của dữ liệu kỹ thuật đã hạn chế tính mềm dẻo của các dịch vụ để tiến hành các thay đ ổi đ ối v ới các k ế hoạch bền vững có mục đích để đạt được sự tiết kiệm chi phí và đáp ứng được những yêu cầu pháp lý về các khả năng duy trì kho chứa... Trừ phi DoD đánh giá và đảm bảo các quyền của mình để sử dụng các dữ liệu kỹ thuật từ sớm trong quá trình mua s ắm các h ệ thống vũ khí khi DoD có tác dụng đòn bẩy lớn nhất để thương th ảo, thì DoD có th ể s ẽ đ ối mặt sau này với những thách thức trong việc làm cho bền vững các hệ th ống vũ khí su ốt vòng đời của chúng”. • Báo cáo của GAO GAO-10-833 tháng 07/2010 [GAO2010] th ấy rằng đối v ới “các d ịch v ụ hỗ trợ các hệ thống vũ khí của DoD, thì thiếu sự truy cập của chính ph ủ t ới các d ữ li ệu k ỹ thuật sở hữu độc quyền và sự tin cậy lâu nhiều thập kỷ vào các nhà thầu cụ thể vì hạn ch ế v ề sự tinh thông - hoặc thậm chí loại bỏ luôn khả năng - cạnh tranh”. Đây là m ột v ấn đ ề nghiêm trọng, vì sự cạnh tranh “là một công cụ sống còn để đạt được s ự hoàn v ốn đ ầu t ư t ốt nhất của chính phủ”. Gần 60% trong số 47 hợp đồng phi cạnh tranh của DoD được GAO xem xét, thì bộ này về cơ bản đã bị mắc kẹt với một nhà th ầu c ụ th ể vì nó đã thi ếu các d ữ liệu kỹ thuật đằng sau các hàng hóa và dịch vụ mà nó đã từng mua. • Ashton B. Carter vào năm 2010 [Carter 2010] đã lưu ý các vấn đ ề có liên quan t ới s ự c ạnh tranh. Điểm đầu tiên của ông về việc cung cấp những sự thúc đẩy là để “Tránh những v ụVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 12/77
  13. 13. 2011 - Các bài học học được về công nghệ mở mua được định hướng và những vật thay thế khác vì sự cạnh tranh thực sự. Sử dụng các gói dữ liệu kỹ thuật và các kiến trúc hệ thống mở để hỗ trợ một môi trường cạnh tranh liên tục”. • Bản ghi của David M. Van Buren năm 2011 [Buren 2011] là sự triển khai của Không Lực đối với đường hướng của USD (AT&L) cho một chiến lược cạnh tranh dày 1 trang. Bản ghi của Không Lực này đòi hỏi rằng mọi chương trình của Không Lực mô t ả cách mà nó s ẽ “có được các dữ liệu kỹ thuật, tài liệu phần mềm máy tính, và các quyền s ở h ữu trí tu ệ có liên quan cần thiết cho việc vận hành, duy trì, bền vững lâu dài, nâng cấp, và cạnh tranh trong tương lai” và một tổng kết về phân tích các trường hợp nghiệp vụ nếu nó không có đ ược chúng.Một dự án OTD đòi hỏi các quyền trí tuệ cụ thể nào đó; việc đòi hỏi các quyền như vậy là luôn luônvới chính sách và đường lối của DoD.1.4.2 Tính đơn giảnSự cộng tác bị gượng gạo bởi tính phức tạp không cần thiết. Phấn đấu liên t ục đ ể đ ơn gi ản hóa d ựán. Đặc biệt, đảm bảo rằng các vấn đề về quyền trí tuệ là đơn giản và rõ ràng (nh ư, thông qua cácgiấy phép rõ ràng và phổ biến), mà tư liệu là dễ dàng có sẵn cho tất c ả nh ững ai có kh ả năng truycập nó, và rằng những thiết kế kỹ thuật là các module rõ ràng.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 13/77
  14. 14. 2011 - Các bài học học được về công nghệ mởChương 2. Điều hành các dự án OTDChương này đưa ra khung cơ bản cho việc điều hành một dự án OTD. Tiểu ph ần đ ầu tiên mô t ảcách thiết lập một chương trình OTD một khi một đề xuất dự án đã được chấp thuận. Các ti ểu ph ầntiếp sau thảo luận việc thiết lập một hạ tầng kỹ thuật cho sự cộng tác, các vấn đề truyền thông, cáctiêu chí quản lý/kỹ thuật, và sự phân phối liên tục. Trong DoD chúng phải phù h ợp theo các quitrình mua sắm của DoD; cách mà điều này có thể xảy ra được thảo luận trong chương 3.2.1 Thiết lập một chương trình OTDMột khi một đề xuất dự án đã được chấp nhận, thì một chương trình OTD có thể được thiết lập có sửdụng các bước được phác thảo ở bên dưới. Nhiều thông tin hơn về cách làm điều này từ vi ễn c ảnhcủa một dự án PMNM có thể thấy trong chương 2 của [Fogel2009].2.1.1 Bước 1: Xác định các lựa chọn sử dụng lạiĐầu tiên, tìm kiếm các dự án PMNM đang tồn tại mà chúng có chức năng phù h ợp. M ột tìm ki ếmweb đơn giản các chuỗi “open source software” (“phần mềm nguồn mở”) cộng với một kh ả năngmong muốn sẽ thường biến thành thứ gì đó gần với những gì bạn cần. Cũng xem xét l ại các site cáckho PMNM như http://www.sourceforge.net, http://www.freshmeat.net, http://www.github.com,http://directory.fsf.org và http://code.google.com. Thậm chí nếu không có gì s ẵn sàng đ ể s ử d ụngmột cách trực tiếp, thì có thể có những phần nhỏ mà có thể là những ý tưởng được tích hợp hoặchữu dụng.Áp dụng kiểu cơ hội chủ nghĩa đối với PMNM là quan trọng vì s ự đ ổi m ới sáng t ạo v ề công ngh ệtrước hết đang xảy ra trên Internet không có gì là bí mật, không phải là trong môi trường quân đ ội.Hầu hết các phần nhỏ đối với bất kỳ dự án đưa ra nào cũng sẵn sàng ở đó, và có vô số các PMNMcó thể nhanh chóng đưa ra trước được các nhu cầu của các dự án chính phủ. Sự đánh giá, lựa chọn,và tham gia cẩn thận trong các dự án bên ngoài này là cách hiệu quả nhất để tiến hóa các khả năngqua vòng đời của một chương trình của chính phủ. Các phần mềm GOTS đang tồn tại có thể nhanhchóng trở thành lỗi thời một khi có một dự án COTS nhà nước (bao gồm c ả m ột d ự án PMNM) v ớimục tiêu y như vậy.Bạn cũng nên xem xét các lựa chọn phần mềm GOTS đang tồn tại. Không có ch ỗ duy nh ất nào đ ểtìm các phần mềm như vậy, nhưng sử dụng các máy tìm kiếm ph ổ bi ến có th ể là đáng giá, cũng nh ưviệc tìm kiếm trong Intellipedia và DTIC.Nếu bạn có phần mềm đã được phát triển trước đó rồi như một ph ần c ủa m ột h ợp đ ồng c ủa chínhphủ, thì hãy xác định liệu bạn có các quyền trí tuệ đủ để đưa ra hoặc chuy ển ph ần m ềm đó thànhnhư một dự án ODT được không. Đối với sự phát triển và duy trì như một d ự án OTD, thì ph ầnmềm đó (như Hình 1.1) cần phải được tung ra như một OGOTS hoặc ưu tiên hơn như một d ự ánPMNM công khai được cộng đồng duy trì. Phụ lục B làm sáng tỏ sự hợp pháp của việc đ ưa raGOTS như là PMNM, phụ thuộc vào các nhà chức trách được viện tới trong hợp đồng ban đầu.Nhiều chương trình của chính phủ có công nghệ hiện hành mà ban đầu được cấp vốn từ chính phủ.Nếu các quyền trí tuệ đối với các công nghệ đó là không phù hợp hoặc không th ể xác đ ịnh đ ược, thìchính phủ nên xem xét thương thảo với các nhà tích hợp/các nhà cung cấp phù hợp để đưa ra mãnguồn theo các quyền dữ liệu ít hạn chế hơn đối với một dự án OGOTS hoặc PMNM. Một cách dễdàng để làm điều này là cấp vốn một cách đơn giản cho quá trình chuyển đổi đối với (các) nhà thầu.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 14/77
  15. 15. 2011 - Các bài học học được về công nghệ mở2.1.2 Bước 2: Xác định dự án để thiết lậpĐưa ra các lựa chọn sử dụng lại, xác định những dự án mới nào là cần thiết và những dự án đang tồntại nào cần phải được chuyển dịch sang OTD. Trong một số trường hợp, “dự án” mới có thể là mộtdự án để mở rộng một số dự án đang tồn tại và để sự mở r ộng đó đ ược tích h ợp vào trong d ự án banđầu. Ở những nơi có thể, hãy tách dự án đó thành vài dự án nhỏ h ơn v ới các giao di ện rõ ràng.Những dự án nhỏ hơn này có thể được phân chia theo một loạt các tiêu chí, bao gồm có thể việc sửdụng lại (để tối đa hóa số lượng những người tham gia trong ít nh ất m ột vài d ự án) và s ự c ần thi ếtphải hạn chế sự truy cập (các module bí mật hoặc được kiểm soát xu ất kh ẩu có th ể c ần đ ược táchbiệt khỏi các thành phần khác, nghĩa là, bằng việc tạo ra một “khung” không bí mật trong đó “cáctrình cài cắm” được kiểm soát có thể được đặt ra).Đặt tên cho từng dự án sao cho không dễ bị nhầm lẫn với các dự án khác. Nó nên là có thể nêu tênđược và dễ tìm trên một máy tìm kiếm web (lý tưởng thì, nó có th ể ch ỉ là k ết qu ả t ừ m ột s ự tìmkiếm; chắc chắn tránh các tên không thể tìm được như “the” hoặc “why”).Mỗi dự án (bao gồm bất kỳ dự án hiện đang tồn t ại nào chuy ển đ ổi sang OTD) c ần m ột tuyên b ố v ềdự định mà nó tham chiếu tới triết lý duy trì phần mềm OTD. Như được khuyến cáo trong[Fogel2009] “tuyên bố nhiệm vụ nên cụ thể, giới hạn, và trên tất cả, ng ắn g ọn”. Tuyên b ố nhi ệm v ụnên làm rõ mục tiêu để sử dụng các nguyên tắc phát triển mở (như tránh s ự khóa trói vào m ột nhàcung cấp duy nhất) và những gì mà các sản phẩm kết quả nên làm. Đây là m ột ví d ụ v ề m ột ph ầnmềm tốt, từ http://www.openoffice.org: Để tạo ra, như một cộng đồng, bộ phần mềm văn phòng quốc tế hàng đầu sẽ chạy trên tất cả các nền tảng và đưa ra sự truy cập tới tất cả chức năng và dữ liệu thông qua các giao diện lập trình ứng dụng API dựa trên các thành phần mở và định dạng tệp dựa trên XML.Trong một dự án của DoD, tuyên bố về triết lý duy trì ph ần m ềm có th ể tham chi ếu t ới DFARS227.7203-2 (“Mua sắm phần mềm máy tính và tài liệu phần mềm máy tính phi thương mại”), và đặcbiệt văn bản tại DFARS 227.7203-2(b)(1) (đậm và gạch chân được bổ sung vào): Những người quản lý dữ liệu hoặc các nhân viên của các yêu cầu khác có tránh nhiệm xác định các nhu cầu tối thiểu của Chính phủ. Bổ sung thêm vào với sự thực thi, tính tương thích, hoặc các xem xét kỹ thuật khác của phần mềm như mong đợi, cần có những xác định nên xem xét những yếu tố như nhiều site hoặc các yêu cầu sử dụng được chia sẻ, liệu triết lý duy trì phần mềm của Chính phủ có đòi hỏi quyền để sửa đổi hoặc các bên thứ 3 sửa đổi phần mềm hay không, và bất kỳ yêu cầu tài liệu phần mềm máy tính đặc biệt nào.Hãy xác định, đối với từng dự án, liệu nó có phải bị hạn chế ch ỉ có s ự truy c ập c ủa DoD ho ặc chínhphủ nói chung như một dự án OGOTS hay không. Mặc định, các dự án nên tr ở thành COTS OSS(COTS PMNM) thay vì OGOTS. Trong một số trường hợp (nh ư, vì tính bí m ật ho ặc ki ểm soát xu ấtkhẩu) một dự án phải bị hạn chế đối với sự truy cập mà DoD hoặc chính phủ Mỹ qui định. Các d ựán GOTS thể hiện một rủi ro cao hơn so với các dự án COTS, vì theo đ ịnh nghĩa s ẽ có ít h ơn nh ữngngười đóng góp tiềm năng (giảm sự cạnh tranh và gia tăng chi phí một cách tiềm tàng), và các nhàthầu (khác so với những người nắm giữ bản quyền của chúng) sẽ không được khích lệ đối với vi ệcsử dụng các dự án GOTS vì chúng không thể sử dụng lại những thành phần hoặc tri thức về chúngtheo các cách thức khác có thể sống sót được một cách thương mại. Trong nhiều trường h ợp có kh ảnăng chia dự án thành 2 dự án, một là PMNM (như một “khung công việc”) và một là OGOTS (nh ưmột “trình cài cắm” vào khung công việc). Phương pháp này đã được sử d ụng thành công trong lĩnhvực ảnh và bản đồ khi mà Văn phòng Trinh sát Quốc gia đã đỡ đầu cho sự phát triển của khungcông việc Hình ảnh và Bản đồ Nguồn Mở OSSIM (Open Source Imagery and Mapping). KhungVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 15/77
  16. 16. 2011 - Các bài học học được về công nghệ mởcông việc này được các lập trình viên khu vực tư nhân phân tán và duy trì một cách r ộng rãi, trongkhi các trình cài cắm bí mật được phát triển trong các mạng an ninh của DoD và đ ược h ạn ch ế đ ốivới các môi trường đó.2.1.3 Bước 3: Chọn và áp dụng một giấy phép chungMỗi dự án phải có một giấy phép rõ ràng và đơn giản xúc tác cho s ự cộng tác h ợp pháp. M ột gi ấyphép đưa ra các quyền và trách nhiệm của các lập trình viên và những người sử dụng phần mềm.Nếu dự án là một dự án PMNM, phải chắc chắn chọn một giấy phép đã có từ trước và nổi ti ếng,một giấy phép đã được xác thực một cách rộng rãi như là PMNM. Nó nên là t ương thích v ới GPL,vì GPL là giấy phép PMNM phổ biến nhất. Nếu phần m ềm đã có tr ước đó r ồi, thì th ường là khônngoan để đưa vào giấy phép trước đó của nó như một trong các lựa chọn. Xem Ph ụ l ục D đ ể cóthêm thông tin về cách chọn một giấy phép PMNM.2.1.4 Bước 4: Thiết lập sự điều hànhCác dự án sử dụng OTD cần phải được điều hành. Quá trình điều hành đối với mỗi dự án c ần ph ảikhuyến khích sự phát triển cộng tác, nhưng nó cũng phải cho phép từ chối các đóng góp ở nh ữngnơi được đảm bảo. Quá trình điều hành OTD phải xúc tác cho nhiều tổ chức làm vi ệc v ới nhau đ ểcải thiện từng thành phần đang trải qua sự phát triển được chia sẻ (bao gồm các ph ần m ềm, cáckiểm thử, và tài liệu của nó), thay vì phát triển lại các thành phần độc lập riêng rẽ với chức năngtương tự. Trước khi thảo luận về các mô hình điều hành khác nhau, đi ều quan tr ọng đ ể l ưu ý là tínhcó thể rẽ nhánh là cần thiết, như được mô tả tiếp sau.2.1.4.1 Tính có thể rẽ nhánhMột rẽ nhánh là một dự án cạnh tranh được thiết lập có sử dụng một bản sao của một ph ần m ềmcủa dự án đang tồn tại.Là cần thiết sống còn rằng một dự án OTD có thể rẽ nhánh được. Đó là, nó phải có khả năng tạo rađược một dự án cạnh tranh có thể sống được có sử dụng một bản sao của mã nguồn phần mềm củadự án đang tồn tại. Việc tạo ra một rẽ nhánh là tương tự một lời gọi đối với một s ự “ bỏ phiếu bất tínnhiệm” trong quốc hội. Người tạo ra rẽ nhánh về cơ bản yêu cầu các lập trình viên và những ngườisử dụng dừng hỗ trợ dự án ban đầu, và thay vào đó hỗ trợ dự án mới được rẽ nhánh (việc hỗ trợ cả 2dự án thường là phi thực tế qua thời gian).Các rẽ nhánh cũng có thể xảy ra vì cộng đồng đang tồn tại không lên k ế ho ạch đ ưa vào m ột ph ầntập hợp các tính năng của cộng đồng được cho là quan trọng, các lý do có thể là: hỗ trợ cho một h ệđiều hành hoặc phần mềm trung gian khác hoặc đưa vào một ngôn ngữ lập trình mới. Bất kể là lý donào, mỗi nỗ lực nên được thực hiện để giữ cho các dự án rẽ nhánh b ằng cách nào đó đ ược đi ều ph ốimột cách tốt nhất có thể.Tính có thể rẽ nhánh được là một phần cần thiết của sự điều hành OTD. Ngay khi m ột d ự án r ẽnhánh, thì lãnh đạo dự án sẽ đấu tranh để có trách nhiệm đối với những người s ử d ụng và các l ậptrình viên. Điều này là vì nếu các quyết định của lãnh đạo là đ ặc bi ệt xu ất s ắc, thì m ột d ự án r ẽnhánh có thể được bắt đầu theo sự quản lý có trách nhiệm hơn. Tính có th ể r ẽ nhánh đ ược m ột cáchdễ dàng thực sự làm giảm rủi ro của một rẽ nhánh, vì lãnh đ ạo s ẽ b ị ép ph ải nghe theo nh ững ng ườisử dụng và các lập trình viên (vì nếu họ không nghe, thì một rẽ nhánh có th ể s ống đ ược s ẽ n ổi lên).Hơn nữa, tính có thể rẽ nhánh được một cách dễ dàng làm gia tăng s ự h ợp lý c ủa các đóng góp; tínhVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 16/77
  17. 17. 2011 - Các bài học học được về công nghệ mởcó thể rẽ nhánh một cách dễ dàng đưa ra sự bảo vệ đáng kể đối với những người đóng góp có thể, vìnếu họ sau này không đồng ý với sự điều hành của dự án, thì họ có thể tạo ra một rẽ nhánh.Nói như vậy, tránh tạo ra các rẽ nhánh ở bất kỳ đâu có thể. Hầu hết những ý định rẽ nhánh đều th ấtbại, vì tình huống phải là đặc biệt tồi tệ đối với nhiều lập trình viên và ng ười sử d ụng đ ể dò tìm đ ốivới rẽ nhánh mới. Ai đó định tạo một rẽ nhánh và không thiết lập được rẽ nhánh đó như một d ự áncó thể sống được thì sẽ thường kết thúc việc duy trì dự án của riêng họ ở chi phí khổng lồ. Côngviệc thông thường trong cả 2 dự án thường để dừng một khoảng thời gian, khi những thảo luận t ậptrung vào việc liệu sự rẽ nhánh có được chứng minh hay không.Để có thêm thông tin về việc rẽ nhánh, xem [Forgel2009] các chương 4 và 8.2.1.4.2 Các mô hình điều hànhCác dự án cần một số quá trình điều hành. Hai tiếp cận chung là: • Người độc tài rộng lượng BD (Benevolent dictator). Trong trường h ợp này, có m ột ng ười chịu trách nhiệm về các quyết định cuối cùng. BD có thể ủy quyền các quyết đ ịnh cho những người khác (trong khi giữ lại một quyền phủ quyết), nhưng cuối cùng, một ng ười duy nhất có trách nhiệm. Điều này đặc biệt phổ biến trong các dự án nhỏ hơn nơi mà một người (thường là người khởi xướng) hiểu được dự án tốt nhất, nhưng thậm chí nó đ ược m ột s ố d ự án PMNM lớn sử dụng (như nhân Linux). • Nhóm ra quyết định. Trong trường hợp này, một nhóm ra quyết định cu ối cùng. Đi ều này có thể thông qua một đa số đơn giản, hoặc thông qua một số cơ chế khác. Một số dự án cho phép các thành viên của nhóm cũng đưa ra một phủ quyết. Thường thì nhóm này không phải là tập hợp của tất cả những người đóng góp, mà là một s ố tập h ợp con, và nhóm này ph ải đồng ý đối với việc đưa thêm vào một thành viên mới. Một quá trình chung đ ể ti ến hành là từ Quỹ Phần mềm Apache. Trong hệ thống này thì một “+1” có nghĩa là chấp nhận, một “-1” có nghĩa là phản đối, và mặc định một đề xuất có thể chỉ thông qua được nếu nó nhận được tổng số ít nhất +3 mà không có phủ quyết nào. Trong một s ố tr ường h ợp Apache cho phép “sự đồng thuận lười biếng” (còn gọi là “im lặng tức là đồng ý”, trong đó m ột đ ề xu ất đ ược chấp thuận trừ phi ai đó phủ quyết (phản đối) trong một khoảng thời gian. Trong bất kỳ quá trình nào như vậy sẽ có một sự rủi ro rằng các phủ quyết s ẽ bị l ạm d ụng quá m ức; tính t ới điều này, Apache yêu cầu tất cả các phủ quyết đưa ra một sự chứng minh n ếu không thì chúng là không hợp lệ [Apache2010]. Nhiều chuyên gia viện lý rằng việc biểu quyết nên là một phương sách cuối cùng (như [Collins2007] và [Fogel2009], và rằng bạn nên cố gắng có được một sự đồng thuận sơ bộ mà không có một phiếu chính thức nào ở bất kỳ đâu có thể.Một vấn đề chính là số lượng người thực sự hiểu được các chi ti ết k ỹ thu ật c ủa d ự án. N ếu m ộtngười hiểu rõ nó tốt hơn những người khác (điều thường đúng ở lúc b ắt đ ầu c ủa d ự án), thì mô hìnhBD nên được khuyến cáo. Nếu nhiều người hiểu dự án tốt như nhau, mà th ường là tr ường h ợp đ ốivới các dự án lớn, thì quá trình ra quyết định của nhóm nên được khuyến cáo.Bất chấp mô hình điều hành, (những) người ra quyết định phải tránh thực hiện một quyết định giữacác lựa chọn thay thế quá sớm. Nếu có một sự không đồng ý, thì có th ể là m ột ti ếp c ận th ỏa hi ệphoặc lựa chọn thay thế mà có thể là tốt hơn so với các lựa ch ọn rõ ngay t ức thì. Vì th ế, nh ững ng ườira quyết định nên cố gắng để các bên thấy được những thỏa hiệp và những lựa chọn thay thế đó. Tuynhiên, nếu một sự thỏa hiệp hợp lý không thể tìm kiếm được và một quy ết đ ịnh ph ải đ ược đ ưa ra,thì (những) người ra quyết định nên đưa ra quyết định sau khi nghe tất c ả các bên. Quy ết đ ịnh đónên được công bố một cách rõ ràng, cùng với sự hợp lý. (Những) người ra quyết định cũng phải cóVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 17/77
  18. 18. 2011 - Các bài học học được về công nghệ mởthiện chí thay đổi một quyết định khi thông tin mới, các lựa chọn mới, hoặc một thay đổi theo hoàncảnh quan trọng được đưa ra.Dự án nên được quản lý và cấu trúc để luôn tiến hóa và có cơ hội. Việc g ắn vào các tiêu chu ẩn vàgiao diện mở sẽ đưa ra được tính mềm dẻo đối với chương trình để nhanh chóng thích nghi các gi ảipháp mới khi chúng xuất hiện.Như được lưu ý trong phần 2.1.4.1, một điều chủ chốt đối với bất kỳ tiếp cận điều hành nào là việcdự án phải có khả năng rẽ nhánh. Bất kỳ mô hình điều hành nào cuối cùng cũng có th ể th ất b ại n ếunhững người ra quyết định không có nhu cầu trả lời cho những người khác. Nếu d ự án là có th ể r ẽnhánh được, thì rồi lãnh đạo (bất chấp mô hình điều hành) cuối cùng cũng phải tôn trọng những nhucầu của người sử dụng và các lập trình viên.Nhiều thông tin hơn có thể thấy trong [Fogel2009] chương 4 và [Bacon2010] chương 8.2.1.5 Bước 5: Thiết lập sự cộng tácViệc thiết lập sự cộng tác không y hệt như việc tạo ra một chiến lược truy ền thông m ột chi ều. C ộngtác liên quan tới sự trao đổi các ý tưởng một cách dễ dàng giữa nhiều đối tượng (bao g ồm gi ới côngnghiệp, giới hàn lâm và các văn phòng và phòng thí nghiệm của các cơ quan chính phủ khác) để sảnxuất ra một kết quả tốt hơn mà bất kỳ một trong số các đối tượng trên có th ể đ ạt đ ược m ột cáchriêng rẽ. Phần 2.2 thảo luận xa hơn cách để thiết lập hạ tầng kỹ thuật cần thiết để xúc tác cho sựcộng tác; phần 2.3 thảo luận khía cạnh xã hội của sự giao tiếp.Khi mở ra một dự án nguồn đóng có từ trước, sẽ là nhạy cảm về thái đ ộ đ ối v ới s ự thay đ ổi. Hãychắc chắn rằng tất cả các lập trình viên hiện đang tồn tại hiểu được r ằng m ột s ự thay đ ổi l ớn đangtới. Hãy giải thích, hãy nói cho họ rằng sự bất tiện ban đầu là hoàn toàn bình thường, và cam đoanvới họ rằng mọi việc sẽ là tốt hơn. Hãy tính tới những nh ầm l ẫn trong nh ững th ảo lu ận riêng gi ữacác lập trình viên lâu năm, và khuyến khích sự chuyển đổi của họ sang các nhóm thảo luận cộngđồng như các danh sách thư [Fogel2009].Vì một số người sẽ vật lộn với tính mở của một dự án OTD, điều quan trọng ph ải nh ấn m ạnh t ớinhu cầu về tính mở. Hãy đưa ra chỉ dẫn như những chỉ dẫn quản trị hiện hành và b ắt bu ộc v ề tínhminh bạch, và trong bản ghi nhớ năm 2009 của DoD về PMNM bắt buộc rằng phần mềm phải đượcđối xử như các dữ liệu và được chia sẻ một cách phù hợp. Trích từ bản ghi nhớ năm 2009: f. Mã nguồn của phần mềm và các tài liệu thiết kế có liên quan là “các dữ liệu” như theo Chỉ thị của DoD số 8320.02 (reference (h)), và vì thế sẽ được chia sẻ khắp DoD m ột cách r ộng rãi nhất có thể để hỗ trợ cho các nhu cầu nhiệm vụ.Có những cuộc thảo luận phải được giữ đóng đối với công chúng, như lựa chọn nguồn các công tyvà các dữ liệu sở hữu độc quyền của các công ty. Nhưng mỗi dự định nên được thực hiện để mở raquá trình phát triển phần mềm càng nhiều càng tốt. Để đơn giản hóa sự điều hành, phương phápđược ưu tiên cũng nên đòi hỏi các nhà thầu và các nhà tích h ợp ph ần m ềm t ổ ch ức các d ự án c ủa h ọsao cho chúng sẽ tiếp tục là minh bạch và mở cho chính phủ cho sự kiểm tra được từ xa.2.1.6 Bước 6: Tạo ra đường lối kỹ thuật của dự ánĐối với từng dự án, hãy xác định các vấn đề kỹ thuật chủ chốt, như những thành phần chủ chốt nàosẽ được sử dụng lại, những thành phần nào mà hệ thống phải tương tác v ới chúng, cách mà nó s ẽđược triển khai (như ngôn ngữ triển khai để sử dụng là gì), trên những nền tảng nào nó phải làmVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 18/77
  19. 19. 2011 - Các bài học học được về công nghệ mởviệc được, và các chỉ dẫn cơ bản cho các lập trình viên. M ỗi d ự án nên nh ấn m ạnh t ới tính có th ểmodule hóa được. Một hệ thống theo module là một hệ thống được xây d ựng t ừ các d ự án t ương tácnhỏ hơn mà chúng có thể được phát triển song song và được thay thế một các đ ộc l ập riêng r ẽ màkhông ảnh hưởng tới các thành phần khác.Tính có thể module hóa được là mấu chốt và làm đơn giản hóa việc s ử d ụng l ại sở h ữu trí tu ệ (IP)của công nghệ và phần mềm, làm giảm nhẹ và tách bạch các vấn đề bí mật và kiểm soát xu ất kh ẩu,làm đơn giản hóa sự quản lý, tăng tốc độ cho sự tri ển khai, làm gi ảm chi phí duy trì, và làm tăngtính lanh lẹ. Một tham chiếu quân sự về tính có thể module hóa có th ể th ấy ở đây:http://www.acq.osd.mil/osjtf/docsmemo.html. Các bằng sáng chế về thiết kế và các bằng sáng chếvề kiến trúc nổi tiếng có thể được sử dụng để chia các vấn đề thành các thành ph ần nh ỏ h ơn[Martin2000].Phần 2.4 thảo luận xa hơn về quản lý kỹ thuật và các tiêu chí kỹ thuật.2.1.7 Bước 7: Công bốKhi một dự án được thành lập và được trình bày (dù chưa tuyệt vời), hoặc một s ự kiện đáng k ể nh ưtung ra một cách chính thức xảy ra, hãy nói cho những người khác xem ai có thể sẽ muốn biết.Nếu bạn biết các danh sách thư nơi mà một tuyên bố về dự án của bạn có thể là chủ đề quan tâm, thìhãy đưa lên đó, nhưng hãy cẩn thận để làm một bài viết chính xác cho m ỗi di ễn đàn, và đ ể h ướngmọi người vào các diễn đàn riêng của dự án của bạn cho những thảo luận sau đó. Nếu có các dự áncó liên quan (như những dự án có thể sử dụng nó hoặc va chạm với nó), thì phải chắc chắn cung cấpcho họ thông tin, và mời họ đưa lên các đường liên kết web t ới website c ủa d ự án c ủa b ạn. Nhi ềungười phát triển các trang web với các danh sách hoặc những rà soát lại của các dạng phần mềmnhư vậy; hãy cung cấp thông tin cho họ sao cho họ có thể c ải thiện đ ược các trang web c ủa h ọ. Hãyđưa lên một cập nhật trên Intellipedia và DoD Techipedia (Điều này là đặc biệt quan trọng cho cácdự án OGOTS, vì có thể là khó để tìm thấy chúng nếu chúng không được bi ết công khai). N ếu đâylà một dự án PMNM công khai, thì hãy đưa ra những công bố như vậy lên http://freshmeat.net/.2.1.8 Tiếp tục rà soát lại các bước từ 1-7Các bước 1-6 nên là sự khởi đầu của một quá trình liên tục n ơi mà các d ự án luôn đ ược luân chuy ểnthông qua tìm kiếm các thành phần mới, phát triển cộng đồng, làm chín muồi các công nghệ và tìmkiếm để mở rộng phạm vi về kích thước, sự nâng cao và sự chín mu ồi c ủa c ộng đ ồng. Qua th ời giancộng đồng sẽ phát triển, vì thế việc đưa vào những người và ý tưởng mới và dẫn dắt tới một sự giatăng trong khả năng và sự cạnh tranh cho các hợp đồng của chính phủ.2.2 Hạ tầng kỹ thuật cho sự cộng tácVì sự cộng tác giữa những người tham gia phân tán một cách r ộng rãi là chìa khóa cho OTD, nêncác dự án phải thiết lập được một site của dự án với hạ tầng k ỹ thu ật c ần thi ết cho s ự c ộng tác. Sitecủa dự án phải xúc tác cho sự phát triển phần mềm, các bộ kiểm thử, và tài liệu (bao gồm cả ngườisử dụng, cài đặt, quản trị, và tài liệu thiết kế) được chia sẻ, dù các chi tiết về cách mà những thứ nàyxảy ra thường khác nhau giữa các dự án. Các chỉ dẫn hữu ích cho việc thiết lập hạ tầng kỹ thuật cóthể thấy trong [Fogel2009] chương 3; sau đây là một ít những điểm mấu chốt. Trong ngôn ngữ hợpđồng của DoD thì hạ tầng kỹ thuật này là tập hợp của “các kho d ữ li ệu” (xem DFARS 227.7108),nhưng sự cần thiết cho việc cộng tác có nghĩa là những kho này ph ải tri ển khai các yêu c ầu b ổ sungVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 19/77
  20. 20. 2011 - Các bài học học được về công nghệ mởkhông phải luôn được các hợp đồng bắt buộc.Phải có khả năng cho tất cả những người đóng góp và những ng ười s ử d ụng ti ềm năng s ử d ụngđược các công cụ một cách dễ dàng. Ví dụ, nếu những hạn chế về an ninh làm quá khó cho m ọingười để tham gia, thì họ sẽ không tham gia. Các dự án nên ưu tiên s ử d ụng các công c ụ c ộng tácđược sử dụng một cách rộng rãi của PMNM mà chúng làm vi ệc tốt đ ược v ới b ất kỳ trình duy ệt webnào tuân thủ các chuẩn. Các công cụ không thông dụng tạo ra một rào cản không cần thiết để thamgia vào, vì chúng đòi hỏi những người sử dụng phải học cách sử dụng các công cụ mới thay vì vi ệcđóng góp một cách đơn giản. (Thậm chí nếu những người s ử dụng đã h ọc đ ược cách s ử d ụng m ộtcông cụ, thì những người sử dụng sẽ có thiện chí nhiều hơn nếu công cụ được sử dụng một cáchrộng rãi vì thời gian học của họ được giảm dần). Các công cụ PMNM nên đ ược ưu tiên m ột cáchmạnh mẽ; chúng có thể được thiết lập cấu hình cho những nhu cầu đặc biệt, có xu hướng sẽ làkhông đắt giá để triển khai, và có xu hướng sẽ đặc biệt tốt cho s ự c ộng tác d ạng OTD vì chúngthường được sử dụng cho mục đích đó. Tối đa hóa sự truy cập thông qua các trình duy ệt web tuânthủ các tiêu chuẩn sẽ là gia tăng khả năng cho những người khác để tương tác v ới s ản ph ẩm, nh ư,họ có thể tương tác từ chiến trường.Các nhà thầu phải mong đợi rằng hạ tầng kỹ thuật này có nghĩa rằng chính phủ và các nhà th ầukhác sẽ luôn có sự truy cập ngay lập tức tới sự tiến bộ. Sự minh bạch này là mặc định từ thiết kế.2.2.1 Các chức năng mấu chốtSite trung tâm của dự án phải hỗ trợ sự cộng tác đối với những c ải tiến đang di ễn ra và nên cungcấp các chức năng sau: • Cửa chính (website). Site trung tâm của dự án phải đưa ra được điểm khởi đầu duy nhất cho những ai có quan tâm về dự án, xúc tác mọi người học về dự án và tìm th ấy tất cả các thông tin có liên quan (đặc biệt, cách để có được nó và/hoặc trở thành một phần của cộng đồng phát triển nó). Thường là một website với một URL cố định đơn giản. • Theo dõi lỗi và tính năng. Site trung tâm của dự án phải đưa ra một cơ chế cho những người sủ dụng để đưa lên các báo cáo lỗi và các yêu cầu về tính năng, và đối với các lập trình viên để xác định cách (hoặc nếu có) để giải quyết chúng. Điều này thường đ ược tri ển khai thông qua các công cụ đặc thù như Bugzilla, Trac, hoặc Redmine, nhưng các công cụ khác (nh ư wikis) cũng có thể được sử dụng. Có thể cần phải có một qui trình đặc biệt cho việc báo cáo những chỗ bị tổn thương về an ninh để ngăn chặn sự để lộ ra chúng trước khi việc sửa chúng là sẵn sàng. • Quản lý Cấu hình Phần mềm (SCM). Site trung tâm của dự án phải đưa ra một cơ chế cho việc theo dõi những thay đổi, bao gồm ít nhất phần mềm và thường cả các b ộ kiểm th ử và một số tài liệu. Nó nên ít nhất là đưa ra một phương pháp cho vi ệc xem xét và theo dõi “nhánh phát triển chính” và mỗi phiên bản chính. SCM phải làm cho có khả năng đ ể th ấy được ai đã tiến hành với từng thay đổi, khi nào, và sự thay đổi đó là gì. Không sử dụng CVS trong các dự án mới; CVS từng là phổ biến trong quá khứ nhưng đã được thay th ế b ằng các công cụ tốt hơn. Có 2 dạng hệ thống SCM chính, SCM tập trung (nh ư Subversion hay SVN) và SCM phân tán (như git và mercurial). Như được th ảo luận bên d ưới, trong m ột môi trường quân sự thì các hệ thống SCM phân tán (như git) có những ưu điểm đáng kể và nên là SCM được ưu tiên cho các dự án OTD. • Tương tác cộng đồng (danh sách thư, wiki, và/hoặc IRC) . Site trung tâm của dự án phải đưaVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 20/77
  21. 21. 2011 - Các bài học học được về công nghệ mở ra một cơ chế cho những người sử dụng và các lập trình viên để thảo luận các vấn đề. Sự tương tác cộng đồng thường được triển khai thông qua các danh sách thư (như Mailman), wikis, hoặc các hệ thống chat như Internet Relay Chat (IRC). Nhiều dự án s ử d ụng các danh sách thư cho các thảo luận để sử dụng sau này, và trao cho mọi ng ười th ời gian đ ể t ạo ra các câu trả lời cẩn trọng. Trong ngữ cảnh quân sự thì các danh sách thư và wikis có xu hướng s ẽ là dễ dàng sử dụng hơn, vì cả 2 chúng đều đã được triển khai một cách rộng rãi rồi trong các máy tính quân sự. Nếu sử dụng các hệ thống chat, thì hãy chắc chắn phải đạt được các thảo luận theo cách là những người tham gia sau này có thể tìm thấy chúng, nếu không các th ảo luận quan trọng sẽ bị mất. Hơn nữa, hãy chắc chắn rằng hệ thống chat hỗ trợ cho bất kỳ yêu cầu an ninh cần thiết nào (như xác thực và bảo mật). • Tải về các phiên bản. Site trung tâm của dự án phải đưa ra được một cơ chế cho việc tải về các phiên bản chính; nếu chúng là lớn, thì việc có các site soi gương (mirroring) có thể là cần thiết.Wikis (như MediaWiki, MoinMoin, PmWiki, và PhpWiki) là các chương trình mềm d ẻo và có th ểđược sử dụng để làm thỏa mãn một vài trong số các chức năng này.2.2.2 Truy cập, công khai, bí mật và kiểm soát xuất khẩuỞ những nơi có thể, hãy xác định các thành phần nào có thể được đưa ra cho công chúng như làPMNM ngay từ trước, và thiết lập dự án bên ngoài trong công chúng ngay từ đầu. Điều này s ẽ h ạnchế nhiều vấn đề, khi điều này làm cho dễ dàng đối với những người khác đ ể tìm ki ếm và đóng gópcho dự án, và làm gia tăng mạnh số lượng những người đóng góp tiềm năng. Đi ều này cũng xúc táccho việc sử dụng các dịch vụ hosting thương mại sẵn có (xem phần 2.2.3). Không có yêu cầu pháplý nào chờ cho tới khi dự án là “hoàn tất về tính năng” trước khi phiên bản này xảy ra, và nếu điềuđó cũng sẽ là công khai nốt, thì càng sớm đưa nó ra công khai bao nhiêu thì càng tốt bấy nhiêu.Một số thành phần là bí mật, và vì thế sự phát triển của chúng chỉ có thể diễn ra trong các h ệ th ốngđược ủy quyền cho việc xử lý bí mật. Tương tự, một số thành phần s ẽ là d ưới sự ki ểm soát xu ấtkhẩu theo ITAR hoặc EAR. Ở những nơi có thể, hãy chia các thành phần dựa trên tính nhạy cảmcủa chúng để hạn chế những gì là bí mật và kiểm soát xuất khẩu phải được bảo vệ. Trong nhữngtrường hợp này, việc thiết lập một dự án OGOTS cho phép sự cộng tác gi ữa nh ững ng ười có th ẩmquyền được truy cập tới dự án. Những dự án như vậy phải làm việc một cách đặc biệt khó đ ể đ ảmbảo rằng những người sử dụng và những người đóng góp tiềm năng biết về sự hiện diện của chúng.Trong nhiều trường hợp sự phát triển phần mềm sẽ có được mong đợi sẽ là sẵn sàng cho công chúngnhư là PMNM, nhưng phải thực hiện trước hết sự rà soát về bí mật và/ho ặc kiểm soát xuất khẩu.Điều này có thể là một rào cản đáng kể cho sự cộng tác, nhưng trong nhiều tr ường h ợp nó là b ướccần thiết. Hãy xem xét việc thiết lập một dự án OGOTS nội bộ để “dựng” nh ững thay đ ổi đ ược đ ềxuất này cho tới khi chúng có thể được tung ra như một dự án PMNM. Việc dàn d ựng là đ ặc bi ệtquan trọng nếu nó được xác định rằng một số thay đổi là cần thiết cho sử dụng của chính phủ vàkhông thể được tung ra cho công chúng. Những đề xuất như vậy, lý tưởng mà nói, nên được thiết lậpnhư “những nhánh“ riêng rẽ sao cho thậm chí nếu một số thay đổi được cho là s ẽ không th ể đ ượctung ra, thì những thay đổi khác vẫn còn có thể tung ra được một cách độc lập.Các dự án nên xem xét một cách nghiêm túc việc sử dụng một SCM phân tán (nh ư “git”) n ơi mà cóthể sẽ có các vấn đề về kiểm soát xuất khẩu hoặc các mức độ khác nhau về bí mật. Các h ệ th ốngSCM phân tán làm cho dễ dàng hơn nhiều để tạo ra các nhánh riêng rẽ bên ngoài và sau này cungcấp chúng cho những người khác cho việc trộn nếu sự phê chuẩn được trao.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 21/77

×