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

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/2011
Bả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)

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ác
phẩ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ày
theo 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ông
tin, 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 (Software
Tech 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.0
Dịch sang tiếng Việt: Lê Trung Nghĩa, letrungnghia.foss@gmail.com; Dịch xong: 31/05/2011
Bả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 the
work), under the condition of attribution (you must attribute the work in the manner specified by the
author 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.0

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 2/77


Thừa nhận
Sự 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ích
hợ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ên
cứu Chéo AT&L và Heather Burke của Trung tâm các Hệ thống SPAWAR Đại Tây dương (SSC
LANT) 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 đ ầu
vào, trợ giúp và chỉ dẫn: John Weathersby, Kane McLean, Gunnar Hellekson, Josh Davis, Deb
Bryant, 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 đồng
Chứ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ày
Chức danh: Điều hành Giám sát, OASD Research & Engineering, Rapid Field Directorate
Người phê chuẩn: ________________________________________________
Tên: Dan Risacher, Chính phủ Mỹ ngày
Chứ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ích
hợp & các Dịch vụ Doanh nghiệp



Mục lục
Chươ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...................................................................................................................13
Chươ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ệ.................................................................................................29
Chươ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)...................................................................................................33



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....................................................................................................39
Chươ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...............................................................................42
Phụ 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ở) ...........................................54
Phụ 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
............................................................................................................................................................55
Phụ 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.......................................................................69
Phụ 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.........................................................................................72
Các tham chiếu...................................................................................................................................75
Bảng chú giải.....................................................................................................................................77



Chương 1. Giới thiệu
Mụ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át
triể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 trong
quố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 trong
cá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 ộng
tá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 ập
trung 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 ương
trì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êu
cầ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 ển
hiệ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 ự tin
cậ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ân
theo 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 ềm
mà 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 đúng
lú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 mua
sắ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 ần
mề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 đ ại
hoạ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.



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 ần
mề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ủa
cá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ày
vớ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ức
củ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ới
nhà 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ảm
cá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 ần
mề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 ền
cô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 ới
sá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ảng
cơ 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à, quan
trọ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.



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ạng
thá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 ằng
bằ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.



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 ững
lậ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 ềm
hoặ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ện
mở, 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 ẩn
và 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 ết
kế 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 ệc
gắ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 được
sử 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 đ ược
củ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 truy
cậ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 ập
tớ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ối
xú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 ềm
hiệ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 ập
trì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 quan
trọ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 ữa
PMNM 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ên
trong 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 ực
tư 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 đội
cá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.



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 ộng
tá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ều
mụ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 đ ơn
nhấ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 ống
củ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 ều
khoả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ông
trong 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ép
cho 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ềm
thươ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ì OTS
khác nhau này.

Hình 1. Các chiến lược duy trì OTS
Có 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 ường
hợ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ận
hay 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 ất
phá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 ều
chươ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ững
thay đổ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 đ ối
vớ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 ẽ



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ẩm
GOTS 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 ích
cho 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 ủa
nhiề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 “PMNM
củ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 GOTS
mà 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át
triể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 ển
sang 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ì sao
chí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 ới
phầ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, ưu
thế 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àng
cho 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 ơ quan
khá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ính
phủ 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 ếp
tụ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ăm
cao 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 ủi
ro đá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 OTD

1.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 ủa
khung 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ệ được
giữ 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ác
luậ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ệt



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ạm
tớ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ông
xung độ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ài
xin 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ính
phủ 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 ững
ngườ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 cung
cấ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ần
mề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ác
quyề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 ột
rà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 ều
nă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 ụ



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ôn
với chính sách và đường lối của DoD.

1.4.2 Tính đơn giản
Sự 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ác
giấ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 truy
cập nó, và rằng những thiết kế kỹ thuật là các module rõ ràng.



Chương 2. Điều hành các dự án OTD
Chươ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 ần
tiế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ác
tiê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 qui
trì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 OTD
Mộ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 ảnh
củ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 ếm
web đơ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ăng
mong 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ác
kho 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 ụng
mộ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ặc
hữ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 PMNM
có 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ăng
qua 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ể nhanh
chó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 ới
mụ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ính
phủ, 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ành
như 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 ần
mề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 ự án
PMNM 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 ra
GOTS 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.



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ồn
tạ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ột
dự á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 ết
phả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ách
biệ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ác
trì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ìm
kiế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 ần
mề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 DFARS
227.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à đặc
biệ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ính
phủ 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 ất
khẩ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 ững
ngườ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 ệc
sử 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úng
theo 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ĩnh
vự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 khung
công việc Hình ảnh và Bản đồ Nguồn Mở OSSIM (Open Source Imagery and Mapping). Khung



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, trong
khi 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 ế đ ối
vớ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 chung
Mỗ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 ấy
phé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ôn
ngoan để đư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ành
Cá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 ải
khuyế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 ững
nơ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ác
kiể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ăng
tươ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ính
có 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ánh
Mộ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 ềm
củ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ủa
dự á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ín
nhiệ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ười
sử 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ả 2
dự á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 ần
tậ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ý do
nà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 ối
mộ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 ập
trì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ách
dễ 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 ười
sử 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ính



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 ất
bạ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 đ ối
vớ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 ự án
có 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ông
việ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 ập
trung 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ành
Cá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 ột
ngườ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ình
BD 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 đ ối
vớ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ữa
cá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 ệp
hoặ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 ười
ra 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ế đó. Tuy
nhiê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ó



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àn
cả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 ải
phá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ệc
dự á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 ếu
nhữ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 nhu
cầ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ác
Việ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 ộng
tá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ông
nghiệ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ản
xuấ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ách
riê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ãy
chắ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 đang
tớ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 đoan
vớ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 ữa
cá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 ới
nhu 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ính
minh 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 ty
và 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ở ra
quá 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ào
sẽ đượ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à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ác
nhỏ 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ăng
tí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 ướng
mọ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ự án
có 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ấp
cho 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 ều
ngườ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ềm
như 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ác
dự á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 đây
là 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-7
Cá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 ển
thô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ìm
kiế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 gian
cộ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ự gia
tă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ác
Vì 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ên
cá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. Site
củ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ười
sử 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ày
xả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 ổ sung



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 ọi
ngườ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 web
nà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 để tham
gia 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 ột
cô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ách
rộ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ách
mạ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úng
thườ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ân
thủ 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 ầu
khá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ốt
Site 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 cung
cấ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 đưa



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 ạn
chế 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óp
cho 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ác
cho 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áp
lý 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 ất
khẩ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ảm
củ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ững
trườ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 ẩm
quyề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ó đ ể đ ảm
bả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úng
như 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 ước
cầ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 ệt
quan 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ập
như “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 ể đ ược
tung 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 ống
SCM 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 cung
cấp chúng cho những người khác cho việc trộn nếu sự phê chuẩn được trao.


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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Otd lessons-learned-and-best-practices-for-military-software-vi

Ähnlich wie Otd lessons-learned-and-best-practices-for-military-software-vi (20)

Mehr von Vu Hung Nguyen

Mehr von Vu Hung Nguyen (20)

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