Khái niệm về sự tự do của phần mềm
Định nghĩa
Vì vậy, khái niệm "Phần mềm tự do" (PMTD) theo Richard Stallman, đề cập đến bốn quyền tự do cơ bản mà người dùng được đảm bảo: quyền chạy chương trình theo ý muốn, quyền nghiên cứu và thay đổi chương trình, quyền phân phối bản sao chương trình, và quyền phát hành các phiên bản đã chỉnh sửa của chương trình.
1 Tự do chạy chương trình ở bất cứ đâu, vì bất kỳ mục đích gì và vĩnh viễn.
2 Tự do nghiên cứu cách mà nó làm việc và để áp dụng nó cho các nhu cầu của chúng ta Điều này cần tới sự truy cập vào mã nguồn
3 Tự do phân phối lại các bản sao, sao cho chúng ta có thể giúp được những bạn bè và hàng xóm của chúng ta.
4 Tự do cải tiến chương trình và đưa những cải tiến đó ra cho công chúng Điều này cũng cần tới mã nguồn.
Cơ chế đảm bảo quyền tự do theo pháp luật hiện hành là thông qua một giấy phép đặc biệt, như sẽ được trình bày trong chương 3 Giấy phép này cho phép tác giả chuyển nhượng quyền cho người nhận chương trình, đồng thời có thể bổ sung các hạn chế mà tác giả mong muốn áp dụng, chẳng hạn như việc công nhận các tác giả ban đầu trong trường hợp phân phối lại Tuy nhiên, để giấy phép được coi là tự do, các hạn chế này không được làm mất hiệu lực các quyền tự do đã nêu.
Sự không rõ nghĩa của khái niệm tự do
Khái niệm PMTD trong tiếng Anh, được dịch là "Free" (tự do), không chỉ đơn thuần ám chỉ 'sự tự do' mà còn có thể mang nghĩa 'miễn phí' hoặc 'biếu không', dẫn đến nhiều sự hiểu lầm Do đó, trong một số trường hợp, tiếng Anh thường mượn từ ngữ từ tiếng Tây Ban Nha hoặc Pháp để chỉ PMTD, tạo sự khác biệt với phần mềm biếu không.
PMTD không nên bị nhầm lẫn với phần mềm miễn phí, mặc dù cả hai đều có những điểm khác biệt quan trọng Quyền tự do thứ 3 cho phép bất kỳ ai phân phối lại chương trình mà không cần xin phép, điều này làm cho việc đạt được lợi nhuận lớn từ việc phân phối PMTD trở nên khó khăn Bất kỳ ai sở hữu PMTD đều có thể phân phối lại với giá thấp hơn hoặc hoàn toàn miễn phí.
Mặc dù bất kỳ ai cũng có thể thương mại hóa một chương trình với bất kỳ mức giá nào, nhưng vẫn tồn tại các mô hình doanh nghiệp tập trung vào việc bán phần mềm thương mại (PMTD) Khách hàng thường sẵn sàng chi trả cho những lợi ích cụ thể, chẳng hạn như sự đảm bảo cho phần mềm hoặc giá trị gia tăng từ việc nâng cấp và tổ chức một bộ chương trình.
Từ góc độ thực tiễn, một số văn bản đã xác định rõ các điều kiện cần thiết để một giấy phép được công nhận là giấy phép PMTD.
Trong số những điểm quan trọng, tầm quan trọng lịch sử của phần mềm tự do (PMTD) được định nghĩa bởi Tổ chức FSF Debian cung cấp hướng dẫn để xác định tính tự do của một chương trình, trong khi định nghĩa về nguồn mở được đưa ra bởi Sáng kiến Nguồn Mở cũng tương tự như những khái niệm đã đề cập ở trên.
Hướng dẫn của Debian quy định rằng tác giả có quyền yêu cầu mã nguồn phân phối không được sửa đổi trực tiếp, mà phải kèm theo bản gốc và các bản vá riêng biệt Ngoài ra, các chương trình nhị phân được tạo ra phải mang tên khác so với bản gốc, và các giấy phép không được làm tổn hại đến các chương trình khác được phân phối theo cách tương tự.
Các khái niệm có liên quan
Phần mềm nguồn mở (PMNM), được khởi xướng bởi Eric Raymond và tổ chức Sáng kiến Nguồn Mở (OSI), tương đương với khái niệm phần mềm tự do (PMTD), nhưng nhấn mạnh vào tính sẵn sàng của mã nguồn hơn là sự tự do Định nghĩa này, mặc dù tương tự với của Debian, mang tính chính trị trung lập hơn và tập trung vào các lợi ích kỹ thuật như cải thiện mô hình phát triển, kinh doanh và an ninh Tuy nhiên, nó đã bị Richard Stallman và FSF chỉ trích mạnh mẽ, nhưng lại phù hợp hơn với văn hóa thương mại và các chiến lược của các công ty hỗ trợ mô hình này.
Những khái niệm có liên quan theo cách nào đó tới PMTD là như sau:
Phần mềm quảng bá là các chương trình miễn phí thường được phân phối dưới dạng nhị phân Người dùng có thể tải về mà không mất phí, tuy nhiên, quyền phân phối lại có thể bị hạn chế, nghĩa là phần mềm chỉ có thể được tải từ trang web chính thức Loại phần mềm này thường được sử dụng để quảng bá cho các chương trình hoặc dịch vụ khác với chức năng đầy đủ hơn Một số ví dụ điển hình bao gồm Skype, Google Earth và Microsoft Messenger.
Phần mềm chia sẻ không phải là phần mềm miễn phí, mà là một hình thức phân phối cho phép sao chép tự do các chương trình, thường không có mã nguồn Tuy nhiên, việc sử dụng liên tục phần mềm này yêu cầu phải trả tiền Sự yêu cầu này có thể xuất phát từ động lực tài chính hoặc từ lương tâm đạo đức của người dùng Ngoài ra, các khái niệm pháp lý liên quan đến giấy phép này có thể được áp dụng để xử lý những người vi phạm.
Phần mềm từ thiện thường là những ứng dụng chia sẻ yêu cầu người dùng đóng góp tài chính để được kết nối với các tổ chức từ thiện được bảo trợ Thay vì yêu cầu trả tiền cố định, một số phần mềm như Vim khuyến khích người dùng thực hiện các đóng góp tự nguyện.
Tác giả không thừa nhận tất cả các quyền của mình để phục vụ lợi ích của miền công cộng, điều này cần được tuyên bố rõ ràng trong chương trình Nếu không, chương trình có thể bị coi là sở hữu độc quyền, khiến mọi hành động liên quan trở nên khó khăn Khi mã nguồn bổ sung được cung cấp, chương trình sẽ trở nên tự do hơn.
Ngược lại với bản quyền, đây là một trường hợp đặc biệt của phần mềm tự do (PMTD), trong đó giấy phép yêu cầu mọi sửa đổi được phân phối phải được thực hiện dưới hình thức tự do.
Proprietary, locked-in, non-free
Sở hữu độc quyền, bị khóa trói, không tự do
Những khái niệm này được sử dụng để tham chiếu tới các phần mềm mà chúng không phải là tự do và cũng không phải là nguồn mở.
Động lực
Như chúng ta đã thấy, có 2 dòng động lực lớn cho sự phát triển PMTD, mà cũng đưa ra 2 cái tên được biết tới như:
Động lực đạo đức, được bảo vệ bởi FSF, kế thừa văn hóa của các hacker và hỗ trợ khái niệm tự do, nhấn mạnh rằng phần mềm là tri thức cần được chia sẻ mà không có rào cản Việc giấu kín phần mềm được coi là hành vi phản xã hội, và khả năng sửa đổi chương trình được xem như một hình thức tự do ngôn luận Để tìm hiểu sâu hơn, bạn có thể tham khảo các tiểu luận chọn lọc của Richard trong cuốn "PMTD, xã hội tự do".
M Stallman) [211] hoặc phân tích của Pekka Himanen (Đạo đức và tinh thần cao thủ của kỷ nguyên thông tin Random House, 2001) [144].
Động cơ thực dụng được bảo vệ bởi tổ chức OSI (http://www.opensource.org), tổ chức này ủng hộ khái niệm nguồn mở nhờ những lợi ích về kỹ thuật và tài chính mà chúng tôi sẽ phân tích trong phần tiếp theo.
Ngoài hai động lực chính, những người làm việc trong lĩnh vực PMTD còn có thể được thúc đẩy bởi nhiều lý do khác, như sở thích cá nhân (Linus Torvalds và David Diamond, Texere, 2001) hoặc lợi ích tài chính, thường liên quan đến các mô hình kinh doanh bền vững Chương 4 sẽ phân tích chi tiết những động lực này dựa trên các nghiên cứu khách quan.
Hệ quả của sự tự do của phần mềm
Đối với người sử dụng đầu cuối
Người sử dụng cuối, dù là cá nhân hay doanh nghiệp, đang đối mặt với sự cạnh tranh gay gắt trong thị trường độc quyền Không nhất thiết phải phụ thuộc vào sự hỗ trợ của nhà sản xuất phần mềm, vì nhiều công ty, kể cả những công ty nhỏ, có thể tận dụng mã nguồn mở và kiến thức để hoạt động kinh doanh, đồng thời vẫn duy trì các chương trình cụ thể ở dạng miễn phí.
Việc đánh giá chất lượng sản phẩm hiện nay không chỉ dựa vào độ tin cậy của nhà sản xuất, mà còn phụ thuộc vào sự chấp nhận và tính sẵn sàng của cộng đồng đối với mã nguồn Chúng ta cần từ bỏ tư duy về các "hộp đen" mà chỉ được tin cậy vì lời nói của nhà sản xuất, cũng như các chiến lược đơn phương của họ trong việc quyết định duy trì hoặc loại bỏ một sản phẩm cụ thể.
Việc đánh giá sản phẩm hiện nay trở nên dễ dàng hơn nhờ khả năng cài đặt và thử nghiệm trực tiếp trong môi trường thực tế, khác với các PMSHĐQ, nơi người dùng phải phụ thuộc vào báo cáo và thương thảo với nhà cung cấp Người dùng có thể tùy chỉnh và sửa đổi chương trình theo nhu cầu riêng, trong khi việc sửa lỗi trên PMSHĐQ thường phức tạp và tốn thời gian, đòi hỏi phải chờ đợi phiên bản cập nhật Ngược lại, với PMTD, người dùng có thể tự sửa lỗi hoặc thuê dịch vụ bên ngoài, cũng như tích hợp và kiểm thử chương trình với các phần mềm khác Điều này cho phép người dùng kiểm soát nhiều hơn, không chỉ giới hạn ở nhà cung cấp như với PMSHĐQ.
Đối với nền hành chính nhà nước
Nền hành chính nhà nước đóng vai trò quan trọng trong việc cung cấp dịch vụ cho công dân, với trách nhiệm đảm bảo tính trung lập và an toàn cho dữ liệu Điều này đòi hỏi nền hành chính phải tuân thủ các chuẩn mực cao hơn so với các công ty tư nhân, bảo vệ tính toàn vẹn và tính riêng tư của thông tin Việc duy trì dữ liệu trong các định dạng mở và sử dụng phần mềm an toàn, được kiểm tra nội bộ là cần thiết để giảm thiểu sự phụ thuộc vào các chiến lược của các công ty nước ngoài Tuy nhiên, sự áp dụng các chuẩn này vẫn chưa được PMSHĐQ chú trọng đúng mức, dẫn đến việc tạo ra các thị trường bị giam cầm.
Nền hành chính không chỉ là một công cụ phục vụ mà còn đóng vai trò quan trọng trong việc định hướng và hỗ trợ ngành công nghiệp, ảnh hưởng lớn đến sự phát triển công nghệ và thịnh vượng quốc gia Sự thịnh vượng này có thể đạt được thông qua việc khuyến khích các công ty phát triển phần mềm công nghệ mới cho nền hành chính, cũng như duy trì, áp dụng và kiểm tra các phần mềm hiện có Trong chương 6, chúng ta sẽ phân tích vấn đề này một cách sâu sắc hơn.
Đối với lập trình viên
Đối với lập trình viên và nhà sản xuất phần mềm, sự tự do trong việc phát triển phần mềm có thể thay đổi hoàn toàn cách thức hoạt động trong ngành Nó giúp các công ty nhỏ duy trì khả năng cạnh tranh và tiếp cận công nghệ hiện đại Bằng cách sửa đổi mã nguồn, chúng ta có thể tận dụng lợi thế từ sản phẩm của người khác, mặc dù đối thủ cũng có thể sử dụng mã nguồn của chúng ta nếu nó thuộc dạng copyleft Nếu dự án được quản lý hiệu quả, có thể thu hút sự hợp tác từ nhiều người, tạo ra một hệ thống phân phối toàn cầu gần như tự do Tuy nhiên, thách thức lớn vẫn là tìm kiếm nguồn tài chính, đặc biệt khi phần mềm không được bán để kiếm lợi nhuận Chương 5 sẽ đi sâu vào khía cạnh này.
Đối với nhà tích hợp
Đối với các nhà tích hợp, PMTD là một nguồn tài nguyên quý giá, giúp loại bỏ các hộp đen cần phải khớp với nhau bằng kỹ thuật nghịch đảo Các góc cạnh thô ráp có thể được làm mịn, cho phép tích hợp các phần của chương trình để tạo ra sản phẩm tích hợp theo yêu cầu Với kho tàng PMTD phong phú, người dùng có thể dễ dàng trích xuất các phần cần thiết cho dự án của mình.
Đối với các nhà cung cấp và duy trì dịch vụ
Mã nguồn có khả năng thay đổi mọi thứ, đưa chúng ta vào vị trí tương tự như nhà sản xuất Tuy nhiên, nếu vị trí này không hoàn toàn giống nhau, đó là do chúng ta thiếu hiểu biết sâu sắc về chương trình, điều mà chỉ lập trình viên mới có Điều này nhấn mạnh sự cần thiết của việc các nhà cung cấp duy trì tham gia vào các dự án yêu cầu sự bảo trì Giá trị gia tăng của các dịch vụ được đánh giá cao hơn nhiều do chi phí chương trình thấp Hiện tại, đây là lĩnh vực kinh doanh rõ ràng nhất đối với PMTD và cũng là nơi có sự cạnh tranh mạnh mẽ.
Tóm lược
Chương đầu tiên giới thiệu khái niệm PMTD do Richard Stallman xác định, dựa trên bốn quyền tự do: tự do chạy, tự do nghiên cứu, tự do phân phối lại và tự do cải tiến, trong đó hai quyền yêu cầu truy cập mã nguồn Tính khả dụng của mã nguồn đã thúc đẩy quan điểm thực dụng hơn, được OSI bảo vệ thông qua khái niệm PMNM Bên cạnh đó, chúng ta cũng đề cập đến các khái niệm tương tự và đối lập để làm rõ sự khác biệt giữa chúng Cuối cùng, chương này thảo luận về các hệ quả của PMTD đối với các bên liên quan chủ chốt.
2 Một chút về lịch sử
Khi bắt đầu làm việc tại Phòng thí nghiệm Trí tuệ Nhân tạo của MIT vào năm 1971, tôi đã gia nhập một cộng đồng chia sẻ phần mềm đã tồn tại từ lâu Việc chia sẻ phần mềm không chỉ giới hạn trong cộng đồng của chúng tôi mà còn có lịch sử lâu dài, tương tự như việc chia sẻ công thức nấu ăn Chúng tôi thực hiện việc này một cách thường xuyên hơn so với nhiều người khác.
PMTD là một khái niệm chưa từng tồn tại, mà chỉ là những gì đã từng xảy ra Chúng tôi luôn sẵn lòng cho phép các trường đại học hoặc công ty khác sử dụng chương trình của mình Nếu bạn thấy ai đó sử dụng một chương trình thú vị và lạ lẫm, bạn có thể yêu cầu xem mã nguồn để đọc, thay đổi hoặc phân tích các phần của nó nhằm tạo ra một chương trình mới.
Richard Stallman, “Dự án GNU” (ban đầu được xuất bản trong cuốn sách Nguồn Mở) [208].
Lịch sử phần mềm tự do mã nguồn mở (PMTD) có chiều dài đáng kể, với nhiều phần mềm ban đầu đã đáp ứng định nghĩa của PMTD trước khi khái niệm này ra đời Sau này, phần mềm sở hữu độc quyền (PMSHĐQ) đã chiếm ưu thế, dẫn đến việc các quỹ được đầu tư cho PMTD như hiện nay Qua thời gian, các chương trình tự do bắt đầu xuất hiện và phát triển thành một xu hướng mạnh mẽ, cho đến nay PMTD đã trở thành một lựa chọn quan trọng trong hầu hết các lĩnh vực.
Lịch sử của PMSHĐQ không được nhiều người biết đến, nhưng đối với các chuyên gia IT, nó được coi là phần mềm "ở tình trạng tự nhiên của nó" Tuy nhiên, thực tế lại khác, và những dấu hiệu của sự thay đổi đã bắt đầu hình thành từ những năm đầu 1980, kéo dài đến thập kỷ đầu tiên của thế kỷ 21.
PMTD không có nhiều câu chuyện chi tiết, và những câu chuyện hiện có thường chỉ cung cấp tài liệu hạn chế liên quan đến chủ đề chính Độc giả quan tâm có thể mở rộng kiến thức của mình về những nội dung đã được mô tả trong chương này bằng cách tham khảo “Sáng kiến Nguồn.”
Lịch sử của OSI đã nhấn mạnh sự ảnh hưởng mạnh mẽ của Phong trào Phần mềm Tự do (PMTD) đối với cộng đồng doanh nghiệp vào cuối thập niên 1990 Bài viết "Một câu chuyện ngắn về phong trào PMTD/PMNM" của Chris Rasch cung cấp cái nhìn tổng quan về sự phát triển của PMTD cho đến năm 2000.
Bài viết "Nguồn gốc và tương lai của PMNM" (1999) của Nathan Newman tập trung vào sự mở rộng đáng kể trong việc khuyến khích không trực tiếp của chính phủ Mỹ đối với PMTD và các hệ thống tương tự trong các thập niên 1970 và 1980.
Phần mềm tự do trước phần mềm tự do
Và lúc ban đầu nó từng là tự do
Trong những năm 60, ngành công nghệ thông tin chủ yếu bị chi phối bởi các máy tính lớn, chủ yếu được sử dụng trong các công ty và cơ quan chính phủ, với IBM là nhà sản xuất hàng đầu Khi mua máy tính, phần mềm thường được bổ sung sau đó, và việc truy cập vào catalog phần mềm chỉ được cấp khi hợp đồng duy trì được thanh toán Hơn nữa, khái niệm về các chương trình phần mềm thời bấy giờ thường được coi là tách biệt với quan điểm thương mại.
Trong giai đoạn này, phần mềm thường được cung cấp kèm theo mã nguồn, và thường thì chỉ có mã nguồn mà không có bất kỳ hạn chế nào.
Các nhóm người dùng như SHARE (người sử dụng hệ thống IBM) và DECUS (người sử dụng DEC) đã tham gia và tổ chức các trao đổi trong lĩnh vực công nghệ thông tin Tạp chí Communication of the ACM với khu vực “các thuật toán” đã từng là một diễn đàn trao đổi quan trọng Trong những năm đầu của ngành IT, phần mềm được coi là tự do, cho phép người dùng có quyền truy cập mã nguồn, chia sẻ, sửa đổi và phân phối những sửa đổi đó.
Vào ngày 30/09/1969, IBM thông báo rằng từ năm 1970, hãng sẽ bán phần mềm riêng biệt, điều này dẫn đến việc khách hàng không còn nhận được các chương trình cần thiết trong giá thành phần cứng Phần mềm bắt đầu được coi là có giá trị thực, khiến cho việc truy cập vào các chương trình và khả năng chia sẻ, sửa đổi hoặc nghiên cứu phần mềm bị hạn chế cả về mặt kỹ thuật và pháp lý Tình trạng này đã trở thành một thực tế phổ biến trong thế giới phần mềm vào đầu thế kỷ 21.
Độc giả quan tâm đến giai đoạn chuyển đổi này có thể tham khảo bài viết “ICP Directory đã bắt đầu như thế nào” (1998) của Larry Welke Trong bài viết, ông thảo luận về sự ra đời của một catalog phần mềm không liên quan đến nhà sản xuất và quá trình phát hiện rằng các công ty sẵn sàng chi trả cho những chương trình không do các nhà sản xuất máy tính phát triển.
Vào giữa những năm 1970, PMSHĐQ đã trở nên phổ biến trong lĩnh vực IT, đánh dấu một sự thay đổi văn hóa lớn trong cộng đồng chuyên nghiệp làm việc với phần mềm Sự thay đổi này đã mở ra cơ hội cho sự phát triển của nhiều công ty mới trong lĩnh vực kinh doanh này Tuy nhiên, phải mất gần một thập kỷ sau, PMTD mới bắt đầu xuất hiện một cách có tổ chức như là phản ứng đối với tình hình hiện tại.
Những năm 70 và đầu những năm 80
Mặc dù xu thế áp đảo đã khai thác mô hình PMSHĐQ, nhưng đã xuất hiện những sáng kiến chỉ ra một số đặc tính của PMTD Thực tế, một số sáng kiến này đã sản xuất PMTD như chúng ta nhận diện ngày nay, điển hình là SPICE, TeX và Unix, những trường hợp phức tạp hơn nhiều.
SPICE (Chương trình Mô phỏng với việc Nhấn mạnh Mạng Tích hợp) là một công cụ mô phỏng điện tử được phát triển bởi Đại học Berkeley, California vào năm 1973 bởi Donald O Pederson Ban đầu, SPICE được sử dụng như một công cụ đào tạo và nhanh chóng lan rộng ra các trường đại học toàn cầu, giúp sinh viên tiếp cận thiết kế mạng tích hợp Với việc nằm trong miền công cộng, SPICE cho phép phân phối, sửa đổi và nghiên cứu, đồng thời có thể được tùy chỉnh cho các yêu cầu cụ thể và bán dưới dạng sản phẩm sở hữu độc quyền Những đặc điểm này đã giúp SPICE trở thành tiêu chuẩn công nghiệp trong lĩnh vực mô phỏng mạng tích hợp, chiếm lĩnh thị trường nhờ vào khả năng chính xác và các phẩm chất kỹ thuật vượt trội.
Để tìm hiểu thêm về lịch sử của SPICE, bạn có thể tham khảo tài liệu "Cuộc sống của SPICE", được trình bày tại cuộc Gặp gỡ Công nghệ và Mạng Lưỡng cực diễn ra ở Minneapolis, MN, Mỹ vào tháng 09/1996 Thông tin chi tiết về SPICE cũng có thể được tìm thấy trên trang web chính thức tại http://bwrc.eecs.berkeley.edu/Classes/IcBook/SPICE/.
Donald Knuth bắt đầu phát triển TeX vào năm 1978 trong một kỳ nghỉ TeX là hệ thống trình bày điện tử phổ biến, được sử dụng để tạo ra tài liệu chất lượng cao Ngay từ đầu, Knuth đã áp dụng một giấy phép tương tự như giấy phép PMTD Đến năm 1985, khi TeX đã đủ ổn định, ông tiếp tục duy trì giấy phép này TeX nhanh chóng trở thành một trong những hệ thống nổi tiếng và phổ biến nhất trong lĩnh vực trình bày tài liệu.
Bạn có thể tìm hiểu về các cột mốc quan trọng trong lịch sử của TeX qua trang web http://www.math.utah.edu/software/plot79/tex/history.html Ngoài ra, bài viết trên Wikipedia về TeX cũng cung cấp thông tin chi tiết và hữu ích tại http://www.wikipedia.org/wiki/TeX.
Sự phát triển ban đầu của Unix
Unix, hệ điều hành khả chuyển đầu tiên, được phát triển bởi Thompson và Ritchie cùng nhóm tại Bell Labs của AT&T Kể từ khi ra đời vào khoảng năm 1972, Unix đã không ngừng phát triển, dẫn đến sự ra đời của vô số biến thể được thương mại hóa bởi nhiều công ty.
Vào những năm 1973 và 1974, Unix đã được giới thiệu đến nhiều trường đại học và trung tâm nghiên cứu trên toàn cầu thông qua một giấy phép cho phép sử dụng cho mục đích hàn lâm Mặc dù có một số hạn chế ảnh hưởng đến việc phân phối tự do, nhiều tổ chức đã thiết lập giấy phép tương tự, tạo nền tảng cho các cộng đồng PMTD sau này.
Những người truy cập mã nguồn của Unix đã có cơ hội nghiên cứu, cải tiến và mở rộng hệ thống, dẫn đến sự hình thành một cộng đồng lập trình viên xung quanh CSRG tại Đại học California, Berkeley Cộng đồng này đã phát triển một văn hóa riêng, đóng vai trò quan trọng trong lịch sử phần mềm tự do Unix có thể được xem như một thử nghiệm sớm cho những gì sau này trở thành GNU và Linux, mặc dù nó hoạt động trong một cộng đồng nhỏ hơn và cần giấy phép của AT&T, nhưng sự phát triển của nó vẫn tương tự trong một thế giới ít liên kết hơn.
Các phương pháp phát triển cố hữu của PMTD
Trong lịch sử và ảnh hưởng của Usenet và Internet, việc mã nguồn mở của Unix đã đóng góp quan trọng vào sự phát triển ban đầu của nó Điều này cho phép người dùng kiểm tra, cải thiện và tùy chỉnh mã nguồn, tạo ra giá trị cho cộng đồng công dân mạng.
Trang 142 của tài liệu nhấn mạnh rằng những người tiên phong như Henry Spencer nhận thức rõ tầm quan trọng của mã nguồn trong việc xác định và sửa lỗi Vào cuối những năm 1970 và đầu những năm 1980, mọi trang Unix đều đã sở hữu các nguồn hoàn chỉnh, cho thấy sự cần thiết của việc truy cập mã nguồn trong phát triển phần mềm.
Văn bản phỏng vấn giữa Marc Rochkind và Dick Haight, được đăng trên Unix Review vào tháng 5 năm 1986, nhấn mạnh rằng một trong những điều tuyệt vời về Unix trong những ngày đầu là sự chia sẻ thông tin giữa mọi người Họ không chỉ học hỏi từ việc chia sẻ tài liệu mà còn không phải lo lắng về cách mọi thứ hoạt động, vì họ luôn có thể truy cập và đọc mã nguồn.
Qua thời gian, Unix trở thành ví dụ điển hình về vấn đề của các hệ thống sở hữu độc quyền, vốn được xem là có một số tính năng của phần mềm tự do Đến cuối những năm 1970 và đặc biệt trong thập kỷ 1980, AT&T đã thay đổi chính sách, khiến việc truy cập các phiên bản mới của Unix trở nên khó khăn và tốn kém Triết lý ban đầu đã làm cho Unix trở nên phổ biến trong cộng đồng lập trình viên đã hoàn toàn thay đổi, đến mức vào năm 1991, AT&T đã cố gắng kiện Đại học Berkeley vì việc xuất bản mã nguồn Unix BSD do CSRG của Berkeley phát triển Đây là một câu chuyện khác mà chúng tôi sẽ kể sau.
Sự bắt đầu: BSD, GNU
Richard Stallman, GNU, FSF: phong trào PMTD ra đời
Vào đầu năm 1984, Richard Stallman, khi đó làm việc tại Phòng thí nghiệm AI của MIT, đã rời bỏ công việc để khởi động dự án GNU với mục tiêu xây dựng một hệ điều hành hoàn chỉnh, tự do và chia sẻ Ông tự nhận mình là một cao thủ máy tính, nhưng sự từ chối ký hợp đồng độc quyền đã khiến ông cảm thấy bị ruồng bỏ trong cộng đồng công nghệ Dự án GNU, viết tắt của “GNU không phải là Unix”, đã nhanh chóng phát triển, mặc dù còn nhiều phần mềm cần được xây dựng Stallman bắt đầu bằng việc phát triển trình biên dịch C (GCC) và trình soạn thảo (Emacs), cả hai vẫn được sử dụng rộng rãi cho đến ngày nay.
Ngay từ đầu dự án GNU, Richard Stallman đã chú trọng đến quyền tự do của người sử dụng phần mềm Ông mong muốn không chỉ những người nhận chương trình trực tiếp từ dự án GNU mà còn cả những người nhận qua nhiều lần phân phối và sửa đổi cũng được hưởng các quyền như sửa đổi và phân phối lại Để đảm bảo điều này, ông đã phác thảo giấy phép GPL, được xem là giấy phép phần mềm tự do đầu tiên nhằm bảo vệ quyền tự do của người sử dụng.
Richard Stallman đã đặt tên cho cơ chế mà các giấy phép GPL sử dụng để đảm bảo quyền lợi, gọi là copyleft Khái niệm này đã trở thành tên gọi cho một loạt các giấy phép phần mềm tự do (PMTD) do Quỹ Phần mềm Tự do (FSF) phát triển, bắt đầu với Giấy phép Công cộng Chung GNU, phiên bản 2, vào tháng 06/1991.
Richard Stallman đã thành lập Quỹ Phần mềm Tự do (FSF) nhằm thu hút đầu tư vốn để phát triển và bảo vệ phần mềm tự do Ông cũng đã thiết lập các nguyên tắc đạo đức của mình thông qua "Tuyên ngôn GNU" vào năm 1985.
[117] và “Vì sao phần mềm phải không có chủ sở hữu” (Richard Stallman, 1998) [207].
Dự án GNU được xem như một nỗ lực có cấu trúc cao với mục tiêu rõ ràng, thường dựa vào các nhóm nhỏ người tự nguyện phát triển các công cụ phù hợp cho hệ GNU Dự án này lấy cảm hứng từ các module của Unix, với phương pháp làm việc chủ yếu qua Internet, mặc dù lúc đó Internet chưa phổ biến FSF đã bán băng từ ghi lại ứng dụng, giúp tổ chức có nguồn tài chính hạn chế từ việc tạo ra PMTD Đến đầu những năm 90, sau khoảng 6 năm hình thành, GNU đã gần đạt được hệ thống tương tự Unix, nhưng vẫn chưa sản xuất được nhân của hệ điều hành, phần quan trọng điều khiển phần cứng và cho phép các ứng dụng chia sẻ tài nguyên.
Phần mềm GNU đã trở nên phổ biến trong cộng đồng người dùng các biến thể của Unix, đặc biệt là trong các doanh nghiệp Dự án GNU đã thu hút sự chú ý của các chuyên gia IT, đặc biệt là tại các trường đại học Trong giai đoạn này, sản phẩm của GNU đã xây dựng được uy tín vững chắc nhờ vào tính ổn định và chất lượng cao.
CSRG của Berkeley
Từ năm 1973, Nhóm Nghiên cứu Khoa học Máy tính CSRG của Đại học California tại Berkeley đã trở thành trung tâm phát triển chính của Unix, đặc biệt trong giai đoạn 1979-1980 Họ không chỉ phát triển các ứng dụng mới mà còn cải tiến nhân và bổ sung nhiều chức năng quan trọng Trong những năm 80, các hợp đồng của DARPA đã tài trợ cho việc triển khai TCP/IP, trở thành tiêu chuẩn cho các giao thức Internet, liên kết sự phát triển của Internet với sự mở rộng của các máy trạm Unix Nhiều công ty đã dựa vào các phát triển của CSRG để xây dựng phiên bản Unix của riêng họ, tạo ra các hệ thống nổi tiếng như SunOS và Ultrix Do đó, Berkeley đã trở thành một trong hai nguồn Unix cơ bản.
Để sử dụng mã nguồn của CSRG và cộng đồng Unix, cần có giấy phép Unix của AT&T, điều này ngày càng khó khăn và tốn kém Để giải quyết vấn đề này, vào tháng 06/1989, CSRG đã phát hành Phiên bản Mạng 1 (Net-1) liên quan đến TCP/IP mà không bao gồm mã nguồn của AT&T, dưới giấy phép BSD Giấy phép này giúp loại bỏ một số rào cản về quảng cáo và cho phép phân phối lại CSRG cũng thử nghiệm mô hình tài chính mới bằng cách bán băng phát tán với giá 1,000 USD, cho phép mọi người phân phối lại nội dung Sau thành công của Net-1, Keith Bostic đã đề xuất viết lại mã nguồn từ Unix gốc của AT&T, và mặc dù có sự nghi ngờ, ông đã công khai kêu gọi sự giúp đỡ Các tiện ích được viết lại theo đặc tả kỹ thuật và dần được tích hợp vào hệ thống Berkeley Đến tháng 06/1991, sau khi được phép từ Đại học Berkeley, Phiên bản Mạng 2 (Net-2) đã ra mắt, bao gồm hầu hết mã nguồn của nhân và các tiện ích của hệ điều hành Unix hoàn chỉnh.
Bộ này đã được phân phối theo giấy phép BSD, với hàng ngàn đầu băng được bán với giá 1,000 USD mỗi băng Chỉ sau 6 tháng ra mắt Net-2, Bill Jolitz đã phát triển mã nguồn cho nhân hoạt động trên kiến trúc i386, dẫn đến sự ra đời của 386BSD, được phân phối qua Internet Mã nguồn này đã trở thành nền tảng cho nhiều bản vá cải tiến 386BSD, từ đó FreeBSD ra đời với mục tiêu hỗ trợ kiến trúc i386 Vài năm sau, dự án OpenBSD được hình thành với sự chú trọng vào an ninh Ngoài ra, một phiên bản sở hữu độc quyền dựa trên Net-2 cũng đã được phát triển bởi công ty BSDI (Berkeley Software Design Inc.), mặc dù công ty này đã ngừng hoạt động.
Phản ứng trước việc phát tán của BSDI, bộ phận phụ của AT&T giữ quyền giấy phép Unix, các Phòng thí nghiệm Hệ thống Unix USL đã kiện BSDI và Đại học California vì phân phối sở hữu trí tuệ của AT&T mà không có phép Sau nhiều cuộc vận động pháp lý, Novell đã mua quyền Unix từ USL và đạt được một thỏa thuận ngoài tòa với Đại học California vào tháng 01/1994 Kết quả của thỏa thuận này là CSRG đã phát hành phiên bản 4.4BSD-Lite, được sử dụng rộng rãi bởi các dự án *BSD Mặc dù CSRG đã ngừng hoạt động sau khi phát hành phiên bản 4.4BSD-Lite Phiên bản 2, nhưng các hệ thống *BSD vẫn tiếp tục tồn tại và phát triển dưới hình thức quản lý mới, đặc trưng cho các dự án PMTD, ngay cả trong thập kỷ đầu tiên của thế kỷ 21.
*BSD là những dự án lâu đời nhất và vững chắc nhất trong thế giới PMTD.
Lịch sử của Unix BSD phản ánh sự phát triển phần mềm độc đáo trong những năm 1970 và 1980 Để hiểu rõ hơn về quá trình này, bạn có thể tham khảo cuốn sách “Hai mươi năm Berkeley Unix” của Marshall Kirk McKusick (1999), mô tả sự tiến hóa từ những ngày đầu khi Bob Fabry bắt đầu phát triển phiên bản đầu tiên của mã nguồn Thompson và Ritchie trên PDP-11 Cuốn sách cũng đề cập đến các vụ kiện của AT&T và những phiên bản mã nguồn mới mà hệ điều hành *BSD đã tạo ra.
Sự khởi đầu của Internet
Kể từ khi ra đời vào thập kỷ 1970, Internet đã gắn liền với Phát triển Phần mềm Mở (PMTD) Ngay từ đầu, cộng đồng lập trình viên đã thiết lập những nguyên tắc quan trọng, như việc người dùng có thể sửa lỗi và chia sẻ mã nguồn BSD Unix đóng vai trò quan trọng trong sự phát triển Internet, cung cấp các triển khai phổ biến cho giao thức TCP/IP trong những năm 1980, giúp lan tỏa các tập quán từ cộng đồng lập trình viên CSRG sang các lập trình viên xây dựng NSFNet, và ngược lại Nhiều ứng dụng thiết yếu cho sự phát triển Internet, như Sendmail và BIND, đã được phát triển dưới hình thức mã nguồn mở, nhờ vào sự hợp tác giữa hai cộng đồng này.
Vào cuối những năm 80 và trong thập niên 90, cộng đồng PMTD đã tiên phong trong việc khai thác khả năng của Internet để hợp tác giữa các nhóm phân tán về địa lý Sự phát triển này đã góp phần quan trọng vào sự hình thành của cộng đồng BSD, FSF và sự phát triển của GNU/Linux.
Một trong những khía cạnh thú vị nhất của sự phát triển Internet là sự quản lý mở hoàn toàn các tài liệu và quy định liên quan Mặc dù ngày nay điều này có vẻ bình thường, tính sẵn sàng tự do của tất cả các đặc tả kỹ thuật và tài liệu thiết kế đã đóng vai trò cách mạng trong sự phát triển của Internet, đặc biệt là trong những năm 90 Lịch sử và ảnh hưởng của Usenet và Internet cho thấy tầm quan trọng của việc chia sẻ thông tin mở trong việc định hình các giao thức và tiêu chuẩn.
Quá trình mở đã dẫn đến sự thay đổi thông tin quan trọng Sự phát triển kỹ thuật chỉ thành công khi thông tin được tự do và dễ dàng trao đổi giữa các bên liên quan Khuyến khích sự tham gia là nguyên tắc chính thúc đẩy sự phát triển của Internet.
Đoạn này có thể được hỗ trợ vững chắc bởi bất kỳ lập trình viên nào tham gia vào dự án PMTD mà họ liên quan đến.
Trong một trích dẫn khác, về “Sự tiến hóa của chuyển mạch gói” [195] (trang 267) chúng ta có thể đọc:
ARPANET, một dự án công cộng, đã kết nối nhiều trường đại học và viện nghiên cứu hàng đầu, vì vậy thông tin về việc triển khai cài đặt và tốc độ thực thi đã được công bố rộng rãi.
Các dự án PMTD thường có xu hướng công khai tất cả thông tin liên quan, không chỉ về quá trình triển khai cài đặt.
Trong những năm 90, trước khi Internet trở thành một ngành kinh doanh lớn, mối quan hệ giữa cộng đồng người sử dụng và lập trình viên đóng vai trò quan trọng Các tổ chức đã học cách tin tưởng vào một hệ sinh thái đa dạng, bao gồm nhiều nhà cung cấp dịch vụ, nhà sản xuất thiết bị và lập trình viên, thay vì chỉ một nguồn duy nhất Những triển khai phần mềm tốt nhất thường không đến từ hệ điều hành đi kèm với phần cứng, mà từ các phiên bản tự do có khả năng thay thế nhanh chóng Các đổi mới sáng tạo chủ yếu xuất phát từ sinh viên và chuyên gia độc lập, những người thử nghiệm ý tưởng và nhận phản hồi từ cộng đồng người dùng chương trình miễn phí của họ.
Internet đã cung cấp cho PMTD nhiều công cụ hợp tác từ xa quan trọng như thư điện tử, nhóm tin, và dịch vụ truyền tệp FTP nặc danh, góp phần vào sự phát triển của cộng đồng PMTD Các dự án như GNU và BSD đã tận dụng hiệu quả những công cụ này, đồng thời phát triển các hệ thống mới, từ đó nâng cao khả năng hoạt động của Internet.
Độc giả quan tâm đến sự phát triển của Internet có thể tham khảo "Lịch sử ngắn gọn về Internet," một tài liệu quan trọng do các nhân vật chủ chốt trong lĩnh vực này viết, được xuất bản bởi ACM vào năm 1997.
Các dự án khác
Trong những năm 1980, nhiều dự án phần mềm mã nguồn mở quan trọng đã ra đời, trong đó có X Window, hệ thống cửa sổ cho các hệ điều hành Unix, được phát triển tại MIT Dự án này minh chứng cho tầm quan trọng và sự phù hợp trong tương lai của phần mềm mã nguồn mở, nhờ vào sự đầu tư tài chính rộng rãi từ một nhóm doanh nghiệp Ngoài ra, Ghostscript, một hệ thống quản lý tài liệu PostScript phát triển bởi Aladdin Software, cũng là một ví dụ điển hình về việc tìm kiếm mô hình kinh doanh từ phần mềm mã nguồn mở.
Cuối những năm 1980, nhiều dự án PMTD nhỏ và vừa đã được thực hiện, cùng với các dự án lớn trước đó Tất cả những nỗ lực này đã tạo nền tảng cho các hệ thống hoàn toàn tự do đầu tiên, xuất hiện vào đầu những năm 1990.
Mọi thứ đều theo cách của nó
Yêu cầu về một nhân kernel
Vào cuối những năm 1980 và đầu những năm 1990, dự án GNU đã phát triển nhiều công cụ và tiện ích, tạo nền tảng cho một hệ điều hành hoàn chỉnh Trong thời gian này, nhiều ứng dụng tự do, như X Window, đã đạt chất lượng hàng đầu trong lĩnh vực của chúng, bao gồm các tiện ích Unix và trình biên dịch Tuy nhiên, để hoàn thiện hệ thống, một phần quan trọng còn thiếu là nhân của hệ điều hành Dự án GNU đã tìm kiếm phần còn thiếu này thông qua dự án Hurd, với mục tiêu xây dựng một nhân sử dụng các công nghệ tiên tiến.
Họ *BSD
Cộng đồng BSD đã tiến gần đến một hệ thống tự do với sự phát tán của Net-2, chỉ thiếu 6 tệp để hoàn thiện, mà đã được Bill Jolitz hoàn tất vào đầu năm 1992 với 386BSD Hệ thống này hoạt động trên kiến trúc i386 và đã góp phần nâng tầm các dự án NetBSD, FreeBSD và OpenBSD Sự phát triển diễn ra nhanh chóng, và đến cuối năm 1992, nó đã đủ ổn định để sử dụng trong các môi trường sản xuất không mang tính sống còn, như trong môi trường cửa sổ nhờ vào dự án XFree và trình biên dịch GCC Mặc dù vẫn còn một số thành phần sử dụng giấy phép khác, hầu hết hệ thống này đã được phân phối theo giấy phép BSD.
Giai đoạn này chứng minh khả năng của mô hình phát triển phần mềm tự do thông qua những câu chuyện nổi bật Một ví dụ điển hình là Linus Torvalds, người đã phát triển Linux khi còn là sinh viên năm thứ hai tại Đại học Helsinki Không chỉ có Torvalds, Thomas Roel cũng đã ghi dấu ấn khi chuyển X11R4 sang máy tính cá nhân PC dựa trên vi xử lý 386, điều này đã mở ra cơ hội làm việc tại Dell cho anh Roel sau đó trở thành người sáng lập các dự án X386 và Xfree, góp phần quan trọng vào việc tạo ra môi trường cửa sổ cho GNU/Linux và các hệ điều hành BSD Để tìm hiểu thêm về XFree và vai trò của Roel, bạn có thể tham khảo bài viết “Lịch sử của xFree86” trên Tạp chí Linux, tháng 12/1991.
Vụ kiện từ USL đã khiến nhiều người sử dụng lo ngại về khả năng bị kiện nếu Đại học California thua kiện hoặc dự án bị bế tắc Điều này có thể là lý do khiến nền tảng cài đặt của GNU/Linux phát triển vượt trội hơn so với tất cả các hệ điều hành *BSD Tuy nhiên, chúng ta không thể khẳng định điều này một cách chắc chắn.
Sự ra đời của GNU/Linux
Vào tháng 07/1991, Linus Torvalds, một sinh viên 21 tuổi người Phần Lan, đã công bố thông điệp đầu tiên về dự án xây dựng hệ điều hành tự do tương tự như Minix Đến tháng 09, phiên bản đầu tiên (0.01) đã ra mắt, và các phiên bản mới tiếp tục được phát hành sau mỗi vài tuần Đến tháng 03/1994, phiên bản 1.0 được giới thiệu là phiên bản ổn định đầu tiên, mặc dù nhân Linux đã có thể sử dụng từ vài tháng trước đó Trong giai đoạn này, hàng trăm lập trình viên đã tham gia phát triển Linux, tích hợp phần mềm GNU cùng với XFree và nhiều chương trình tự do khác Khác với hệ điều hành BSD, nhân Linux và nhiều thành phần xung quanh nó được phân phối dưới giấy phép GPL.
Câu chuyện về Linux là một trong những câu chuyện nổi bật và hấp dẫn nhất trong lĩnh vực phần mềm mã nguồn mở Nhiều thông tin về Linux có thể được tìm thấy từ các trang kỷ niệm 10 năm tuyên bố của nó, trong đó “Lịch sử của Linux” của Ragib Hasan là một trong những nguồn tài liệu thú vị Linus Torvalds đã công bố việc bắt đầu phát triển Linux trên nhóm thảo luận comp.os.minix, nơi ông chia sẻ quá trình làm việc trên nhân của mình từ tháng 04 và việc tích hợp các công cụ từ dự án GNU, đặc biệt là Bash và GCC.
Một trong những câu chuyện thú vị xoay quanh Linux là sự phát triển của các bản phân phối (distros) Những bản phân phối đầu tiên xuất hiện vào năm 1992, như MCC Interim Linux, TAMU và SLS, đã tạo ra sự cạnh tranh trong thế giới hệ điều hành dựa trên Linux Mỗi bản phân phối đều cố gắng cung cấp một phiên bản GNU/Linux dễ sử dụng, với nền tảng phần mềm tương tự nhưng cải tiến để đáp ứng nhu cầu của người dùng Ngoài việc cung cấp các gói phần mềm đã được biên dịch sẵn, các bản phân phối cũng phát triển công cụ quản lý riêng để cài đặt, thay thế và gỡ bỏ các gói, nhằm hỗ trợ người dùng trong việc quản lý và quản trị hệ điều hành.
Qua thời gian, các phát tán đã liên tiếp xuất hiện và trở nên nổi tiếng Trong số đó, có một số phát tán đáng chú ý mà chúng tôi muốn nhấn mạnh.
1 Debian, được phát triển bởi một cộng đồng những người sử dụng tự nguyện.
2 Red Hat Linux, mà lần đầu tiên được phát triển nội bộ bên trong công ty Red Hat, nhưng sau đó đã áp dụng một mô hình dựa trên cộng đồng, làm nổi cho Fedora Core.
3 SuSE, mà làm nổi cho OpenSuSE, sau một sự tiến bộ tương tự như của Red Hat.
1 Khái niệm này được giải thích chi tiết trong bài viết tương ứng trong Wikipedia, www.wikipedia.org/wiki/Linux_distribution
4 Mandriva, (hậu duệ của Mandrake Linux và Conectiva).
5 Ubuntu, bắt nguồn từ Debian và được phát triển trên cơ sở của Debian bởi hãng Canonical.
Thời gian chín muồi
Kết thúc những năm 90
Vào giữa những năm 1990, PMTD đã phát triển các môi trường hoàn chỉnh như GNU/Linux và các hệ thống *BSD, hỗ trợ công việc hàng ngày cho nhiều lập trình viên Mặc dù vẫn còn nhiều thách thức, đặc biệt là trong việc cải thiện giao diện đồ họa so với Windows 95, đã có hàng ngàn người trên thế giới sử dụng PMTD cho công việc hàng ngày Các dự án mới tiếp tục được công bố, đánh dấu sự phát triển liên tục của PMTD và nâng cao nhận thức trong cộng đồng, các công ty và phương tiện truyền thông.
Giai đoạn này đánh dấu sự bùng nổ của Internet như một mạng lưới kết nối mọi người, chủ yếu nhờ vào các chương trình mã nguồn mở, đặc biệt là trong nền tảng của nó Sự xuất hiện của mạng tại hàng triệu hộ gia đình đã thúc đẩy tình trạng này, với hầu hết các máy chủ web như NCSA và Apache đều là mã nguồn mở Bài viết nổi tiếng của Eric Raymond, “Nhà thờ lớn và cái chợ”, đã mô tả rõ ràng con đường phát triển của phần mềm mã nguồn mở (PMTD) và nhấn mạnh tầm quan trọng của việc phổ biến khái niệm này trong cộng đồng lập trình viên Việc công khai và phân phối nội dung này đã giúp khuyến khích PMTD như một phương thức phát triển thay thế cho các phương thức truyền thống trong ngành công nghiệp phần mềm.
Bài viết quan trọng "Việc thiết lập cửa hàng Kinh doanh PMNM" của Frank Hecker đã lần đầu tiên mô tả các mô hình kinh doanh tiềm năng cho PMTD, nhằm ảnh hưởng đến quyết định phát hành mã nguồn của Netscape Navigator.
Bài viết của Raymond đã từng là công cụ hữu ích trong việc khuyến khích các đặc tính cơ bản của PMTD Tuy nhiên, sự ra mắt mã nguồn của Netscape Navigator đánh dấu lần đầu tiên một công ty lớn trong lĩnh vực đổi mới sáng tạo quyết định phát hành sản phẩm dưới dạng PMTD Dù Netscape Navigator đã thất bại trong cuộc chiến trình duyệt với Internet Explorer của Microsoft, một phần do chiến thuật kết hợp của Microsoft với hệ điều hành của hãng, nhiều người tin rằng Netscape đã nỗ lực hết sức để thay đổi luật lệ nhằm cạnh tranh với gã khổng lồ Từ sự thay đổi này, dự án Mozilla đã ra đời, mặc dù gặp phải nhiều vấn đề, nhưng sau vài năm đã trở thành một trình duyệt có chất lượng kỹ thuật tương đương với các đối thủ độc quyền, dù chưa đạt được thị phần khổng lồ như Netscape trước đây.
Tuyên bố của Netscape về việc cung cấp mã nguồn trình duyệt đã tạo ra ảnh hưởng lớn đến ngành công nghiệp phần mềm, khiến nhiều công ty bắt đầu chú ý đến phần mềm mã nguồn mở (PMTD) Thị trường tài chính cũng đã nhận ra giá trị của PMTD, đặc biệt trong bối cảnh bùng nổ dotcom, khi nhiều công ty PMTD trở thành mục tiêu đầu tư Một ví dụ điển hình là Red Hat, công ty tiên phong trong việc nhận ra mô hình kinh doanh tiềm năng từ việc bán đĩa CD chứa hệ điều hành GNU/Linux sẵn sàng sử dụng.
Red Hat đã bắt đầu phân phối Red Hat Linux với trọng tâm vào sự dễ dàng sử dụng và bảo trì, không cần nền tảng IT đặc biệt Qua thời gian, công ty đã đa dạng hóa và vào tháng 09/1998, Intel và Netscape đã đầu tư vào Red Hat, khiến nhiều nhà đầu tư tin tưởng rằng “nếu tốt cho Intel và Netscape, thì cũng tốt cho chúng tôi.” Khi Red Hat ra công chúng vào mùa hè năm 1999, IPO đã được thuê bao hoàn toàn và giá trị cổ phiếu tăng mạnh Đây là lần đầu tiên một công ty nhận được tài chính từ thị trường chứng khoán với mô hình dựa vào PMTD, mở đường cho các công ty khác như VA Linux và Andover.net làm theo.
Red Hat đã công bố một danh sách các cột mốc quan trọng của hãng tại trang web http://fedora.redhat.com/about/history/ Trong thời gian này, nhiều công ty mới đã được hình thành với các mô hình kinh doanh dựa trên PMTD.
Mặc dù không nổi bật trên thị trường, nhiều công ty như SuSE (Đức), Conectiva (Brazil) và Mandrake (Pháp) đã đóng góp quan trọng vào sự phát triển của phần mềm mã nguồn mở (PMTD) thông qua việc phân phối các phiên bản GNU/Linux Một số công ty khác như LinuxCare (Mỹ), Alcove (Pháp) và ID Pro (Đức) cung cấp dịch vụ cho các doanh nghiệp muốn duy trì hoặc áp dụng sản phẩm tự do.
Các công ty lớn trong khu vực đã bắt đầu xác định vị trí của mình trong mối quan hệ với PMTD IBM đã tích hợp PMTD vào chiến lược của mình, trong khi Sun Microsystems có mối quan hệ phức tạp, thỉnh thoảng hỗ trợ và thỉnh thoảng phản đối Nhiều công ty như Apple, Oracle, HP và SGI đã áp dụng mô hình PMTD với các chiến lược khác nhau, từ việc phát hành phần mềm có chọn lọc đến việc cung cấp sản phẩm cho GNU/Linux Ngoài ra, còn có những phương án khác như tăng cường PMTD trong sản phẩm (ví dụ như Mac OS X) hoặc phát triển mô hình kinh doanh dựa trên bảo trì sản phẩm PMTD.
Trong giai đoạn này, sự kiện nổi bật nhất có lẽ là sự ra đời của hai dự án đầy tham vọng: KDE và GNOME Hai dự án này được thiết kế nhằm đưa PMTD vào môi trường máy tính để bàn, phục vụ cho những người sử dụng IT không có kinh nghiệm Mục tiêu cuối cùng là loại bỏ sự cần thiết phải sử dụng dòng lệnh để tương tác với hệ điều hành GNU/Linux hoặc *BSD cùng với các chương trình trong các môi trường này.
KDE, được công bố vào tháng 10/1996, đã sử dụng các thư viện đồ họa Qt để phát triển một tập hợp các ứng dụng máy tính để bàn với giao diện thống nhất Phiên bản 1.0 của Môi trường Để bàn K (K Desktop Environment) ra mắt vào tháng 07/1998, nhanh chóng được cải tiến qua các phiên bản tiếp theo Các phát tán GNU/Linux sớm đã tích hợp KDE như một giao diện cho người sử dụng, hoặc ít nhất là như một tùy chọn môi trường máy tính để bàn.
Vào tháng 08/1997, dự án GNOME được công bố như một phản ứng trước sự phụ thuộc của KDE vào thư viện độc quyền của Qt, với mục tiêu và đặc tính tương tự như KDE, nhưng nhấn mạnh cam kết về phần mềm tự do GNOME 1.0 ra mắt vào tháng 02/1999, đã trải qua nhiều cải tiến và ổn định theo thời gian Tại thời điểm đó, hầu hết các hệ điều hành tự do và nhiều hệ điều hành sở hữu độc quyền dựa trên Unix đều cung cấp GNOME hoặc KDE như một lựa chọn, cùng với các ứng dụng của cả hai môi trường.
Các dự án PMTD chính vẫn duy trì sự hiệu quả trong khi nhiều dự án mới liên tục xuất hiện hàng ngày Trong nhiều thị trường khác nhau, PMTD được công nhận là giải pháp tối ưu trên toàn cầu Kể từ khi ra mắt vào tháng 04/1995, Apache đã chứng minh được giá trị của mình.
Sau này, Qt đã được phân phối theo giấy phép QPL (Qt Public License), không tương thích với GPL, gây ra một số vấn đề do hầu hết các phần mềm của KDE sử dụng GPL Cuối cùng, Trolltech đã quyết định phân phối Qt theo giấy phép GPL, giải quyết những vấn đề này Xfree86, dự án phát triển X Window, vẫn là phiên bản nổi tiếng nhất của X Window cho các hệ điều hành Unix GCC được công nhận là trình biên dịch C tốt nhất và chất lượng cao nhất, trong khi GNAT, hệ thống biên soạn cho Ada 95, đã chiếm lĩnh thị trường trình biên dịch Ada chỉ trong vài năm.
Trong năm 1998, OSI được thành lập và quyết định áp dụng khái niệm PMNM như một thương hiệu để giới thiệu PMTD vào doanh nghiệp, đồng thời tránh sự mơ hồ về khái niệm tự do Quyết định này đã dẫn đến những tranh luận gay gắt trong thế giới PMTD, kéo dài đến ngày nay, khi FSF và những người khác cho rằng PMTD nên được gọi là nguồn mở OSI đã thực hiện một chiến dịch quảng bá hiệu quả cho thương hiệu mới, được ưa chuộng hơn trong cộng đồng nói tiếng Anh Để định nghĩa PMNM, OSI đã tham khảo định nghĩa từ dự án Debian về PMTD.
Thập niên 2000
Vào đầu những năm 2000, PMTD đã trở thành một đối thủ cạnh tranh đáng gờm trong lĩnh vực máy chủ và chuẩn bị cho máy tính để bàn Các hệ thống như GNOME, KDE, OpenOffice.org và Mozilla Firefox đã trở nên phổ biến với người dùng cá nhân và đáp ứng nhu cầu của nhiều doanh nghiệp, đặc biệt là những nơi chú trọng đến ứng dụng Hệ thống mã nguồn mở, đặc biệt là những hệ thống dựa trên Linux, không chỉ dễ cài đặt mà còn có mức độ bảo trì và cập nhật tương đương với các hệ thống sở hữu độc quyền khác.
Hiện nay, mọi công ty trong ngành công nghiệp phần mềm đều có chiến lược về PMTD Các tập đoàn đa quốc gia hàng đầu như IBM, HP, Sun, Novell, Apple, và Oracle đều tích hợp PMTD ở mức độ khác nhau Oracle, ví dụ, đã đơn giản đưa sản phẩm của mình lên GNU/Linux, trong khi IBM thực hiện các chiến dịch công khai lớn nhất về GNU/Linux Trong số các công ty hàng đầu trong lĩnh vực IT, Microsoft là ngoại lệ khi rõ ràng định vị mình chống lại PMTD và phần mềm phân phối theo giấy phép GPL.
Thế giới PMTD đang trải qua sự tăng trưởng mạnh mẽ, mặc dù có những tranh cãi trong cộng đồng Mỗi ngày, số lượng lập trình viên và dự án PMTD gia tăng, cùng với sự gia tăng người sử dụng PMTD đang dần chuyển mình từ những con đường phụ trở thành một lực lượng quan trọng không thể bỏ qua.
Dựa trên những nguyên lý mới nổi lên trong nghiên cứu PMTD, chúng ta đang dần hiểu rõ hơn về cách hoạt động của PMTD qua các khía cạnh khác nhau, bao gồm thiết kế kỹ thuật, mô hình phát triển và động lực của lập trình viên.
Trong những năm gần đây, chúng ta đã bắt đầu nhận thấy những ảnh hưởng đầu tiên từ việc thuê ngoài, nhờ vào sự phát triển của phần mềm mã nguồn mở (PMTD) Các quốc gia đang tích cực tham gia vào thế giới PMTD, coi đó là một phần quan trọng trong sự phát triển công nghệ Chẳng hạn, số lượng lập trình viên từ Mexico và Tây Ban Nha, hai quốc gia có truyền thống hạn chế trong ngành công nghiệp phần mềm, đã tham gia đáng kể vào các dự án như GNOME.
Brazil đóng vai trò quan trọng trong lĩnh vực công nghệ phần mềm tự do, với sự tham gia của nhiều lập trình viên và chuyên gia Sự hỗ trợ mạnh mẽ từ các cơ quan nhà nước đã tạo điều kiện thuận lợi cho sự phát triển này Một ví dụ điển hình là gnuLinEx, cho thấy rằng một khu vực với ít truyền thống phát triển phần mềm vẫn có thể thay đổi tình hình thông qua chiến lược mạnh mẽ gắn kết với phần mềm tự do mã nguồn mở.
Trong bối cảnh ra quyết định về việc triển khai giải pháp phần mềm, có những thị trường như dịch vụ Internet và ứng dụng văn phòng mà PMTD trở thành lựa chọn tự nhiên Tuy nhiên, môi trường pháp lý cho PMTD đang thay đổi nhanh chóng trên toàn cầu Sự gia tăng áp dụng bằng sáng chế phần mềm ở nhiều quốc gia cùng với các luật bản quyền mới đang tạo ra khó khăn trong việc phát triển ứng dụng tự do, điển hình là vấn đề liên quan đến trình xem DVD và thuật toán mã hóa CSS.
Vào đầu năm 2002, Chính quyền vùng Extremadura đã công bố dự án gnuLinEx nhằm khuyến khích phát triển một phiên bản GNU/Linux, với mục tiêu chính là triển khai trên hàng ngàn máy tính trong các trường công Extremadura, nằm ở phía tây Tây Ban Nha giáp Bồ Đào Nha, có khoảng 1 triệu dân và chưa từng nổi tiếng về công nghệ, thực tế không có nền công nghiệp phần mềm phát triển.
GnuLinEx đã đóng góp quan trọng vào bức tranh toàn cầu về phần mềm mã nguồn mở (PMTD), không chỉ là một phiên bản mới của GNU/Linux dựa trên Debian mà còn là sự hỗ trợ mạnh mẽ từ chính quyền vùng Extremadura Chính quyền này đã thử nghiệm mô hình sử dụng phần mềm giáo dục và mở rộng ra tất cả các phần mềm trong khu vực, trở thành chính quyền nhà nước đầu tiên của một quốc gia phát triển áp dụng cách tiếp cận này Sự quan tâm xung quanh sáng kiến này đã lan tỏa, với nhiều viện hàn lâm giảng dạy IT sử dụng gnuLinEx, sách giáo khoa được xuất bản và máy tính được bán với gnuLinEx cài sẵn Họ đang xây dựng một hệ sinh thái giáo dục và kinh doanh quanh kinh nghiệm này, và mô hình đã được xuất khẩu ra nhiều cộng đồng tự trị ở Tây Ban Nha, làm nổi bật tầm quan trọng của PMTD trong giáo dục.
Vào cuối những năm 90, mặc dù đã có một số bản phân phối GNU/Linux dễ cài đặt, nhưng Knoppix, ra mắt vào năm 2002, đã thực sự thể hiện ý tưởng này một cách đầy đủ Đây là một CD khởi động có thể chạy trên hầu hết các máy tính cá nhân mà không cần định dạng ổ cứng, cho phép người dùng trải nghiệm một hệ điều hành GNU/Linux hoàn chỉnh với nhiều công cụ hữu ích Knoppix tự động phát hiện phần cứng và cung cấp một loạt chương trình, mang đến trải nghiệm trực tiếp về việc làm việc với GNU/Linux Sự phát triển này đã mở đường cho nhiều bản phân phối tương tự, đáp ứng nhu cầu đa dạng của người dùng.
Vào năm 1999, Sun Microsystems đã mua Stardivision, công ty Đức phát triển StarOffice, một bộ ứng dụng văn phòng tương tự Microsoft Office Năm 2000, Sun phát hành mã nguồn của StarOffice theo giấy phép GPL, tạo ra dự án OpenOffice.org Phiên bản 1.0 của OpenOffice.org ra mắt vào tháng 5/2002, trở thành bộ ứng dụng văn phòng chất lượng cao với chức năng tương tự các sản phẩm văn phòng khác và tương tác tốt với định dạng dữ liệu của Microsoft Office, từ đó trở thành ứng dụng PMTD tham chiếu trong lĩnh vực phần mềm văn phòng.
OpenOffice.org đóng vai trò quan trọng trong việc mở rộng phần mềm mã nguồn mở cho đông đảo người dùng, với khả năng thay thế các bộ văn phòng độc quyền trong môi trường doanh nghiệp Nó có thể hoạt động tốt trên nhiều hệ điều hành, bao gồm cả Microsoft Windows, cho phép người dùng trải nghiệm PMTD mà không cần thay đổi hệ điều hành hiện tại Sự linh hoạt này giúp OpenOffice.org dễ dàng tiếp cận cả các môi trường tự do như GNU/Linux với GNOME hoặc KDE, góp phần thúc đẩy sự chuyển dịch sang phần mềm mã nguồn mở.
Mozilla, Firefox và phần còn lại
Netscape Navigator, ra mắt vào năm 1994, từng chiếm lĩnh thị trường trình duyệt web với hơn 80% thị phần cho đến năm 1996 Tuy nhiên, sự xuất hiện của Internet Explorer trong Windows 95 đã khiến Netscape dần mất thị phần Đến đầu năm 1998, Netscape công bố kế hoạch phân phối mã nguồn của trình duyệt dưới dạng PMTD, khởi động dự án Mozilla vào tháng 3 cùng năm Dự án này trải qua giai đoạn không chắc chắn và bi quan, đặc biệt khi người đứng đầu Jamie Zawinski rời bỏ, dẫn đến việc không có sản phẩm nào được phát hành trong một thời gian dài.
Vào tháng 01/2000, dự án Mozilla đã phát hành phiên bản M13, đánh dấu sự ra mắt của một phiên bản ổn định đầu tiên Đến tháng 05/2002, phiên bản 1.0 chính thức được phát hành, trở thành phiên bản ổn định đầu tiên sau 4 năm kể từ khi mã nguồn của Netscape Navigator được công bố.
Mozilla đã trở thành một thực tế quan trọng trong lĩnh vực trình duyệt, mặc dù đã đến muộn so với sự thống trị của Internet Explorer vào đầu những năm 2000 Dự án Mozilla không chỉ cho ra đời trình duyệt Mozilla mà còn phát triển Firefox, một sản phẩm chủ lực đã dần dần chiếm lĩnh thị phần của các trình duyệt khác từ khi ra mắt năm 2005 Sự xuất hiện của Mozilla đã lấp đầy khoảng trống trong thị trường phần mềm mã nguồn mở, đặc biệt là khi không có trình duyệt tự do nào với giao diện đồ họa trước đó Nhiều dự án dựa trên Mozilla đã được phát triển, tạo ra một loạt trình duyệt phong phú Sự kết hợp giữa Mozilla Firefox và OpenOffice.org đã cho phép người dùng thực hiện hầu hết các tác vụ trong môi trường Microsoft Windows, đồng thời hỗ trợ trên các hệ điều hành như GNU/Linux và FreeBSD Đây là bước chuyển đổi quan trọng từ phần mềm proprietary sang phần mềm mã nguồn mở trong môi trường văn phòng, giúp người dùng dễ dàng chuyển đổi sang hệ điều hành tự do mà không gặp khó khăn.
Tương lai: Một tiến trình đầy trở ngại?
Tất nhiên, khó đoán trước được tương lai Và điều đó chắc chắn không phải là mục tiêu của chúng tôi
Thay vì dự đoán tương lai của PMTD, chúng tôi sẽ chỉ ra những thách thức mà nó sẽ phải đối mặt, những vấn đề đã tồn tại trong thời gian dài Khả năng của PMTD trong việc vượt qua những trở ngại này sẽ quyết định tình trạng của nó trong những năm tới.
FUD (sợ hãi, không chắc chắn, nghi ngờ) là một kỹ thuật phổ biến trong lĩnh vực công nghệ thông tin, thường được các đối thủ cạnh tranh của PMTD sử dụng để làm giảm lòng tin vào PMTD thông qua những biện hộ và thành công khác nhau Tuy nhiên, PMTD đã trở nên khá miễn dịch trước các kỹ thuật này, có lẽ nhờ vào sự phức tạp và những phương thức đa dạng mà công ty áp dụng.
Nhiều công ty đang thử nghiệm các giới hạn của PMTD để phát triển các mô hình tương tự, nhằm cung cấp cho khách hàng những giải pháp mới Tuy nhiên, điều này gây ra sự lúng túng cho cả khách hàng và lập trình viên, vì họ phải tham khảo tài liệu chi tiết để hiểu rõ về các sản phẩm không có ưu điểm rõ rệt như PMTD Một trong những mô hình nổi bật trong lĩnh vực này là chương trình Mã nguồn Chia sẻ (Shared Source) của Microsoft.
Nhiều người sử dụng phần mềm mã nguồn mở (PMTD) do thiếu tri thức, nghĩ rằng nó miễn phí hoặc "hợp thời trang" Nếu không tìm hiểu kỹ về các ưu điểm của PMTD, họ có nguy cơ không khai thác hết tiềm năng của nó Những giả thiết trong PMTD thường khác biệt so với PMSHĐQ, đòi hỏi phân tích tối thiểu để nhận ra rằng những gì hiệu quả trong một trường hợp có thể không áp dụng được trong trường hợp khác Sự thiếu hụt tri thức này dẫn đến sự không thỏa mãn và mất cơ hội cho cá nhân hoặc tổ chức khi tiếp cận PMTD.
Những cản trở pháp lý đang trở thành vấn đề chính mà PMTD phải đối mặt trong những năm tới Mặc dù môi trường pháp lý trong thập niên 80 và nửa đầu 90 đã không lý tưởng, nhưng vẫn cho phép PMTD phát triển tự do Tuy nhiên, sự mở rộng của việc cấp bằng sáng chế cho phần mềm và các quy định về bản quyền hiện nay đang tạo ra những rào cản ngày càng lớn, hạn chế khả năng sáng tạo của lập trình viên và ảnh hưởng đến sự thâm nhập của PMTD vào các lĩnh vực ứng dụng quan trọng.
Tóm lược
Chương này khám phá lịch sử của phần mềm tin học Trong những năm 60, thị trường phần mềm chủ yếu bị chi phối bởi các máy tính lớn của IBM, nơi phần mềm thường được phân phối cùng với phần cứng và mã nguồn Đến những năm 70, phần mềm bắt đầu được bán riêng lẻ, dẫn đến sự xuất hiện của các phân phối sở hữu độc quyền, không bao gồm mã nguồn và không cho phép sửa đổi hay phân phối lại, trở thành lựa chọn chủ yếu trên thị trường.
Vào thập kỷ 1970, Bell Labs của AT&T đã bắt đầu phát triển hệ điều hành Unix, dẫn đến sự ra đời của Unix BSD Sự tiến hóa của Unix, cùng với sự phát triển của Internet, đã trở thành một môi trường thử nghiệm cho các phương pháp hợp tác mới, sau này trở nên phổ biến trong lĩnh vực phát triển phần mềm.
Trong năm 1984, Richard Stallman đã bắt đầu làm việc trong dự án GNU, sáng lập FSF, viết giấy phép
GPL, và nói chung, thiết lập ra những quỹ của PMTD như chúng ta biết bây giờ.
Vào những năm 90, Internet đã phát triển mạnh mẽ, mở ra những kênh giao tiếp và phân phối mới cho cộng đồng phần mềm mã nguồn mở Năm 1991, Linus Torvalds bắt đầu phát triển nhân Linux, góp phần hoàn thiện hệ điều hành GNU, với các thành phần như trình biên dịch GCC, trình soạn thảo Emacs và hệ thống cửa sổ X Window Kết quả là các hệ điều hành GNU/Linux ra đời, phân nhánh thành nhiều phiên bản như Red Hat GNU/Linux và Debian GNU/Linux Đến cuối những năm 90, các hệ thống này đã hoàn thiện với hai môi trường giao diện màn hình nổi bật: KDE và GNOME.
Trong thập niên 2000, PMTD đã chiếm ưu thế trong nhiều lĩnh vực, đặc biệt là trong các máy chủ web, nơi Apache là lựa chọn hàng đầu Sự xuất hiện của các công cụ mới đã đáp ứng một loạt các yêu cầu về công nghệ thông tin.
Những độc giả có quan tâm sẽ thấy trong Phụ lục B một danh sách của một số ngày tháng thích hợp nhất trong lịch sử của PMTD.
3 Các khía cạnh pháp lý
“Các giấy phép cho hầu hết các phần mềm được thiết kế để lấy đi sự tự do của bạn để chia sẻ và thay đổi nó”.
Giấy phép Công cộng Chung GNU, phiên bản 2 (GPLv2).
Chương này phân tích các khía cạnh pháp lý quan trọng liên quan đến PMTD, bắt đầu bằng việc giới thiệu các khái niệm cơ bản về quyền sở hữu trí tuệ và sở hữu công nghiệp Tiếp theo, chúng tôi cung cấp định nghĩa chi tiết về PMTD, PMNM và các khái niệm liên quan Ngoài ra, chương cũng xem xét các giấy phép PMTD phổ biến và ảnh hưởng của chúng đến các mô hình kinh doanh và phát triển, một chủ đề sẽ được khai thác sâu hơn trong chương 5.
Giới thiệu ngắn gọn về sở hữu trí tuệ
Bản quyền
Bản quyền bảo vệ sự diễn đạt của nội dung, không phải bản thân nội dung, nhằm bù đắp cho các tác giả sách và tác phẩm nghệ thuật Các tác phẩm được bảo vệ có thể diễn đạt ý tưởng, tri thức hoặc phương pháp một cách tự do, nhưng việc tái sinh chúng mà không có sự cho phép là bị cấm Bảo vệ bản quyền tự động có hiệu lực khi tác phẩm được xuất bản, và hiện đã được mở rộng cho các chương trình máy tính cùng một số biên soạn dữ liệu trong lĩnh vực địa lý.
Luật Sở hữu Trí tuệ (LPI) tại Tây Ban Nha, cùng với các luật tương tự ở các quốc gia khác, được xây dựng dựa trên Công ước Berne năm 1886 nhằm bảo vệ các tác phẩm văn học và nghệ thuật Quyền sở hữu trí tuệ được chia thành hai loại: quyền đạo đức và quyền kinh tế Quyền đạo đức đảm bảo tác giả kiểm soát việc phân phối tác phẩm, nhận diện nguồn gốc, tôn trọng tính toàn vẹn của tác phẩm và quyền sửa đổi hoặc rút lại tác phẩm Trong khi đó, quyền kinh tế cho phép tác giả khai thác tác phẩm về mặt tài chính, có thể chuyển nhượng một phần hoặc toàn bộ cho bên thứ ba Quyền đạo đức có hiệu lực suốt đời hoặc không hạn chế, trong khi quyền trí tuệ có thời hạn 70 năm sau khi tác giả qua đời theo luật Tây Ban Nha.
Việc nhượng lại quyền sở hữu trí tuệ được thực hiện qua hợp đồng gọi là giấy phép, thường là giấy phép sử dụng không dành riêng, tự động chấp nhận khi mở hoặc cài đặt sản phẩm mà không cần ký kết Người nhận không chấp nhận giấy phép sẽ không có quyền hợp pháp theo luật Giấy phép không thể hạn chế quyền được pháp luật trao, như quyền sao chép cá nhân tác phẩm nghệ thuật, nhưng không áp dụng cho chương trình Theo Luật Sở hữu trí tuệ Tây Ban Nha năm 1996 và sửa đổi năm 2006, người dùng có quyền tạo bản sao lưu, nghiên cứu và sửa đổi chương trình để phù hợp với nhu cầu cá nhân, mặc dù việc truy cập mã nguồn thường khó khăn Các quyền này không thể bị hạn chế qua giấy phép, mặc dù có xu hướng pháp lý đang xem xét nhằm hạn chế quyền của người sử dụng Các biên soạn tổ chức tác phẩm hoặc dữ liệu của bên thứ ba cũng phải tuân thủ bản quyền, với các điều khoản thời gian khác nhau.
Công nghệ thông tin mới, đặc biệt là web, đã làm thay đổi sâu sắc việc bảo vệ bản quyền, vì việc sao chép nội dung trở nên dễ dàng hơn rất nhiều so với việc bảo vệ chính nội dung đó.
Các chương trình và tác phẩm nghệ thuật như âm nhạc, hình ảnh, phim, và văn học có thể hoạt động tự động trên máy tính mà không cần nỗ lực con người Tuy nhiên, các thiết kế và phát minh sáng chế cần được xây dựng và đưa vào sản xuất Việc tạo ra của cải mà không tốn chi phí đã dẫn đến tình trạng công chúng, đặc biệt ở các nước nghèo, nhân bản các chương trình mà không trả tiền cho giấy phép Điều này đang được coi là một "hành động độc hại", khác với việc ăn cắp tài sản vật lý Các nhà sản xuất chương trình, cá nhân hoặc liên minh như BSA, đang gây áp lực lớn lên chính phủ để mua giấy phép nhằm ngăn chặn tình trạng bị coi là ăn cướp.
Thuật ngữ "ăn cướp" hiện được sử dụng phổ biến như một từ đồng nghĩa cho việc vi phạm sở hữu trí tuệ, đặc biệt là trong việc sao chép trái phép các chương trình, âm nhạc và phim ảnh Tuy nhiên, khái niệm này có vẻ bị cường điệu hóa, vì trong từ điển của Học Viện Ngôn ngữ Hoàng gia Tây Ban Nha, nó mang ý nghĩa tượng trưng, với nguồn gốc liên quan đến "sự cướp bóc bằng bạo lực trên biển." Điều này lý giải cho lời khuyên của Richard Stallman về việc tránh sử dụng thuật ngữ này, nhấn mạnh rằng có những từ và cụm từ nặng nề cần được xem xét cẩn thận.
Để bảo vệ bản quyền nội dung, các hệ thống quản lý quyền số (DRM) được sử dụng nhằm kiểm soát truy cập và sử dụng dữ liệu số Tuy nhiên, việc áp dụng DRM đã nhận nhiều chỉ trích vì nó áp đặt các hạn chế quá mức, dẫn đến việc các tổ chức như FSF khuyến cáo thuật ngữ này nên được hiểu là "quản lý những hạn chế số" Điều này nhằm phản ánh sự tước đoạt quyền lợi của người dùng để phục vụ cho yêu cầu bản quyền.
Bí mật thương mại
Các công ty có thể tận dụng bí mật thương mại như một tài nguyên quan trọng để tối đa hóa lợi nhuận từ các khoản đầu tư, nhờ vào sự bảo vệ của luật sở hữu công nghiệp Để bảo vệ thông tin nhạy cảm, các công ty cần thực hiện các biện pháp bảo mật thích hợp Đối với các sản phẩm hóa học và dược phẩm, chính phủ cam kết giữ bí mật các dữ liệu đã được đệ trình, miễn là không có yêu cầu công khai bắt buộc.
Ngành công nghiệp phần mềm sở hữu độc quyền là một trong những lĩnh vực nổi bật trong việc bảo vệ bí mật thương mại Các công ty thường cung cấp các chương trình đã được biên dịch mà không cho phép truy cập vào mã nguồn, nhằm ngăn chặn việc phát triển các chương trình dẫn xuất từ sản phẩm của họ.
Sự bảo vệ bí mật thương mại có thể bị coi là bất công, vì nó có thể ngăn cản xã hội tiếp cận những tri thức hữu ích Một số luật pháp đã nhận thức được điều này và cho phép kỹ thuật nghịch đảo để hạn chế hoạt động này tại nhiều quốc gia, trong khi ở những nơi khác, việc thực hiện chỉ được phép nếu có sự tương thích nhất định.
Bí mật thương mại có thể mang lại lợi thế cạnh tranh vượt trội hơn cả bằng sáng chế, vì nó cho phép doanh nghiệp đưa sản phẩm ra thị trường trước khi đối thủ có thể sao chép thông qua kỹ thuật nghịch đảo.
Sản phẩm càng tinh vi và phức tạp, thì mức độ tổn thất cho sự cạnh tranh để tái sinh chúng càng cao, trong khi những sản phẩm tầm thường dễ dàng bị sao chép Sự bắt chước và cải tiến đã đóng vai trò quan trọng trong sự phát triển của các siêu cường như Mỹ và Nhật Bản, đồng thời cũng là yếu tố thiết yếu cho sự độc lập tài chính của các quốc gia đang phát triển.
Các bằng sáng chế và các mô hình tiện ích
Một phương án thay thế cho bí mật thương mại là bằng sáng chế, cho phép độc quyền từ 17 đến 25 năm đổi lấy việc công khai hóa phát minh Điều này khuyến khích nghiên cứu cá nhân mà không gây tốn kém cho người đóng thuế Người giữ bằng sáng chế có quyền quyết định việc cấp phép cho người khác sử dụng phát minh và mức phí cần trả cho giấy phép.
Hệ thống bằng sáng chế, theo học thuyết chính thống, được cho là khuyến khích đổi mới sáng tạo Tuy nhiên, ngày càng có nhiều quan điểm cho rằng hệ thống này thực sự cản trở đổi mới, do việc triển khai kém hiệu quả hoặc do sự hiểu lầm về chức năng của nó (François-René Rideau, "Các bằng sáng chế là một sự vụ lý ngớ ngẩn về kinh tế", 2000).
Sự đổi mới sáng tạo đã trải qua nhiều thay đổi theo thời gian, với áp lực lớn để mở rộng hệ thống bao gồm các thuật toán, chương trình, mô hình kinh doanh, và cả các yếu tố tự nhiên như gen và hình thái sống TRIPS yêu cầu hệ thống bằng sáng chế không phân biệt đối xử với bất kỳ lĩnh vực tri thức nào Tổ chức Sở hữu Trí tuệ Thế giới (WIPO) đang nỗ lực giảm bớt yêu cầu đối với đổi mới sáng tạo nhằm tạo điều kiện thuận lợi hơn cho việc cấp bằng sáng chế Mỹ, với những yêu cầu tối thiểu về tính khả thi cấp bằng sáng chế, thường tham gia vào các cuộc tranh luận với các quốc gia khác để áp dụng tiêu chuẩn của mình, trong khi quên rằng chính họ đã từng từ chối chấp nhận bằng sáng chế từ các nước chưa phát triển.
Sau khi nhận bằng sáng chế, quyền của chủ sở hữu không phụ thuộc vào chất lượng phát minh hay nỗ lực để có được nó Chi phí duy trì và kiện tụng liên quan đến bằng sáng chế thường chỉ nằm trong khả năng của các công ty lớn, cho phép họ duy trì một danh mục bằng sáng chế rộng lớn và chống lại cạnh tranh Với việc dễ dàng có được các bằng sáng chế cho những giải pháp thông thường hoặc phổ biến, các công ty này có thể độc quyền một phạm vi hoạt động kinh tế rộng lớn.
Việc lập trình hiện nay trở nên rủi ro do sự tồn tại của nhiều bằng sáng chế, khiến cho việc phát triển các chương trình phức tạp dễ dẫn đến vi phạm Khi nhiều công ty cùng nghiên cứu giải quyết một vấn đề, khả năng họ đạt được giải pháp tương tự là rất cao Tuy nhiên, chỉ một công ty, thường là công ty có nhiều tài nguyên nhất, sẽ giành được bằng sáng chế cho phát minh của mình, điều này ngăn cản các công ty khác có cơ hội thu hồi đầu tư của họ.
Sự phát triển công nghệ phức tạp có thể trở thành cơn ác mộng nếu không kiểm tra kỹ lưỡng các bằng sáng chế liên quan trước khi tìm giải pháp Đặc biệt trong lĩnh vực PMTD, việc vi phạm bằng sáng chế thuật toán dễ dàng xảy ra qua việc kiểm tra mã nguồn Mặc dù hiện tại châu Âu cấm cấp bằng sáng chế cho thuật toán, khả năng này có thể thay đổi trong tương lai gần, có thể ngay khi độc giả đang đọc bài viết này.
Thương hiệu và logo được đăng ký
Thương hiệu và logo đại diện cho chất lượng và sự đầu tư công khai, nhưng trong thế giới phần mềm mã nguồn mở (PMTD), chúng không được coi trọng do chi phí đăng ký Chỉ một số tên quan trọng như Nguồn Mở, Debian, GNOME, GNU, và OpenOffice.org được đăng ký tại một vài quốc gia Việc không đăng ký tên đã dẫn đến những vấn đề pháp lý, như trường hợp ở Mỹ và Hàn Quốc vào những năm 1990, khi người khác đăng ký tên Linux và yêu cầu phí sử dụng, gây ra chi phí pháp lý và yêu cầu chứng minh quyền sử dụng trước ngày đăng ký.
Các giấy phép của PMTD
Các loại giấy phép
Nhiều dự án hiện nay thường sử dụng một nhóm nhỏ khoảng 4 hoặc 5 loại giấy phép tự do, vì lý do thực tế và thiếu tài nguyên để thiết kế giấy phép riêng Hơn nữa, người dùng thường ưu tiên chọn giấy phép nổi tiếng thay vì phải đọc và phân tích các giấy phép phức tạp.
Có sự biên tập và thảo luận về các giấy phép không tự do hoặc không tương thích với GPL từ quan điểm của FSF trong tài liệu "Các giấy phép Tự do" Sự khác biệt triết lý giữa FSF và OSI thể hiện qua danh sách giấy phép của OSI Một số giấy phép như Giấy phép Nguồn Công cộng Apple phiên bản 1.2 (APSL v1.2) bị FSF coi là không tự do do yêu cầu công khai tất cả các thay đổi và khả năng hủy bỏ đơn phương Tuy nhiên, áp lực từ phân loại này đã khiến Apple phát hành phiên bản 1.0 vào tháng 08/2003, mà FSF sau đó đã công nhận là giấy phép tự do.
Giấy phép phần mềm tự do (PMTD) có thể được chia thành hai loại chính Loại đầu tiên là các giấy phép dễ dãi, cho phép phân phối và sửa đổi phần mềm mà không đặt ra điều kiện đặc biệt nào cho việc phân phối lại lần hai Loại thứ hai, được gọi là giấy phép mạnh hay giấy phép copyleft, như GNU GPL, yêu cầu tuân thủ các điều kiện nhất định khi phân phối lại phần mềm, nhằm đảm bảo rằng các điều kiện của giấy phép được duy trì trong các lần phân phối tiếp theo.
Nhóm đầu tiên nhấn mạnh sự tự do của người nhận chương trình trong việc sử dụng sản phẩm theo ý muốn, trong khi nhóm thứ hai chú trọng đến quyền tự do của những người có tiềm năng nhận tác phẩm dẫn xuất, yêu cầu rằng các sửa đổi và phân phối lại phải tuân thủ điều khoản của giấy phép gốc Sự khác biệt giữa hai loại giấy phép này vẫn là một vấn đề gây tranh cãi trong cộng đồng phần mềm mã nguồn mở Tuy nhiên, cần lưu ý rằng tất cả đều thuộc về các giấy phép tự do.
Khái niệm copyleft, khi áp dụng cho giấy phép, chủ yếu được sử dụng bởi Quỹ Tự do Phần mềm (FSF) để chỉ các giấy phép của riêng quỹ này Copyleft mang ý nghĩa tương tự như các giấy phép mạnh được nhắc đến trong văn bản này.
Những giấy phép dễ dãi
Giấy phép dễ dãi, còn được gọi là giấy phép hào phóng hoặc tối thiểu, không áp đặt nhiều điều kiện lên người nhận phần mềm, cho phép họ sử dụng, phân phối lại và sửa đổi Mặc dù cách tiếp cận này mang lại sự tự do tối đa cho người nhận, nhưng nó cũng có thể được xem là thiếu sót trong việc đảm bảo rằng quyền tự do đó được duy trì khi phần mềm được phân phối lại Thực tế, nhiều giấy phép này cho phép phần mềm được phát hành theo giấy phép dễ dãi nhưng lại có thể bị phân phối lại dưới giấy phép sở hữu độc quyền.
Giấy phép BSD (Berkeley Software Distribution) là một trong những giấy phép mã nguồn mở nổi tiếng nhất, xuất phát từ các phiên bản Unix của Đại học Berkeley, California Giấy phép này yêu cầu người sử dụng phải công nhận các tác giả, đồng thời cho phép phân phối lại dưới cả hai định dạng nhị phân và mã nguồn mà không có bất kỳ ràng buộc nào Ngoài ra, giấy phép BSD cũng cho phép thực hiện các thay đổi và tích hợp vào các chương trình khác một cách tự do, gần như không có hạn chế.
Một trong những hệ quả thực tế của giấy phép BSD là việc thúc đẩy các chuẩn, khi các lập trình viên nhận thấy không có rào cản trong việc làm cho các chương trình tương thích với triển khai cài đặt tham chiếu Điều này đã góp phần vào sự phổ biến nhanh chóng của các giao thức Internet và giao diện lập trình dựa trên các khe cắm (socket), vì nhiều lập trình viên thương mại đã phát triển triển khai của họ từ giao diện lập trình của Đại học Berkeley.
Giấy phép dễ dãi, như BSD, X Window, Tcl/Tk và Apache, rất phổ biến trong cộng đồng phần mềm Những giấy phép này ra đời từ các phần mềm được phát triển tại các trường đại học thông qua các dự án nghiên cứu được Chính phủ tài trợ.
Tại Mỹ, các trường đại học không bán các chương trình này vì chúng đã được Chính phủ tài trợ, tức là do người đóng thuế chi trả Điều này có nghĩa là bất kỳ công ty hoặc cá nhân nào cũng có thể sử dụng những phần mềm này gần như không có hạn chế nào.
Chương trình được phân phối dưới giấy phép dễ dãi có thể dẫn đến việc tạo ra phiên bản mới với quyền sở hữu độc quyền Các chỉ trích đối với giấy phép BSD chỉ ra rằng điều này có thể gây nguy hiểm cho sự tự do của các phiên bản tương lai Ngược lại, những người ủng hộ giấy phép này cho rằng nó thể hiện tối đa sự tự do, cho phép người dùng thực hiện hầu hết mọi thứ với phần mềm.
Hầu hết các giấy phép dễ dãi hiện nay đều là bản sao của giấy phép gốc từ Berkeley, chỉ sửa đổi các phần liên quan đến quyền tác giả Một số giấy phép, như giấy phép của dự án Apache, bổ sung thêm điều khoản cấm sử dụng tên gốc cho các phiên bản phân phối lại Tất cả các giấy phép này thường bao gồm điều khoản tương tự như BSD, cấm sử dụng tên của người giữ bản quyền nhằm khuyến khích phát triển các sản phẩm dẫn xuất.
Tất cả các giấy phép, bao gồm cả loại BSD, đều có một hạn chế về sự đảm bảo, thực chất là một sự khước từ nhằm tránh các khiếu nại pháp lý liên quan đến các đảm bảo tuyệt đối Mặc dù sự khước từ này trong PMTD đã từng bị chỉ trích, nhưng nó vẫn là một thực tế phổ biến trong PMSHĐQ, nơi mà thường chỉ đảm bảo rằng phương pháp được sử dụng là chính xác và chương trình hoạt động trong điều kiện nghi ngờ.
Phác thảo tóm lược về giấy phép BSD
Copyright © [của người chủ sở hữu] All rights reserved.
Việc phân phối lại và sử dụng mã nguồn cũng như mã nhị phân, có hoặc không có sửa đổi, được phép nếu các điều kiện sau đây được đáp ứng.
1 Việc phân phối lại mã nguồn phải tái sinh lưu ý về bản quyền, và liệt kê những điều kiện và sự khước từ này.
2 Việc phân phối lại ở dạng nhị phân phải tái sinh lưu ý về bản quyền và liệt kê những điều kiện và sự khước từ này trong tài liệu được đưa ra.
3 Tên của chủ sở hữu và tên của những người đóng góp có thể không được sử dụng để xác nhận các sản phẩm dẫn xuất từ phần mềm này nếu không có quyền.
Chương trình này được cung cấp "như nó có", và mọi sự cho phép liên quan đến tính có thể thương mại hoặc sự phù hợp cho mục đích cụ thể đều bị từ chối Người chủ sở hữu không chịu trách nhiệm về bất kỳ thiệt hại nào phát sinh từ việc sử dụng chương trình, bao gồm mất dữ liệu, mất lợi nhuận hoặc gián đoạn kinh doanh.
Tiếp theo chúng ta mô tả ngắn gọn một ít giấy phép dễ dãi:
Giấy phép X Window, phiên bản 11 (X11), là giấy phép phân phối hệ thống X Window, hệ thống cửa sổ phổ biến trong môi trường Unix và GNU/Linux Giấy phép này tương tự như giấy phép BSD, cho phép phân phối, sử dụng và sửa đổi mà không có hạn chế nào Mặc dù đôi khi được gọi là giấy phép MIT, điều này không chính xác vì MIT đã sử dụng nhiều dạng giấy phép khác nhau Các sản phẩm dẫn xuất từ hệ thống X Window, như XFree86, cũng được phân phối theo giấy phép này.
Giấy phép Zope Public License 2.0 (ZPL) là giấy phép được sử dụng cho việc phân phối Zope, một máy chủ ứng dụng, cùng với các sản phẩm liên quan Giấy phép này tương tự như giấy phép BSD nhưng có điểm khác biệt là nó chỉ cấm việc sử dụng các thương hiệu đã được đăng ký bởi tập đoàn Zope.
Giấy phép Apache là giấy phép chính được áp dụng cho hầu hết các chương trình của dự án Apache, tương tự như giấy phép BSD Một số chương trình tự do không có giấy phép cụ thể mà tác giả công bố thuộc về miền công cộng, cho phép tác giả từ bỏ mọi quyền đối với chương trình Điều này có nghĩa là chương trình có thể được sửa đổi, phân phối và sử dụng theo bất kỳ cách nào, tương tự như các chương trình theo giấy phép BSD.
Các giấy phép mạnh
GNU General Public Licence (GNU GPL)
Giấy phép Công cộng Chung GNU (GPL) được phát triển bởi FSF vào năm 1991 và là giấy phép phổ biến nhất trong lĩnh vực phần mềm tự do Ban đầu, GPL được thiết kế cho các phần mềm của FSF, nhưng đã nhanh chóng trở thành lựa chọn ưa chuộng cho hơn 70% dự án trên Freshmeat, bao gồm cả những dự án hàng đầu như nhân Linux.
Giấy phép GPL là một khía cạnh thú vị trong pháp luật bản quyền, vì nó không chỉ giới hạn quyền của người sử dụng mà còn bảo vệ và đảm bảo quyền lợi cho họ Hành động này được gọi là copyleft, một trò chơi chữ thay thế "phải" bằng "trái" Một người có khiếu hài hước đã sáng tạo ra khẩu hiệu "copyleft, mọi quyền được nghịch đảo".
Giấy phép GPL cho phép phân phối lại mã nguồn và mã nhị phân, yêu cầu cung cấp mã nguồn khi phân phối ở dạng nhị phân Nó cũng cho phép thực hiện các sửa đổi mà không bị hạn chế, nhưng việc phân phối lại mã nguồn GPL tích hợp với mã nguồn khác chỉ được phép nếu có giấy phép tương thích Hiệu ứng này, thường được gọi là hiệu ứng virus của GPL, ngụ ý rằng một khi mã nguồn đã được phát hành theo các điều kiện này, nó sẽ không thể thay đổi được.
Một giấy phép không tương thích với GPL khi nó hạn chế các quyền mà GPL đảm bảo, phủ nhận mệnh đề của nó hoặc áp đặt hạn chế mới Chẳng hạn, giấy phép BSD hiện tại là tương thích, trong khi giấy phép Apache không tương thích vì yêu cầu ghi nhận nguồn gốc của mã từ các quyền sở hữu Điều này không có nghĩa là các chương trình với hai giấy phép này không thể sử dụng cùng nhau hoặc tích hợp, mà chỉ ra rằng việc phân phối các chương trình tích hợp này là không thể, do không tuân thủ đồng thời các điều kiện phân phối của cả hai giấy phép.
Giấy phép GPL được thiết kế để bảo đảm mã nguồn luôn tự do, ngăn chặn việc trở thành sở hữu độc quyền Chương trình và các sửa đổi của nó không thể được cấp phép dưới giấy phép khác ngoài GPL Những người ủng hộ giấy phép BSD cho rằng điều này hạn chế tự do, trong khi những người ủng hộ GPL tin rằng nó bảo vệ sự tự do của phần mềm GPL tối đa hóa tự do cho người sử dụng, trong khi BSD tối đa hóa tự do cho lập trình viên Tuy nhiên, cần lưu ý rằng lập trình viên ở đây không bao gồm các tác giả, vì nhiều tác giả ủng hộ GPL để bảo vệ quyền lợi của họ, buộc các đối thủ phải công bố sửa đổi khi phân phối lại phần mềm, điều này không bắt buộc với giấy phép BSD.
Giấy phép GPL, với triết lý của FSF, khẳng định rằng phần mềm không nên có chủ sở hữu, theo Richard Stallman Mặc dù phần mềm GPL có tác giả, quyền sở hữu phần mềm sẽ được chuyển giao cho người sở hữu nó, không phải cho người sáng tạo Điều này thể hiện sự đối lập tự nhiên giữa giấy phép này và bản quyền truyền thống.
Giấy phép này bao gồm các khước từ nhằm bảo vệ quyền lợi của các tác giả Để duy trì uy tín của các tác giả gốc, mọi sự sửa đổi đối với tệp nguồn cần phải được ghi chú rõ ràng, bao gồm ngày tháng và tên tác giả của sự sửa đổi đó.
GPL yêu cầu rằng nếu mã nguồn chứa các thuật toán được cấp bằng sáng chế, người phát hành phải cung cấp giấy phép miễn phí để sử dụng bằng sáng chế, nếu không, mã nguồn không thể được phân phối theo GPL Điều này phản ánh sự khác biệt trong quy định về bằng sáng chế phần mềm giữa Mỹ và châu Âu.
Phiên bản mới nhất của giấy phép GPL, phiên bản 2, đã được xuất bản năm 1991 (dù lúc viết phiên bản
Giấy phép GPL phiên bản 3 đại diện cho một bước tiến quan trọng trong việc cấp phép phần mềm, khuyến khích các tác giả tuân thủ theo các điều kiện của phiên bản 2 hoặc các phiên bản sau của FSF Tuy nhiên, một số nhà phát triển, như Linus Torvalds, vẫn chọn giữ phần mềm của họ dưới điều kiện của phiên bản 2, điều này có thể khiến họ tách biệt khỏi những tiến bộ trong tương lai mà FSF có thể mang lại.
Phiên bản 3 của GPL (http://gplv3.fsf.org) dự kiến sẽ được cập nhật để phù hợp với tình hình phần mềm hiện tại, tập trung vào các vấn đề như bằng sáng chế, quản lý quyền số (DRM) và các hạn chế khác đối với tự do phần mềm Ví dụ, bản phác thảo hiện tại (tháng 05/2007) không cho phép nhà sản xuất phần cứng khóa việc sử dụng các module phần mềm cụ thể nếu chúng không có chữ ký số từ một tác giả xác định.
Một ví dụ điển hình về tình trạng này là các đầu ghi video số TiVo, khi họ cung cấp mã nguồn cho toàn bộ phần mềm của mình (được cấp phép theo GPLv2) nhưng lại không cho phép sửa đổi mã nguồn để sử dụng trong các phần cứng khác.
Giấy phép này không cho phép các phần mềm hoạt động trong môi trường đã được thiết lập sẵn, đặc biệt là khi sử dụng các nhân không được ký, vì việc này bị cấm phân phối và được coi là cần thiết vì lý do an ninh.
Giấy phép GPLv3 đã gây ra sự đối lập giữa các lập trình viên phát triển nhân Linux, bao gồm cả Linus Torvalds, do yêu cầu sử dụng các thành phần phần mềm được ký Họ lo ngại rằng điều này có thể dẫn đến việc hạn chế tính tự do của phần mềm, đặc biệt khi các chữ ký chỉ áp dụng cho những nền tảng phần cứng và phần mềm cụ thể Mặc dù FSF đồng ý về việc sử dụng cơ chế chữ ký vì lý do an ninh, nhưng họ cũng cảnh báo rằng việc cấm các thành phần không được ký có thể tạo ra những kịch bản hạn chế sự tự do sửa đổi mã nguồn trên nhiều nền tảng khác nhau.
The GNU Lesser General Public Licence (GNU LGPL)
Giấy phép Công cộng Chung Nhỏ GNU (GNU LGPL, phiên bản 2.1, 02/1999) là một giấy phép của FSF, thường được gọi tắt là LGPL Giấy phép này ban đầu được thiết kế để sử dụng cho các thư viện (chữ L đại diện cho library) và gần đây đã được sửa đổi để được xem như là "cô em nhỏ" của GPL.
Giấy phép LGPL cho phép các chương trình tự do tích hợp với các phần mềm khác mà không gặp nhiều hạn chế, khác với GPL Mục đích ban đầu của giấy phép này là khuyến khích việc sử dụng và phát triển các thư viện, nhưng sau khi ra mắt, FSF đã nhận thấy rằng các thư viện tự do không được phổ biến như mong đợi Do đó, họ đã khuyên không nên sử dụng LGPL trừ trong những trường hợp đặc biệt Hiện nay, nhiều chương trình không phải thư viện cũng được cấp phép theo LGPL, như trình duyệt Mozilla và bộ phần mềm văn phòng OpenOffice.org.
4 Trường hợp này đã gợi ra việc sử dụng từ tivoisation (tivo hóa) đối với các trường hợp tương tự đã xảy ra.
Phân phối theo vài giấy phép
Cho đến nay, chúng ta đã giả định rằng mỗi chương trình chỉ được phân phối theo một giấy phép duy nhất, quy định các điều kiện sử dụng và phân phối Tuy nhiên, một tác giả có thể phát hành tác phẩm của mình dưới nhiều giấy phép khác nhau Điều này cần được hiểu rằng mỗi ấn phẩm là một tác phẩm mới, và các phiên bản khác nhau có thể có sự khác biệt chỉ ở giấy phép Hầu hết thời gian, điều này phụ thuộc vào mong muốn của người sử dụng về việc sử dụng phần mềm, do đó họ cần xem xét các điều khoản của từng giấy phép.
Một trong những ví dụ nổi bật về giấy phép đôi là thư viện Qt, được phát triển cho môi trường desktop KDE Trolltech, công ty Na Uy, đã phát hành Qt với giấy phép độc quyền nhưng không thu phí cho các chương trình không sử dụng vì mục đích thương mại Điều này khiến KDE chọn Qt vào giữa thập kỷ 90, dẫn đến tranh cãi với FSF khi KDE hoàn toàn phụ thuộc vào thư viện sở hữu Sau đó, GNOME nổi lên như đối thủ tự do của KDE Để giải quyết tranh cãi, Trolltech quyết định áp dụng hệ thống giấy phép đôi cho Qt: các chương trình GPL có thể sử dụng phiên bản Qt GPL, trong khi các chương trình với giấy phép không tương thích phải mua giấy phép đặc biệt Giải pháp này đã làm hài lòng tất cả các bên, và KDE hiện được công nhận là PMTD.
Các ví dụ nổi bật về giấy phép đôi bao gồm StarOffice và OpenOffice.org, cũng như Netscape Communicator và Mozilla Trong những trường hợp này, sản phẩm đầu tiên thuộc quyền sở hữu độc quyền, trong khi sản phẩm thứ hai là phiên bản tự do, thường tuân theo các điều kiện của một số giấy phép tự do.
Mặc dù các dự án tự do ban đầu bị hạn chế, nhưng các phiên bản sở hữu độc quyền đã phát triển theo con đường riêng của chúng, dẫn đến việc ngày nay chúng đạt được mức độ độc lập cao.
Tài liệu chương trình
Tài liệu đi kèm với chương trình là phần thiết yếu, cung cấp giải thích về mã nguồn, như được công nhận bởi Luật Sở hữu Trí tuệ của Tây Ban Nha Việc tích hợp này cho thấy rằng các quyền tự do tương tự cũng cần áp dụng cho tài liệu, và tài liệu phải phát triển song song với chương trình Mọi sửa đổi trong chương trình đều cần phải được cập nhật đồng thời trong tài liệu đi kèm.
Hầu hết tài liệu thường được trình bày dưới dạng tệp văn bản không định dạng, nhằm đảm bảo tính truy cập linh hoạt với môi trường tối giản các công cụ Các tài liệu này thường bao gồm một lời giới thiệu ngắn gọn về chương trình (tệp README), hướng dẫn cài đặt (tệp INSTALL), lịch sử phát triển và kế hoạch tương lai (tệp CHANGELOG và TODO), thông tin về các tác giả và bản quyền (tệp AUTHORS và COPYRIGHT hoặc COPYING), cùng với hướng dẫn sử dụng Tất cả các thông tin này, bao gồm cả tác giả và bản quyền, cần phải được giữ ở trạng thái tự do và có thể chỉnh sửa khi chương trình phát triển Đối với tác giả, chỉ cần liệt kê tên và quyền mà không hạn chế, và bản quyền chỉ cần điều chỉnh nếu các điều kiện cho phép.
Hướng dẫn sử dụng thường được trình bày trong các định dạng phức tạp hơn, do chúng thường là tài liệu dài và đa dạng về định dạng.
PMTD yêu cầu tài liệu phải dễ dàng thay đổi và tuân theo các định dạng minh bạch với các đặc tả kỹ thuật đã biết Những định dạng này cần có khả năng xử lý bởi các công cụ tự do, bao gồm văn bản sạch và các định dạng như Unix, TexInfo, LaTeX hoặc DocBook Điều này cho phép phân phối kết quả từ tài liệu nguồn sang các định dạng khác phù hợp hơn cho việc hiển thị và in ấn, chẳng hạn như HTML, PDF hoặc RTF, mà không bị ràng buộc bởi các định kiến.
Tài liệu chương trình thường được chuẩn bị bởi các bên thứ ba không tham gia vào quá trình phát triển, và có thể bao gồm nhiều loại hình khác nhau Đôi khi, tài liệu này phục vụ mục đích giáo dục, giúp cài đặt và sử dụng một chương trình cụ thể (tệp HOWTO) Ngoài ra, có thể có tài liệu tổng quát hơn, bao gồm nhiều chương trình và sự tích hợp của chúng, so sánh các giải pháp, hoặc dưới dạng sách chỉ dẫn tham chiếu và trợ giúp học Một ví dụ đáng chú ý là dự án tài liệu của Linux (http://www.tldp.org) Bên cạnh đó, chúng ta cũng có thể kể đến các tài liệu kỹ thuật khác không nhất thiết liên quan đến phần mềm, như hướng dẫn bắc dây cho mạng cục bộ, xây dựng lò năng lượng mặt trời, sửa chữa động cơ, hoặc lựa chọn nhà cung cấp công cụ.
Những tài liệu này nằm giữa chương trình thuần túy và các bài báo, sách thực tiễn và kỹ thuật cao Tác giả không có thành kiến đối với quyền tự do đọc, sao chép, sửa đổi và phân phối lại, nhưng có thể mong muốn bảo vệ ý kiến của mình khỏi sự bóp méo Họ có thể muốn giữ lại những đoạn văn nhất định như là thừa nhận hoặc để tăng sức thuyết phục cho các phần khác, chẳng hạn như tiêu đề Mặc dù những mối quan tâm này cũng có thể xuất hiện trong phần mềm, nhưng chúng không nên được thể hiện một cách mãnh liệt trong thế giới tài liệu tự do như trong PMTD.
Tóm lược
Trong chương này, chúng ta đã khám phá các khía cạnh pháp lý ảnh hưởng đến phần mềm mã nguồn mở (PMTD), liên quan đến sở hữu trí tuệ nhằm khuyến khích sáng tạo Bản quyền là yếu tố quan trọng, giúp đảm bảo sự tồn tại của PMTD thông qua các giấy phép tự do Chúng ta đã phân tích tầm quan trọng của giấy phép trong PMTD, cùng với các hình thái, nền tảng và hệ quả của chúng GPL tối đa hóa tự do cho người dùng, trong khi giấy phép BSD tập trung vào tự do cho người sửa đổi và phân phối lại Việc lựa chọn giấy phép cho dự án cần được thực hiện cẩn thận, vì sửa đổi sau này có thể gặp khó khăn, đặc biệt với nhiều đóng góp từ bên ngoài Cuối cùng, PMTD và phần mềm sở hữu độc quyền (PMSHĐQ) khác nhau về giấy phép phân phối, và chương sau sẽ xem xét ảnh hưởng của sự khác biệt pháp lý này đến quy trình phát triển phần mềm.
“truyền thống” được sử dụng trong nền công nghiệp phần mềm ở một mức độ ít hơn hoặc nhiều hơn, phụ thuộc vào từng trường hợp một.
4 Các lập trình viên và những động lực của họ
Trở thành một cao thủ lập trình (hacker) là một hành trình thú vị nhưng đòi hỏi nhiều nỗ lực Động lực của những người thành công thường xuất phát từ niềm đam mê trong việc vượt qua giới hạn của bản thân Tương tự như các vận động viên, bạn cần tạo ra sự hứng thú từ việc giải quyết vấn đề, rèn luyện kỹ năng và mở rộng kiến thức của mình.
Giới thiệu
Phương thức nặc danh và phân tán trong phát triển PMTD đã dẫn đến việc nhiều tài nguyên con người vẫn chưa được biết đến rộng rãi, tạo ra những huyền thoại xung quanh thế giới PMTD và những người tham gia Gần đây, cộng đồng khoa học đã nỗ lực tìm hiểu sâu hơn về những người tham gia dự án PMTD, động lực và nền tảng hàn lâm của họ Việc nhận diện những cá nhân tham gia và lý do họ tham gia có thể rất hữu ích trong việc phát triển PMTD Một số nhà khoa học, đặc biệt là kinh tế học, tâm lý học và xã hội học, nhận thấy tiềm năng hình thành các cộng đồng mới với các quy tắc riêng, khác biệt với xã hội truyền thống Một trong những bí ẩn lớn là động lực của các lập trình viên khi tham gia cộng đồng này, khi mà lợi ích tài chính, ít nhất là trực tiếp, gần như không tồn tại, và khó đo lường một cách gián tiếp.
Các lập trình viên là những ai?
Phần này nhằm cung cấp cái nhìn tổng quan về những cá nhân đã cống hiến thời gian và công sức cho các dự án PMTD, với dữ liệu chủ yếu từ các nghiên cứu khoa học gần đây Các nghiên cứu quan trọng bao gồm "Khảo sát về các lập trình viên" (2002) và "Ai đang làm nó? Biết thêm về các lập trình viên PMTD" (2001), mặc dù không giới hạn trong các PMTD và PMNM.
Các lập trình viên phần mềm thường có độ tuổi trung bình khoảng 27, với nhóm chủ yếu nằm trong khoảng từ 21 đến 24, đặc biệt là 23 tuổi Độ tuổi tham gia phong trào PMTD chủ yếu từ 18 đến 25, rõ ràng nhất giữa 21 và 23, phù hợp với độ tuổi của sinh viên đại học Mặc dù có khoảng 20% lập trình viên dưới 20 tuổi, nhưng phần lớn (60%) là trong độ tuổi 20 Những người dưới 20 và trên 30 chia sẻ 40% còn lại.
Từ độ tuổi tham gia PMTD, có thể thấy sự ảnh hưởng lớn của các trường đại học đối với lĩnh vực này Điều này không bất ngờ, vì trước khi PMTD được biết đến, nó đã gắn liền với nền giáo dục cao hơn Hiện nay, sinh viên và các trường đại học vẫn là những người dẫn dắt việc sử dụng và phát triển PMTD, với hơn 70% lập trình viên có trình độ đại học Dữ liệu này càng đáng chú ý khi nhớ rằng 30% còn lại không ở độ tuổi đại học do vẫn đang học phổ thông Mặc dù vậy, những lập trình viên không có cơ hội tiếp cận giáo dục cao hơn vẫn có sự đam mê và đóng góp không nhỏ cho công nghệ thông tin.
Lập trình viên của PMTD chủ yếu là nam giới, với tỷ lệ nữ giới trong cộng đồng chỉ dao động từ 1% đến 3%, gần như sát với sai số khảo sát Khoảng 60% lập trình viên cho biết họ có bạn khác giới, trong khi chỉ 16% là trẻ em Độ tuổi của lập trình viên PMTD cho thấy sự phân bố tương đối bình thường Hình ảnh lập trình viên cô đơn, với niềm đam mê công nghệ chỉ để khoe khoang, thực chất là một ngoại lệ hiếm gặp trong thực tế.
Lập trình viên làm gì?
Các lập trình viên PMTD thường tự mô tả mình là kỹ sư phần mềm (33%), sinh viên (21%), lập trình viên (11%), nhà tư vấn (10%) và giáo sư đại học (7%), trong khi chỉ khoảng 1% xác định mình thuộc lĩnh vực bán hàng hoặc marketing Điều thú vị là số lượng người tự nhận là kỹ sư phần mềm gấp gần ba lần số lập trình viên, cho thấy sự ưu tiên trong việc áp dụng các kỹ thuật phần mềm kinh điển và hiện đại trong lĩnh vực PMTD.
Sự kết nối giữa các đại học và ngành công nghiệp phần mềm đã được khẳng định một lần nữa, với khoảng 1 trong 3 lập trình viên là sinh viên hoặc giáo sư đại học Điều này cho thấy sự hợp tác mạnh mẽ giữa giới công nghiệp và giới hàn lâm trong lĩnh vực lập trình.
Một nghiên cứu cho thấy khoảng 1/5 lập trình viên đến từ các lĩnh vực không phải công nghệ thông tin, cho thấy sự đa dạng trong nguồn gốc và lợi ích của các đội phát triển Đặc biệt, 64% lập trình viên là nhân viên được trả lương, trong khi chỉ 14% là lập trình viên tự do Thêm vào đó, có khoảng 20% sinh viên trong ngành, và chỉ 3% không có việc làm, phản ánh sự phong phú và tính đa dạng của ngành công nghiệp phần mềm trong bối cảnh sau cuộc khủng hoảng dotcom.
Mô hình kinh doanh PMTD không giống như PMSHĐQ, không thể đạt được chỉ bằng việc bán giấy phép, dẫn đến nhiều tranh cãi về cách lập trình viên kiếm sống Trong khảo sát của chúng tôi, 50% lập trình viên cho biết họ nhận được bù đắp tài chính cho sự tham gia vào PMTD, nhưng nhiều người khác vẫn chưa rõ ràng Richard Stallman, người sáng lập dự án GNU, khi được hỏi về cách lập trình viên PMTD kiếm tiền, đã cho rằng họ có thể phải làm những công việc khác, như làm hầu bàn.
Phân bố theo địa lý
Việc thu thập dữ liệu địa lý của lập trình viên cần được tiếp cận một cách khoa học hơn Nghiên cứu trong chương này chỉ ra rằng các khảo sát trên Internet mở ra cơ hội cho bất kỳ ai tham gia, nhưng mức độ tham gia phụ thuộc vào các trang web nơi khảo sát được công bố Cần lưu ý rằng những khảo sát này không nhằm mục đích đại diện mà chỉ nhằm thu thập câu trả lời và ý kiến từ càng nhiều lập trình viên PMTD càng tốt.
Tuy nhiên, chúng ta có thể mạo hiểm đưa ra một số tuyên bố về vấn đề này, dù rằng dữ liệu không đáng tin cậy như trước và sẽ có nhiều lỗi hơn Thực tế là hầu hết lập trình viên của PMTD đến từ các quốc gia công nghiệp, trong khi sự hiện diện của lập trình viên từ các quốc gia thế giới thứ ba rất hiếm Điều này dẫn đến việc bản đồ lập trình viên của dự án Debian phản ánh hình ảnh Trái đất về đêm, nơi có ánh sáng là nơi có nền văn minh công nghiệp Mặc dù có tiềm năng cho PMTD tại các quốc gia thế giới thứ ba, nhưng dữ liệu cho thấy xu hướng li tâm trong dự án này, với sự giảm sút số lượng lập trình viên từ Mỹ, quốc gia đóng góp nhiều nhất Trong khi đó, số lượng tình nguyện viên từ các quốc gia khác đã tăng gấp đôi từ 1999 đến 2003, với Pháp là ví dụ nổi bật Dự án Debian, bắt đầu từ châu Mỹ, đã chuyển mình sang châu Âu trong những năm gần đây, và có thể sẽ mở rộng hơn nữa ra các quốc gia Nam Mỹ, châu Phi và châu Á, mặc dù dữ liệu hiện tại không hứa hẹn nhiều về điều này.
Trong lĩnh vực PMTD, có một cuộc tranh luận sôi nổi về sự ưu thế giữa châu Âu và Mỹ Nhiều nghiên cứu cho thấy số lượng lập trình viên châu Âu vượt trội hơn so với Bắc Mỹ, mặc dù dân số châu Âu lớn hơn Điều này dẫn đến một cuộc chiến về số liệu, khi tỷ lệ lập trình viên trên đầu người lại cao hơn ở Bắc Mỹ Nếu xem xét số lượng người có truy cập Internet, châu Âu lại tiếp tục dẫn đầu.
Các quốc gia có mức độ thâm nhập lập trình viên cao nhất theo tỷ lệ dân số bao gồm Bắc Âu (Phần Lan, Thụy Điển, Nauy, Đan Mạch và Iceland) và Trung Âu (Bạch Nga, Đức, Tiệp) Tiếp theo là Úc, Canada, New Zealand và Mỹ Mặc dù các quốc gia vùng Địa Trung Hải như Pháp, Ý và Tây Ban Nha có dân số lớn, nhưng mức độ thâm nhập lập trình viên ở khu vực này lại thấp hơn mức trung bình.
Bảng 1 Các quốc gia với số lượng lớn nhất các lập trình viên dự án Debian
Sự cống hiến
Số giờ mà lập trình viên PMTD dành cho việc phát triển phần mềm không rõ ràng, khác với các công ty nơi thời gian và sự đóng góp của từng thành viên được ghi nhận cụ thể Thời gian cống hiến của lập trình viên cho PMTD có thể phản ánh mức độ chuyên nghiệp của họ, nhưng dữ liệu hiện có chủ yếu dựa trên ước tính từ các khảo sát, dẫn đến độ chính xác thấp Do đó, cần lưu ý rằng sai số có thể xuất phát từ cách mà mỗi lập trình viên định nghĩa thời gian phát triển.
Nhiều lập trình viên có thể không tính thời gian dành cho việc đọc email, mà chỉ ghi nhận thời gian dành cho lập trình và sửa lỗi Do đó, các số liệu mà chúng ta sẽ đề cập sau đây cần được xem xét một cách thận trọng.
Nghiên cứu cho thấy mỗi lập trình viên phần mềm trung bình dành 11 giờ mỗi tuần cho các dự án nguồn mở, tuy nhiên, con số này có thể gây nhầm lẫn do sự khác biệt về thời gian làm việc của từng lập trình viên Trong khảo sát về PMTD và PMNM, phần IV đã chỉ ra sự đa dạng trong thời gian mà các lập trình viên dành cho các dự án của họ.
Theo khảo sát, 22.5% người tham gia cho biết họ chỉ dành dưới 2 giờ mỗi tuần cho sự đóng góp, trong khi 26.5% dành từ 2 đến 5 giờ Khoảng 21% cho biết họ dành từ 6 đến 10 giờ, 14.1% dành từ 11 đến 20 giờ, và 9.2% dành từ 20 đến 40 giờ mỗi tuần Cuối cùng, 7.1% người tham gia cho biết họ dành hơn 40 giờ cho việc phát triển PMTD.
Bảng 2 Sự cống hiến theo số giờ trong một tuần
Số giờ trong tuần 40
Việc xác định mức độ chuyên nghiệp của các đội phát triển PMTD và thời gian lập trình viên bỏ ra là rất quan trọng trong việc ước tính và so sánh chi phí thực hiện với các mô hình phát triển PMSHĐQ trong ngành công nghiệp này Hiện tại, với PMTD, chúng ta chỉ có thể tiếp cận các sản phẩm cuối cùng như những dẫn xuất phần mềm mới và việc đồng bộ hóa mã nguồn trong hệ thống phiên bản, mà không thể biết rõ thời gian lập trình viên đã đầu tư để đạt được những sản phẩm đó.
Khoảng 80% lập trình viên thực hiện các nhiệm vụ này trong thời gian rỗi, trong khi chỉ 20% coi đây là hoạt động chuyên nghiệp Dữ liệu này sẽ được phân tích trong chương về kỹ thuật phần mềm, cho thấy mối liên hệ với những đóng góp của lập trình viên, phản ánh quy luật Pareto.
Những động lực
Nhiều phỏng đoán đã được đưa ra về động lực của lập trình viên trong việc phát triển phần mềm tự do (PMTD), đặc biệt khi hoạt động này thường diễn ra trong thời gian rảnh rỗi, chiếm tới 80% thời gian của các lập trình viên.
Trong các phần trước, chúng ta đã khảo sát dữ liệu để hiểu tầm quan trọng của việc nhận thức rằng các câu trả lời đến từ chính các lập trình viên, điều này giúp chúng ta gắn kết với thực tế hơn Đáng lưu ý, tỷ lệ phần trăm vượt quá 100% do người tham gia có thể chọn nhiều câu trả lời.
Khoảng 80% người tham gia muốn học và phát triển kỹ năng mới, trong khi 50% thực hiện điều này để chia sẻ kiến thức và kỹ năng của mình Bên cạnh đó, khoảng 1/3 số người tham gia tìm kiếm cơ hội để tham gia vào các hình thức cộng tác mới.
Dữ liệu ban đầu cho thấy rằng những người chuyên nghiệp với tri thức cao hơn thường có yêu cầu cao hơn so với những người có tri thức ít hơn Tuy nhiên, việc giải thích dữ liệu thứ hai lại khó khăn và có thể mâu thuẫn với quan điểm của Nikolai Bezroukov trong bài viết “Cái nhìn thứ 2 vào nhà thờ lớn và cái chợ” (Tháng 12/1999), khi cho rằng những người lãnh đạo các dự án PMTD thường không chia sẻ đầy đủ thông tin về quyền sở hữu để duy trì quyền lực của họ Ngược lại, lựa chọn thứ ba, phản ánh nhiệt huyết của các lập trình viên trong việc phát triển PMTD, cho thấy khó có thể tìm thấy một ngành công nghiệp nào mà một nhóm tình nguyện viên được tổ chức lỏng lẻo lại có thể hoạt động hiệu quả như vậy.
- về mặt công nghệ mà nói - đứng lên chống lại được những người khổng lồ của khu vực này.
Mặc dù lý thuyết "kinh điển" giải thích lý do tại sao lập trình viên PMTD đóng góp cho các dự án này chủ yếu dựa trên uy tín và lợi ích kinh tế lâu dài, thực tế cho thấy chỉ 5% lập trình viên tham gia để kiếm tiền Ngược lại, tới 90% cho biết họ tham gia nhằm xây dựng uy tín cá nhân Điều này cho thấy việc nghiên cứu động lực của lập trình viên trong cộng đồng PMTD là nhiệm vụ quan trọng mà các nhà xã hội học và tâm lý học cần xem xét trong tương lai gần.
Sự lãnh đạo
Uy tín và sự lãnh đạo là hai yếu tố quan trọng giải thích thành công của PMTD, đặc biệt là mô hình cái chợ Có sự khác biệt rõ rệt giữa các giấy phép của PMTD và giấy phép trong lĩnh vực tài liệu, điều này xuất phát từ cách duy trì sự lãnh đạo và nhấn mạnh ý kiến của các tác giả trong văn bản hơn là trong các chương trình.
Trong PMTD và PMNM Khảo sát và nghiên cứu, phần IV: “Khảo sát về các lập trình viên” (2002)
Một câu hỏi đã được đặt ra cho các lập trình viên, yêu cầu họ chỉ ra những người từ một danh sách mà họ biết, không nhất thiết phải biết cá nhân.
Kết quả, được đưa ra ở bảng 3, chỉ ra những người có thể được chia thành 3 nhóm khác biệt rõ ràng:
Bảng 3 Mức độ thừa nhận đối với các lập trình viên quan trọng
Lập trình viên Linus Torvalds Richard Stallman Miguel de Icaza Eric Raymond Bruce Perens Được biết bởi 96.50% 93.30% 82.10% 81.10% 57.70%
Lập trỡnh viờn Jamie Zawinski Mathias Ettrich Jửrg Schilling Marco Pesenti
Bryan Andrews Được biết bởi 35.80% 34.20% 21.50% 5.70% 5.60%
Lập trình viên Guenter Bartsch Arpad Gereoffy Martin
Roulini Sal Valliger Được biết bởi 3.50% 3.30% 2.90% 2.60% 1.20%
Nhóm đầu tiên bao gồm những cá nhân mang trong mình ý nghĩa lịch sử và triết lý sâu sắc trong thế giới của PMTD, mặc dù họ cũng sở hữu những kỹ năng kỹ thuật ấn tượng.
Linus Torvalds là người sáng tạo ra nhân Linux, một hệ điều hành mã nguồn mở phổ biến nhất hiện nay Ông cũng là đồng tác giả của cuốn sách "Chỉ để vui: câu chuyện về một cuộc cách mạng ngẫu nhiên".
Richard Stallman là nhà tư tưởng nổi bật, người sáng lập Quỹ Phần mềm Tự do (FSF) và là lập trình viên chủ chốt trong nhiều dự án GNU Ông cũng là tác giả của một số bài viết quan trọng về phần mềm tự do, trong đó có bài viết nổi tiếng "Vì sao phần mềm tự do là tốt hơn phần mềm không miễn phí".
1998 [206], “Copyleft: Chủ nghĩa lý tưởng thực dụng”, 1998 [205], “Dự án GNU” [208] và
3 Miguel de Icaza: Đồng sáng lập của dự án GNOME và hãng Ximian, và là lập trình viên trong GNOME và MONO.
4 Eric Raymond: Người sáng lập ra OSI, tác giả của “Nhà thờ lớn và cái chợ” [192] và là lập trình viên chính của fetchmail.
5 Bruce Perens: Cựu lãnh đạo của dự án Debian, người sáng lập (được chuyển đổi) của OSI và lập trình viên của công cụ e-fence.
Jamie Zawinsky, cựu lập trình viên của Mozilla, nổi tiếng với bức thư năm 1999, trong đó ông đã chỉ trích mô hình phát triển của dự án Mozilla, cho rằng nó có thể không bao giờ đạt được thành công.
7 Mathias Ettrich: Người sáng lập của KDE và lập trình viên của LyX và những thứ khác.
Nhóm thứ hai trong khảo sát là các lập trình viên, trong đó bao gồm những cái tên nổi bật từ 6 dự án nổi tiếng nhất trên trang tải về PMTD FreshMeat Kết quả cho thấy, trừ Linus Torvalds và Jürg Schilling vì những lý do rõ ràng, mức độ thừa nhận của các lập trình viên này khá thấp.
1 Jửrg Schilling, người sỏng tạo ra cdrecord và những ứng dụng khỏc.
2 Marco Pesenti Gritti, lập trình viên chính của Galeon.
3 Bryan Andrews, lập trình viên của Apache Toolbox.
4 Guenther Bartsch, người sáng lập ra Xine.
5 Arpad Gereoffy, lập trình viên của MPEGPlayer.
• Nhóm 3 có những cái tên của 3 “người” cuối cùng trong bảng Những cái tên này đã được sáng tạo ra bởi đội khảo sát để kiểm tra sai số.
Từ các kết quả này, chúng ta có thể rút ra hai kết luận quan trọng: đầu tiên, sai số được coi là nhỏ (dưới 3%); thứ hai, hầu hết các lập trình viên của các ứng dụng PMTD phổ biến thường không nổi tiếng như nhiều người vẫn nghĩ Dữ liệu này khiến những ai khẳng định rằng một trong những lý do phát triển PMTD là để tìm kiếm danh tiếng cần xem xét lại.
Tóm lược và các kết luận
Chương này làm sáng tỏ vấn đề ít được biết đến về những người dành thời gian cho PMTD Có thể khẳng định rằng lập trình viên của PMTD thường là những thanh niên trẻ với trình độ đại học hoặc đang theo đuổi nó Mối quan hệ giữa PMTD và các trường đại học, bao gồm sinh viên và giáo sư, rất chặt chẽ, mặc dù lập trình viên thường không liên quan đến môi trường học thuật cho đến khi họ đạt được sự xuất sắc vượt trội.
Trong lĩnh vực PMTD, có sự khác biệt rõ rệt về số giờ cống hiến, tương tự như quy luật Pareto Các lập trình viên thường không coi tiền bạc và tính ích kỷ là động lực chính, mà thay vào đó, họ hướng tới việc chia sẻ và học hỏi Bên cạnh đó, uy tín trong cộng đồng PMTD không chỉ phụ thuộc vào việc lập trình thành công một ứng dụng, mà còn liên quan đến nhiều yếu tố khác.
“Những thứ của công là không có chủ” (dịch tự do) Đã xuất hiện trong một quảng cáo của IBM về Linux (2003)
Chương này phân tích các khía cạnh kinh tế liên quan đến PMTD, bắt đầu với việc xác định cách thức tài trợ cho các dự án PMTD, thường dựa vào nỗ lực và tài nguyên tự nguyện Tiếp theo, chúng ta sẽ khám phá các mô hình kinh doanh chủ yếu mà các công ty liên quan đến PMTD đã triển khai Cuối cùng, chương này kết thúc với một nghiên cứu nhỏ về mối quan hệ giữa PMTD và các nhà độc quyền trong ngành công nghiệp phần mềm.
Cấp vốn cho các dự án PMTD
Vốn nhà nước
Một hình thức đặc biệt của việc cấp vốn cho các dự án tự do là sự hỗ trợ từ nhà nước, bao gồm chính phủ ở các cấp độ khác nhau hoặc các cơ quan nhà nước như quỹ Việc cấp vốn này thường giống như hỗ trợ cho các dự án nghiên cứu và phát triển (R&D), với mục tiêu khuyến khích sự sáng tạo trong công nghiệp và công nghệ Thông thường, các cơ quan cấp vốn không tìm kiếm hoàn vốn đầu tư trực tiếp, nhưng vẫn có những mục tiêu rõ ràng như thúc đẩy đổi mới sáng tạo và phát triển ứng dụng công nghệ.
Trong nhiều trường hợp, việc cấp vốn cho các sản phẩm và dịch vụ liên quan đến PMTD không được thực hiện một cách rõ ràng, mà thường là kết quả phụ của các hợp đồng với mục tiêu chung hơn Chẳng hạn, Ủy ban châu Âu tài trợ cho các dự án nhằm nâng cao tính cạnh tranh trong những lĩnh vực cụ thể, và một số dự án này cần phải tích hợp các mục tiêu liên quan đến việc sử dụng, cải thiện và phát triển PMTD trong khuôn khổ nghiên cứu, như một công cụ nghiên cứu hoặc sản phẩm phát sinh từ đó.
Những động lực cho dạng cấp vốn này là rất khác nhau, nhưng chúng ta có thể phân biệt như sau:
1 Khoa học: Đây là cách thường thấy nhất trong trường hợp các dự án nghiên cứu được cấp vốn nhà nước Dù mục tiêu của nó không phải là để tạo ra phần mềm nhưng là để điều tra nghiên cứu một lĩnh vực cụ thể nào đó (dù có liên quan hay không tới công nghệ thông tin), có thể yêu cầu các chương trình sẽ được phát triển như các công cụ cho việc đạt được các mục tiêu của dự án Thường thì dự án này không có quan tâm trong việc thương mại hóa các công cụ này, hoặc thậm chí có thể được quan tâm một cách tích cực trong các nhóm khác có sử dụng và cải thiện chúng Trong các trường hợp như vậy, khá là chung để phân phối chúng như là PMTD Theo cách này, nhóm tiến hành nghiên cứu có một phần vốn dành riêng cho việc sản xuất phần mềm, nên chúng ta có thể nói rằng nó đã được phát triển với việc cấp vốn của nhà nước.
2 Khuyến khích các chuẩn Việc có một triển khai tham chiếu là một trong những cách thức tốt nhất để khuyến khích một chuẩn Trong nhiều trường hợp điều này liên quan tới việc có các chương trình mà chúng tạo thành một phần của triển khai được nói tới (hoặc nếu chuẩn này tham chiếu tới lĩnh vực phần mềm, thì sẽ là những triển khai tự bản thân chúng) Đối với triển khai tham chiếu sẽ là hữu dụng trong việc khuyến khích chuẩn, nó cần phải là sẵn sàng, ít nhất để kiểm tra tính tương hợp cho tất cả những ai mong muốn phát triển các sản phẩm mà chúng đăng ký tới chuẩn đó Và trong mọi trường hợp cũng được tư vấn cho các nhà sản xuất để có khả năng áp dụng triển khai tham chiếu này một cách trực tiếp để sử dụng nó với các sản phẩm của họ nếu muốn.
Các giao thức Internet đã được phát triển thành một chuẩn vạn năng, và việc cung cấp các triển khai tham chiếu như PMTD có thể đóng góp lớn cho việc khuyến khích này PMTD là sản phẩm phụ của việc khuyến khích chuẩn, thường do một cơ quan nhà nước đảm nhiệm, mặc dù đôi khi có thể là một nhóm doanh nghiệp tư nhân.
3 Xã hội: PMTD là một công cụ rất thú vị cho việc tạo ra nền tảng cơ sở cho xã hội thông tin Những tổ chức có quan tâm trong việc sử dụng PMTD để cải thiện sự truy cập vạn năng tới xã hội thông tin có thể cấp vốn cho các dự án có liên quan tới nó (thường với các dự án cho việc phát triển các ứng dụng mới hoặc việc áp dụng những ứng dụng đang tồn tại sẵn rồi).
Một ví dụ điển hình về việc cấp vốn của nhà nước cho mục tiêu xã hội là gnuLinEx, được Chính quyền Vùng Extremadura (Tây Ban Nha) triển khai nhằm nâng cao hiểu biết về máy tính trong cộng đồng Chính quyền đã đầu tư phát triển một phiên bản dựa trên Debian để đạt được mục tiêu này Tương tự, chính phủ Đức cũng đã tài trợ cho việc phát triển GnuPG, nhằm đơn giản hóa việc sử dụng cho những người không có kinh nghiệm, khuyến khích công dân sử dụng thư điện tử an toàn.
Sự phát triển của GNAT
Trình biên dịch GNAT, một sản phẩm quan trọng trong phát triển phần mềm, đã nhận được tài trợ từ dự án Ada 9X của Bộ Quốc phòng Mỹ nhằm cải thiện phiên bản mới của ngôn ngữ lập trình Ada (sau này là Ada95) Để tránh những vấn đề như chậm trễ và chi phí cao mà phiên bản trước (Ada 83) gặp phải, dự án đã hợp tác với Đại học New York (NYU) với ngân sách khoảng 1 triệu USD để phát triển một “triển khai khái niệm” cho trình biên dịch Ada 95 Nhờ vào việc tận dụng vốn và nền tảng GCC, đội ngũ NYU đã thành công trong việc ra mắt trình biên dịch Ada 95 đầu tiên dưới giấy phép GNU GPL Sự thành công này đã dẫn đến việc một số thành viên trong nhóm sáng lập công ty Ada Core Technologies, hiện là nhà dẫn đầu thị trường trong lĩnh vực trình biên dịch và công cụ phát triển phần mềm Ada.
Dự án này nổi bật với sự kết hợp giữa nghiên cứu tiên tiến trong việc xây dựng các phần mặt tiền và hệ thống thời gian thực cho trình biên dịch ngôn ngữ Ada, đồng thời nhấn mạnh tầm quan trọng của việc khuyến khích các chuẩn, điều mà cơ quan cấp vốn đã xác định là mục tiêu rõ ràng.
Việc cấp vốn không vì lợi nhuận của tư nhân
Dạng cấp vốn này có nhiều điểm tương đồng với hình thức trước, thường do các quỹ hoặc tổ chức phi chính phủ thực hiện Động lực chính trong các trường hợp này thường tạo ra PMTD cho lĩnh vực mà cơ quan cấp vốn cho là phù hợp Ngoài ra, còn có động lực gián tiếp từ việc đóng góp để giải quyết các vấn đề, chẳng hạn như một quỹ khuyến khích nghiên cứu về một căn bệnh có thể tài trợ cho việc xây dựng chương trình thống kê nhằm phân tích các nhóm thí nghiệm trong nghiên cứu đó.
Cả động lực và cơ chế của hình thức cấp vốn này tương tự như các phương thức cấp vốn của nhà nước, nhưng luôn được đặt trong bối cảnh các mục tiêu của cơ quan cấp vốn.
Quỹ FSF, thành lập từ giữa những năm 1980, là một ví dụ điển hình về việc khuyến khích sự phát triển của phần mềm tự do mã nguồn mở (PMTD) Quỹ này không chỉ hỗ trợ các dự án GNU mà còn đóng góp vào sự phát triển chung của PMTD.
Quỹ Tin Sinh Mở (Open Bioinformatics Foundation) là một tổ chức quan trọng trong lĩnh vực tin học sinh học, với mục tiêu khuyến khích phát triển các chương trình máy tính cơ bản cho nghiên cứu trong mọi nhánh của tin sinh Quỹ này hỗ trợ thông qua việc cấp vốn và đóng góp cho việc xây dựng các phần mềm tự do, nhằm thúc đẩy sự tiến bộ trong lĩnh vực này.
Cấp vốn bởi ai đó yêu cầu những cải tiến
Một hình thức cấp vốn khác cho sự phát triển phần mềm mã nguồn mở (PMTD) không hoàn toàn vị tha là khi một công ty cần cải tiến sản phẩm của mình Chẳng hạn, để sử dụng nội bộ, công ty có thể cần một chương trình với chức năng cụ thể hoặc để sửa lỗi Trong những trường hợp này, công ty thường yêu cầu ký hợp đồng để phát triển theo yêu cầu.
Sự phát triển này thường là PMTD (hoặc vì giấy phép của chương trình được sửa áp đặt nó, hoặc vì công ty quyết định nó)
Trường hợp của Corel và Wine
Cuối những năm 1990, Corel quyết định chuyển sản phẩm sang GNU/Linux và nhận ra rằng một chương trình tự do hỗ trợ chạy tệp nhị phân Windows trên Linux có thể tiết kiệm đáng kể chi phí phát triển Để đạt được điều này, chương trình cần được cải tiến bằng cách bổ sung mô phỏng một số chức năng của Windows mà các sản phẩm của Corel đã sử dụng.
Corel đã hợp tác với Macadamian để cải tiến dự án Wine, mang lại lợi ích cho cả hai bên.
Việc cấp vốn với những lợi ích liên quan
Cơ quan cấp vốn nhằm mục tiêu đạt lợi nhuận từ các sản phẩm liên quan đến chương trình phát triển của mình Lợi nhuận thu được không phải là độc quyền, vì nhiều đối thủ khác cũng có thể tham gia thị trường và bán sản phẩm tương tự Tuy nhiên, thị phần mà cơ quan này chiếm được đủ lớn để họ không phải lo lắng về việc chia sẻ lợi ích với các đối thủ, hoặc họ có thể sở hữu một lợi thế cạnh tranh rõ ràng.
Một số ví dụ về những sản phẩm liên quan tới một phần mềm cụ thể là như sau:
Công ty cung cấp các sách học, chỉ dẫn và tài liệu khóa học liên quan đến chương trình tự do mà họ hỗ trợ cấp vốn Mặc dù các công ty khác cũng có thể bán sách tương tự, việc cấp vốn cho dự án giúp công ty có được quyền truy cập sớm vào các lập trình viên chủ chốt, tạo lợi thế cạnh tranh Điều này cũng góp phần xây dựng hình ảnh tích cực trong cộng đồng người sử dụng chương trình theo yêu cầu.
Khi một công ty đầu tư vào việc phát triển hệ thống phần cứng với phần mềm mã nguồn mở, họ có thể đối mặt với sự cạnh tranh từ các đối thủ sử dụng cùng một công nghệ mà không cần hợp tác Tuy nhiên, công ty vẫn giữ được một số lợi thế, đặc biệt là vị thế của họ như một nguồn tài chính cho dự án, cho phép họ tận dụng ảnh hưởng để thúc đẩy các phát triển mà họ quan tâm nhất.
CD với các chương trình là mô hình phổ biến, trong đó các công ty tài trợ cho những phát triển cụ thể để phục vụ cho việc phân phối phần mềm của họ Một ví dụ điển hình là việc tạo ra một môi trường máy tính để bàn tốt, điều này có thể thúc đẩy doanh số bán hàng hiệu quả.
Cung cấp đĩa CD với một phân phối GNU/Linux cụ thể có thể mang lại lợi nhuận cho các nhà bán hàng, vì việc đầu tư vào sự phát triển của phần mềm này là một cơ hội kinh doanh tiềm năng.
Dưới tiêu đề này, việc cấp vốn theo yêu cầu cần được thực hiện với động lực lợi nhuận, yêu cầu cơ quan cấp vốn phải thu được lợi nhuận tiềm tàng Tuy nhiên, thực tế cho thấy có sự kết hợp giữa động lực lợi nhuận và lòng vị tha khi công ty cung cấp vốn cho dự án tự do, từ đó mong đợi lợi nhuận một cách không trực tiếp.
Một ví dụ điển hình về việc đóng góp vốn cho dự án là sự hỗ trợ của nhà xuất bản O'Reilly cho sự phát triển của Perl O'Reilly không chỉ là một trong những nhà xuất bản hàng đầu về các chủ đề liên quan đến Perl, mà còn không độc quyền trong lĩnh vực xuất bản này Thực tế cho thấy, có nhiều nhà xuất bản khác cạnh tranh trong thị trường này với các mức độ thành công khác nhau.
VA Software, trước đây là VA Research và sau này là VA Linux, đã tích cực tham gia vào việc phát triển nhân Linux Sự đóng góp này không chỉ giúp công ty duy trì mối quan hệ vững chắc với khách hàng mà còn đảm bảo tính bền vững trong kinh doanh, khi mà sản phẩm chính của hãng là các thiết bị được cài đặt sẵn hệ điều hành GNU/Linux.
Red Hat đã đầu tư vào sự phát triển của các thành phần GNOME để tạo ra một môi trường máy tính để bàn cho các bản phân phối của mình, từ đó tăng cường doanh số bán hàng Mặc dù nhiều nhà sản xuất bản phân phối khác cũng hưởng lợi từ sự phát triển này, không phải tất cả đều hợp tác với dự án GNOME như Red Hat, và một số hãng hoàn toàn không tham gia Dù vậy, Red Hat vẫn thu được lợi ích từ những đóng góp của mình cho GNOME.
Việc cấp vốn như một sự đầu tư nội bộ
Nhiều công ty phát triển phần mềm theo yêu cầu (PMTD) như một phần trong mô hình kinh doanh của họ, ví dụ như khởi động dự án tự do mới nhằm khai thác cơ hội kinh doanh và thu hồi vốn đầu tư Mô hình này có thể được xem là một biến thể của cấp vốn gián tiếp, với “lợi ích liên quan” là những ưu thế từ việc sản xuất chương trình tự do Do sản phẩm tự do được kỳ vọng tạo ra lợi nhuận, nó xứng đáng có tiêu đề riêng Hình thức cấp vốn này dẫn đến nhiều mô hình kinh doanh khác nhau, và trong phân tích sau, chúng tôi sẽ chỉ ra những lợi ích mà công ty có thể đạt được từ đầu tư này cùng với các phương pháp để tối ưu hóa lợi nhuận Tuy nhiên, cần lưu ý rằng phần mềm theo yêu cầu có thể được phát triển chỉ để đáp ứng nhu cầu nội bộ của công ty, và sau đó mới quyết định ra mắt sản phẩm, mở ra một dòng kinh doanh mới dựa trên đó.
Tập đoàn Zope, trước đây là Digital Creations, là một ví dụ điển hình về công ty đầu tư vào phát triển phần mềm mã nguồn mở với hy vọng thu hồi vốn đầu tư Vào năm 1998, Digital Creations đã tìm kiếm nguồn vốn đầu tư rủi ro để phát triển máy chủ ứng dụng độc quyền và nhận được sự quan tâm từ Opticality Ventures, điều kiện đặt ra là sản phẩm phải được phát hành dưới dạng mã nguồn mở để chiếm lĩnh thị trường Digital Creations đã đồng ý và sau đó ra mắt phiên bản đầu tiên của Zope Hiện nay, Tập đoàn Zope tập trung vào việc tư vấn, đào tạo và hỗ trợ các hệ thống quản trị nội dung dựa trên Zope cùng các sản phẩm khác, khẳng định vị thế vững chắc của mình trong lĩnh vực này.
Ximian, trước đây là Helix Code, là một ví dụ điển hình về phát triển ứng dụng tự do trong môi trường doanh nghiệp, gắn bó chặt chẽ với dự án GNOME Công ty đã phát triển các phần mềm nổi bật như Evolution, Red Carpet và MONO, cung cấp các giải pháp tương tự như Microsoft Outlook và quản lý gói hiệu quả Thành lập vào tháng 10/1999, Ximian thu hút nhiều lập trình viên từ GNOME, đồng thời tiếp tục hợp tác với dự án này Ximian định vị mình là một công ty chuyên cung cấp dịch vụ phát triển ứng dụng dựa trên GNOME và các công cụ liên quan đến môi trường máy tính để bàn Vào tháng 08/2003, Ximian đã được Novell mua lại.
Hệ thống In Doanh nghiệp của Cisco (CEPS) là một giải pháp quản lý in ấn dành cho các tổ chức sử dụng nhiều máy in Được phát triển nội bộ để đáp ứng nhu cầu của Cisco, hệ thống này đã được phát hành miễn phí vào năm 2000 theo giấy phép GNU GPL Mặc dù lý do cụ thể cho việc phát hành không rõ ràng, có thể liên quan đến việc nhận tài trợ cho các đóng góp từ cộng đồng như báo cáo lỗi và bản vá Cisco không có kế hoạch thương mại hóa sản phẩm này và do đó, quyết định phát hành đã không mang lại rủi ro lớn cho công ty.
Các phương thức cấp vốn khác
Có nhiều phương thức cấp vốn khác mà khó phân loại theo các tiêu chí đã nêu Một ví dụ điển hình là những hình thức tài trợ sáng tạo hoặc các quỹ đầu tư mạo hiểm.
Thị trường kết nối lập trình viên với khách hàng, đặc biệt là trong các dự án nhỏ, giúp giải quyết khó khăn trong việc tìm kiếm lập trình viên phù hợp cho các yêu cầu phát triển đặc biệt Để cải thiện tình hình này, các thị trường phát triển của PMTD được thiết lập, cho phép lập trình viên quảng bá kỹ năng và khách hàng nêu rõ nhu cầu phát triển của họ Khi lập trình viên và khách hàng đạt được thỏa thuận, quá trình này tương tự như việc cấp vốn cho những cải tiến mà bên yêu cầu mong muốn.
SourceXchange là một nền tảng kết nối lập trình viên với khách hàng tiềm năng thông qua việc trình bày yêu cầu đề xuất (RFP) cho các dự án phát triển Khi khách hàng đăng tải RFP, lập trình viên có thể đề xuất giải pháp nếu họ thấy thú vị Khi hai bên đồng ý về các điều khoản, dự án sẽ được khởi động và thường có sự giám sát của một người kiểm tra ngang hàng để đảm bảo rằng lập trình viên tuân thủ các đặc tả kỹ thuật Người kiểm tra cũng đảm bảo thanh toán khi dự án hoàn tất và cung cấp các công cụ giám sát cho khách hàng Dự án đầu tiên qua SourceXchange được hoàn thành vào tháng 03/2000, nhưng nền tảng này đã ngừng hoạt động vào tháng 04/2001.
Việc cấp vốn cho dự án thông qua bán phiếu nợ (bond) là một phương thức tương tự như thị trường phiếu nợ truyền thống, nhưng tập trung vào phát triển phần mềm Khi một lập trình viên có ý tưởng cho một chương trình mới hoặc cải tiến chương trình hiện tại, họ sẽ viết một đặc tả kỹ thuật và ước lượng chi phí phát triển, sau đó phát hành phiếu nợ để huy động vốn Giá trị của phiếu nợ chỉ được thực hiện khi dự án hoàn thành và được bên thứ ba xác nhận Những người có nhu cầu về chương trình mới hoặc cải tiến sẽ quan tâm đến việc mua phiếu nợ này, từ đó thiết lập ưu tiên cho lập trình viên Điều này cho phép chi phí phát triển được chia sẻ giữa nhiều công ty và cá nhân, chỉ phải thanh toán khi dự án thành công Một cơ chế tương tự đã được đề xuất trong “Giao thức của người trình diễn của Phố Uôn” của Chris Rasch (2001).
Hệ thống phiếu nợ được phát triển dựa trên giao thức của người trình diễn trên đường phố, được trình bày trong Hội thảo USENIX về Thủ tục Thương mại Điện tử năm 1998 và tài liệu “Giao thức và bản quyền số của người trình diễn trên đường phố” năm 1999 Cơ chế này nhằm tạo điều kiện cho việc cấp vốn tư nhân cho các sáng kiến tự do, cho phép bất kỳ ai quan tâm có thể hứa hẹn trả một khoản tiền nhất định nếu công việc được hoàn thành và công bố công khai Mục tiêu chính là tìm ra phương thức mới để tài trợ cho những dự án nhỏ, dễ tiếp cận và có khả năng mở rộng, như phiếu nợ cho việc xây dựng PMTD Một ví dụ thực tiễn về giao thức này là dự án The Circle, nơi đã áp dụng để huy động vốn cho phần tài chính của dự án.
Hợp tác giữa các lập trình viên tại PMTD diễn ra thông qua việc tham gia vào các hiệp hội tương tự như hợp tác xã, thay vì làm việc riêng lẻ hoặc cho một công ty Tổ chức này hoạt động giống như một công ty với cam kết đạo đức đối với PMTD, có thể được đưa vào quy chế công ty Trong mô hình này, sự phối hợp giữa công việc tình nguyện và công việc được trả tiền diễn ra, với một ví dụ điển hình là các lập trình viên tự do.
Hệ thống quyên góp là cơ chế thanh toán cho tác giả phần mềm thông qua trang web quản lý dự án, cho phép người dùng hỗ trợ tài chính bằng cách quyên góp tự nguyện Điều này giúp duy trì và phát triển các phiên bản mới của phần mềm, đồng thời tạo điều kiện cho lập trình viên tiếp tục công việc của họ.
Các mô hình kinh doanh dựa trên PMTD
Hiểu biết tốt hơn
Các công ty theo mô hình kinh doanh này tập trung vào việc tạo ra lợi nhuận từ sự hiểu biết về sản phẩm tự do hoặc tập hợp sản phẩm Doanh thu của họ đến từ khách hàng của các sản phẩm mà công ty cung cấp dịch vụ liên quan như phát triển, sửa đổi, áp dụng, cài đặt và tích hợp Ưu thế cạnh tranh của công ty gắn liền với sự hiểu biết về sản phẩm, đặc biệt nếu công ty là nhà sản xuất hoặc tham gia tích cực vào dự án sản xuất phần mềm Điều này giải thích tại sao các công ty này thường tham gia vào các dự án phần mềm mà họ cung cấp dịch vụ, giúp họ thu thập kiến thức sâu sắc và được công nhận Việc khẳng định rằng đội ngũ nhân viên bao gồm các lập trình viên có kinh nghiệm từ dự án phần mềm sẽ tạo ra sự tin tưởng và đảm bảo cho khách hàng.
Mối quan hệ với các dự án phát triển
Các công ty này rất chú trọng đến việc xây dựng hình ảnh về sự hiểu biết sâu sắc đối với các sản phẩm tự do Điều này dẫn đến việc họ tích cực hỗ trợ các dự án PMTD, cho phép nhân viên tham gia trong giờ làm việc, không chỉ đơn thuần là hành động mang tính nhân văn.
Một trong những tài sản sinh lợi nhất của công ty là việc khách hàng đánh giá tích cực sản phẩm, cho thấy công ty hiểu rõ về nhu cầu của họ Điều này giúp công ty phát triển một cách chặt chẽ, đảm bảo rằng các cải tiến được khách hàng yêu cầu sẽ được tích hợp vào sản phẩm trong quá trình phát triển dự án.
Từ một góc độ tổng quát, đây là tình huống mà cả công ty và dự án đều thu được lợi ích từ sự hợp tác Dự án nhận được sự phát triển từ công ty, trong khi một số lập trình viên của công ty được trả lương cho công việc của họ trong dự án Công ty có được hiểu biết sâu sắc về sản phẩm, cải thiện hình ảnh với khách hàng, và tăng cường ảnh hưởng đối với dự án Các dịch vụ mà công ty cung cấp rất đa dạng, thường bao gồm phát triển tùy chỉnh, áp dụng thích nghi, và tích hợp sản phẩm mà họ chuyên môn, cũng như tư vấn cho khách hàng về cách sử dụng sản phẩm một cách hiệu quả, đặc biệt khi sản phẩm đó phức tạp hoặc có tầm quan trọng sống còn đối với khách hàng.
Những ví dụ về các công ty mà đã sử dụng mô hình kinh doanh này như sau:
LinuxCare, được thành lập vào năm 1996, ban đầu cung cấp dịch vụ tư vấn và hỗ trợ cho GNU/Linux và PMTD tại Mỹ với đội ngũ chuyên gia về GNU/Linux Tuy nhiên, vào năm 2002, công ty đã chuyển hướng mục tiêu, tập trung vào việc cung cấp dịch vụ độc đáo cho GNU/Linux chạy trên máy ảo của IBM Mô hình kinh doanh của LinuxCare cũng đã thay đổi, chuyển sang cung cấp "những hiểu biết tốt hơn với những hạn chế", trong đó ứng dụng không tự do Levanta trở thành một phần quan trọng trong dịch vụ của họ.
Alcôve (http://www.alcove.com) được thành lập vào năm 1997 tại Pháp, chuyên cung cấp dịch vụ tư vấn PMTD, tư vấn chiến lược, hỗ trợ và phát triển Kể từ khi ra đời, công ty đã tạo điều kiện cho các lập trình viên tham gia vào nhiều dự án tự do, nhằm cải thiện hình ảnh của mình Alcôve cũng nỗ lực xây dựng mối liên kết với cộng đồng PMTD thông qua việc hợp tác với các hiệp hội người sử dụng và công khai các dự án hợp tác, chẳng hạn như thông qua Alcôve - Labs.
Hiểu biết tốt hơn với những hạn chế
Các mô hình này tương tự như những gì đã được mô tả trước đó, nhưng nhằm hạn chế sự cạnh tranh Trong khi các mô hình thuần túy dựa vào sự hiểu biết tốt hơn cho phép bất kỳ ai tham gia, các mô hình này tạo ra rào cản cạnh tranh thông qua bằng sáng chế hoặc giấy phép sở hữu độc quyền, ảnh hưởng đến một phần nhỏ nhưng quan trọng của sản phẩm Điều này giải thích tại sao các mô hình này được xem như mô hình pha trộn, ở giữa PMTD và PMSHĐQ.
Cộng đồng PMTD phát triển phiên bản riêng, dẫn đến việc ưu thế cạnh tranh có thể bị mất hoặc thậm chí trở thành bất lợi cho công ty Nếu đối thủ cạnh tranh tự do trở thành chuẩn mực của thị trường và được khách hàng yêu cầu, điều này có thể ảnh hưởng tiêu cực đến vị thế của công ty.
Mô hình kinh doanh này được áp dụng phổ biến do tính ít rủi ro hơn so với mô hình thuần túy của sự hiểu biết Các công ty đã áp dụng mô hình này đã phát triển theo nhiều cách khác nhau, tạo ra sự đa dạng trong chiến lược kinh doanh.
Caldera là một công ty có lịch sử phức tạp, nổi tiếng với việc phát triển bản phân phối GNU/Linux mang tên Caldera OpenLinux, tập trung phục vụ cho thị trường doanh nghiệp.
Năm 2001, công ty đã mua lại phiên bản Unix từ SCO và đổi tên thành SCO Group vào năm 2002 Chiến lược kinh doanh của họ đã thay đổi liên tục, từ việc hỗ trợ hoàn toàn cho GNU/Linux đến việc khởi kiện IBM và Red Hat vào năm 2003.
Vào năm 2003, Caldera đã gặp khó khăn trong việc phát tán sản phẩm của mình, đặc biệt là trong việc đặt tên và mô hình kinh doanh của họ cho đến năm 2002 Công ty này đã cố gắng tận dụng hiểu biết về nền tảng GNU/Linux, nhưng đã hạn chế cạnh tranh bằng cách đưa vào PMSHĐQ trong phát tán của mình Điều này đã gây khó khăn cho khách hàng trong việc chuyển đổi sang các phát tán khác, mặc dù Caldera đã tích hợp một số phát tán GNU/Linux vào phần tự do của OpenLinux, nhưng không bao gồm trong phần sở hữu độc quyền.
Ximian, được thành lập vào năm 1999 dưới tên Helix Code bởi các lập trình viên liên quan đến dự án GNOME, đã được Novell mua lại vào tháng 08/2003 Hầu hết phần mềm của Ximian đều là mã nguồn mở, chủ yếu thuộc dự án GNOME Tuy nhiên, trong một lĩnh vực đặc thù, Ximian đã cấp phép cho một thành phần quan trọng là PMSHĐQ (Connector to Exchange), cho phép sản phẩm chủ lực của họ, Evolution, tương tác với các máy chủ Microsoft Exchange, thường được sử dụng trong các tổ chức lớn.
Ximian đã cố gắng cạnh tranh với các công ty khác bằng cách phát triển các dịch vụ dựa trên GNOME, mặc dù các sản phẩm của họ không tương tác dễ dàng với Exchange Mô hình của Ximian đã trở thành một trong những "sự hiểu biết tốt hơn" nhờ vào việc có nguồn mở cho chương trình Thành phần này được giới thiệu dưới tên PMTD vào năm 2005.
Nguồn của một sản phẩm PMTD
Mô hình này tương tự như mô hình dựa trên sự hiểu biết tốt hơn nhưng chuyên môn hóa, với công ty là nhà sản xuất chính của một sản phẩm tự do Ưu thế cạnh tranh tăng lên nhờ việc phát triển sản phẩm theo yêu cầu, kiểm soát sự tiến hóa của nó và ra mắt trước đối thủ Điều này giúp công ty củng cố vị thế mạnh mẽ với khách hàng tìm kiếm dịch vụ cho chương trình Hơn nữa, mô hình này tạo ấn tượng tích cực về sự phát triển của công ty thông qua việc tạo ra và duy trì ứng dụng theo yêu cầu, từ đó thuyết phục khách hàng về khả năng của mình Đồng thời, nó cũng xây dựng hình ảnh tốt cho cộng đồng PMTD khi công ty cung cấp sản phẩm mới, góp phần vào miền cộng đồng chung.
Nhiều sản phẩm tự do đang được phát triển trong các công ty, và thường thì chính những công ty này tiếp tục dẫn dắt sự phát triển tiếp theo của sản phẩm.
Ximian đã áp dụng mô hình hiểu biết tốt hơn với những hạn chế, đồng thời tuân theo mô hình rõ ràng dựa trên việc cung cấp các chương trình tự do Các sản phẩm như Evolution và Red Carpet được phát hành theo giấy phép GPL, trong khi những sản phẩm quan trọng khác như Mono chủ yếu sử dụng giấy phép MIT X11 hoặc LGPL Ximian đã phát triển các sản phẩm độc đáo từ đầu và cố gắng hoàn vốn đầu tư thông qua việc ký hợp đồng, giúp sản phẩm tiến hóa, đáp ứng nhu cầu khách hàng, cũng như cung cấp sự tùy biến và duy trì.
Zope Corporation (http://www.zope.com) được thành lập vào năm 1995 bởi Digital Creations, với mục tiêu phát triển một sản phẩm độc quyền cho quản lý quảng cáo phân loại trên web Năm 1997, công ty nhận được đầu tư từ Opticality Ventures, một công ty đầu tư mạo hiểm, với điều kiện phát triển sản phẩm thành PMTD, dẫn đến sự ra đời của Zope, một trong những hệ thống quản trị nội dung nổi tiếng trên Internet Kể từ đó, mô hình kinh doanh của Zope Corporation tập trung vào việc sản xuất Zope và các sản phẩm liên quan, cũng như cung cấp dịch vụ ứng dụng và bảo trì cho các sản phẩm này.
Nguồn sản phẩm với những hạn chế
Mô hình này tương tự như mô hình trước, nhưng nhấn mạnh vào việc hạn chế cạnh tranh hoặc tối đa hóa doanh số Một số hạn chế phổ biến có thể kể đến bao gồm:
Trong mô hình phân phối sở hữu độc quyền, sản phẩm được phát hành dưới dạng PMTD, với hoặc không có hứa hẹn về phân phối tự do sau này Mỗi phiên bản mới được bán như PMSHĐQ, và sau một khoảng thời gian nhất định, phiên bản cũ sẽ được cấp phép tự do Điều này giúp công ty sản xuất thu hút khách hàng quan tâm đến các phiên bản mới, đồng thời hạn chế sự cạnh tranh, vì các đối thủ chỉ có thể sử dụng phiên bản mới khi nó được phát hành với các cải tiến và hỗ trợ hoàn chỉnh.
Phân phối phần mềm một cách hạn chế có thể mang lại lợi ích cho nhà sản xuất, khi họ cung cấp phần mềm miễn phí ban đầu nhưng chỉ phân phối cho những khách hàng trả tiền trong một thời gian nhất định Sau đó, phần mềm sẽ được phát hành công khai, tạo giá trị gia tăng cho những khách hàng đã trả tiền Tuy nhiên, mô hình này chỉ thành công nếu khách hàng không chia sẻ phần mềm ra công chúng ngay khi nhận được Điều này có thể không phổ biến đối với một số loại khách hàng, và các công ty phát triển thường thu được lợi ích từ mô hình này thay vì giá thành bằng 0 Việc trì hoãn phát hành sản phẩm cho cộng đồng cũng hạn chế khả năng nhận được đóng góp từ bên ngoài, làm giảm lợi ích cho nhà sản xuất.
Một số công ty sử dụng mô hình kinh doanh này như sau:
ArtOfCode LLC (http://artofcode.com/) đã bắt đầu bán Ghostscript từ năm 2000 với ba phiên bản khác nhau, kế thừa mô hình của Alladin Enterprises Phiên bản mới nhất, AFPL Ghostscript, được phân phối theo giấy phép sở hữu độc quyền cho phép sử dụng và phân phối không thương mại Sau khoảng một năm, phiên bản tiếp theo được phát hành dưới dạng GNU Ghostscript theo giấy phép GNU GPL.
Vào năm 2003, phiên bản AFPL 8.11 được phát hành vào ngày 16/08, trong khi phiên bản GNU 7.07 được phát hành vào ngày 17/05, nhưng phiên bản AFPL tương đương đã ra mắt vào năm 2002 Ngoài ra, artofcode cũng phát hành một phiên bản thứ ba với giấy phép sở hữu độc quyền, cho phép tích hợp vào các sản phẩm không tương thích với GNU GPL, sử dụng mô hình giấy phép đôi.
Ada Core Technologies, được thành lập vào năm 1994 bởi các tác giả của trình biên dịch Ada 95, đã phát triển với sự tài trợ từ chính phủ Mỹ và dựa trên GCC, trình biên dịch GNU Ngay từ những ngày đầu, sản phẩm của công ty đã là PMTD, tuy nhiên, hầu hết chúng chỉ được giới thiệu lần đầu cho khách hàng trong khuôn khổ hợp đồng duy trì.
Ada Core Technologies phát triển trình biên dịch dựa trên Pro, nhưng không công khai phát hành cho người dùng thông thường Các phiên bản của trình biên dịch này thường không có sẵn trên Internet Sau khoảng một năm trì hoãn, Ada Core Technologies sẽ phát hành các phiên bản tương tự cho công chúng dưới dạng tệp FTP nặc danh, tuy nhiên không có hỗ trợ kèm theo.
Các giấy phép đặc biệt
Theo các mô hình phân phối, công ty sản xuất một sản phẩm và cấp phép theo nhiều giấy phép khác nhau, trong đó ít nhất một giấy phép là PMTD Các giấy phép còn lại thường là sở hữu độc quyền, cho phép sản phẩm được bán theo cách truyền thống Bên cạnh việc bán sản phẩm, công ty còn cung cấp dịch vụ tư vấn và phát triển liên quan Chẳng hạn, một công ty có thể phát hành sản phẩm dưới giấy phép GNU GPL và đồng thời cung cấp một phiên bản sở hữu độc quyền cho những khách hàng không muốn tuân theo điều kiện của GPL, như khi họ cần tích hợp sản phẩm với một sản phẩm sở hữu độc quyền khác.
Sleepycat Software, được thành lập vào năm 1996, đã đạt được lợi nhuận ngay từ những ngày đầu, điều này thể hiện sự thành công trong ngành phần mềm Sản phẩm nổi bật của họ, Berkeley DB, là một hệ quản trị dữ liệu được ưa chuộng nhờ khả năng nhúng dễ dàng vào các ứng dụng khác Công ty phân phối sản phẩm theo giấy phép yêu cầu mã nguồn của cả hai sản phẩm khi nhúng Ngoài ra, Sleepycat còn cung cấp dịch vụ tư vấn và phát triển, cho phép nhúng sản phẩm mà không cần phân phối mã nguồn, thông qua các hợp đồng đặc biệt và chế độ bán PMSHĐQ.
2005 thì Oracle đã mua Sleepycat Software.
Bán thương hiệu
Nhiều khách hàng sẵn sàng chi trả nhiều hơn cho một thương hiệu nổi tiếng, mặc dù có những sản phẩm tương tự với giá rẻ hơn Các công ty đầu tư vào việc xây dựng hình ảnh thương hiệu tốt và được công nhận, cho phép họ bán sản phẩm với lợi nhuận cao Họ không chỉ cung cấp sản phẩm mà còn mang đến dịch vụ giá trị gia tăng mà khách hàng đánh giá cao.
Mô hình kinh doanh nổi tiếng nhất liên quan đến việc bán các bản phân phối GNU/Linux, nơi các công ty cố gắng tiếp thị sản phẩm có thể tải miễn phí từ Internet với giá thấp hơn Để thuyết phục khách hàng chi trả cho giá trị gia tăng, họ đầu tư mạnh vào quảng cáo và tạo ra các lợi ích cụ thể như bản phân phối chất lượng cao và kênh phân phối thuận tiện Ngoài ra, các công ty này thường cung cấp nhiều dịch vụ bổ sung, từ đào tạo đến chương trình chứng chỉ của bên thứ ba, nhằm nâng cao hình ảnh thương hiệu và tạo sự khác biệt trên thị trường.
Red Hat (http://www.redhat.com) đã bắt đầu phân phối Red Hat Linux vào năm 1994 và trở nên nổi tiếng với tên gọi hiện tại vào năm 1995 Trong một thời gian dài, Red Hat đã khẳng định vị thế của mình như một trong những phân phối GNU/Linux hàng đầu, mặc dù vào giữa những năm 2000, hãng đã chia sẻ vị trí này với các công ty khác như OpenSuSE, Ubuntu và có thể là Debian Hiện nay, Red Hat cung cấp đa dạng dịch vụ liên quan đến phân phối GNU/Linux và phần mềm nói chung.
Những phân loại mô hình kinh doanh khác
Phân loại theo Hecker
Sự phân loại này được đưa ra trong “Thiết lập cửa hàng: kinh doanh PMNM” (Frank Hecker, 1998)
OSI đã được sử dụng phổ biến trong việc quảng bá và là một trong những nỗ lực đầu tiên để phân loại các doanh nghiệp nổi lên trong thời gian này Tuy nhiên, nó bao gồm nhiều mô hình ít liên quan đến PMTD, trong khi PMTD đóng vai trò như một con đường dẫn đến các mô hình chính Các mô hình được mô tả trong tài liệu này như sau:
Công ty cung cấp sự hỗ trợ cho người bán bằng cách bán các dịch vụ liên quan đến sản phẩm Họ khuyến khích sản phẩm PMTD mà công ty đã phát triển hoặc tham gia tích cực, đồng thời cung cấp các dịch vụ như tư vấn và áp dụng thích nghi để đáp ứng các yêu cầu đặc thù của khách hàng.
Người dẫn đầu thị trường thường gặp khó khăn khi phải cạnh tranh với các sản phẩm sở hữu độc quyền khác Trong tình huống này, chương trình tự do có thể được áp dụng để quảng bá cho việc bán các sản phẩm độc quyền liên quan, nhằm tăng cường khả năng tiếp cận và thu hút khách hàng.
Công ty chuyên bán các thiết bị phần cứng, trong đó phần mềm và dịch vụ kỹ thuật (PMTD) được xem như một yếu tố bổ sung quan trọng, giúp nâng cao lợi thế cạnh tranh trên thị trường.
• Bán các phụ tùng (bán các phụ tùng): Các sản phẩm liên quan tới PMTD được bán, như là sách, các thiết bị máy tính, …
PMTD cung cấp dịch vụ trực tuyến nhằm tạo ra nguồn lợi nhuận cho công ty.
Cấp phép thương hiệu là quá trình mà một công ty đăng ký thương hiệu của mình để liên kết với các chương trình PMTD mà nó đã phát triển Qua đó, công ty có thể kiếm lợi nhuận bằng cách cấp phép sử dụng các thương hiệu này cho các bên khác.
Bán sản phẩm, sau đó giải phóng nó là một mô hình tương tự như người dẫn đầu thua thiệt, nhưng được thực hiện theo chu kỳ tuần tự Đầu tiên, sản phẩm được giới thiệu ra thị trường với tên gọi PMTD Nếu sản phẩm thành công, phiên bản tiếp theo sẽ được phân phối dưới dạng PMSHĐQ trong một thời gian nhất định, sau đó sẽ được giải phóng tự do Trong quá trình này, một phiên bản sở hữu độc quyền sẽ tiếp tục được phân phối, và mô hình này sẽ lặp lại.
Trao đặc quyền phần mềm là hành động mà một công ty cấp quyền sử dụng thương hiệu của mình liên quan đến một chương trình tự do cụ thể Điều này cho phép các bên thứ ba sử dụng thương hiệu để phát triển và phân phối sản phẩm hoặc dịch vụ, đồng thời tạo ra cơ hội mở rộng thị trường và tăng cường sự hiện diện của thương hiệu.
Độc giả nhận thấy rằng sự phân loại này có sự khác biệt rõ rệt so với phân loại đã đưa ra, tuy nhiên, một số chủng loại vẫn gần như hoàn toàn khớp với các phân loại của chúng ta.
Ảnh hưởng lên vị thế độc quyền
Các yếu tố thiên vị cho các sản phẩm áp đảo
Trong lĩnh vực phần mềm máy tính, thường xuất hiện một sản phẩm chiếm ưu thế trong từng phân khúc thị trường Điều này diễn ra phổ biến vì nhiều lý do, trong đó có thể nhấn mạnh một số yếu tố quan trọng.
Các định dạng dữ liệu thường gắn liền với một ứng dụng cụ thể Khi có đủ người sử dụng, định dạng này trở thành chuẩn de facto, dẫn đến áp lực lớn để mọi người phải áp dụng nó cùng với ứng dụng tương ứng.
Các chuỗi phân phối thường gặp khó khăn trong việc cung cấp bản sao của chương trình, đặc biệt là những chương trình không phải là hàng đầu trên thị trường Điều này khiến cho các đối thủ cạnh tranh nhỏ khó tiếp cận được các cửa hàng máy tính nơi người dùng có thể mua sản phẩm Ngược lại, đối với các sản phẩm nổi bật, việc tiếp cận trở nên dễ dàng hơn, vì cửa hàng máy tính sẽ tự tìm kiếm để có được sản phẩm đó.
Marketing tự do mà sản phẩm đạt được khi có một tỷ lệ lớn người dùng là rất mạnh mẽ Truyền khẩu hoạt động hiệu quả khi chúng ta trao đổi thông tin với những người quen biết Tuy nhiên, ảnh hưởng từ các phương tiện truyền thông là lớn nhất; các tạp chí máy tính thường xuyên nhắc đến sản phẩm nếu nó được ưa chuộng, dẫn đến việc tổ chức các khóa đào tạo, xuất bản sách mô tả và thực hiện phỏng vấn với người sử dụng.
Đầu tư vào huấn luyện công cụ là rất quan trọng, vì khi đã bỏ ra thời gian và tiền bạc, người dùng sẽ có động lực cao để duy trì và không thay đổi công cụ đó Hơn nữa, những công cụ này thường chiếm ưu thế trên thị trường, giúp dễ dàng tìm kiếm tài liệu và hỗ trợ để học cách sử dụng hiệu quả.
Việc sở hữu một máy tính với các phần mềm được cài đặt sẵn là một động lực lớn để người dùng bắt đầu sử dụng, ngay cả khi phải chi trả riêng cho từng phần mềm.
Và thông thường, dạng phần mềm mà người bán máy tính được chuẩn bị để cài đặt sẵn sẽ chỉ là những phần mềm được sử dụng nhiều nhất.
Thế giới của PMSHĐQ
Trong lĩnh vực PMSHĐQ, sự xuất hiện của một sản phẩm vượt trội trong mọi phân khúc thể hiện sự độc quyền của công ty sản xuất Chẳng hạn, một số sản phẩm và công ty có tình trạng độc quyền de facto trong các thị trường như hệ điều hành, xuất bản, cơ sở dữ liệu, thiết kế đồ họa, xử lý văn bản và bảng tính trên máy tính để bàn.
Công ty dẫn đầu thị trường có sự kiểm soát lớn đối với sản phẩm của họ, khiến cho người tiêu dùng ít có động lực để tìm kiếm lựa chọn khác Điều này dẫn đến việc cạnh tranh gặp khó khăn, vì các công ty chỉ có thể cải tiến sản phẩm của riêng mình để thách thức vị thế áp đảo của sản phẩm dẫn đầu, nhưng thường với thành công hạn chế.
Tình trạng này khiến toàn bộ khu vực phụ thuộc vào chiến lược của công ty áp đảo, ảnh hưởng đến mọi yếu tố, bao gồm cả sự phát triển công nghệ phần mềm Những cải tiến mà công ty thực hiện cho sản phẩm sẽ định hình tình hình chung, dẫn đến những tác động kinh tế tiêu cực của sự độc quyền Đặc biệt, công ty áp đảo thiếu động lực để điều chỉnh sản phẩm theo nhu cầu ngày càng thay đổi của khách hàng, tạo ra một thị trường bị giam hãm.
Tình trạng với PMTD
Trong trường hợp của PMTD, một sản phẩm áp đảo không đồng nghĩa với việc doanh nghiệp sở hữu độc quyền Nếu sản phẩm được phát triển tự do, bất kỳ công ty nào cũng có thể cải tiến và áp dụng nó theo nhu cầu khách hàng, từ đó thúc đẩy sự tiến bộ của sản phẩm Vị thế áp đảo của sản phẩm sẽ thu hút nhiều công ty quan tâm hợp tác, buộc nhà sản xuất gốc phải cạnh tranh để duy trì vị thế trên thị trường Điều này tạo động lực cho họ cải tiến sản phẩm theo mong muốn của người sử dụng, mặc dù họ có lợi thế về hiểu biết sâu sắc hơn về chương trình Cuối cùng, cạnh tranh sẽ diễn ra vì mỗi khách hàng.
Sự xuất hiện của sản phẩm áp đảo trong lĩnh vực PMTD đã gia tăng cạnh tranh giữa các công ty, buộc họ phải lắng nghe nhu cầu của người sử dụng để tồn tại Điều này tạo ra một động lực mạnh mẽ cho việc cải tiến sản phẩm, đảm bảo rằng người tiêu dùng luôn nắm giữ quyền kiểm soát trong thị trường.
Apache đã từ lâu dẫn đầu thị trường máy chủ web, nhưng có nhiều công ty lớn và nhỏ, như IBM, đóng góp vào dự án này để cải tiến nó Mặc dù Apache gần như độc quyền trong nhiều lĩnh vực, chẳng hạn như trên nền tảng GNU/Linux và *BSD, nó không thuộc sở hữu của một công ty duy nhất mà được hỗ trợ bởi hàng tá công ty khác nhau.
GNU/Linux không phải là một sự độc quyền mà là lựa chọn thứ hai trên thị trường hệ điều hành, với hàng chục phát tán từ các công ty khác nhau tự do cạnh tranh Mỗi phát tán mang lại những cải tiến mà đối thủ phải áp dụng để không bị tụt hậu Tuy nhiên, các phát tán này cần phải tuân thủ "chuẩn của GNU/Linux" để không bị người dùng từ chối Sự phát triển thị phần của GNU/Linux đã tạo ra một môi trường cạnh tranh giữa nhiều công ty, giúp hệ thống này tiến hóa và đáp ứng tốt hơn nhu cầu của người sử dụng, điều này là yếu tố quan trọng để họ tồn tại trên thị trường.
GCC là sản phẩm nổi bật trong lĩnh vực trình biên dịch C và C++ trên thị trường GNU/Linux, không dẫn đến tình trạng độc quyền của bất kỳ công ty nào Cygnus, hiện là Red Hat, từng chịu trách nhiệm phát triển GCC trong một thời gian dài Nhiều công ty khác cũng tham gia cải tiến hệ thống này và cạnh tranh để đáp ứng nhu cầu người dùng Khi một công ty hoặc tổ chức không thể phối hợp hiệu quả, có thể xảy ra tình trạng phân nhánh dự án, dẫn đến sự xuất hiện của hai sản phẩm song song cho đến khi chúng hợp nhất trở lại, như đã xảy ra với GCC 3.x hiện nay.
Các chiến lược cho việc trở thành một sự độc quyền với PMTD
Mặc dù thế giới của PMTD không thân thiện với các độc quyền doanh nghiệp như PMSHĐQ, vẫn có những chiến lược mà công ty có thể áp dụng để đối phó với tình trạng độc quyền trên thị trường Các thực tế này thường gặp trong nhiều lĩnh vực khác nhau của nền kinh tế, và để ngăn chặn chúng, các cơ quan quản lý cạnh tranh đã được thành lập Đặc biệt trong thị trường phần mềm, một yếu tố quan trọng cần lưu ý là sự chấp nhận chứng nhận sản phẩm từ bên thứ ba, đã được trải nghiệm trong một số tình huống cụ thể.
Khi một công ty phân phối phần mềm, họ thường cần "chứng nhận" sản phẩm cho sự kết hợp với phần mềm khác Nhà sản xuất chỉ cung cấp dịch vụ hỗ trợ nếu sản phẩm được sử dụng trong môi trường đã được chứng nhận Ví dụ, một chương trình quản trị cơ sở dữ liệu có thể chỉ chứng nhận cho một phát tán GNU/Linux cụ thể, buộc khách hàng phải sử dụng phát tán đó để nhận hỗ trợ Nếu một nhà sản xuất chiếm ưu thế với sản phẩm được chứng nhận bởi bên thứ ba, người dùng sẽ không còn lựa chọn nào khác ngoài việc sử dụng sản phẩm đó, dẫn đến tình trạng độc quyền doanh nghiệp.
Trong thị trường phát tán GNU/Linux, đang xuất hiện xu hướng độc quyền de facto thông qua chứng nhận sản phẩm Nhiều nhà sản xuất sản phẩm sở hữu độc quyền chỉ công nhận các sản phẩm trên một số phát tán nhất định, thường là Red Hat Linux Hiện tại, tình trạng này chưa dẫn đến độc quyền cho bất kỳ công ty nào, vì chứng nhận không thực sự phù hợp với người dùng trong thị trường GNU/Linux Tuy nhiên, chỉ có thời gian mới cho biết liệu tình trạng này có thể dẫn đến độc quyền de facto trong tương lai hay không.
Điều quan trọng cần nhớ là các vị thế độc quyền không dễ dàng đạt được và thường thông qua các cơ chế "không phải phần mềm" Điều này khác với tình trạng sản phẩm độc quyền, thường đạt được qua các cơ chế liên quan đến công nghệ thông tin và các mẫu sử dụng của nó.
Nếu tất cả phần mềm sử dụng đều miễn phí, chiến lược này có thể hạn chế cơ hội thành công Một nhà sản xuất có thể mong muốn nhiều công ty chứng nhận sản phẩm của mình, nhưng khách hàng luôn có thể xem xét các công ty khác để tìm kiếm dịch vụ và hỗ trợ phù hợp hơn.
6 PMTD và hành chính nhà nước
Phần mềm được chấp nhận cho Nhà nước không chỉ cần có khả năng thực hiện nhiệm vụ mà còn phải đáp ứng các yêu cầu về cấp phép theo hợp đồng Nếu không có những điều kiện này, Nhà nước sẽ không thể đảm bảo rằng dữ liệu của công dân được xử lý một cách phù hợp, bảo mật và có thể truy cập theo thời gian, điều này rất quan trọng cho trách nhiệm chung của Nhà nước.
Edgar David Villanueva Nỳủez (thư trả lời cho tổng giỏm đốc của Microsoft Peru, 2001).
Các cơ quan nhà nước, bao gồm cả những cơ quan có khả năng làm luật và các cơ quan hành chính, đóng vai trò quan trọng trong việc áp dụng và khuyến khích công nghệ Mặc dù trước năm 2000, những cơ quan này chưa thể hiện sự quan tâm đến PMTD, tình hình đã bắt đầu thay đổi Nhiều cơ quan hành chính đã tích cực sử dụng PMTD như một phần của hạ tầng công nghệ thông tin Đồng thời, một số cơ quan đã khuyến khích sự phát triển và sử dụng PMTD, cả trực tiếp lẫn gián tiếp Hơn nữa, các cơ quan lập pháp cũng đã bắt đầu chú ý đến PMTD, đôi khi ưu tiên phát triển, đôi khi gây cản trở, và đôi khi chỉ đơn thuần ghi nhận sự hiện diện của nó.
Trước khi đi vào chi tiết, cần lưu ý rằng PMTD đã phát triển mà không có sự hỗ trợ rõ ràng từ các cơ quan nhà nước Sự quan tâm gần đây từ các cơ quan này đối với PMTD không tránh khỏi sự đối kháng và lúng túng Trong những năm gần đây, các sáng kiến liên quan đến chuẩn mở ngày càng được chú ý, thường dẫn đến những đo đếm liên quan trực tiếp đến PMTD.
Trong chương này, chúng ta sẽ mô tả hiện trạng và những đặc điểm nổi bật của PMTD liên quan đến khu vực "nhà nước".
Ảnh hưởng lên các cơ quan hành chính nhà nước
Những ưu điểm và những ảnh hưởng tích cực
Việc sử dụng PMTD trong cơ quan hành chính nhà nước mang lại nhiều ưu điểm quan trọng, bao gồm việc nâng cao hiệu quả công việc, tối ưu hóa quy trình xử lý thông tin và cải thiện khả năng phục vụ người dân Những viễn cảnh mới mà PMTD mở ra bao gồm việc tăng cường tính minh bạch, cải thiện khả năng tiếp cận dịch vụ công và thúc đẩy sự đổi mới sáng tạo trong quản lý hành chính.
1 Việc phát triển nền công nghiệp bản địa
Một trong những lợi ích nổi bật của phần mềm tự phát triển (PMTD) là khả năng thúc đẩy sự hình thành một ngành công nghiệp phần mềm nội địa Khi áp dụng phần mềm mã nguồn mở (PMSHĐQ), tất cả chi phí cho giấy phép sẽ được đầu tư trực tiếp vào nhà sản xuất sản phẩm, giúp củng cố vị thế của họ Mặc dù điều này không nhất thiết là tiêu cực, nhưng lại tạo ra sự kém hiệu quả đối với các khu vực mà cơ quan hành chính nhà nước có liên quan, khi so sánh với các giải pháp thay thế từ việc sử dụng PMTD.
Trong bối cảnh này, các công ty bản địa có cơ hội cạnh tranh bình đẳng trong việc cung cấp dịch vụ cho cơ quan hành chính nhà nước Điều này cho thấy sự nỗ lực của cơ quan hành chính trong việc xóa bỏ sự bất bình đẳng và tạo điều kiện thuận lợi cho tất cả các doanh nghiệp tham gia vào thị trường.
Tất nhiên, "bất kỳ ai" cũng bao gồm các công ty địa phương, những đơn vị có khả năng tận dụng những lợi thế cạnh tranh như hiểu biết sâu sắc về nhu cầu của khách hàng và sự gần gũi về địa lý.
2 Sự độc lập với nhà cung cấp và cạnh tranh thị trường
Trong môi trường cạnh tranh, tổ chức thường ưu tiên không phụ thuộc vào một nhà cung cấp duy nhất, nhằm tránh việc bị áp đặt điều kiện cung cấp sản phẩm Tuy nhiên, trong lĩnh vực cơ quan hành chính nhà nước, điều này trở thành yêu cầu thiết yếu và thậm chí là nghĩa vụ pháp lý trong một số trường hợp Cơ quan hành chính không có quyền tự do chọn nhà cung cấp mà phải xác định các yêu cầu một cách rõ ràng, để bất kỳ công ty nào đáp ứng các tiêu chí nhất định đều có cơ hội được lựa chọn cho hợp đồng.
Trong trường hợp của PMSHĐQ, mỗi sản phẩm chỉ có một nhà cung cấp, bất chấp việc có nhiều trung gian Khi một sản phẩm cụ thể được chỉ định, cơ quan hành chính nhà nước sẽ quyết định nhà cung cấp để trao hợp đồng Việc chỉ định sản phẩm cụ thể thường không thể tránh khỏi, đặc biệt trong lĩnh vực chương trình máy tính Những lý do như tính tương thích nội bộ hoặc tiết kiệm chi phí trong đào tạo và quản trị hệ thống thường dẫn đến quyết định sử dụng sản phẩm nhất định từ các cơ quan hành chính.
Cách duy nhất để thoát khỏi tình trạng này là biến sản phẩm chỉ định thành tự do, cho phép mọi công ty quan tâm có thể cung cấp sản phẩm và các dịch vụ liên quan Điều này phụ thuộc vào khả năng và hiểu biết của công ty về sản phẩm Hơn nữa, với dạng hợp đồng này, cơ quan hành chính nhà nước có thể dễ dàng thay đổi nhà cung cấp trong tương lai mà không gặp vấn đề kỹ thuật nào, vì sản phẩm sẽ vẫn giữ nguyên chất lượng dù có sự thay đổi công ty.
3 Tính mềm dẻo và sự thích nghi đối với các yêu cầu đặc thù
Sự thích nghi với yêu cầu đặc thù là yếu tố quan trọng đối với tổ chức sử dụng máy tính, đặc biệt trong các cơ quan hành chính nhà nước Tại PMTD, quá trình thích nghi diễn ra dễ dàng hơn và có thể dựa vào thị trường cạnh tranh nếu cần hợp đồng Khi các cơ quan hành chính mua sản phẩm độc quyền, việc sửa đổi thường yêu cầu hợp đồng với nhà sản xuất, bên duy nhất có khả năng thực hiện điều này về mặt pháp lý và kỹ thuật Trong bối cảnh này, việc thương thảo trở nên khó khăn nếu nhà sản xuất không quan tâm đến thị trường mà cơ quan hành chính đó đại diện.
Việc sử dụng sản phẩm tự do cho phép cơ quan hành chính nhà nước linh hoạt trong việc sửa đổi theo nhu cầu, với điều kiện có đội ngũ cá nhân có năng lực hoặc thuê ngoài dịch vụ sửa đổi Nguyên tắc thuê ngoài khuyến khích cạnh tranh giữa các công ty, từ đó giúp giảm giá thành và nâng cao chất lượng sản phẩm.
Trường hợp các phát tán GNU/Linux
Trong những năm gần đây, nhiều chính quyền vùng tại Tây Ban Nha đã bắt đầu phát triển các phiên bản GNU/Linux riêng của họ Xu hướng này không chỉ dừng lại ở GNU/Linux mà còn mở rộng ra nhiều hệ điều hành khác Mặc dù một số chuyên gia đã chỉ trích sự xuất hiện của các phiên bản này, nhưng chúng minh chứng rõ ràng cho tính linh hoạt mà phần mềm mã nguồn mở (PMTD) mang lại Bất kỳ cơ quan nhà nước nào cũng có thể đầu tư một cách hợp lý để tùy chỉnh một phiên bản GNU/Linux phù hợp với nhu cầu và ưu tiên của họ mà không gặp phải bất kỳ rào cản nào Ví dụ, họ có thể điều chỉnh giao diện người dùng, lựa chọn bộ ứng dụng và ngôn ngữ mặc định, cũng như cải thiện khả năng bản địa hóa cho các ứng dụng.
Máy tính để bàn và các phần mềm liên quan có thể được điều chỉnh để đáp ứng các yêu cầu cụ thể, mang lại sự linh hoạt và tính tùy biến cho người sử dụng.
Sự sửa đổi để phù hợp có thể tốn kém, nhưng kinh nghiệm cho thấy rằng điều này có thể thực hiện với chi phí khá thấp Xu hướng hiện tại cho thấy rằng việc tùy biến các phát tán ngày càng trở nên dễ dàng và rẻ hơn.
4 Áp dụng dễ dàng hơn các chuẩn mở Đưa ra bản chất rất tự nhiên của chúng, các chương trình tự do thường sử dụng các chuẩn mở không sở hữu độc quyền Trong thực tế, hầu như hoàn toàn bằng định nghĩa, bất kỳ khía cạnh nào của một chương trình tự do mà chúng ta có thể quan tâm để xem xét đều có thể sản xuất lại một cách dễ dàng và, vì thế, không phải là sở hữu độc quyền Ví dụ, các giao thức được sử dụng bởi một chương trình tự do để tương tác với các chương trình khác có thể được nghiên cứu và sản xuất lại, nghĩa là chúng sẽ không phải là sở hữu độc quyền Hơn nữa, rất thông thường và theo mối quan tâm của bản thân các dự án, chúng ta sẽ cố gắng sử dụng các chuẩn mở.
Trong mọi trường hợp, các chương trình tự do thường sử dụng các chuẩn không phải sở hữu độc quyền cho việc trao đổi dữ liệu, mang lại lợi ích lớn cho các cơ quan hành chính nhà nước Việc này giúp giảm bớt lo ngại về các chuẩn sở hữu độc quyền, khuyến khích sự tương tác giữa chính quyền và công dân mà không yêu cầu họ phải mua sản phẩm từ một công ty cụ thể.
5 Sự xem xét kỹ lưỡng về an ninh của cơ quan hành chính nhà nước Đối với một cơ quan hành chính nhà nước, việc có khả năng đảm bảo rằng các hệ thống máy tính của nó chỉ làm những gì chúng phải làm là một bổn phận cơ bản, và trong nhiều quốc gia, là một yêu cầu pháp lý Thường những hệ thống này quản lý các dữ liệu riêng tư, mà các bên thứ 3 có thể quan tâm (ví dụ như các dữ liệu thuế, các hồ sơ tội phạm, các dữ liệu trưng cầu hoặc bầu cử, …) Nếu một ứng dụng sở hữu độc quyền được sử dụng, mà không có mã nguồn có sẵn, khó mà đảm bảo rằng các ứng dụng sẽ xử lý các dữ liệu theo cách mà nó phải làm Nhưng ngay cả nếu nó cung cấp mã nguồn, thì những khả năng của một cơ quan hành chính nhà nước đảm bảo rằng nó không chứa các mã nguồn lạ sẽ rất bị hạn chế Chỉ nếu nhiệm vụ này có thể được ủy quyền đều đặn một cách như thường lệ cho các bên thứ 3, và cộng với bên có quan tâm mới có thể soi xét kỹ lưỡng nó được, có thể cơ quan hành chính nhà nước sẽ chắc chắn một cách hợp lý rằng nó phù hợp với những nhiệm vụ cơ bản của mình, hoặc ít nhất tiến hành những biện pháp trong quyền hạn của nó để làm thế.
6 Tính sẵn sàng về lâu dài
Những khó khăn của việc áp dụng và những vấn đề khác
Mặc dù việc áp dụng PMTD mang lại nhiều lợi ích cho các cơ quan hành chính nhà nước, vẫn tồn tại không ít thách thức cần vượt qua để triển khai hiệu quả trong thực tế Một số khó khăn đáng chú ý bao gồm:
1 Thiếu sự hiểu biết và cam kết chính trị
Một trong những vấn đề chính mà PMTD phải đối mặt khi thâm nhập vào các cơ quan hành chính nhà nước là sự thiếu hiểu biết của các nhà quyết định về PMTD Điều này dẫn đến việc các tổ chức khác nhau đều có chung nhận định rằng PMTD vẫn chưa được biết đến rộng rãi trong các cơ quan này.
Mặc dù vấn đề này đang dần được cải thiện, nhưng ở nhiều khu vực, các cơ quan hành chính nhà nước vẫn coi PMTD là một khái niệm lạ lẫm Do đó, các quyết định liên quan đến việc sử dụng PMTD vẫn tiềm ẩn những rủi ro nhất định.
Việc ra quyết định chính trị đóng vai trò quan trọng trong việc triển khai PMTD tại các cơ quan hành chính nhà nước Mặc dù chi phí triển khai PMTD thường cao, đặc biệt với số lượng lớn máy tính trạm, nhưng lợi ích mà nó mang lại vượt xa mọi chiến lược Nếu không có ý chí chính trị để thay đổi hệ thống phần mềm và triết lý hiện tại, sự phát triển của PMTD trong các cơ quan này sẽ gặp khó khăn.
2 Sự áp dụng kém cỏi các cơ chế hợp đồng
Các cơ chế hợp đồng hiện nay mà cơ quan hành chính nhà nước áp dụng, từ đấu thầu công khai đến chi tiết hóa các điều khoản giá thành, chủ yếu phục vụ cho việc mua sắm sản phẩm công nghệ thông tin và dịch vụ liên quan Tuy nhiên, khi sử dụng PMTD, thường không có sản phẩm cụ thể để mua hoặc giá trị của nó không đáng kể Để tận dụng tối đa các cơ hội từ PMTD, cần thiết phải có khả năng ký kết hợp đồng cho các dịch vụ liên quan Điều này yêu cầu thiết kế các cơ chế phù hợp để tạo điều kiện thuận lợi cho việc ký kết hợp đồng trước khi PMTD được áp dụng một cách nghiêm túc.
3 Thiếu chiến lược triển khai
Nhiều cơ quan hành chính nhà nước thường bắt đầu sử dụng phần mềm miễn phí (PMTD) chỉ vì lý do chi phí thấp Tuy nhiên, trong nhiều trường hợp, các sản phẩm này được tích hợp vào hệ thống máy tính mà không có kế hoạch cụ thể, dẫn đến việc thiếu một chiến lược toàn cầu cho việc sử dụng PMTD Hệ quả là, nhiều lợi ích tiềm năng của PMTD bị mất đi, vì việc chỉ tập trung vào sản phẩm rẻ hơn không khai thác được những giá trị thực sự mà chúng mang lại.
Việc sử dụng PMTD trong cơ quan hành chính nhà nước có thể dẫn đến chi phí cao nếu không được thiết kế phù hợp Trong những trường hợp bị cô lập và thiếu khung công việc rõ ràng, PMTD có thể không mang lại hiệu quả và gây nản lòng cho người sử dụng.
4 Sự khan hiếm các sản phẩm PMTD trong những phân khúc nhất định
Việc triển khai PMTD trong tổ chức có thể gặp khó khăn do thiếu giải pháp tự do chất lượng cho một số ứng dụng nhất định Để giải quyết vấn đề này, cần khuyến khích sự phát triển của sản phẩm tự do Các cơ quan hành chính nhà nước có thể đóng vai trò quan trọng trong việc nghiên cứu và cấp vốn cho sự phát triển này, nhằm cung cấp cho công dân quyền truy cập tốt nhất đến xã hội thông tin và khuyến khích nền kinh tế công nghiệp bản địa Việc tạo ra nhiều chương trình tự do sẽ góp phần tích cực vào các mục tiêu này, không chỉ từ góc độ chi phí/lợi ích trực tiếp mà còn mang lại nhiều lợi ích gián tiếp.
5 Tính tương hợp với các hệ thống đang tồn tại
Việc chuyển đổi hoàn toàn sang PMTD không thường diễn ra đồng thời trên toàn bộ hệ thống, do đó, cần đảm bảo rằng các phần được chuyển đổi vẫn hoạt động hiệu quả với phần còn lại và tương thích với nhau Đây là một thách thức phổ biến trong bất kỳ quá trình chuyển đổi nào, đặc biệt là với PMTD Khi nghiên cứu sự chuyển đổi, điều này cần được xem xét kỹ lưỡng May mắn thay, PMTD có thể được áp dụng với các yêu cầu tương thích phù hợp với các hệ thống khác, và nếu cần thiết, yếu tố này cũng phải được tính toán vào ngân sách cho chi phí chuyển đổi.
6 Chuyển đổi các dữ liệu Đây là một vấn đề chung của bất kỳ sự chuyển đổi nào sang các ứng dụng mới mà sử dụng các định dạng dữ liệu khác, ngay cả nếu chúng là sở hữu độc quyền Trên thực tế, trong trường hợp của PMTD thì vấn đề này thường được làm dịu bớt, vì thường phải tiến hành một nỗ lực đặc biệt để dự kiến trước được càng nhiều định dạng và chuẩn trao đổi dữ liệu có thể càng tốt Mà thường thì các dữ liệu phải được chuyển đổi Và giá thành của việc làm này là cao Vì thế, trong việc tính toán giá thành của một sự chuyển đổi tiềm năng sang PMTD, yếu tố này cần phải được xem xét một cách thận trọng.
Hành động của cơ quan hành chính nhà nước trong thế giới PMTD
Làm sao thỏa mãn nhu cầu của các cơ quan hành chính nhà nước?
Các cơ quan hành chính nhà nước là những người tiêu dùng lớn của công nghệ thông tin, thường mua sản phẩm phần mềm có sẵn và hệ thống tùy biến Họ hoạt động như các trung tâm mua sắm lớn, tương tự như các công ty lớn, nhưng với các yêu cầu riêng Quyết định mua sắm của họ không chỉ dựa vào giá cả mà còn xem xét tác động đến lợi ích của ngành công nghiệp và xã hội Hiện nay, nhiều cơ quan vẫn sử dụng các sản phẩm phần mềm độc quyền hàng đầu như Windows và Office, với số tiền đáng kể được chi cho các giấy phép Tuy nhiên, giải pháp tự do đang dần thâm nhập vào thị trường, với sự gia tăng sử dụng các sản phẩm như OpenOffice.org và GNU/Linux với GNOME và KDE cho máy tính để bàn.
Sự chuyển đổi sang PMTD có thể mang lại nhiều lợi ích, ví dụ như việc các cơ quan hành chính nhà nước châu Âu có thể phát triển và áp dụng các chương trình tự do trong vòng 1-2 năm cho các nhiệm vụ tiêu chuẩn Nếu tất cả các cơ quan này phối hợp quản lý các vụ thầu, một ngành công nghiệp địa phương chuyên về cải tiến và áp dụng có thể hình thành Các cơ quan hành chính sẽ có sự lựa chọn giữa 3-4 sản phẩm tự do từ các công ty, và để khuyến khích cạnh tranh, các công ty sẽ nhận được đền bù dựa trên mức độ sử dụng sản phẩm của họ Cuối cùng, PMTD sẽ không chỉ phục vụ cho các cơ quan nhà nước mà còn cho các công ty và cá nhân có nhu cầu tương tự.
Trong lĩnh vực phần mềm tùy biến, quy trình hiện tại thường liên quan đến việc ký hợp đồng với một công ty theo mô hình sở hữu độc quyền Mọi phát triển theo yêu cầu của cơ quan hành chính nhà nước sẽ thuộc quyền sở hữu của công ty phát triển Điều này dẫn đến việc các cơ quan hành chính nhà nước bị ràng buộc với nhà cung cấp trong các vấn đề liên quan đến cải tiến, cập nhật và hỗ trợ, tạo ra một vòng luẩn quẩn làm khó khăn cho sự cạnh tranh và làm chậm quá trình hiện đại hóa Hơn nữa, các chương trình tương tự thường được bán cho nhiều cơ quan hành chính nhà nước khác nhau với chi phí phát sinh tương tự như việc phát triển mới hoàn toàn.
Một nhóm các cơ quan hành chính nhà nước cần phần mềm tùy biến để đạt được kết quả là PMTD, cho phép các cơ quan khác hưởng lợi và khuyến khích hợp tác Các phần mềm này có thể được phát triển miễn phí, không yêu cầu ký hợp đồng với nhà cung cấp duy nhất, tạo cơ hội cho sự cạnh tranh trên thị trường hiện đang bị hạn chế Do đó, chi phí cuối cùng cho các cơ quan hành chính có thể không cao hơn so với việc áp dụng mô hình sở hữu độc quyền.
Các kịch bản này có thể không hoàn toàn là khoa học viễn tưởng, nhưng chúng phản ánh những sáng kiến đang phát triển trong lĩnh vực công nghệ PMTD đang hỗ trợ việc tạo ra và duy trì một nền công nghiệp trong khu vực mua sắm của cơ quan hành chính nhà nước, đồng thời cung cấp những ưu điểm cụ thể cho miền công cộng Một ví dụ điển hình là việc phát triển phần mềm trong các ngôn ngữ thiểu số, điều này không chỉ đáp ứng nhu cầu của nhiều cơ quan hành chính mà còn giúp duy trì độc lập chiến lược và đảm bảo tính khả dụng của dữ liệu trong dài hạn Do đó, các cơ quan nhà nước ngày càng quan tâm đến PMTD như một giải pháp tiềm năng.
Một vài trường hợp có liên quan tới các cơ quan hành chính nhà nước của Đức
Vào tháng 07/2003, phiên bản ổn định đầu tiên của Kolab, một sản phẩm của dự án Kroupware, đã được ra mắt Kolab là hệ thống groupware tự do cho nhóm làm việc dựa trên KDE, được phát triển nhằm đáp ứng nhu cầu của Văn phòng Liên bang Đức về An ninh Thông tin (BSI) trong việc tìm kiếm giải pháp tương thích với Windows và Outlook, cũng như GNU/Linux và KDE Hợp đồng đã được trao cho ba công ty Erfrakon, Intevation và Klarolvdalens Datakonsult, với đề xuất cung cấp một giải pháp tự do một phần dựa trên phần mềm của dự án KDE, kết hợp với các phát triển tự do riêng của họ để tạo ra Kolab.
Vào tháng 05/2003, Tòa thị chính Munich đã quyết định chuyển đổi sang hệ điều hành GNU/Linux và các ứng dụng văn phòng miễn phí cho khoảng 14,000 máy tính để bàn Quyết định này không chỉ dựa trên yếu tố tài chính mà còn xem xét các khía cạnh chiến lược và chất lượng Một phân tích tổng hợp trước đó cho thấy giải pháp GNU/Linux kết hợp với OpenOffice.org đạt 6,218 điểm, vượt trội so với giải pháp truyền thống dựa trên phần mềm của Microsoft, chỉ đạt dưới 5,000 điểm.
Vào tháng 07/2003, Koordinierungs-und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) thuộc Bộ Nội vụ Đức đã công bố tài liệu "Hướng dẫn chuyển đổi cho các thành phần phần mềm cơ bản của các máy tính chủ và máy tính trạm" Tài liệu này cung cấp cho các cơ quan nhà nước Đức một bộ chỉ dẫn nhằm hỗ trợ quá trình chuyển đổi sang các giải pháp dựa trên PMTD Các chỉ dẫn này được thiết kế để giúp các nhà ra quyết định đánh giá tính phù hợp của việc chuyển đổi sang PMTD và hướng dẫn cách thức triển khai nếu quyết định được thông qua.
Khuyến khích xã hội thông tin
Các cơ quan nhà nước đầu tư nhiều tài nguyên vào việc khuyến khích chi tiêu cho công nghệ thông tin, điều này có thể giúp các công nghệ mới phát triển trong xã hội Tuy nhiên, việc khuyến khích sử dụng một trình duyệt cụ thể có thể dẫn đến tình trạng độc quyền không mong muốn, ảnh hưởng tiêu cực đến xã hội PMTD có thể đóng vai trò trung lập, không cho phép bất kỳ nhà sản xuất nào độc quyền chương trình tự do Nếu cơ quan nhà nước muốn khuyến khích sử dụng các chương trình tự do, họ có thể tổ chức đấu thầu để mọi công ty trong lĩnh vực này tham gia, từ đó quản lý việc phân phối và cải tiến các chương trình cho công dân Điều này cũng mang lại lợi ích kinh tế đáng kể.
Trong nhiều trường hợp, với cùng một số vốn, doanh nghiệp có thể lựa chọn mua giấy phép cho các chương trình sở hữu độc quyền hoặc mua bản sao tự do kèm theo hợp đồng hỗ trợ Ngoài ra, việc thương thảo với nhà sản xuất PMSHĐQ về quyền chuyển đổi sản phẩm thành PMTD cũng là một lựa chọn khả thi.
Trong lĩnh vực giáo dục, việc phát triển một phiên bản GNU/Linux dành riêng cho các trường tiểu học có thể giúp nâng cao chất lượng đào tạo Phân bổ một phần ngân sách cho việc tin học hóa này sẽ hỗ trợ việc duy trì và cập nhật phần mềm, đảm bảo rằng các công cụ công nghệ luôn đáp ứng nhu cầu học tập của học sinh.
Để đảm bảo phần mềm hoạt động đúng cách, mọi người cần có trách nhiệm không chỉ trong việc đáp ứng các yêu cầu giáo dục mà còn trong việc tạo ra thị trường cho các công ty bản địa cung cấp dịch vụ duy trì Điều này mở ra một tương lai bền vững, khi phần mềm không bị cô lập trong một thời gian ngắn mà có thể được cập nhật liên tục, duy trì lợi ích của chương trình với một khoản đầu tư ổn định qua từng năm.
Vào cuối năm 2001, Chính quyền vùng Extremadura, Tây Ban Nha, đã quyết định áp dụng phát tán GNU/Linux gnuLinEx để máy tính hóa tất cả các trường công Để thực hiện điều này, họ đã cấp vốn cho việc phát triển gnuLinEx, một phiên bản GNU/Linux dựa trên Debian, được công bố vào mùa thu năm 2002 và yêu cầu sử dụng trong tất cả các thầu mua sắm thiết bị máy tính cho trường học Chính quyền cũng đã triển khai các chương trình đào tạo cho giáo viên, tạo tài liệu giảng dạy và chia sẻ kinh nghiệm Đến giữa năm 2003, dự án này đã được xem là thành công và mở rộng có tổ chức sang các vùng khác, như Andalucia thông qua dự án Guadalinex.
Thúc đẩy nghiên cứu
PMTD mang lại nhiều lợi ích nổi bật trong việc phát triển các chính sách nghiên cứu và phát triển (R&D) Nhà nước đang đầu tư vào nhiều dự án phần mềm, mang lại lợi ích cho xã hội, cả trực tiếp lẫn gián tiếp Tuy nhiên, nhiều khoản vốn R&D không đi kèm với kế hoạch thương mại hóa, dẫn đến việc sản phẩm bị bỏ quên Đặc biệt, những người đã tài trợ cho các chương trình này thông qua thuế có thể ngừng cấp vốn nếu họ cần mua giấy phép để sử dụng sản phẩm.
PMTD đưa ra một lựa chọn thú vị cho các cơ quan hành chính trong việc xem xét các chính sách đổi mới sáng tạo Sự cạnh tranh trước trong nghiên cứu, đặc biệt trong cấp vốn nhà nước, cho phép toàn bộ ngành công nghiệp và xã hội hưởng lợi từ nguồn tiền đầu tư cho R&D trong lĩnh vực phần mềm Khi một công ty không thể bán được kết quả, công ty khác lại có thể tìm thấy cơ hội kinh doanh Nhờ đó, các kết quả nghiên cứu được tối đa hóa, đồng thời tăng cường sự cạnh tranh giữa các công ty muốn áp dụng những kết quả từ dự án.
Mô hình này không mới và đã góp phần vào sự phát triển của Internet Nếu các cơ quan nhà nước yêu cầu rằng kết quả nghiên cứu từ nguồn vốn của họ phải được phân phối dưới dạng PMTD, điều này có thể dẫn đến những trường hợp tương tự xuất hiện với các mức độ khác nhau Kết quả nghiên cứu có thể trở nên kém hiệu quả hoặc vô dụng, đòi hỏi cần xem xét lại cách lựa chọn dự án cấp vốn Ngược lại, nếu được để lại cho các công ty, sự năng động này có thể tạo ra những sản phẩm mới và phát triển không thể đoán trước.
Những ví dụ của những sáng kiến về pháp lý
Các dự luật tại Pháp
Vào năm 1999 và 2000, Pháp đã trình bày hai dự luật liên quan đến PMTD, đánh dấu sự khởi đầu cho một chuỗi tranh luận pháp lý kéo dài về vấn đề này.
Dự luật 1999-495, do Lafitte, Tresgouet và Cabanel đệ trình, đã được công bố trên trang web của Thượng viện Pháp vào tháng 10/1999 Sau hai tháng tranh luận trên Internet, dự luật đã được sửa đổi thành dự luật số 2000-117, yêu cầu sử dụng PMTD trong các cơ quan hành chính nhà nước, đồng thời đề xuất các ngoại lệ và phương thức chuyển giao cho những trường hợp không thể thực hiện về mặt kỹ thuật, trong bối cảnh mở rộng sử dụng Internet và PMTD trong các cơ quan hành chính của Pháp.
Vào năm 2000, các nghị sĩ Jean-Yves Le Déaut, Christian Paul và Pierre Cohen đã trình bày một luật mới nhằm tăng cường tự do và an ninh cho người sử dụng, đồng thời cải thiện bình quyền trong xã hội thông tin, tương tự như dự thảo của Laffitte, Trégouet và Cabanel.
Dự luật thứ hai không yêu cầu các cơ quan hành chính nhà nước phải sử dụng phần mềm mã nguồn mở (PMTD) như dự luật của Laffitte, Trégouet và Cabanel Thay vào đó, nó nhấn mạnh rằng phần mềm được sử dụng bởi các cơ quan này cần có mã nguồn sẵn sàng, nhưng không bắt buộc phải được phân phối dưới giấy phép PMTD Để đạt được mục tiêu, các nhà lập pháp đã tập trung vào việc đảm bảo "quyền cho tính tương thích" của phần mềm, thông qua việc áp dụng các cơ chế thực hiện nguyên tắc tương hợp theo Chỉ thị của Ủy ban châu Âu về bảo vệ pháp luật các chương trình máy tính (Chỉ thị 91/250/EEC, ngày 14/05/1991).
Cả 2 phác thảo của Pháp đã không được phê chuẩn thành luật, nhưng cả 2 đã phục vụ để truyền cảm hứng cho hầu hết các sáng kiến sau này trên toàn thế giới, mà nó giải thích vì sao chúng đặc biệt thú vị để nghiên cứu
Dự thảo thứ 2 do Le Déaut, Paul và Cohen đề xuất nhấn mạnh tính tương thích và tương hợp của phần mềm, đồng thời khẳng định sự sẵn sàng của mã nguồn cho các ứng dụng của cơ quan hành chính nhà nước Tuy nhiên, dự thảo này không yêu cầu các ứng dụng phát triển phải tuân thủ tiêu chuẩn PMTD, tức là phần mềm phải được phân phối dưới các giấy phép cho phép tự do sửa đổi, sử dụng và phân phối lại.
Trong phần D.1 và D.2 của phụ lục D, chúng ta sẽ xem xét lại hầu hết các bài viết và bản ghi nhớ giải thích liên quan đến hai dự luật này Những bản ghi nhớ này đặc biệt thú vị vì chúng nhấn mạnh các vấn đề đang đe dọa các cơ quan hành chính nhà nước trong việc sử dụng phần mềm nói chung.
Dự luật của Brazil
In 1999, Congressman Walter Pinheiro submitted a bill regarding open-source software to the Brazilian Chamber of Deputies (Proposal PL-2269/1999), which addressed the use of open-source programs by public and private entities under the control of public administration This initiative aimed to promote the adoption of open-source software in government agencies and private companies where the state holds a majority stake.
Nó khuyến cáo sử dụng PMTD cho các cơ quan mà không có hạn chế về cho vay, mượn, sửa đổi hoặc phân phối Các bài viết pháp luật mô tả chi tiết định nghĩa PMTD và các giấy phép liên quan Định nghĩa này phù hợp với định nghĩa kinh điển của PMTD trong dự án GNU Bản ghi nhớ giải thích về lịch sử dự án GNU, phân tích những ưu điểm và thành tựu của nó, đồng thời tham chiếu đến hiện trạng của PMTD, với hệ điều hành GNU/Linux làm ví dụ.
Một trong những điểm hấp dẫn nhất của bài viết là việc xác định rõ ràng lĩnh vực mà việc sử dụng PMTD được đề xuất Cần lưu ý rằng định nghĩa "chương trình mở" trong các bài viết sau đây được hiểu tương tự như PMTD.
Tất cả các cơ quan hành chính nhà nước từ trung ương đến địa phương, bao gồm cả doanh nghiệp công tư hợp doanh và các công ty nhà nước, đều phải tuân thủ sự kiểm soát của Nhà nước Brazil Họ có trách nhiệm ưu tiên sử dụng các chương trình mã nguồn mở trong hệ thống và trang thiết bị máy tính của mình, nhằm đảm bảo tính tự do trong việc nhượng lại, sửa đổi và phân phối mà không bị ràng buộc bởi các hạn chế sở hữu độc quyền.
Các dự luật tại Peru
Tại Peru, một số dự án luật đã được trình bày liên quan đến việc sử dụng PMTD trong các cơ quan hành chính nhà nước Dự luật nổi bật nhất, do nghị sĩ Edgar Villanueva Nỳủez đề xuất vào tháng 12/2001, là dự luật PMTD số 1609.
PMTD, theo định nghĩa kinh điển về 4 quyền tự do, cần được bổ sung bằng một định nghĩa pháp lý chính xác hơn, chỉ rõ 6 đặc tính của một chương trình tự do Đề xuất này nhấn mạnh việc áp dụng PMTD chỉ trong các cơ quan hành chính nhà nước của Peru.
Các cơ quan hành pháp, lập pháp, tư pháp, cơ quan phân quyền địa phương và các công ty mà Nhà nước nắm giữ cổ phần đa số chỉ được phép sử dụng các chương trình hoặc phần mềm thiết bị trong hệ thống và thiết bị máy tính của họ.
Bất chấp, sau đó, các điểm 4 và 5 đưa vào một số ngoại lệ cho qui định này.
Dự luật này đã tạo ra tác động toàn cầu khi lần đầu tiên đề xuất việc sử dụng PMTD trong các cơ quan hành chính nhà nước Sự trao đổi thư từ giữa nghị sỹ Villanueva và đại diện của Microsoft tại Peru đã nêu ra những lý do phản đối đề xuất này Đáng chú ý, sứ quán Mỹ cũng bày tỏ sự lo ngại về việc mua sắm của Chính phủ Peru chỉ giới hạn trong PMNM hoặc PMTD Microsoft và sứ quán Mỹ lập luận rằng dự luật có thể phân biệt đối xử giữa các công ty, gây cản trở đầu tư và phát triển ngành công nghiệp phần mềm quốc gia Tuy nhiên, Villanueva đã khẳng định rằng dự luật không ưu tiên bất kỳ công ty nào và không chỉ định nhà cung cấp cụ thể, mà chỉ quy định các điều kiện cung cấp phần mềm cho các cơ quan hành chính nhà nước.
PMTD của các cơ quan hành chính nhà nước không gây hại bằng bất kỳ cách nào cho sự cạnh tranh tự do giữa các nhà cung cấp.
Vào ngày 08/04/2002, các nghị sỹ quốc hội Peru, Edgar Villanueva Núñez và Jacques Rodrich Ackerman, đã đệ trình dự luật số 2485 về việc sử dụng phần mềm mã nguồn mở trong các cơ quan hành chính nhà nước Dự luật này, vẫn còn lưu giữ tại quốc hội vào tháng 08/2003, được xem là một bước tiến từ Dự luật 1609, với nhiều cải tiến đáng chú ý Nó là một ví dụ điển hình về việc đề xuất sử dụng phần mềm mã nguồn mở trong các cơ quan nhà nước, đồng thời bảo lưu một số trường hợp ngoại lệ Bản ghi nhớ đi kèm cung cấp những giải thích rõ ràng về các đặc tính cần thiết của phần mềm trong các cơ quan hành chính và cách mà phần mềm mã nguồn mở đáp ứng những tiêu chí này tốt hơn so với phần mềm thương mại.
Các dự luật tại Tây Ban Nha
Tại Tây Ban Nha đã từng có một vài sáng kiến pháp lý có liên quan tới PMTD Dưới đây, chúng ta trích ra một số trong đó:
Sắc lệnh 72/2003, ngày 18/03, về các Biện pháp Khuyến khích Xã hội Tri thức tại Andalucia là một sáng kiến pháp lý quan trọng tại Tây Ban Nha, đã chính thức có hiệu lực Sắc lệnh này tập trung vào việc sử dụng PMTD, chủ yếu trong lĩnh vực giáo dục, nhằm thúc đẩy phát triển xã hội tri thức trong khu vực.
Nó khuyến khích ưu tiên sử dụng PMTD tại các trung tâm giáo dục nhà nước, yêu cầu tất cả trang thiết bị mua sắm phải tương thích với các hệ điều hành tự do Điều này cũng áp dụng cho các trung tâm của chính quyền vùng cung cấp dịch vụ truy cập Internet công cộng.
Dự luật về phần mềm mã nguồn mở (PMTD) trong các cơ quan hành chính nhà nước của Catalonia đã gặp khó khăn trong việc thu hút sự ủng hộ, mặc dù các cộng đồng khác đã đưa ra những đề xuất tham vọng hơn Đề xuất nổi bật nhất là "Proposició de llei de programari lliure trong khung pháp lý của Administració pública de Catalunya" vào năm 2002, tương tự như một đề xuất mà Esquerra Republicana de Catalunya đã trình lên Hạ viện Tuy nhiên, đề xuất này đã không thành công trong việc được thông qua tại Quốc hội Catalonia.
Dự luật của Joan Puigcercós Boixassa (Esquerra Republicana de Catalunya) về các biện pháp thâm nhập của PMTD vào các cơ quan hành chính nhà nước đã được trình lên Hạ viện vào năm 2002 Sáng kiến này nhằm ưu tiên PMTD trong các cơ quan hành chính, tương tự như những sáng kiến khác có cùng mục tiêu Tuy nhiên, điểm đặc biệt của nó là nhấn mạnh tính sẵn sàng của các chương trình tự do cho các ngôn ngữ đồng chính thức tại các cộng đồng tự trị Dù vậy, sáng kiến này đã không được phê chuẩn trong chương trình nghị sự của quốc hội.
“Cách tốt nhất để có được một ý tưởng tốt là phải có chúng nhiều”
Trong các chương trước, chúng ta đã chỉ ra rằng thách thức của PMTD không chỉ đơn thuần là cạnh tranh về tốc độ, chi phí và chất lượng phần mềm PMTD khác biệt so với phần mềm truyền thống ở nhiều khía cạnh, bao gồm triết lý, động lực, thị trường và mô hình kinh doanh mới, cũng như cách thức tạo ra phần mềm Kỹ thuật phần mềm bị ảnh hưởng bởi những yếu tố này, do đó, nghiên cứu về sự phát triển của PMTD trong vòng chưa đầy 10 năm qua đã trở thành một chủ đề đáng chú ý Chương này sẽ tranh luận về những nghiên cứu và bằng chứng quan trọng, nhằm cung cấp cho độc giả cái nhìn hiện đại và triển vọng tương lai về kỹ thuật của PMTD.
Giới thiệu
Mặc dù PMTD đã được phát triển trong nhiều thập kỷ, nhưng chỉ trong những năm gần đây, chúng ta mới bắt đầu chú ý đến các mô hình và quy trình phát triển của nó từ góc độ kỹ thuật phần mềm Tương tự, không chỉ tồn tại một mô hình duy nhất cho sự phát triển của PMSHĐQ hay PMTD 5, mà chúng ta cũng nhận thấy những đặc điểm thú vị mà hầu hết các dự án chia sẻ nghiên cứu có thể xuất phát từ các thuộc tính của các chương trình tự do.
Vào năm 1997, Eric S Raymond đã phát hành bài viết nổi tiếng “Nhà thờ lớn và cái chợ”, trong đó ông suy ngẫm về Linux và phong trào mã nguồn mở, đánh dấu một cuộc cách mạng ngẫu nhiên trong lĩnh vực công nghệ.
Bài viết của Associates (2001) tại http://www.ora.com đã mô tả các đặc tính của mô hình phát triển PMTD, đặc biệt nhấn mạnh sự khác biệt giữa các mô hình này và sự phát triển của PMSHĐQ Từ đó, bài viết đã trở thành một trong những tác phẩm nổi bật và gây tranh cãi nhất trong lĩnh vực PMTD, đánh dấu sự khởi đầu cho sự phát triển của kỹ thuật PMTD.
Nhà thờ lớn và cái chợ
Raymond so sánh sự tương đồng giữa việc xây dựng các nhà thờ lớn thời trung cổ và quy trình sản xuất phần mềm kinh điển Ông nhấn mạnh rằng cả hai đều có sự phân chia nhiệm vụ và chức năng rõ ràng, với sự hiện diện của một nhà thiết kế có khả năng nhìn nhận tổng thể và kiểm soát quá trình phát triển Đồng thời, việc lập kế hoạch được thực hiện một cách nghiêm ngặt, với các quy trình chi tiết nhằm đảm bảo rằng mỗi thành viên tham gia đều có vai trò cụ thể trong hoạt động.
Bài viết “Sinh thái học của sự phát triển PMNM” của Kieran Healy và Alan Schussman (2003) nêu bật nhiều dự án đa dạng và số lượng lập trình viên phong phú, cùng với việc sử dụng các công cụ và bản tải về khác nhau, cho thấy vai trò quan trọng của động lực trong quá trình phát triển phần mềm mã nguồn mở.
Raymond đã lấy cảm hứng từ các mô hình xây dựng nhà thờ lớn để áp dụng vào quy trình phát triển phần mềm, như mô hình thác nước và Quy trình Thống nhất Hợp lý (RUP) Ông nhấn mạnh rằng các dự án như GNU và NetBSD có sự tập trung cao độ, với một nhóm nhỏ người chịu trách nhiệm thiết kế và triển khai phần mềm Các nhiệm vụ trong dự án được phân công rõ ràng, và những người muốn tham gia vào đội phát triển phải được giao nhiệm vụ cụ thể Hơn nữa, việc phát hành phần mềm diễn ra theo một lịch trình nghiêm ngặt, dẫn đến ít lần phát hành và chu kỳ dài giữa các lần phát hành.
Mô hình đối nghịch với nhà thờ lớn là cái chợ, theo Raymond, một số chương trình PMTD, đặc biệt là nhân Linux, được phát triển theo sơ đồ tương tự như chợ phương Đông Trong chợ, không có nhà chức trách lớn kiểm soát quá trình phát triển hay lên kế hoạch nghiêm ngặt cho những gì cần xảy ra Các vai trò của người tham gia cũng có thể thay đổi liên tục, với người bán có thể trở thành khách hàng mà không có sự chỉ định bên ngoài.
“Nhà thờ lớn và cái chợ” mô tả quá trình thành công của Linux, cung cấp danh sách các “kinh nghiệm thực tiễn tốt” nhằm tối đa hóa cơ hội từ mã nguồn mở Bài viết nhấn mạnh tính tương tác thông qua việc sử dụng các hệ thống và công cụ từ xa.
Dự án PMTD thường bắt nguồn từ hành động cá nhân của lập trình viên, người nhận thấy khả năng hạn chế trong việc giải quyết vấn đề Để bắt đầu, lập trình viên cần có kiến thức đủ để phát triển một giải pháp khả thi, đơn giản và được thiết kế tốt Khi có sản phẩm đầu tiên, việc chia sẻ nó với cộng đồng PMTD qua hình thức ra mắt sớm sẽ thu hút sự chú ý từ những lập trình viên khác có cùng vấn đề Một nguyên tắc quan trọng trong mô hình phát triển này là xem người sử dụng như những đồng phát triển, cần được đối xử cẩn trọng vì họ có thể cung cấp phản hồi giá trị và tham gia vào quá trình kiểm thử Việc kiểm thử, khác với đồng phát triển, có thể thực hiện song song và cho phép người dùng kiểm tra phần mềm trong các điều kiện cụ thể, tạo ra ảnh hưởng lớn đến đội ngũ phát triển nhờ vào sự đa dạng của kiến trúc và môi trường.
Khi chúng ta coi người sử dụng như những đồng lập trình viên, họ có thể phát hiện và gửi bản vá lỗi cho dự án, giúp giải quyết vấn đề trong phiên bản tiếp theo Ngoài ra, một người khác cũng có thể tình cờ hiểu và sửa lỗi đó Tất cả những tình huống này đều thúc đẩy sự phát triển của phần mềm, cho thấy lợi ích của việc tham gia vào một môi trường hợp tác như vậy.
Tình huống này trở nên hiệu quả hơn với việc tung ra thường xuyên, vì động lực sửa lỗi cao do giả định rằng chúng sẽ được tham dự ngay lập tức Sự tích hợp thường xuyên, lý tưởng là một hoặc nhiều lần trong ngày, không yêu cầu pha cuối cùng cho việc tích hợp các module của chương trình Điều này được gọi là sự tung ra thường xuyên, cho phép mức độ module hóa cao và tối đa hóa hiệu ứng tuyên truyền từ báo chí đối với phiên bản phần mềm mới nhất.
Quản lý phiên bản mới phụ thuộc vào kích thước của dự án, với các vấn đề cần giải quyết khác nhau giữa đội phát triển nhỏ và lớn Đối với các dự án nhỏ, quy trình quản lý thường không chính thống, trong khi các dự án lớn tuân theo quy trình xác định và phức tạp hơn Bài viết “Quản lý phiên bản trong các dự án nguồn mở” của Justin R Ehrenkrantz (2003) mô tả chi tiết quy trình này trong các dự án như máy chủ web Apache và nhân Linux Để tránh việc phát hành phiên bản quá thường xuyên gây lo ngại cho người dùng, một số dự án PMTD triển khai nhiều nhánh phát triển song song, như trường hợp nổi tiếng của nhân Linux, tập trung vào độ tin cậy cho người dùng và các phiên bản không ổn định dành cho lập trình viên.
Sự lãnh đạo và ra quyết định trong cái chợ
Raymond cho rằng mỗi dự án PMTD cần một nhà lãnh đạo độc tài nhân từ, thường là người sáng lập, để hướng dẫn và có tiếng nói quyết định cuối cùng Người lãnh đạo này cần có khả năng động viên, phối hợp dự án, hiểu rõ người dùng và lập trình viên, đồng thời tìm kiếm sự đồng thuận và tích hợp các thành viên có đóng góp Điều đáng chú ý là năng lực kỹ thuật, dù quan trọng, không phải là yêu cầu hàng đầu trong những phẩm chất cần thiết này.
Khi kích thước dự án và số lượng lập trình viên tăng lên, các phương pháp tổ chức ra quyết định mới đã xuất hiện Chẳng hạn, Linux có cấu trúc thứ bậc với Linus Torvalds, được gọi là "nhà độc tài nhân từ", nắm quyền quyết định cuối cùng Mặc dù một số phần của Linux có "các nhà độc tài nhân từ" riêng, quyền lực của họ vẫn bị giới hạn bởi sự kiểm soát của Torvalds Đây là ví dụ rõ ràng về cách tính module hóa trong dự án PMTD ảnh hưởng đến tổ chức và quy trình ra quyết định.
Một số người so sánh cách tổ chức các dự án PMTD với một đội phẫu thuật, ý tưởng này được Harlan Mills từ IBM đề xuất vào những năm 70 và sau đó được Frederick P Brooks Jr phổ biến trong cuốn sách nổi tiếng “Người - tháng thần thoại” (1975).
Trong một số trường hợp, đội phát triển của một ứng dụng PMTD có thể chỉ bao gồm một nhà thiết kế và một nhóm lập trình viên thực hiện các nhiệm vụ phụ trợ như quản trị hệ thống và viết tài liệu Tuy nhiên, sự phân chia vai trò này không bao giờ đạt được độ chính xác như mong đợi, như đã được Mills và Brooks chỉ ra Brooks nhấn mạnh rằng trong bối cảnh phát triển phần mềm, số lượng lập trình viên cần thiết để giao tiếp hiệu quả trong việc tạo ra một hệ thống lớn và phức tạp thường thấp hơn nhiều so với tổng số lập trình viên tham gia.
Quỹ Apache áp dụng một chế độ nhân tài đặc biệt, với ủy ban giám đốc được hình thành từ những cá nhân có đóng góp đáng kể cho dự án Tuy nhiên, đây không phải là một chế độ nghiêm ngặt, vì ủy ban được bầu cử dân chủ bởi các thành viên của Quỹ, những người có trách nhiệm quản lý nhiều dự án như Apache và Jakarta.
Để gia nhập Quỹ Apache, bạn cần có những đóng góp quan trọng và liên tục cho một trong các dự án của Quỹ, hệ thống này cũng được áp dụng cho các dự án khác như FreeBSD và GNOME.
Ban Chỉ đạo GCC, được thành lập vào năm 1998 với sự hỗ trợ của FSF, nhằm ngăn chặn việc kiểm soát dự án GCC (Bộ sưu tập các trình biên dịch của GNU) Ban này tiếp nối truyền thống của một ban tương tự từ dự án EGCS, với nhiệm vụ đảm bảo rằng GCC thực hiện đầy đủ sứ mệnh của mình Các thành viên trong ban được chọn từ dự án, đại diện cho các cộng đồng khác nhau tham gia vào sự phát triển của GCC, bao gồm lập trình viên cho nhiều ngôn ngữ và các nhóm quan tâm đến lập trình nhúng.
Lãnh đạo của một dự án PMTD không nhất thiết phải là người duy nhất giữ vai trò này mãi mãi Có hai hoàn cảnh chính dẫn đến sự thay đổi lãnh đạo: thứ nhất là khi người lãnh đạo thiếu thời gian, sự quan tâm hoặc động lực, dẫn đến việc chuyển giao trách nhiệm cho lập trình viên khác Nghiên cứu của González Barahona và Robles (2003) cho thấy sự thay đổi lãnh đạo trong dự án là điều bình thường, với nhiều thế hệ lập trình viên xuất hiện theo thời gian Thứ hai, vấn đề phức tạp hơn liên quan đến việc rẽ nhánh, khi giấy phép PMTD cho phép bất kỳ ai sửa đổi và phân phối mã nguồn mà không cần sự phê duyệt của lãnh đạo dự án Điều này có thể xảy ra để tránh sự can thiệp từ lãnh đạo, tương tự như một cuộc “đảo chính” hợp pháp Vì vậy, một trong những nhiệm vụ của lãnh đạo dự án là giữ cho các đồng nghiệp hài lòng nhằm giảm thiểu khả năng xảy ra rẽ nhánh.
Các qui trình của PMTD
Mặc dù PMTD không gắn liền với một quy trình phát triển phần mềm cụ thể, nhưng có sự đồng thuận về các quy trình phổ biến được sử dụng Các dự án PMTD thường không chính thức, với đội phát triển thực hiện nhiệm vụ tự nguyện mà không mong đợi phần thưởng tài chính Cách nắm bắt yêu cầu trong PMTD phụ thuộc vào "tuổi" và kích thước dự án; trong giai đoạn đầu, người sáng lập và người sử dụng thường là một Khi dự án mở rộng, việc nắm bắt yêu cầu diễn ra qua danh sách email và có sự phân biệt giữa lập trình viên và người sử dụng Đối với các dự án lớn, yêu cầu được nắm bắt bằng công cụ quản lý lỗi, cho phép phân loại và giám sát tình trạng giải quyết Sự tiến hóa trong PMTD đã dẫn đến việc áp dụng các công cụ lập kế hoạch, mặc dù tài liệu tập hợp yêu cầu vẫn hiếm gặp, khác với mô hình thác nước.
Trong thiết kế hệ thống toàn cầu, chỉ những dự án lớn mới thường được tài liệu hóa chi tiết Ngược lại, với các dự án nhỏ hơn, chỉ có một hoặc vài lập trình viên nắm rõ thiết kế, đôi khi không có thiết kế nào được ghi chép, dẫn đến việc hệ thống phát triển một cách tự phát Sự thiếu hụt thiết kế chi tiết không chỉ hạn chế khả năng tái sử dụng các module mà còn gây khó khăn cho lập trình viên mới trong việc tiếp cận, khiến họ phải trải qua một quá trình học tập tốn kém và chậm chạp Hơn nữa, việc thiếu thiết kế chi tiết cũng đồng nghĩa với việc nhiều cơ hội tái sử dụng mã nguồn bị bỏ lỡ.
Giai đoạn cài đặt triển khai là thời điểm mà các lập trình viên PMTD tập trung mọi nỗ lực của mình, vì họ coi đây là giai đoạn thú vị nhất Để đạt được kết quả mong muốn, mô hình lập trình kinh điển về kiểm thử và lỗi thường được giám sát chặt chẽ Lịch sử cho thấy, việc kiểm thử thường không được tích hợp vào mã nguồn ngay từ đầu, mặc dù việc sửa đổi mã nguồn sau này từ các lập trình viên khác sẽ dễ dàng hơn Đối với các dự án lớn như Mozilla, có các máy chuyên dụng để tải về kho mã nguồn mới nhất và biên dịch cho các kiến trúc khác nhau Những lỗi được phát hiện sẽ được ghi lại vào danh sách của các lập trình viên.
Kiểm thử tự động không phải là một thực tế cố định, mà thường được triển khai bởi người sử dụng với nhiều kiến trúc và kết hợp khác nhau Điều này giúp quản lý song song với chi phí tối thiểu cho đội phát triển Tuy nhiên, thách thức nằm ở việc thu thập và tổ chức phản hồi từ người dùng một cách hiệu quả Trong bối cảnh bảo trì phần mềm của PMTD, việc duy trì các phiên bản trước phụ thuộc vào tính chất của dự án Đối với những dự án cần tính ổn định, như hệ điều hành, các phiên bản trước sẽ được bảo trì để tránh lỗi khi chuyển sang phiên bản mới Ngược lại, trong hầu hết các dự án PMTD, khi phát hiện lỗi trong phiên bản cũ, lập trình viên thường khuyến cáo người dùng nên sử dụng phiên bản mới nhất với hy vọng lỗi đã được khắc phục.
Chỉ trích về “Nhà thờ lớn và cái chợ”
Bài viết "Nhà thờ lớn và cái chợ" đã bị chỉ trích về tính không có hệ thống và thiếu chặt chẽ, chủ yếu từ giới phóng viên, hơn là từ bản chất của giới khoa học Những chỉ trích này thường nhấn mạnh rằng bài viết chủ yếu giải thích cho trải nghiệm cụ thể của Linux và cố gắng mở rộng những kết luận này cho tất cả các dự án PMTD Trong nghiên cứu "Hang động hay cộng đồng? Một sự kiểm tra theo kinh nghiệm của 100 dự án nguồn mở chín muồi", cho thấy sự tồn tại của một cộng đồng lớn như của Linux thực chất là một ngoại lệ, không phải là quy luật chung.
Nhiều chỉ trích đối với Linux đến từ những người xem nó là một biểu tượng của mô hình phát triển giống như nhà thờ lớn Họ lập luận rằng có sự hiện diện của một động lực hoặc một cá nhân có quyền lực tối thượng, cùng với một hệ thống thứ bậc rõ ràng, đảm bảo trách nhiệm từ cấp cao xuống cấp thấp, bao gồm cả những lập trình viên Hơn nữa, sự phân công nhiệm vụ trong mô hình này là rất rõ ràng Quan điểm "cái nhìn thứ 2 vào nhà thờ lớn và cái chợ" thể hiện sự hoài nghi và có phần cay đắng, cho rằng phép ẩn dụ về cái chợ là một sự đối lập nội tại trong chính mô hình này.
Một trong những điểm gây tranh cãi nhất trong "Nhà thờ lớn và cái chợ" là quan điểm của Brooks, cho rằng việc thêm lập trình viên vào một dự án phần mềm đã bị chậm trễ sẽ chỉ càng làm cho tiến độ của dự án chậm hơn Quan điểm này được trình bày trong tác phẩm "Người - tháng thần thoại Tiểu luận về kỹ thuật phần mềm" năm 1975.
Trong thế giới của PMTD, giá trị của [150] không được công nhận Theo [148], thực tế cho thấy rằng các ngữ cảnh môi trường sẽ khác nhau, và những nguyên lý dường như không phù hợp với luật Brooks Sau khi thực hiện một phân tích tổng hợp, điều này chỉ là một ảo vọng.
Các nghiên cứu có tính định lượng
PMTD cho phép nghiên cứu sâu về mã nguồn và các tham số liên quan nhờ vào việc truy cập nhiều nguồn thông tin công khai Điều này khuyến khích các lĩnh vực kỹ thuật phần mềm truyền thống, như kỹ thuật phần mềm theo chủ nghĩa kinh nghiệm, nhờ vào lượng thông tin phong phú có sẵn mà không cần can thiệp nặng nề vào phát triển PMTD Các tác giả tin rằng tầm nhìn này có thể đóng góp lớn cho việc phân tích và tổng hợp các hiện tượng liên quan đến PMTD và phần mềm nói chung, đồng thời có khả năng tạo ra các mô hình phần mềm dự đoán với phản hồi thời gian thực Ý tưởng đơn giản là tận dụng cơ hội nghiên cứu hàng triệu chương trình PMTD Thêm vào đó, việc công khai sự tiến hóa của dự án trong quá khứ cho phép phân tích và đóng gói thông tin kịp thời, phục vụ như nền tảng tri thức để đánh giá tình trạng dự án, hỗ trợ quyết định và dự đoán các phức tạp trong hiện tại và tương lai.
Nghiên cứu lượng hóa đầu tiên về bất kỳ tầm quan trọng nào trong thế giới của PMTD ngược về năm
Vào năm 1998, một khảo sát về PMTD Orbiten được công bố vào đầu năm 2000 nhằm tìm hiểu sự tham gia của lập trình viên theo chủ nghĩa kinh nghiệm Nghiên cứu này đã phân tích thống kê các chỉ định quyền tác giả trong tiêu đề các tệp mã nguồn, cho thấy rằng 80% mã nguồn được đóng góp bởi 20% lập trình viên tích cực nhất, tương ứng với quy luật Pareto Nhiều nghiên cứu sau đó đã khẳng định và mở rộng kết quả này thông qua các phương pháp khác nhau liên quan đến sự tham gia trong việc đóng góp mã nguồn, như danh sách thư, lưu ý lỗi và số lượng tải về.
Nhiều khái niệm kinh tế trong nghiên cứu kỹ thuật PMTD xuất phát từ sự quan tâm của các nhà kinh tế học về động cơ của những người tình nguyện tạo ra sản phẩm có giá trị mà không nhận lợi ích trực tiếp Bài viết nổi tiếng "Thị trường của các nồi nấu nước" trình bày mô hình kinh tế cho giao dịch hàng hóa và dịch vụ tự do trên Internet, giới thiệu khái niệm nền kinh tế quà biếu Nguyên lý Pareto và sự tổng quát của nó về phân bổ được giải thích chi tiết tại Wikipedia, trong khi đường cong Lorenz minh họa sự tham gia của lập trình viên trong dự án và hệ số Gini phản ánh sự không bình đẳng của hệ thống.
Công cụ nghiên cứu này được phát hành dưới giấy phép tự do, cho phép tái sử dụng và làm lại kết quả, đồng thời hỗ trợ việc thực hiện các nghiên cứu mới.
Trong nghiên cứu của Koch (2000), ông đã phân tích các tương tác trong dự án PMTD, sử dụng nguồn thông tin từ danh sách thư và kho phiên bản của dự án GNOME Điểm nổi bật trong nghiên cứu này là phân tích kinh tế, cung cấp cái nhìn sâu sắc về các yếu tố kinh tế trong phát triển phần mềm nguồn mở.
Koch tập trung vào việc kiểm tra tính chính xác của các dự báo giá thành qua các phương pháp truyền thống như mô hình COCOMO, đồng thời chỉ ra những vấn đề khi áp dụng chúng Ông nhấn mạnh rằng các kết quả cần được xem xét một cách thận trọng, phù hợp với thực tế Koch kết luận rằng PMTD cần những mô hình và phương pháp nghiên cứu riêng, vì các kiến thức hiện có không phù hợp với tính tự nhiên của nó Tuy nhiên, có khả năng thu thập dữ liệu liên quan đến sự phát triển của PMTD một cách công khai, mang lại hy vọng cho việc đạt được các mục tiêu trong tương lai gần Phân tích của Koch được xem là phân tích định lượng đầu tiên, mặc dù thiếu một phương pháp rõ ràng và một số công cụ hiện đại để xác minh kết quả và nghiên cứu các dự án khác.
Vào năm 2000, Mockus cùng các cộng sự đã thực hiện nghiên cứu đầu tiên về các dự án PMTD, cung cấp mô tả chi tiết về quy trình phát triển và cấu trúc tổ chức, kèm theo bằng chứng định tính và định lượng từ trường hợp máy chủ Apache Họ đã phân tích các báo cáo thay đổi nhật ký và lỗi phần mềm để đo lường sự tham gia của lập trình viên, kích thước nhóm cốt lõi, tác giả mã nguồn, năng suất, mật độ lỗi và thời gian giải quyết vấn đề Nghiên cứu này được coi là một nghiên cứu kinh điển trong lĩnh vực kỹ thuật phần mềm, nhấn mạnh rằng dữ liệu thu thập được chủ yếu từ việc điều tra bán tự động các thông tin công khai trên mạng.
Nghiên cứu kỹ thuật phần mềm trong các dự án phát triển nguồn mở sử dụng dữ liệu công khai đã không cung cấp công cụ hoặc quy trình tự động nào có thể tái sử dụng cho các đội nghiên cứu khác trong tương lai.
Trong các nghiên cứu như “Đánh giá kích cỡ của Linux” và “Hơn là một gigabuck: đánh giá của GNU/Linux”, một phân tích định lượng về dòng mã lệnh và ngôn ngữ lập trình trong phát tán Red Hat đã được thực hiện González Barahona et al cũng đã tiến hành phân tích tương tự cho phát tán Debian, cho thấy sự phân bổ dòng mã lệnh theo từng ngôn ngữ lập trình Công cụ tính số dòng mã lệnh (SLOC) đã chỉ ra rằng kích thước gói trung bình trong 5 năm qua không thay đổi, mặc dù có sự gia tăng tự nhiên được trung lập hóa bởi các gói nhỏ hơn Ngôn ngữ lập trình C, mặc dù vẫn chiếm ưu thế, đang giảm dần, trong khi các ngôn ngữ script như Python, PHP, Perl và Java đang gia tăng Các ngôn ngữ biên dịch cổ điển như Pascal và Ada đang dần mất đi Ngoài ra, những nghiên cứu này cũng áp dụng mô hình đánh giá nỗ lực COCOMO từ thập kỷ 80 để đánh giá các nỗ lực và chi phí của dự án.
Mặc dù là những người tiên phong, hầu hết các nghiên cứu trong phần này gặp nhiều hạn chế trong việc phân tích các dự án Phương pháp được áp dụng cho các dự án này chủ yếu là sự kết hợp giữa thủ công và tự động hóa, có thể áp dụng cho các dự án PMTD khác Điều này dẫn đến việc nghiên cứu một dự án mới yêu cầu nỗ lực lớn hơn, vì phương pháp cần phải được áp dụng lại và các nhiệm vụ thủ công phải được thực hiện lại.
Gần đây, các nghiên cứu như "nghiên cứu sự tiến hóa của các dự án PMTD sử dụng dữ liệu công khai" và "Việc tự động hóa đo đếm của các dự án nguồn mở" đã nhấn mạnh tầm quan trọng của việc xây dựng một hạ tầng phân tích tích hợp nhiều công cụ để tự động hóa quy trình Có hai lý do chính cho điều này: thứ nhất, khi đầu tư thời gian và công sức vào việc phát triển một công cụ phân tích chung, việc áp dụng cho các dự án PMTD khác sẽ trở nên dễ dàng hơn; thứ hai, việc sử dụng nhiều công cụ phân tích từ các góc độ khác nhau có thể dẫn đến cái nhìn hạn chế về dự án Thông tin chi tiết về những sáng kiến này có thể được tìm thấy trên website về Kỹ thuật của PMTD.
Công việc tương lai
Lịch sử nghiên cứu kỹ thuật phần mềm trên PMTD vẫn đang ở những bước đầu tiên, với nhiều khía cạnh quan trọng cần được thẩm tra và phân tích chi tiết Chúng ta cần phát triển một mô hình giải thích sự hình thành của PMTD Trong tương lai gần, cần tập trung vào việc phân loại các dự án PMTD, xây dựng phương pháp dựa trên phân tích và sử dụng những hiểu biết để phát triển mô hình giúp hiểu rõ quá trình phát triển của PMTD, đồng thời hỗ trợ ra quyết định dựa trên kinh nghiệm.
Một khía cạnh quan trọng cần xem xét là tính đúng đắn của các phương pháp kỹ thuật kinh điển trong lĩnh vực PMTD, đặc biệt khi kỹ thuật phần mềm đang phát triển mạnh mẽ Các luật về sự tiến hóa của phần mềm do Hehman đề xuất từ những năm 1970, mặc dù đã được cập nhật trong những năm 80 và 90, dường như không còn phù hợp hoàn toàn với sự phát triển của một số dự án PMTD hiện nay Điều này đặt ra câu hỏi về việc áp dụng và điều chỉnh các luật này trong bối cảnh mới của PMNM.
Hiện nay, sự thiếu hụt trong việc phân loại các dự án PMTD là một vấn đề nghiêm trọng, khi các tiêu chí phân loại hiện tại quá rộng và không phản ánh được sự khác biệt của các dự án Điều này dẫn đến việc các dự án có tổ chức, kỹ thuật và đặc tính khác nhau bị xếp chung vào một nhóm Sự khác biệt giữa Linux, với cộng đồng lập trình viên đông đảo, và các dự án nhỏ hơn cho thấy sự cần thiết phải có một hệ thống phân loại chi tiết hơn Việc này không chỉ giúp tận dụng kinh nghiệm từ các dự án tương tự mà còn hỗ trợ trong việc dự đoán và quản lý rủi ro hiệu quả hơn.
Kỹ thuật PMTD cần được ràng buộc chặt chẽ với các xu thế hiện hành và phương pháp hỗ trợ, nhằm tạo ra một nền tảng nghiên cứu công bằng cho tất cả các dự án Phương pháp rõ ràng giúp phát hiện hiện trạng, tiến hóa và phân loại các dự án Các công cụ phân tích là cần thiết, cho phép xử lý hàng ngàn dự án với nỗ lực tối thiểu Mục tiêu của PMTD là nghiên cứu sâu từng dự án dựa trên một tập hợp tham số hạn chế, chỉ ra nơi thông tin có thể tìm thấy trên mạng Quản lý dự án trở thành một phần tách biệt trong phân tích tổng thể, giúp chẩn đoán tình trạng sức khỏe của dự án qua các chỉ số cần cải tiến.
Khi chúng ta đã có các phương pháp, phân loại và mô hình, cơ hội gia tăng từ sự mô phỏng sẽ trở nên chính xác hơn, tạo ra tác nhân tri thức lớn Việc coi điểm khởi đầu như một hệ thống phức tạp sẽ giúp xây dựng các mô hình năng động cho phần mềm Sự hiểu biết về các yếu tố khác biệt sẽ cải thiện mô hình thực tế của chúng ta Mặc dù có nhiều đề xuất cho sự mô phỏng PMTD, chúng vẫn còn đơn giản và thiếu hoàn chỉnh do sự thiếu hụt trong hiểu biết về các tương tác trong quá trình tạo ra PMTD Nếu chúng ta có thể xử lý thông tin dự án qua lịch sử của chúng, các tác nhân này sẽ là chìa khóa cho sự hiểu biết về sự tiến hóa trong tương lai Một trong những đề xuất tiến bộ nhất hiện nay có thể được tìm thấy tại http://wwwai.wuwien.ac.at/~koch/oss-book/.
Tóm lược
Kỹ thuật PMTD vẫn là một lĩnh vực non trẻ và chưa được khám phá, với những bước đầu nhờ vào nỗ lực của các phóng viên trong việc đề xuất mô hình phát triển hiệu quả hơn Hiện nay, sau nhiều năm nghiên cứu và phân tích các dự án tự do, một nỗ lực lớn đang được thực hiện để xây dựng một hạ tầng toàn cầu nhằm phân loại, phân tích và mô hình hóa các dự án trong một không gian thời gian hạn chế và tự động hóa Sự phân tích các dự án PMTD hiện tại đang tốn nhiều thời gian và công sức, mở ra giai đoạn mới trong kỹ thuật phần mềm, tập trung vào việc dự đoán sự tiến hóa của phần mềm và nhận diện các phức tạp tiềm tàng.
8 Các môi trường và công nghệ phát triển
Các công cụ mà chúng ta sử dụng ảnh hưởng mạnh mẽ đến thói quen suy nghĩ của chúng ta, từ đó tác động đến khả năng tư duy của chúng ta.
Edsger W Dijkstra, "Làm thế nào chúng ta nói lên được những sự thực mà có thể gây tổn thương?"
Trong quá khứ, các dự án PMTD đã phát triển những công cụ và hệ thống riêng để hỗ trợ quá trình phát triển Mỗi dự án có quy định và bộ công cụ riêng, nhưng vẫn tồn tại những thực tế, môi trường và công nghệ chung trong lĩnh vực PMTD Chương này sẽ khám phá những yếu tố phổ biến này và phân tích tác động của chúng đến quản lý và sự tiến hóa của các dự án.
Mô tả các môi trường, công cụ và hệ thống
Trước khi đi vào chi tiết về các công cụ cụ thể, chúng ta cần xác định những đặc tính chung và thuộc tính của chúng dựa trên nhiệm vụ thực hiện và cách tổ chức của các lập trình viên Thông thường, trong môi trường phát triển, các công cụ và máy tính ảo đích thường là miễn phí, mặc dù điều này không phải lúc nào cũng đúng.
Dự án GNU được phát triển nhằm thay thế Unix, đã phải hoạt động trong các hệ thống Unix sở hữu độc quyền cho đến khi Linux và FreeBSD ra đời Hiện nay, khi phần mềm mã nguồn mở (PMTD) trở thành một phần của mô hình kinh doanh, xu hướng cho thấy máy tính đích cũng có thể là hệ thống sở hữu độc quyền thông qua các máy ảo như Java, Python, PHP Do đó, môi trường và máy ảo cần phải đủ chung và tiết kiệm để cung cấp cho các lập trình viên những công cụ cần thiết.
Để thu hút đông đảo lập trình viên, các công cụ cần phải đơn giản, phổ biến và hoạt động hiệu quả trên các máy tính có cấu hình thấp Những yếu tố này có thể giải thích tại sao thế giới công nghệ ngày càng chú trọng đến sự dễ dàng và hiệu suất trong việc phát triển phần mềm.
PMTD khá là bảo thủ khi nói về các ngôn ngữ, công cụ và môi trường
Mô hình phát triển của PMTD hiện nay có xu hướng phân tán cao độ, với nhiều cộng tác viên tiềm năng trên toàn cầu Do đó, các công cụ cộng tác không đồng bộ trở nên cần thiết, giúp phát triển tiến bộ một cách dễ dàng, bất chấp số lượng và nhịp độ công việc của từng cộng tác viên Những công cụ này hỗ trợ biên dịch và kiểm thử các chương trình trong nhiều kiến trúc khác nhau.
Các ngôn ngữ và công cụ có liên quan
Hầu hết các phần mềm mã nguồn mở (PMTD) được phát triển bằng ngôn ngữ C, không chỉ vì C là ngôn ngữ tự nhiên của các biến thể Unix, mà còn do tính phổ biến và hiệu quả của nó GCC, trình biên dịch tiêu chuẩn, được cài đặt mặc định trên hầu hết các hệ điều hành, làm cho C trở thành lựa chọn hàng đầu cho các dự án GNU Các ngôn ngữ tương tự như C++ và Java cũng được sử dụng phổ biến, với Java cho phép phát triển trên nhiều nền tảng khác nhau Mặc dù Ada được coi là ngôn ngữ phù hợp hơn cho việc phát triển phần mềm chất lượng, nhưng tỷ lệ dự án viết bằng C vẫn chiếm ưu thế Đồng thời, tiếng Anh là ngôn ngữ chính trong cộng đồng lập trình viên, mặc dù Esperanto có cấu trúc dễ học hơn Các ngôn ngữ biên dịch như Perl, Python và PHP cũng được ưa chuộng trong việc phát triển ứng dụng và dịch vụ web.
Ngôn ngữ C là tiêu chuẩn chính, với công cụ make được sử dụng phổ biến để xây dựng chương trình, thường là phiên bản GNU (GNU make) Công cụ này cho phép lập trình viên chỉ định các cây phụ thuộc giữa các tệp và quy định cách tạo ra các tệp phụ thuộc Chẳng hạn, tệp đối tượng x.o phụ thuộc vào các tệp nguồn x.c và x.h, và để biên dịch, cần thực hiện lệnh gcc -c x.c Khi sử dụng make, chỉ những module bị ảnh hưởng sẽ được biên dịch lại, giúp tối ưu hóa quy trình phát triển Tuy nhiên, make là một công cụ ở mức thấp và không tự động xác định khi nào một module cần được biên dịch lại.
C có khả năng kiểm tra các chuỗi của includes và kết hợp các công cụ biến đổi tệp để xây dựng các mục tiêu phức tạp cho dự án đa ngôn ngữ, nhưng nó phụ thuộc nhiều vào môi trường Unix Các giải pháp thay thế như jam, aap và ant hiếm khi được sử dụng, mặc dù ant đang ngày càng phổ biến trong thế giới Java Để tạo ra các chương trình khả chuyển, các công cụ như GNU autoconf, automake và libtool giúp đơn giản hóa quy trình trong môi trường C và Unix Đối với sự đa dạng ngôn ngữ và văn hóa, lập trình viên C thường sử dụng gettext và các tùy chọn quốc tế hóa từ thư viện tiêu chuẩn của C để dễ dàng bản địa hóa ứng dụng cho mọi môi trường văn hóa.
Khi nhận một gói nguồn thường được viết bằng C, gói này thường được nén bằng gzip và đóng gói bằng tar, có khả năng tương thích với autoconf cùng các công cụ liên kết Quá trình cài đặt gói sẽ diễn ra tương tự như sau: giải nén gói bằng lệnh tar xzvf package-1.3.5.tar.gz và sau đó chuyển vào thư mục package-1.3.5.
Các môi trường phát triển tích hợp
Một môi trường phát triển tích hợp (IDE) là hệ thống giúp lập trình viên phần mềm dễ dàng hơn bằng cách tích hợp các chức năng như xuất bản ngôn ngữ, trình biên dịch, dò tìm và sửa lỗi, đo lường hiệu suất, và quản lý mã nguồn Các tính năng này thường được tổ chức theo dạng module, tạo ra một quy trình làm việc hiệu quả và thuận tiện cho người dùng.
Không phải tất cả lập trình viên PMTD đều yêu thích các công cụ này, mặc dù việc sử dụng chúng ngày càng gia tăng Trong lĩnh vực PMTD, GNU Emacs là môi trường đầu tiên được sử dụng một cách tích cực, đây là sản phẩm nổi bật của Richard Stallman, được phát triển và mở rộng bằng Emacs Lisp với nhiều đóng góp từ cộng đồng.
Eclipse được xem là IDE tham chiếu trong lĩnh vực phát triển phần mềm, mặc dù nó hoạt động hiệu quả hơn trên máy ảo Java không tự do của Sun Các môi trường phát triển khác bao gồm Kdevelop cho KDE, Anjuta cho GNOME, Netbeans của Sun cho Java và Code::Blocks cho ứng dụng C++.
Các cơ chế cộng tác cơ bản
PMTD là một hiện tượng được hình thành nhờ sự hợp tác của các cộng đồng phân tán, yêu cầu các công cụ hiệu quả để tối ưu hóa sự cộng tác Mặc dù việc gửi băng từ vật lý đã tồn tại từ lâu, sự phát triển của PMTD thực sự bùng nổ khi khả năng giao tiếp nhanh chóng với nhiều người trở nên khả thi, cho phép phân phối mã chương trình và phản hồi bình luận hoặc bản vá Thay vì gửi mã nguồn trực tiếp, thông điệp có thể được sử dụng để cung cấp thông tin về trang web nơi mã nguồn có thể được truy cập Thực tế, ngay từ đầu những năm 70, thư điện tử đã trở thành một phần mở rộng của giao thức truyền tệp trên ARPANET.
Trong những năm 70, giao thức truyền tệp uucp của Unix đã được phát triển để hỗ trợ giao tiếp giữa các máy tính qua dial-up và đường dây chuyên dụng, từ đó hình thành nền tảng cho thư điện tử Năm 1979, USENET được kết nối lần đầu tiên qua UUCP, tạo ra một hệ thống diễn đàn phân tán theo cấu trúc thứ bậc USENET đã đóng vai trò quan trọng trong sự phát triển của phần mềm mã nguồn mở, cho phép gửi mã nguồn chương trình tới các nhóm comp.sources.
Vào năm 1981, danh sách thư BITNET đã được phát triển, đánh dấu sự khởi đầu quan trọng cho các nhà quản lý trong lĩnh vực này Hiện nay, xu hướng sử dụng danh sách thư đã chuyển sang các nhóm tin, phản ánh sự thay đổi trong cách thức giao tiếp và chia sẻ thông tin.
USENET đã từng gặp phải vấn đề lạm dụng cho mục đích thương mại và sự thâm nhập trái phép từ những người thiếu suy nghĩ, gây rối loạn trong các cuộc thảo luận Trong khi đó, danh sách thư cung cấp một giải pháp kiểm soát tốt hơn và khả năng tiếp cận rộng rãi hơn Người nhận cần đăng ký và bất kỳ địa chỉ email nào cũng đều hợp lệ, ngay cả khi không có truy cập trực tiếp vào Internet Người quản trị danh sách thư có quyền theo dõi ai đã đăng ký hoặc hủy đăng ký.
Các đóng góp có thể bị giới hạn chỉ dành cho những thành viên hoặc lập trình viên, những người có khả năng điều chỉnh các bài viết trước khi chúng được công bố.
Theo truyền thống, quản trị danh sách thư thường được thực hiện qua thư điện tử với các thông điệp đặc biệt và mật khẩu, nhưng hiện nay việc này ngày càng hiếm Các công cụ quản lý danh sách thư phổ biến như Mailman và GNU Mailing List Manager không còn được quản lý qua thư điện tử mà cần phải thông qua web Danh sách thư đóng vai trò quan trọng trong lĩnh vực PMTD và trong nhiều trường hợp, chúng là phương tiện duy nhất để đóng góp.
Hiện nay, với sự phát triển của internet, nhiều nhóm thảo luận đã chuyển sang hình thức thuần túy trên web, hay còn gọi là weblogs, mà chỉ có giao diện do trình duyệt cung cấp Những nhóm này có thể là chung, như Slashdot (tin tức dành cho người đam mê công nghệ) hoặc Barrapunto của Tây Ban Nha, nơi thảo luận về các phần mềm và công nghệ mới Ngoài ra, cũng có những nhóm thảo luận chuyên biệt về một chủ đề cụ thể, thường được tích hợp với các công cụ bổ sung trong các trang web cộng tác Bên cạnh đó, còn tồn tại các giao diện web cho nhóm tin và danh sách truyền thống.
Một cơ chế cộng tác phổ biến hiện nay là sử dụng wikis để xây dựng tài liệu chung, chẳng hạn như đặc tả kỹ thuật cho chương trình, module hoặc hệ thống Chúng ta sẽ thảo luận chi tiết về chủ đề này trong phần 8.6.2.
Cuối cùng, cần nhấn mạnh các cơ chế tương tác mà lập trình viên sử dụng để giao tiếp trong thời gian thực Đối với PMTD, việc tìm ra thời gian phù hợp cho tất cả lập trình viên trên toàn cầu là một thách thức Tuy nhiên, một số dự án vẫn áp dụng các công cụ chat văn bản, thường là trong các hội nghị ảo đã được lên lịch IRC (Internet Relay Chat) là công cụ phổ biến nhất, kết nối người dùng qua các "kênh" theo chủ đề dựa trên nhiều máy chủ cộng tác Việc sử dụng các công cụ đa phương tiện như âm thanh và hình ảnh không phổ biến do yêu cầu về kết nối chất lượng, điều này có thể gây khó khăn cho tính sẵn sàng của PMTD và cho việc ghi chép, soạn thảo kết quả hội thoại.
6 Cũng có những nhóm tin có điều tiết
7 Ví dụ, những đóng góp cho Linux phải được thực hiện như các bản vá bằng văn bản cho danh sách linuxkernel@vger.kernel.org
Quản lý mã nguồn
Hệ thống Phiên bản Đồng thời
Hệ thống phiên bản đồng thời CVS (Concurrent Version System) là một công cụ quản lý nguồn mở được phát triển vào cuối những năm 80, phổ biến trong các dự án mã nguồn tự do CVS sử dụng kho trung tâm với cơ chế truy cập qua máy khách/máy chủ, cho phép người quản trị quyết định quyền truy cập của từng lập trình viên Khi đã được chấp nhận, lập trình viên có thể truy cập tất cả các tệp trong kho Ngoài ra, hệ thống cũng hỗ trợ truy cập nặc danh theo phương thức chỉ đọc cho bất kỳ ai.
Người cộng tác nặc danh
CVS nặc danh là công cụ thiết yếu để thực hiện khái niệm "phiên bản sớm và thường xuyên" theo Eric Raymond Người dùng có thể dễ dàng truy cập phiên bản mới nhất của chương trình từ CVS, phát hiện lỗi và gửi báo cáo, bao gồm cả các miếng vá sửa lỗi Ngoài ra, CVS còn cho phép kiểm tra lịch sử phát triển toàn diện của phần mềm.
Một người dùng cao cấp muốn truy cập phiên bản mới nhất của module mod từ kho nặc danh trên progs.org, thư mục /var/lib/cvs, bằng giao thức pserver Để thực hiện điều này, anh ta nhập lệnh: cvs -d:pserver:anonymous@progs.org:/var/lib/cvs login.
Nếu mật khẩu được yêu cầu, người dùng sẽ đăng nhập với tư cách nặc danh và thông tin này sẽ được lưu trữ trong một tệp cục bộ, mặc dù điều này không thực sự cần thiết cho việc truy cập nặc danh Tuy nhiên, chương trình sẽ thông báo nếu tệp mật khẩu không tồn tại Để lấy bản sao đầu tiên của module, bạn cần sử dụng lệnh: cvs -d:pserver:anonymous@progs.org:/var/lib/cvs co mod Lệnh này sẽ tạo ra một thư mục mod chứa tất cả các tệp và thư mục con của module cùng với một số siêu dữ liệu, cho phép bạn truy cập thông tin mà không cần lặp lại.
Người sử dụng cao cấp của chúng ta vào trong thư mục được tạo ra, tạo gói và kiểm thử nó: cd mod
Khi cần có phiên bản mới, anh ta chỉ cần cập nhật bản sao của mình trong mod bằng cách sử dụng lệnh "cd mod cvs update".
Nếu phát hiện lỗi, anh ta có thể sửa ngay lập tức và gửi bản vá qua email cho người duy trì chương trình bằng lệnh: cvs diff -ubB | mail -s "My patches" mod-maint@progs.org.
Lập trình viên bình thường
Lập trình viên thông thường sở hữu một tài khoản trên máy chủ, cho phép họ sử dụng cơ chế và giao thức tương tự như người dùng nặc danh, chỉ khác ở chỗ họ có thể thay thế sự nặc danh bằng tên tài khoản của mình.
Khi có một bản sao làm việc của module, người dùng có thể thực hiện các thay đổi cần thiết Sau khi xác nhận rằng những thay đổi này đã ổn định, họ có thể ủy thác chúng vào kho lưu trữ Chẳng hạn, nếu người dùng sửa đổi các tệp part.h và part.c, họ sẽ thực hiện ủy thác bằng lệnh: cvs ci part.h part.c.
Trước khi hoàn tất hoạt động, CVS sẽ yêu cầu người dùng giải thích về các hành động đã thực hiện, và thông tin này sẽ được ghi lại trong các tệp log Đồng thời, số phiên bản của mỗi tệp sẽ được tăng lên một đơn vị, giúp xác định các thời điểm quan trọng trong lịch sử của tệp và cho phép phục hồi từng thời điểm đó khi cần thiết.
Một lập trình viên cần tiến hành ủy thác khi có sự đồng thuận giữa các thành viên trong dự án Thông thường, những thay đổi không qua biên dịch sẽ không được ủy thác, nhưng cũng cần ưu tiên thực hiện một đoạn kiểm thử tối thiểu Trong nhiều dự án, sự phê chuẩn từ một giám sát dự án hoặc dự án phụ là điều cần thiết để kiểm tra các sửa đổi.
Trong quá trình phát triển và sửa đổi, lập trình viên nên thường xuyên cập nhật bản sao của họ (cvs cập nhật) để đảm bảo rằng các tệp không bị lỗi do sửa đổi từ những người khác Nếu có sự thay đổi ở các tệp khác, môi trường làm việc có thể đã thay đổi, dẫn đến việc các kiểm thử trước đó có thể không còn hiệu lực Nếu các tệp của chúng ta cũng bị sửa đổi, có thể xảy ra xung đột, và trong trường hợp này, cần thảo luận với lập trình viên đã thực hiện các thay đổi khác để thống nhất một phiên bản cuối cùng Để nhận diện tốt hơn các thành phần của dự án, việc mang theo thông tin sửa đổi liên quan là rất quan trọng CVS có thể tự động gán nhãn cho mã nguồn và các đối tượng nếu tuân thủ các nguyên tắc nhất định, như việc sử dụng từ khóa $Id$ trong chú giải mã nguồn, cho phép cập nhật thông tin về tên tệp, số sửa đổi, ngày tháng, thời gian ủy thác và tác giả.
8 Trong CVS các số sửa lại thường có 2 thành phần (chính và phụ), nhưng chúng có thể có 4, 6,
Khi từ khóa được đưa vào chuỗi chương trình, nó sẽ xuất hiện trong đối tượng và khu vực thực thi sau khi biên dịch, cho phép xác định nó bằng một công cụ (ident).
Vì lý do an ninh, các tài khoản có quyền ghi và SSH thường được ưa chuộng, vì chúng cung cấp một kênh giao tiếp được xác thực và mã hóa.
Người quản trị chịu trách nhiệm chính trong việc duy trì kho, bao gồm việc đăng ký chương trình, cấp quyền cho lập trình viên, điều phối công việc và gắn nhãn cho các phiên bản.
Trong mọi dự án, cần có một phiên bản ổn định và một phiên bản thực nghiệm, được tạo ra thông qua các nhánh Nhánh ổn định tập trung vào việc sửa lỗi, trong khi nhánh thực nghiệm phát triển các tính năng mới Khi nhánh thực nghiệm đạt được sự ổn định, nó sẽ được tích hợp vào nhánh ổn định, nhưng phải đảm bảo các sửa đổi cần thiết đã được áp dụng Quá trình này gọi là việc trộn, được hỗ trợ bởi CVS, mặc dù ở mức độ cơ bản Ý tưởng này cũng có thể được mở rộng cho các nhánh thực nghiệm tiến hóa theo nhiều hướng khác nhau, và bất kể kết quả, chúng sẽ cần được tích hợp vào sản phẩm ổn định với sự trộn hợp lý.
Các hệ thống quản lý nguồn khác
Bất chấp là hệ thống kiểm soát phiên bản được sử dụng rộng rãi nhất, CVS có một số nhược điểm đáng chú ý:
1 CVS không hỗ trợ việc đổi tên hoặc thay đổi thư mục các tệp, hoặc siêu dữ liệu (người chủ, các quyền, …) hoặc các kết nối tượng trưng.
2 Vì nó là một tiến hóa của một hệ thống kiểm soát phiên bản cho các tệp riêng rẽ, về mặt tự nhiên nó không hỗ trợ kiểm soát phiên bản cho các nhóm đầy đủ.
3 CVS không hỗ trợ các tập hợp những thay đổi cố kết Quả thực, việc bổ sung thêm một tính năng hoặc việc sửa cho đúng một lỗi có thể liên quan tới việc thay đổi một số tệp Những thay đổi này phải là nguyên tử.
4 Trong CVS việc sử dụng các nhánh và trộn khá phức tạp Trên thực tế, nếu chúng ta tạo ra một nhánh thực nghiệm của một dự án và muốn đưa vào những sửa đổi cho đúng được thực hiện cho phiên bản ổn định, thì chúng ta cần biết chi tiết các sửa đổi nào đã được thực hiện rồi và cái nào chưa, sao cho không thực hiện chúng vài lần.
5 CVS phụ thuộc vào một máy chủ trung tâm, và dù nó là có khả năng để làm việc mà không có một kết nối, thì chúng ta phải cần một kết nối cho việc tạo ra những phiên bản, việc so sánh và trộn chúng.
6 CVS không tạo, mà không trợ giúp các công cụ một cách riêng rẽ, tệp changelog , mà nó chỉ ra lịch sử toàn cầu về những thay đổi của một dự án.
7 CVS không hỗ trợ tốt các dự án với một số lượng lớn các tệp, như trong trường hợp của nhân Linux
Có những hệ thống quản lý phiên bản tự do khác như Subversion, kế thừa từ CVS, mà giải quyết triệt để các vấn đề cơ bản của CVS Subversion hỗ trợ mở rộng HTTP (WebDAV), giúp người dùng vượt qua các chính sách an ninh và hạn chế.
Mô hình phát triển dựa trên kho trung tâm, mặc dù hỗ trợ công việc cộng tác, không đáp ứng đầy đủ mọi yêu cầu, do khả năng tạo ra các nhánh phát triển riêng Sự truy cập vào máy chủ và việc quản lý hiệu quả là yếu tố quan trọng Đôi khi, kho phân tán được yêu cầu để tạo ra nhánh riêng tư hoặc công cộng, có thể kết hợp hoặc không với nhánh chính Điều này lý giải cho việc GNU arch, bazaar và BitKeeper được Linus Torvalds chọn để duy trì Linux từ tháng 02/2002, khi không có công cụ tự do nào phù hợp Sử dụng BitKeeper đã thúc đẩy nhanh chóng sự phát triển của Linux, mặc dù bị chỉ trích vì tính sở hữu độc quyền Giấy phép của BitKeeper cho phép các dự án tự do sử dụng miễn phí, với điều kiện thay đổi được ghi lại trên máy chủ công cộng Linus đã phát triển một sản phẩm tự do thay thế, git, vào tháng 04/2005, hỗ trợ phát triển phi tập trung và cho phép quản lý nhánh một cách an toàn và hiệu quả.
Tài liệu
DocBook
Vấn đề xuất phát từ việc thiếu sự phân biệt giữa nội dung và hình thức trình bày trong cả TeX và nroff, khi mà trừu tượng được xây dựng trong các lớp Sự phân biệt này thường được thực hiện bởi các ứng dụng.
SGML (ngôn ngữ đánh dấu tổng quát theo chuẩn) và XML (ngôn ngữ đánh dấu mở rộng) cho phép trình bày nội dung bằng các bảng kiểu riêng biệt Mặc dù SGML đã được ứng dụng đơn giản trong một số dự án như linuxdoc và debiandoc, nhưng do khả năng diễn tả hạn chế, DocBook đã trở thành lựa chọn phổ biến hơn cho việc tổ chức tài liệu.
DocBook là một ứng dụng SGML được phát triển ban đầu cho tài liệu kỹ thuật trong lĩnh vực công nghệ thông tin, hiện nay đã có phiên bản XML Hiện tại, DocBook là tiêu chuẩn định dạng tài liệu tự do cho nhiều dự án như Linux Documentation Project, KDE, GNOME và Mandriva Linux, đồng thời cũng là mục tiêu hướng tới của nhiều dự án khác như Linux, *BSD và Debian.
DocBook là một ngôn ngữ phức tạp với nhiều thẻ, do đó, việc sử dụng các công cụ hỗ trợ soạn thảo là rất cần thiết, mặc dù chúng thường khá cơ bản và hiếm Một trong những công cụ phổ biến nhất là phương thức psgml của Emacs Tuy nhiên, quy trình và các trình xử lý tự do vẫn có thể tạo ra tài liệu chất lượng cao và hấp dẫn.
Wikis
Nhiều người cảm thấy khó khăn khi viết tài liệu bằng các ngôn ngữ phức tạp như DocBook và sử dụng các cơ chế cộng tác như CVS Điều này dẫn đến sự phổ biến của một cơ chế mới cho việc chuẩn bị tài liệu trực tuyến qua web, được gọi là wiki, do Ward sáng tạo.
Cunningham đã giới thiệu các nguyên lý thiết kế Wiki vào năm 1995, và hiện nay chúng được áp dụng rộng rãi trong nhiều biến thể để tạo ra các tài liệu năng động Những tài liệu này thường không được thiết kế cho in ấn và có vòng đời ngắn, như trong trường hợp tổ chức hội nghị.
Khác với DocBook, wiki sử dụng ngôn ngữ đơn giản và cú pháp dễ hiểu, cho phép người dùng tập trung vào nội dung mà không cần lo lắng về định dạng phức tạp Các đoạn văn được phân tách bằng một dòng trống, danh sách không được đánh số bắt đầu bằng dấu gạch nối, trong khi danh sách có số thứ tự bắt đầu bằng số 0 Bảng được tạo ra bằng cách sử dụng các đường thẳng đứng và nằm ngang để phân chia các ô, giúp trình bày thông tin một cách rõ ràng và dễ dàng.
Một wiki không có khái niệm về "tài liệu đầy đủ", mà là một tập hợp các tài liệu nhỏ được liên kết với nhau để giải thích các khái niệm hoặc chủ đề mới khi cần thiết Những tài liệu này thường được tạo ra một cách tự động, với công cụ soạn thảo yêu cầu người dùng nhập một khái niệm thông qua tên WikiName, thường là hai từ liên kết với nhau và ký tự đầu được viết hoa Hầu hết các wiki không cho phép tạo siêu liên kết bên trong cùng một trang.
Khác với CVS, bất kỳ ai cũng có thể viết trong một wiki, mặc dù việc đăng ký trước được khuyến khích để xác định bản thân Khi truy cập vào một wiki, người dùng sẽ thấy các trang có nút cho phép chỉnh sửa Nhấn vào nút này sẽ hiển thị một mẫu với mã nguồn của tài liệu, cho phép người dùng thay đổi nội dung Đây là một trình soạn thảo WYSIWYG, không khuyến khích những người chỉ muốn can thiệp, nhưng lại đủ đơn giản để bất kỳ ai quan tâm có thể dễ dàng sửa đổi tài liệu.
Wikis sở hữu hệ thống kiểm soát phiên bản tài liệu độc đáo, cho phép truy cập tất cả các phiên bản, đồng thời ghi lại thông tin về người tạo và thời gian tạo Chúng cũng hỗ trợ so sánh các phiên bản một cách dễ dàng Hơn nữa, wikis thường tích hợp cơ chế tìm kiếm, tối thiểu cho mỗi tên trang và nội dung từ, giúp người dùng dễ dàng tìm kiếm thông tin.
Tác giả ban đầu của một trang thường muốn theo dõi các thay đổi được thực hiện và có thể đăng ký nhận thông báo qua email Trong trường hợp người xem không muốn thay đổi nội dung, họ có thể để lại bình luận Các trang wiki thường có phần thảo luận ở cuối tài liệu, nơi tác giả hoặc biên tập viên có thể sử dụng để phục hồi văn bản gốc bằng cách chuyển các mệnh đề từ bình luận vào vị trí thích hợp.
Cách hiệu quả nhất để nắm bắt khái niệm wiki là truy cập vào một wiki và trải nghiệm trực tiếp trên một trang được thiết kế cho mục đích này, thường được gọi là Hộp Cát (SandBox).
Quản lý lỗi và các vấn đề khác
Một trong những ưu điểm của mô hình phát triển tự do là sự tham gia tích cực của cộng đồng trong việc báo cáo lỗi, giúp các lập trình viên nhận được thông tin đầy đủ và có hệ thống Để đạt được điều này, cần có một cơ chế báo cáo lỗi đơn giản, cho phép người dùng cung cấp chi tiết về vấn đề, mức độ quan trọng và giải pháp khả thi Hơn nữa, việc tự động xác định phiên bản và môi trường hoạt động của chương trình cũng rất cần thiết Các lỗi cần được lưu trữ trong một cơ sở dữ liệu có thể tra cứu, giúp theo dõi tình trạng của lỗi, xem liệu chúng đã được thông báo và sửa chữa hay chưa, cùng với mức độ nghiêm trọng của từng lỗi.
Có nhiều hệ thống khác nhau với triết lý riêng, bao gồm các phương thức tiếp cận qua web, thư điện tử và các chương trình trung gian Tất cả đều cung cấp giao diện web cho tư vấn, một số cho phép báo cáo nặc danh, trong khi số khác yêu cầu xác thực bằng địa chỉ email để tránh nhiễu thông tin Mặc dù thủ tục qua web có vẻ đơn giản, việc tự động thu thập thông tin trong môi trường lỗi không hề dễ dàng Ví dụ, hệ thống của Debian sử dụng chương trình reportbug, yêu cầu người dùng cung cấp tên gói cần báo cáo và sẽ tra cứu lỗi trên máy chủ Nếu không có ai đề cập đến vấn đề, người dùng sẽ được yêu cầu mô tả chi tiết và đánh giá mức độ nghiêm trọng của lỗi.
Thông thường, các nhãn như "không quan trọng" hoặc "gợi ý" được sử dụng để phân loại Khi yêu cầu được xác nhận, hệ thống sẽ tự động xác định phiên bản gói và các phụ thuộc của nó, bao gồm cả phiên bản và kiến trúc của nhân Hệ thống cũng biết địa chỉ email, do đó, nó gửi một báo cáo tương tự đến đúng trang web.
After reloading a page containing complex tables several dozen times, w3m had used all physical memory and thrashing commenced This is an Alpha machine.
The kernel version of the system is Linux romana 2.2.19, released on June 1, 2001 The package w3m-ssl relies on several essential libraries, including libc6.1 (GNU C Library), libgc5 (Conservative garbage collector for C), libgpmg1 (General Purpose Mouse Library), libncurses5 (libraries for terminal handling), and libssl0.9.6 (SSL shared libraries) Additionally, it depends on w3m, a browsable pager that supports tables and frames, with the version being 0.2.1-2.
Thông điệp lỗi được tạo ra sẽ có một số duy nhất, gửi đến người quản lý và được lưu trữ trong cơ sở dữ liệu Khi lỗi được khắc phục, chúng ta sẽ nhận được thông báo Mỗi lỗi đều có một địa chỉ email để cung cấp thông tin bổ sung Chúng ta có thể tra cứu lỗi tại http://bugs.debian.org bất cứ lúc nào Hệ thống giám sát lỗi có thể chỉ định người giải quyết và thiết lập thời hạn Ngoài ra, còn có các vấn đề khác như công việc treo, cải tiến theo yêu cầu và bản dịch.
Quản lý các nhiệm vụ trong PMTD đòi hỏi cơ chế linh hoạt, không thể áp dụng các quy tắc cứng nhắc cho từng lập trình viên, đặc biệt khi nhiều cộng tác viên là tình nguyện viên Các nhiệm vụ có thể được xác định và người dùng có thể đăng ký nhận chúng trong khoảng thời gian nhất định Cần có sự kiểm soát đối với những nhiệm vụ mà mỗi cá nhân có thể thực hiện, bao gồm việc xác định ai làm gì, mức độ quan trọng của nhiệm vụ và ai đang tham gia Nhiều dự án quan trọng sử dụng Bugzilla hoặc các hệ thống tương tự để quản lý các khía cạnh này Đôi khi, một người làm việc trong dự án có thể phát hiện lỗi trong dự án khác, nhưng lại sử dụng hệ thống quản lý lỗi khác Điều này thường xảy ra với những người sử dụng các bản phát tán, khi họ muốn một công cụ duy nhất để báo cáo và theo dõi lỗi Để thuận tiện hơn trong việc báo cáo và giám sát lỗi, nên tổ chức lại thành liên đoàn các hệ thống khác nhau, như đã được thực hiện bởi Malone.
Hỗ trợ cho các kiến trúc khác
Để làm việc với một chương trình khả chuyển, yêu cầu tối thiểu là có quyền truy cập vào các trại biên dịch, giúp chương trình được biên dịch trên nhiều kiến trúc và hệ điều hành khác nhau Chẳng hạn, SourceForge đã cung cấp các môi trường Debian GNU/Linux cho các kiến trúc như Intel x86, DEC Alpha, PowerPC và SPARC, cùng với các môi trường Solaris và Mac OS/X.
Dịch vụ kiểm thử chương trình không chỉ yêu cầu biên dịch mà còn tiêu tốn nhiều tài nguyên và thời gian của người quản trị Việc cung cấp môi trường biên dịch cho nhiều ngôn ngữ và thư viện lớn là cần thiết, nhưng kiểm thử chương trình lại gặp nhiều khó khăn do yêu cầu về tài nguyên và vấn đề an ninh, làm cho việc quản trị hệ thống trở nên phức tạp Tuy nhiên, vẫn tồn tại một số dịch vụ biên dịch với cài đặt chuẩn cho nhiều kiến trúc, cho phép kiểm thử hiệu quả.
Các trại công khai là dịch vụ yêu cầu lập trình viên sao chép và biên dịch tệp của họ trên máy tính để kiểm thử kết quả Quá trình này có thể lặp đi lặp lại nhiều lần trước khi phát hành phiên bản quan trọng của chương trình Một phương pháp thú vị hơn là thực hiện biên dịch và kiểm thử tự động theo lịch trình, như mỗi đêm nếu có thay đổi mã nguồn Một số dự án lớn sử dụng hạ tầng riêng gọi là "tinderbox" để hỗ trợ lập trình viên bên ngoài, ví dụ như Mozilla, được tài trợ bởi Netscape Giao diện web của nhóm bùi nhùi cung cấp kết quả và theo dõi tình trạng khác nhau, xác định trách nhiệm về lỗi và tạo điều kiện cho sự tiến bộ Các dự án như OpenOffice và FreeBSD cũng áp dụng mô hình này.
Các site hỗ trợ phát triển
SourceForge
Một trong những dịch vụ nổi tiếng nhất trong lĩnh vực này là SourceForge (http://sourceforge.net), được quản lý bởi OSDN (Mạng Phát triển Phần mềm Mở), một bộ phận của VA Software Tính đến tháng 03/2007, SourceForge đã chứa hơn 144,000 dự án và được cấu trúc xung quanh một tập hợp các chương trình cùng tên, với các phiên bản lên tới 2 là PMTD.
SourceForge là một nền tảng cung cấp giao diện web toàn cầu và cổng truy cập cho từng dự án, cho phép người dùng theo dõi các tin tức, quảng cáo và tham gia vào các dự án Để cộng tác trên nền tảng này, người dùng cần trở thành thành viên, điều này là cần thiết nếu muốn tạo hoặc tham gia vào dự án Người dùng không cần phải là thành viên để xem các dự án đang phát triển tích cực hoặc được tải xuống nhiều nhất, và có thể tìm kiếm theo loại hoặc từ khóa Mỗi dự án có mô tả chi tiết, tình trạng phát triển (alpha, beta, sản phẩm), thông tin về ngôn ngữ lập trình, hệ điều hành, chủ đề và giấy phép, cùng với các lỗi và tình trạng hoạt động theo thời gian.
Chúng ta có thể tham gia vào các nhóm thảo luận hoặc báo cáo lỗi một cách nặc danh, tuy nhiên điều này không được khuyến khích vì có thể không nhận được câu trả lời.
Người dùng được xác thực có thể yêu cầu đăng ký dự án trên SourceForge, với điều kiện tuân thủ chính sách của site Sau khi được xác thực, người tạo có quyền thêm quản trị viên và lập trình viên khác để sửa mã nguồn Sau bước xác thực, dự án sẽ không chịu nhiều kiểm soát, dẫn đến tình trạng nhiều dự án không hoạt động Tuy nhiên, người dùng không gặp khó khăn trong việc tìm kiếm dự án, vì các dự án sẽ được phân loại theo mức độ hoạt động, hạn chế khả năng xuất hiện của những dự án ít hoạt động hoặc không hoạt động SourceForge cung cấp nhiều dịch vụ cho dự án, tương tự như các dịch vụ khác trên thị trường.
Hosting cho các trang web dự án tại địa chỉ project.sourceforge.net cho phép công chúng truy cập Các trang này có thể là tĩnh hoặc động, sử dụng CGI hoặc PHP, và có thể kết nối với cơ sở dữ liệu MySQL Nội dung được đưa lên thông qua các lệnh sao chép từ xa và có thể được quản lý qua phiên tương tác đầu cuối từ xa (SSH).
Một máy chủ ảo có khả năng phản hồi cho các địa chỉ từ miền một cách tách biệt, chẳng hạn như www.project.org hoặc cvs.project.org, mà không cần phải tuân theo quy tắc bắt buộc nào.
• Nhiều bao nhiêu nhóm thảo luận bằng web và/hoặc danh sách thư là tùy ý theo ý kiến của người quản trị.
• Một dịch vụ tin nơi mà những người quản trị công bố những tiến bộ có liên quan tới dự án
Những người giám sát chịu trách nhiệm báo cáo và giám sát lỗi, yêu cầu hỗ trợ, cũng như cải tiến và tích hợp các bản vá Họ phân loại từng vấn đề theo mức độ ưu tiên và chỉ định lập trình viên để tìm ra giải pháp hiệu quả.
Những người quản lý nhiệm vụ, giống như giám sát viên, đóng vai trò quan trọng trong việc xác định các dự án phụ thông qua một loạt nhiệm vụ cụ thể Mỗi nhiệm vụ được gán một mức ưu tiên và thời hạn chót rõ ràng Theo thời gian, các lập trình viên được giao nhiệm vụ có thể cập nhật phần trăm hoàn thành, giúp theo dõi tiến độ hiệu quả.
• Một CVS hoặc Subversion (phiên bản phụ) với các quyền truy cập ban đầu cho tất cả các lập trình viên.
Dịch vụ tải lên và tải về phần mềm cho phép người dùng đăng ký các phiên bản mới khi có sự thay đổi, giúp họ nhận thông báo kịp thời Việc tải lên ban đầu cũng liên quan đến việc tạo ra nhiều bản sao trên toàn cầu, từ đó hỗ trợ cho quá trình phân phối hiệu quả.
Dịch vụ xuất bản tài liệu định dạng HTML cho phép bất kỳ ai đăng ký, nhưng nội dung chỉ hiển thị sau khi được quản trị viên phê duyệt.
Bản sao sao lưu đóng vai trò quan trọng trong việc phục hồi thảm họa, giúp khôi phục dữ liệu khi ổ đĩa bị hỏng mà không phải do lỗi của người sử dụng, hoặc khi tệp tin bị xóa một cách ngẫu nhiên.
• Cơ chế tích hợp cho những hiến tặng của những người sử dụng, cho các dự án và cho SourceForge.
Người dùng được xác thực sẽ sở hữu một trang cá nhân chứa tất cả thông tin liên quan đến các dự án, mẫu themes, nhiệm vụ đang treo, nhóm thảo luận và các tệp mà họ muốn giám sát Hơn nữa, để tiết kiệm thời gian, người dùng sẽ nhận được thông báo qua email về những nội dung mà họ quan tâm mà không cần phải thường xuyên kiểm tra trang cá nhân.
Những người kế thừa của SourceForge
Vào năm 2001, VA Software gần như phá sản do khủng hoảng dotcom, sau đó đã phát hành phiên bản mới của phần mềm SourceForge với giấy phép không tự do để cứu doanh thu bằng cách bán cho các công ty Họ cũng hạn chế khả năng chuyển dự án sang trang khác, gây lo ngại rằng hàng ngàn dự án trên SourceForge có thể rơi vào tay một công ty duy nhất và bị sử dụng cho phần mềm không tự do Trước tình hình này, các phiên bản tự do mới đã được phát triển và các cổng như Savannah và BerliOS ra đời, phục vụ cho các dự án GNU và các chương trình với giấy phép copyleft Đây là bước đầu trong việc phát triển một nền tảng phân tán, nơi không ai có quyền kiểm soát tuyệt đối đối với các dự án.
Một ví dụ điển hình về hệ thống quản lý dự án PMTD là Launchpad (https://launchpad.net), được Ubuntu sử dụng để phát triển các phiên bản phát tán Launchpad không phải là kho mã nguồn, mà là công cụ hỗ trợ giám sát mã nguồn, theo dõi các sự kiện và quản lý bản dịch Hệ thống này sử dụng công cụ Malone, cho phép định hướng các sự kiện tới các kho mã nguồn của các module liên quan.
Các site và chương trình khác
Các hệ thống cộng tác đã và đang phát triển một cách tự nhiên, với nhiều công ty xây dựng mô hình kinh doanh dựa trên việc cung cấp dịch vụ cho các trang web này Chẳng hạn, dự án Tigris (Tigris.org) không chỉ duy trì các dự án kỹ thuật PMTD mà còn sử dụng cổng cộng tác SourceCast do CollabNet quản lý, đồng thời duy trì các trang riêng cho các dự án như OpenOffice.org Ngoài ra, các trang web mới như GForce (gforge.org) cũng đang được áp dụng cho các PMTD mới, ví dụ như dự án Debian Để có cái nhìn sâu hơn, có thể tham khảo “So sánh các site hosting tự do/nguồn mở (FOSPhost)” để so sánh nhiều trang hosting cho các dự án.
9 Các trường hợp điển hình
GNU, viết tắt của "GNU's Not Unix", là tên gọi của hệ thống phần mềm hoàn toàn tương thích với Unix mà tôi đang phát triển để có thể chia sẻ tự do với mọi người Hiện tại, tôi nhận được sự hỗ trợ từ một số tình nguyện viên, và rất cần các đóng góp về thời gian, tiền bạc, chương trình và thiết bị để tiếp tục dự án này.
Richard Stallman, “Tuyên ngôn của GNU” (1985).
Chương này cung cấp cái nhìn sâu sắc về một số dự án PMTD, tập trung vào ảnh hưởng, kết quả đạt được, các mô hình quản lý và sự phát triển lịch sử của chúng Mặc dù số lượng dự án được thảo luận là nhỏ so với hàng chục ngàn dự án PMTD hiện có, chương này không nhằm mục đích toàn diện Chúng tôi hy vọng rằng sau khi đọc xong, độc giả sẽ có được hiểu biết cơ bản về việc áp dụng các lý thuyết đã được trình bày trong cuốn sách vào thực tế.
Chúng tôi đã chọn các dự án trải dài từ những ứng dụng tương tác với hệ thống vật lý của máy tính đến các môi trường làm việc thiết kế cho người sử dụng cuối Ngoài ra, chúng tôi cũng xem xét các dự án PMTD, không nhất thiết phải phát triển nghiêm ngặt, đặc biệt là các phát tán có khả năng được sử dụng như hệ thống tích hợp Những phát tán này thường bao gồm một tập hợp ứng dụng độc lập và cho phép tạo ra một hệ thống tương tác hiệu quả, bao gồm cả tùy chọn cài đặt, cập nhật và xóa bỏ ứng dụng theo nhu cầu của người sử dụng.
Trong bài viết này, chúng tôi sẽ thảo luận về các dự án mã nguồn mở nổi bật như Linux, hệ điều hành tự do nổi tiếng, và FreeBSD, kết hợp nhân BSD với ứng dụng từ bên thứ ba Chúng tôi sẽ nghiên cứu hai môi trường làm việc phổ biến là KDE và GNOME Đối với máy chủ, Apache sẽ được đề cập như là người dẫn đầu trong thị trường máy chủ WWW Ngoài ra, chúng tôi sẽ giới thiệu Mozilla, một trong những trình duyệt WWW đáng tin cậy Cuối cùng, OpenOffice.org sẽ được nhắc đến như một bộ công cụ văn phòng miễn phí.
Chúng tôi sẽ nghiên cứu chi tiết về hai bản phân phối phổ biến là Red Hat Linux và Debian GNU/Linux, đồng thời so sánh kích thước của chúng với các hệ thống thông dụng khác như Microsoft Windows và Solaris Cuối cùng, môi trường phát triển phần mềm đa ngôn ngữ Eclipse cũng sẽ được xem xét.
Sau khi thảo luận về các trường hợp điển hình khác nhau, chúng tôi sẽ trình bày bảng tổng hợp những đặc tính quan trọng của từng ứng dụng hoặc dự án Một yếu tố có thể gây ngạc nhiên cho độc giả là kết quả đánh giá về chi phí, thời gian và số lượng lập trình viên cần thiết Chúng tôi đã thu thập những kết quả này thông qua các phương pháp phổ biến trong kỹ thuật phần mềm, đặc biệt là mô hình COCOMO Mô hình COCOMO (Kinh tế kỹ thuật của phần mềm, 1981) sử dụng số lượng dòng mã lệnh làm thước đo ban đầu để ước lượng tổng chi phí, thời gian phát triển và nỗ lực cần thiết để tạo ra phần mềm COCOMO được thiết kế cho các quy trình phát triển phần mềm “kinh điển” và cho các dự án có kích thước trung bình hoặc lớn, do đó, các con số mà nó đưa ra cần được xem xét với những hạn chế nhất định Tuy nhiên, những kết quả này vẫn cung cấp cái nhìn tổng quan về phạm vi công việc và nỗ lực cần thiết để đạt được kết quả tương tự với mô hình phát triển PMSHĐQ.
Mô hình COCOMO cung cấp ước lượng giá thành dựa trên hai yếu tố chính: lương trung bình của lập trình viên và tổng chi phí Lương trung bình cho lập trình viên hệ thống toàn thời gian được lấy từ "Khảo sát về lương năm 2000" Tổng chi phí bao gồm tất cả các khoản chi cần thiết để sản phẩm được phát hành, không chỉ giới hạn ở lương của lập trình viên mà còn bao gồm chi phí cho nhân viên văn phòng, marketing, thiết bị văn phòng như máy photocopy và phần cứng Tổng kết lại, giá thành được tính toán bằng COCOMO phản ánh tổng chi phí mà công ty phải chịu để phát triển phần mềm, trong đó chỉ một phần nhỏ được trả cho lập trình viên thiết kế phần mềm Khi các yếu tố này được xem xét, giá thành trở nên hợp lý hơn.
Linux
Lịch sử của Linux
Lịch sử của Linux bắt đầu vào năm 1991 khi Linus Torvalds, một sinh viên Phần Lan, quyết định tìm hiểu về chế độ bảo vệ 386 trên máy tính của mình Thời điểm đó, hệ điều hành Minix, được thiết kế cho mục đích học thuật, đã tồn tại và được sử dụng trong các khóa học đại học về hệ điều hành Câu chuyện về Linux không chỉ đơn thuần là một phần của lịch sử phần mềm mã nguồn mở mà còn mang đậm tính thần thoại.
Minix, một hệ thống dựa trên các hệ thống Unix truyền thống, vẫn được sử dụng cho đến ngày nay Andrew Tanenbaum, giáo sư nổi tiếng tại đại học này, là người lãnh đạo đội ngũ phát triển Minix Mặc dù Minix là một hệ thống hạn chế, nhưng nó hoàn toàn có khả năng và được thiết kế tốt, đồng thời nằm trong một viện hàn lâm rộng lớn cùng với cộng đồng kỹ sư năng động.
Minix là một hệ điều hành với giấy phép phân phối tự do, cho phép sử dụng cho các mục đích hàn lâm Mặc dù được phát triển độc lập, Minix thường xuyên áp dụng các bản vá để cải thiện chức năng Điều này dẫn đến việc tồn tại một phiên bản chính thức của Minix, mà người dùng đã sử dụng, cùng với nhiều bản vá bổ sung được triển khai sau đó.
Vào giữa năm 1991, Linus, một sinh viên vô danh người Phần Lan, đã thông báo cho nhóm Minix về việc bắt đầu phát triển một hệ điều hành mới dựa trên Minix bằng cách viết lại mã nguồn Mặc dù Linus không rõ ràng về việc sẽ phát hành nó với giấy phép PMTD, nhưng anh đã nhấn mạnh rằng hệ thống mà anh dự định tạo ra sẽ không có rào cản nào.
Minix đã bắt đầu hình thành một cộng đồng xung quanh mình, mặc dù có thể anh ta vẫn chưa hoàn toàn rõ ràng về điều này và không thực sự mong muốn.
Phiên bản 0.0.2 ra mắt vào tháng 10/1991, mặc dù còn hạn chế, đã có thể chạy trên các máy đầu cuối và trình biên dịch GCC Đến tháng 3/1992, nhờ vào sự đóng góp từ cộng đồng, Linus đã phát hành phiên bản 0.95, được công nhận là ổn định Tuy nhiên, vẫn còn nhiều việc cần làm trước khi phát hành phiên bản 1.0, được xem là phiên bản ổn định đầu tiên Vào tháng 12/1993, phiên bản 0.99pl14 được phát hành, và tháng 3/1994 đánh dấu sự ra đời của Linux 1.0 Linux được phát hành theo giấy phép GPL, một quyết định mà Torvalds coi là một trong những lựa chọn tốt nhất của ông, giúp phân phối và phổ biến nhân Linux.
Bài viết "Sự tiến hóa trong PMNM: một trường hợp điển hình" cung cấp một phân tích sâu sắc về sự phát triển của các phiên bản khác nhau của nhân Linux, nhấn mạnh vào phạm vi và tính module hóa của chúng.
Vào cuối tháng 01/1992, một sự kiện quan trọng trong lịch sử PMTD đã xảy ra khi Andrew Tanenbaum và Linus Torvalds tranh luận trên nhóm tin Minix Tanenbaum, có phần khó chịu trước thành công của Torvalds với Linux, đã chỉ trích hệ điều hành này cũng như Linus một cách không công bằng Ông nhấn mạnh rằng Linux là một hệ thống nguyên khối, trong khi microkernel, mà ông ủng hộ, có thiết kế mô-đun, giúp hệ thống nhỏ gọn hơn và cho phép tải các mô-đun theo yêu cầu Cuộc tranh luận này đã thu hút sự chú ý lớn và được ghi nhận trong nhóm tín “tranh luận giữa Tanenbaum-Torvalds”.
Cách thức làm việc của Linux
Cách mà Linus Torvalds phát triển Linux là không thông thường, chủ yếu thông qua một danh sách thư, nơi mọi người không chỉ tranh luận mà còn tham gia phát triển Torvalds rất chú trọng đến việc phản ánh toàn bộ quá trình phát triển dự án trên danh sách thư, cho phép anh yêu cầu mọi người gửi bản vá trực tiếp vào danh sách Thay vì gửi các tệp đính kèm, anh thích nhận mã nguồn trong thân của thông điệp để có thể bình luận và thảo luận Mặc dù nhiều người có thể đưa ra ý kiến và gửi các bản sửa đổi hoặc tính năng mới, quyết định cuối cùng vẫn thuộc về Linus Torvalds, người sẽ chọn mã nguồn nào được hợp nhất vào Linux Cách làm này vẫn tiếp tục tồn tại cho đến năm 2007.
Sự nhất quán của Linus Torvalds với vai trò “kẻ độc tài nhân từ” đã dẫn đến nhiều câu chuyện hài hước trong dự án, trong đó có quan điểm rằng mọi ý tưởng, dù đúng hay sai, đều cần phải được triển khai Điều này dẫn đến việc nhiều ý tưởng hay không được sử dụng, do thiếu mã nguồn Hơn nữa, nếu việc cài đặt không đúng, thì cần phải cố gắng thực hiện Một ví dụ điển hình là trường hợp của Gooch, người đã phải làm việc với 146 miếng vá song song trước khi Linus quyết định tích hợp chúng vào nhánh chính của nhân.
Một trong những sáng kiến của Torvalds là phát triển hai nhánh của nhân Linux song song: nhánh ổn định (phiên bản chẵn như 2.4.18) và nhánh không ổn định (phiên bản lẻ như 2.5.12) Torvalds là người quyết định nội dung của từng nhánh, và nhiều quyết định gây tranh cãi xoay quanh vấn đề này Linux không có kế hoạch phân phối cố định; sản phẩm sẽ được phát hành khi nó sẵn sàng, và người dùng chỉ có thể chờ đợi Quyết định về sự sẵn sàng của hệ thống hoàn toàn thuộc về Linus.
Phương pháp phát triển trong Linux đã chứng minh hiệu quả cao, với độ ổn định vượt trội và khả năng sửa lỗi nhanh chóng, thường chỉ trong vài phút nhờ vào sự đóng góp của hàng ngàn lập trình viên Khi một lỗi xuất hiện, khả năng được phát hiện là rất cao, và nếu người phát hiện không thể sửa chữa, sẽ luôn có người khác sẵn sàng tìm ra giải pháp nhanh chóng Điều này thể hiện rõ ràng sự hợp tác và nỗ lực của cộng đồng phát triển Linux.
9 Thư điện tử của danh sách này là linuxkernel@vger.kernel.org Các thông điệp lịch sử có thể được tìm thấy tại http://www.uwsg.indiana.edu/hypermail/linux/kernel/ Sự thành công của danh sách này không có gì đáng ngạc nhiên, vì nó có sự cập nhật hàng tháng và cung cấp thông tin quan trọng cho cộng đồng.
Cách thức làm việc trong phát triển Linux là rất tốn kém, đặc biệt khi tài nguyên bị hạn chế Việc nhận nhiều đề xuất cho một chức năng mới hoặc hàng loạt bản vá cho cùng một lỗi không phải là điều hiếm gặp Thông thường, chỉ một trong các bản vá cuối cùng sẽ được đưa vào nhân, dẫn đến thời gian và công sức của các lập trình viên cho các bản vá khác trở nên vô ích Do đó, mô hình phát triển này hiệu quả trong Linux nhưng không phù hợp cho tất cả các dự án khác.
Hiện trạng của Linux
Vào đầu năm 2007, phiên bản 2.6 của Linux đã được phát hành, bao gồm nhiều cải tiến từ phiên bản 2.4 như NUMA, các hệ thống tệp mới, và nâng cấp cho mạng không dây cùng kiến trúc âm thanh ALSA Mô hình phát triển của Linux đã có sự thay đổi đáng kể, với mã nguồn không còn phải truyền qua danh sách thư, điều này phần lớn nhờ vào BitKeeper, một hệ thống kiểm soát phiên bản độc quyền Sự tranh cãi xung quanh BitKeeper đã dẫn đến sự phát triển của git, một hệ thống kiểm soát phiên bản hiện tại của Linux Quá trình phát triển Linux tuân theo cấu trúc hình chóp, nơi các lập trình viên đề xuất bản vá và phải được phê duyệt bởi các cấp cao hơn, với Linus Torvalds và Andrew Morton ở vị trí cuối cùng trong việc chấp nhận các bản vá Dự án Linux hiện có hơn 5 triệu dòng mã, xếp vào hàng những dự án PMTD lớn nhất, và mặc dù thời gian thiết kế có thể ngắn hơn so với trước đây, số lượng lập trình viên toàn thời gian cần thiết cho dự án lại cao hơn.
Ước tính giá thành theo COCOMO đạt khoảng 215 triệu USD, một con số có thể so sánh với khoản tiền mà các câu lạc bộ bóng đá hàng đầu chi trả cho những ngôi sao xuất sắc nhất.
Bảng 4 Phân tích về Linux
Website http://www.kernel.org
Bắt đầu của dự án Thông điệp đầu tiên trên news.comp.os.minix:
Phiên bản được phân tích 2.6.20 (phiên bản ổn định vào ngày 20/02/2007)
Số dòng mã lệnh 5,195,239 Ước tính giá thành (Cơ bản theo COCOMO) $215,291,772.00 Ước tính thời gian thiết kế (cơ bản theo
8.83 years (105.91 tháng) Ước tính số lượng trung bình các lập trình viên
Số lượng áng chừng các lập trình viên Được ước lượng là hàng ngàn (dù chỉ hàng trăm là đáng tin cậy [219)]
Các công cụ hỗ trợ phát triển Danh sách thư và git
Linux thể hiện sự áp đảo của ngôn ngữ lập trình C, được xem là ngôn ngữ lý tưởng cho thiết kế hệ thống yêu cầu tốc độ cao Khi C không đáp ứng đủ yêu cầu về tốc độ, ngôn ngữ assembly thường được sử dụng, mặc dù nó có nhược điểm là không khả chuyển giữa các kiến trúc khác nhau Mỗi kiến trúc có tập hợp lệnh riêng, dẫn đến việc mã nguồn assembly cần được chuyển đổi khi chuyển sang kiến trúc khác Các ngôn ngữ lập trình khác có phạm vi ảnh hưởng hạn chế, chủ yếu phục vụ cho các chức năng cài đặt và tiện ích phát triển Bài viết phân tích phiên bản Linux 2.6.20, phát hành vào ngày 20/02/2007, không bao gồm các bản vá sau đó.
Bảng 5 Các ngôn ngữ lập trình được sử dụng trong Linux
Ngôn ngữ lập trình Số dòng lệnh Phần trăm
Ngôn ngữ lập trình Số dòng lệnh Phần trăm
FreeBSD
Lịch sử của FreeBSD
Phiên bản 1.0 của FreeBSD ra mắt vào cuối năm 1993, dựa trên 4.3BSD Net/2 và 386BSD 4.3BSD Net/2 có mã nguồn được phát triển trong những năm 70 khi Unix được AT&T phát triển, nhưng đã gặp phải nhiều vấn đề pháp lý chưa được giải quyết cho đến năm 1995 Khi FreeBSD 2.0 được phát hành, nó không còn sử dụng mã nguồn gốc của AT&T mà dựa vào 4.4BSD Lite, một phiên bản nhẹ hơn của 4.4BSD với nhiều module bị hạn chế vì lý do pháp lý Phiên bản này được phát hành bởi Đại học California.
Lịch sử của FreeBSD không thể hoàn chỉnh nếu không nhắc đến các phát tán "chị em" như NetBSD và OpenBSD NetBSD ra mắt phiên bản 0.8 vào giữa năm 1993, với mục tiêu chính là tính khả chuyển, mặc dù ban đầu chỉ thích nghi cho i386, và phương châm của nó là "Tất nhiên nó chạy NetBSD" OpenBSD xuất phát từ NetBSD vào giữa năm 1996, với sự khác biệt về triết lý và cá nhân giữa các lập trình viên, tập trung vào an ninh và mật mã, tự nhận là hệ điều hành an toàn nhất, đồng thời vẫn giữ được tính khả chuyển cao nhờ vào nền tảng NetBSD.
Sự phát triển trong FreeBSD
Dự án FreeBSD sử dụng mô hình phát triển dựa trên hai công cụ chính là hệ thống kiểm soát phiên bản CVS và phần mềm theo dõi lỗi GNATS Toàn bộ cấu trúc của dự án được xây dựng dựa trên hai công cụ này, tạo ra một tôn ti trật tự rõ ràng Những lập trình viên được ủy thác, có quyền truy cập ghi vào kho CVS, đóng vai trò quan trọng nhất trong dự án, thông qua sự lựa chọn của nhóm nòng cốt.
Trong GNATS, bất kỳ ai cũng có thể báo cáo lỗi mà không cần phải là người được ủy thác Tất cả các báo cáo lỗi sẽ được đánh giá bởi một người được ủy thác, người có thể phân công nhiệm vụ cho các thành viên khác hoặc yêu cầu thêm thông tin từ người báo cáo Đôi khi, những lỗi đã được sửa cho một số nhánh gần đây sẽ bị chỉ định trạng thái treo Mục tiêu cuối cùng là đóng báo cáo khi lỗi đã được khắc phục.
FreeBSD cung cấp phần mềm của mình dưới hai hình thức: bản khả chuyển và gói Bản khả chuyển cho phép người dùng tải về mã nguồn, biên dịch và cài đặt ứng dụng trên máy tính cục bộ, giúp họ tùy chỉnh và tối ưu hóa phần mềm theo nhu cầu Ngược lại, gói là các mã nguồn đã được biên dịch sẵn, cho phép cài đặt nhanh chóng hơn nhiều do không cần biên dịch lại.
Qui trình ra quyết định trong FreeBSD
Ban lãnh đạo của FreeBSD, hay còn gọi là đội nòng cốt, có trách nhiệm xác định hướng đi của dự án và đảm bảo các mục tiêu được thực hiện, đồng thời giải quyết xung đột giữa các thành viên Trước tháng 10/2000, đội nòng cốt là một nhóm kín, chỉ chấp nhận thành viên qua lời mời Tuy nhiên, từ tháng 10/2000, các thành viên được bầu định kỳ và dân chủ bởi những người được ủy thác, với quy định bầu cử quan trọng nhất cho đội nòng cốt được thiết lập.
1 Những người được ủy thác đã làm ít nhất một sự ủy thác vào năm vừa qua có quyền bầu cử.
2 Ban Giám đốc sẽ được bầu mới mỗi 2 năm một lần.
3 Các thành viên của ban giám đốc có thể bị “trục xuất” bởi một cuộc bỏ phiếu của 2/3 tổng số những người được ủy thác.
4 Nếu số lượng các thành viên của ban giám đốc ít hơn 7, thì bầu cử mới sẽ được diễn ra.
5 Cuộc bầu cử mới sẽ diễn ra khi 1/3 các phiếu của những người được ủy thác đồng ý.
6 Bất kỳ thay đổi nào trong các qui định đòi hỏi 2/3 những người được ủy thác đồng ý.
Các công ty làm việc xung quanh FreeBSD
Nhiều công ty cung cấp dịch vụ và sản phẩm dựa trên FreeBSD, với danh sách được công bố trên website của dự án Trong bài viết này, chúng ta sẽ khám phá những khía cạnh quan trọng nhất của FreeBSD, đặc biệt là BSDI và Walnut Creek CDROM.
FreeBSD được phát triển vào năm 1991 với sự hỗ trợ tài chính từ công ty BSDI, do nhóm CSRG tại Đại học Berkeley thực hiện Hệ điều hành này không chỉ nhận được sự hỗ trợ thương mại từ BSDI mà còn dẫn đến việc phát triển các sản phẩm khác, bao gồm máy chủ Internet và máy chủ cổng, tách biệt với phiên bản thương mại của FreeBSD.
Walnut Creek CDROM được thành lập với mục tiêu thương mại hóa FreeBSD như một sản phẩm cuối cùng, tương tự như cách GNU/Linux đã làm Vào tháng 11 năm 1998, công ty đã ra mắt FreeBSD Mall, cho phép thương mại hóa các sản phẩm dựa trên FreeBSD, bao gồm cả việc tự phân phối, áo thun, tạp chí và sách Họ cũng công bố các sản phẩm của bên thứ ba trên website và cung cấp hỗ trợ chuyên nghiệp cho người dùng FreeBSD.
Vào tháng 03/2000, BSDI và Walnut Creek đã sát nhập thành BSDI nhằm hợp tác chống lại sự phát triển của Linux, khiến các hệ thống BSD, đặc biệt là FreeBSD, bị bỏ lại phía sau Đến tháng 05/2001, Wind River đã mua lại bộ phận phát triển phần mềm của BSDI với mục tiêu khuyến khích sự phát triển của FreeBSD cho các ứng dụng trong hệ thống nhúng và thiết bị thông minh kết nối mạng.
Hiện trạng của FreeBSD
Theo dữ liệu mới nhất từ thăm dò của Netcraft, hiện có khoảng 2 triệu máy chủ chạy FreeBSD Người dùng mới có thể lựa chọn giữa phiên bản 6.2, được coi là “ổn định”, và các phiên bản cao cấp hơn hoặc nhánh “phát triển” Phiên bản 6.2 mang lại sự ổn định, đặc biệt trong lĩnh vực đa xử lý bất đối xứng, trong khi các phiên bản phát triển cho phép người dùng trải nghiệm những cải tiến mới nhất Tuy nhiên, cần lưu ý rằng các phiên bản phát triển thường chứa mã nguồn thử nghiệm, có thể ảnh hưởng đến tốc độ hệ thống Một tính năng nổi bật của FreeBSD là jails, giúp hạn chế thiệt hại từ các cuộc tấn công vào các dịch vụ mạng cơ bản như Sendmail và BIND Các dịch vụ này được chạy trong môi trường cách ly, và jails có thể được quản lý thông qua nhiều tiện ích tích hợp sẵn trong FreeBSD.
Bức tranh X quang của FreeBSD
FreeBSD không chỉ là một hệ điều hành mà còn tích hợp nhiều tiện ích, tương tự như các bản phát tán của GNU/Linux Quá trình phát triển của FreeBSD gắn liền với hệ thống kiểm soát phiên bản CVS, cho phép chúng ta hiểu rõ hơn về cấu trúc của nó Dữ liệu phân tích FreeBSD được thực hiện vào ngày 21/08/2003 sẽ cung cấp cái nhìn sâu sắc về hệ điều hành này.
Một trong những điểm thú vị của FreeBSD là các con số của nó tương tự như trong KDE và GNOME, với kích thước phần mềm vượt quá 5 triệu dòng mã, khoảng 250,000 tệp và tổng số lần ủy thác lên tới 2 triệu Tuy nhiên, sự khác biệt chính giữa GNOME và KDE so với FreeBSD là tuổi đời của dự án, với FreeBSD gần đây được phát triển.
Sau 10 năm phát triển, FreeBSD vẫn chưa thu hút được nhiều lập trình viên so với các môi trường máy tính để bàn khác Mặc dù kích thước tương tự, số lượng lập trình viên có quyền truy cập ghi tới CVS chỉ khoảng 400, trong khi danh sách lập trình viên của FreeBSD ghi nhận khoảng 1,000 người Điều này dẫn đến hoạt động đăng ký trong CVS của FreeBSD thấp hơn mức trung bình, với khoảng 500 ủy thác mỗi ngày, so với GNOME (900) và KDE (1,700, bao gồm cả ủy thác tự động).
Hệ thống cơ bản của FreeBSD được lưu trữ trong thư mục src/src của module gốc (root) của CVS, với hơn nửa triệu lần ủy thác trong suốt 10 năm qua Tổng cộng có hơn 5 triệu dòng mã lệnh, không chỉ bao gồm nhân mà còn nhiều tiện ích bổ sung và trò chơi Nếu chỉ tính riêng nhân, nằm trong thư mục con sys, thì số lượng mã lệnh là 1.5 triệu dòng, chủ yếu được viết bằng ngôn ngữ C.
Ước tính thời gian của COCOMO cho dự án FreeBSD cho thấy sự khác biệt đáng kể so với thời gian thực tế, với số lượng lập trình viên ước tính cao hơn nhiều so với thực tế Trong năm qua, chỉ có 75 lập trình viên hoạt động, trong khi COCOMO dự đoán rằng cần tới 235 lập trình viên cho hơn 10 năm phát triển.
Cuối cùng, cần lưu ý rằng FreeBSD chủ yếu hoạt động dựa vào kho CVS và các chức năng của hệ thống kiểm soát lỗi GNATS.
Bảng 6 Phân tích của FreeBSD
Website http://www.FreeBSD.org
Giấy phép Dạng của BSD
Phiên bản được phân tích 4.8
Số dòng mã lệnh (chỉ trong nhân) 1,500,000
Số lượng các tệp 250,000 Ước tính giá thành $ 325,000,000 Ước tính thời gian thực hiện 10.5 năm (126 tháng) Ước tính số lượng trung bình các lập trình viên 235
Số lượng các lập trình viên khoảng 400 được ủy thác (1,000 cộng tác viên)
Số lượng người được ủy thác tích cực trong năm cuối 75 (ít hơn 20% tổng số)
Số lượng người được ủy thác tích cực trong 2 năm cuối 165 (khoảng 40% tổng số)
Số lượng ủy thác trong CVS 2,000,000
Số lượng trung bình các ủy thác (tổng) trong 1 ngày Khoảng 500
Công cụ hỗ trợ phát triển CVS, GNATS, danh sách thư và site tin
C là ngôn ngữ chủ yếu trong FreeBSD, giữ khoảng cách lớn hơn so với C++ so với các trường hợp khác Số lượng dòng mã lệnh trong ngôn ngữ assembly của FreeBSD tương đương với Linux, mặc dù tương ứng chỉ với 25,000 dòng trong nhân Kết luận, trong FreeBSD, các ngôn ngữ kinh điển như C, Shell và Perl chiếm ưu thế, trong khi các ngôn ngữ khác như C++, Java, và Python không được tích hợp.
Bảng 7 Các ngôn ngữ lập trình được sử dụng trong FreeBSD
Ngôn ngữ lập trình Số dòng lệnh Phần trăm
Các nghiên cứu hàn lâm về FreeBSD
Mặc dù FreeBSD là một dự án thú vị với lịch sử phát triển kéo dài hơn 10 năm, nhưng nó vẫn chưa thu hút được nhiều sự quan tâm trong cộng đồng khoa học Tuy nhiên, một nhóm nghiên cứu đã chỉ ra sự quan tâm đối với FreeBSD từ nhiều góc độ khác nhau, đặc biệt là trong việc phân tích "Sự tích hợp dần dần và phi tập trung hóa trong FreeBSD" Nghiên cứu này tập trung vào cách mà các vấn đề liên quan đến tích hợp phần mềm được giải quyết một cách dần dần và phi tập trung.
KDE
Lịch sử của KDE
Những người theo Unix nhận thấy sự thành công của Windows 95 và nhận ra rằng các môi trường giống Unix thiếu hệ thống trực giác, vì vậy họ quyết định phát triển một giải pháp mới Năm 1996, dự án K Desktop Environment (KDE) ra đời dưới sự dẫn dắt của Matthias Ettrich và các chuyên gia khác, nhằm tạo ra một môi trường máy tính để bàn trực quan và tự do Dự án KDE đặt ra những mục tiêu rõ ràng để cải thiện trải nghiệm người dùng.
Để phát triển các hệ thống như Unix, cần tạo ra một môi trường thân thiện với người sử dụng, đồng thời đảm bảo tính mở, ổn định, đáng tin cậy và mạnh mẽ.
• Để phát triển một tập hợp các thư viện cho việc viết các ứng dụng chuẩn trong một hệ thống đồ họa cho Unix X11.
Để phát triển một loạt ứng dụng hiệu quả, chúng cần giúp người dùng đạt được mục tiêu của mình một cách nhanh chóng và hiệu quả.
Một cuộc tranh cãi đã nổ ra khi các thành viên của dự án KDE quyết định sử dụng thư viện hướng đối tượng Qt, thuộc sở hữu của Trolltech, mà không tuân thủ bất kỳ giấy phép phần mềm tự do nào.
Mặc dù các ứng dụng của KDE được cấp phép theo GPL, nhưng việc liên kết với thư viện Qt đã khiến chúng không thể phân phối lại Điều này vi phạm một trong bốn quyền tự do được Richard Stallman thiết lập trong Tuyên ngôn về Phần mềm Tự do Để giải quyết vấn đề này, từ phiên bản 2.0, Trolltech đã áp dụng giấy phép đôi cho Qt, quy định rằng nếu ứng dụng sử dụng thư viện theo GPL, thì giấy phép hợp lệ cho Qt cũng là GPL Nhờ đó, một trong những tranh luận nóng bỏng trong cộng đồng phần mềm tự do đã được giải quyết một cách tích cực.
KDE, ban đầu mang ý nghĩa là Môi trường Để bàn Kool, đã được rút gọn thành Môi trường Để bàn K Giải thích cho sự thay đổi này là chữ cái K đứng trước L, đại diện cho Linux trong bảng chữ cái Latin.
Sự phát triển của KDE
KDE là một trong những dự án phần mềm mã nguồn mở tuân theo lịch trình phát hành phiên bản mới một cách đều đặn, khác với các dự án như Linux hay GNOME thường gặp phải sự chậm trễ Việc đánh số phiên bản KDE bao gồm hai con số chính: số cao nhất và hai số thấp hơn, với ví dụ là KDE 3.1.2, trong đó 3 là số cao nhất Các phiên bản có cùng số cao đảm bảo tính tương thích nhị phân, không cần biên dịch lại ứng dụng Những thay đổi ở số cao thường đi kèm với các cập nhật trong thư viện Qt, cho phép lập trình viên tận dụng các tính năng mới Các phiên bản với số thấp hơn duy nhất bao gồm cả tính năng mới và sửa lỗi, trong khi các phiên bản với số thứ hai chỉ chứa các bản sửa lỗi KDE đã được xây dựng dưới sự quản lý của hiệp hội KDE e.V tại Đức, với ban quản lý chịu trách nhiệm về các quyên góp và phát triển dự án Để thúc đẩy sự phát triển và phổ biến KDE, Liên đoàn KDE đã được thành lập, bao gồm các công ty quan tâm đến dự án.
Liên đoàn KDE
Liên đoàn KDE là một tổ chức bao gồm các công ty và cá nhân nhằm thúc đẩy, phân phối và phát triển KDE Các thành viên không nhất thiết phải tham gia trực tiếp vào phát triển KDE, nhưng được khuyến khích làm như vậy, trong khi đại diện cho một môi trường công nghiệp và xã hội thân thiện với KDE Mục tiêu chính của Liên đoàn KDE là tạo ra một nền tảng hỗ trợ cho sự phát triển bền vững của KDE.
Khuyến khích và tạo điều kiện thuận lợi cho giáo dục chính thống và không chính thống nhằm phát triển các chức năng, khả năng và phẩm chất của KDE là rất quan trọng Việc cung cấp các nguồn lực và hỗ trợ sẽ giúp nâng cao chất lượng giáo dục, đáp ứng nhu cầu đa dạng của học sinh.
• Khuyến khích các đoàn thể, chính phủ, công ty và cá nhân sử dụng KDE.
• Khuyến khích các đoàn thể, chính phủ, công ty và cá nhân tham gia vào sự phát triển của KDE.
• Cung cấp kiến thức, thông tin, sự quản lý và định vị xung quanh KDE trong việc sử dụng và phát triển nó.
• Khuyến khích giao tiếp và cộng tác giữa các lập trình viên của KDE.
Khuyến khích giao tiếp và hợp tác giữa lập trình viên và công chúng thông qua các hình thức như xuất bản phẩm, bài báo, website, hội họp, tham gia hội nghị và triển lãm, phát hành thông cáo báo chí, thực hiện phỏng vấn, cung cấp tư liệu và tham gia vào các ủy ban thúc đẩy.
Liên đoàn KDE bao gồm nhiều công ty nổi bật như SuSE (nay là Novell), Mandriva, TurboLinux, Lindows và Hancom, cùng với các nhà phát triển như Trolltech và Klarölvdalens Datakonsult AB, bên cạnh sự góp mặt của IBM và KDE.com Trong số này, Trolltech, Novell và Mandriva Software đóng vai trò quan trọng, với sự tham gia của họ có liên quan chặt chẽ đến dự án KDE và các mô hình kinh doanh của họ.
Trolltech là công ty Na Uy có trụ sở tại Oslo, nổi tiếng với việc phát triển thư viện Qt, một công cụ giao diện đồ họa cho người dùng và API cho lập trình viên, cũng như ứng dụng trong thiết bị cá nhân như PDA Dự án KDE đóng vai trò quan trọng trong chiến lược thương mại của Trolltech, không chỉ là phương tiện quảng bá mà còn khuyến khích phát triển máy tính để bàn và áp dụng các cải tiến Nhiều lập trình viên hàng đầu của KDE, bao gồm Matthias Ettrich, người sáng lập công ty, làm việc cho Trolltech Sự tham gia của Trolltech trong KDE không chỉ giới hạn ở thư viện Qt, mà còn mở rộng đến các dự án như KOffice, với các lập trình viên hợp tác bán thời gian.
SuSE, hiện là một phần của Novell, luôn thể hiện sự ưa chuộng đặc biệt đối với môi trường desktop KDE, chủ yếu do đội ngũ lập trình viên của họ phần lớn là người Đức hoặc gốc Trung Âu Nhận thức được rằng một môi trường desktop tốt hơn sẽ thúc đẩy việc phân phối và doanh số bán hàng, SuSE đã đầu tư ngân sách đáng kể vào việc chuyên nghiệp hóa các vị trí chủ chốt trong dự án KDE Hiện tại, người quản trị hệ thống kiểm soát phiên bản cùng hai lập trình viên chính đều nhận lương từ SuSE, và công ty cũng có nhiều lập trình viên sẵn sàng dành thời gian cho việc phát triển KDE.
Mandriva là một trong những nhà phát triển lớn nhất hỗ trợ KDE, với nhiều lập trình viên chính làm việc cho công ty Tuy nhiên, tình trạng tài chính của Mandriva đã dẫn đến việc công ty này tuyên bố phá sản.
2003, có nghĩa là hãng đã đánh mất ảnh hưởng trong ít năm vừa qua.
Hiện trạng của KDE
Sau khi phát hành KDE 3 vào tháng 5 năm 2002, nhiều ý kiến cho rằng các máy để bàn đang phải đối mặt với sự cạnh tranh từ các đối thủ độc quyền Một trong những thành tựu nổi bật của KDE 3 là hệ thống các thành phần Kparts, cho phép nhúng ứng dụng này vào ứng dụng khác, ví dụ như tích hợp bảng tính KSpread vào trình xử lý văn bản Kword Bên cạnh đó, sự phát triển của DCOP cũng là một điểm nhấn, cung cấp một hệ thống quy trình giao tiếp đơn giản với tính năng xác thực.
DCOP là một cam kết của dự án đã ảnh hưởng tiêu cực đến công nghệ CORBA, gây ra nhiều tranh cãi trong cộng đồng máy để bàn tự do, đặc biệt là tại GNOME, nơi CORBA được chấp nhận sử dụng Lịch sử đã phân định rõ ràng vị trí của mỗi công nghệ, như thể hiện qua đề xuất DBUS, một cải tiến của DCOP từ FreeDesktop.org Dự án này tập trung vào việc khuyến khích tính tương thích và sử dụng các công nghệ kết hợp trong môi trường máy để bàn tự do, được dẫn dắt bởi một trong những nhân vật nổi bật của GNOME.
Bảng tổng kết dưới đây nêu bật các đặc tính quan trọng của dự án KDE Các giấy phép mà dự án chấp nhận phụ thuộc vào việc chúng phục vụ cho ứng dụng hay thư viện Đặc biệt, giấy phép cho thư viện mang lại sự linh hoạt cao cho các bên thứ ba, cho phép họ phát triển các ứng dụng sở hữu độc quyền liên kết với các thư viện này.
Phiên bản mới nhất của KDE, 3.5.6, đã ra mắt vào đầu năm 2007, trong khi thế hệ 4, dựa trên Qt4, dự kiến sẽ ra mắt giữa năm 2007 Sự chuyển đổi này đòi hỏi nhiều nỗ lực để thích nghi, mặc dù các ứng dụng cũ vẫn sẽ hoạt động Để duy trì tính tương thích, các phiên bản cũ của thư viện sẽ được giữ lại, dẫn đến việc cần tải nhiều phiên bản thư viện cùng lúc, gây lãng phí tài nguyên hệ thống Các lập trình viên KDE xem đây là một phần tự nhiên trong quá trình phát triển dự án, mặc dù nó có thể gây ra một số khó khăn nhỏ.
Hình ảnh X quang của KDE
Tại những khu vực mà KDE được quan tâm, các số liệu thảo luận liên quan đến tình trạng của CVS vào tháng 08/2003 cần được xem xét với những hạn chế đã đề cập trước đó Ngoài ra, một số module sử dụng trong nghiên cứu vẫn đang trong quá trình phát triển và chưa đạt tiêu chuẩn của sản phẩm hoàn chỉnh Tuy nhiên, điều này không ảnh hưởng đến mục tiêu của chúng ta, vì chúng ta tập trung vào phạm vi kết quả hơn là các con số chính xác.
KDE đã được phát triển với tổng cộng 6 triệu dòng mã nguồn trong nhiều ngôn ngữ lập trình khác nhau, mất khoảng 9 năm rưỡi để hoàn thành, vượt qua 7 năm của dự án Số lượng lập trình viên làm việc toàn thời gian ước tính khoảng 200 người, trong khi vào năm 2003, có khoảng 800 người có quyền truy cập vào CVS, nhưng chỉ một nửa trong số đó hoạt động Số lượng lập trình viên KDE có hợp đồng toàn thời gian chưa bao giờ vượt quá 20 người, cho thấy năng suất của KDE rất cao, vượt xa ước tính của COCOMO.
Một công ty muốn phát triển một sản phẩm quy mô lớn có thể cần đầu tư hơn 250 triệu USD Để so sánh, số tiền này tương đương với khoản đầu tư của một nhà sản xuất ô tô để xây dựng một nhà máy mới ở Đông Âu, hoặc số tiền mà một công ty dầu khí nổi tiếng dự kiến chi cho 200 trạm xăng tại Tây Ban Nha.
Một phần lớn nỗ lực phát triển dự án KDE, gần như một nửa, tập trung vào việc dịch giao diện người dùng và tài liệu Mặc dù chỉ khoảng 1,000 dòng lập trình được chú ý cho nhiệm vụ này, số lượng tệp dành riêng cho việc dịch lên tới 75,000, và con số này có thể tăng đến 100,000 nếu tính cả tài liệu ở các định dạng khác nhau Điều này tạo nên khoảng 1/4 đến 1/3 trong tổng số 310,000 tệp có trong CVS Hoạt động tổng hợp này của CVS ghi nhận 1,200 ủy thác mỗi ngày, tương ứng với thời gian trung bình giữa các lần ủy thác là khoảng 1 phút 10 giây Các công cụ và thông tin hỗ trợ phát triển của KDE cung cấp một loạt khả năng phong phú hơn so với những gì có sẵn trong Linux Ngoài hệ thống kiểm soát phiên bản và danh sách thư, KDE còn có nhiều website cung cấp thông tin và tài liệu kỹ thuật cũng như không kỹ thuật về dự án.
Có một trang thông tin mới nơi các giải pháp và đề xuất được thảo luận, nhưng không thể thay thế cho các danh sách thư, nơi diễn ra tranh luận và quyết định tương lai như với Linux Trang này thực chất là một điểm gặp gỡ cho người dùng Cuối cùng, KDE đã tổ chức các cuộc gặp thường xuyên trong suốt 3 năm qua.
Có 10 quan sát quan trọng cần lưu ý: Thứ nhất, khi một ủy thác có nhiều tệp khác nhau, dường như mỗi tệp đều có một ủy thác riêng biệt; Thứ hai, số lượng ủy thác là một ước lượng tổng quát, do dự án này có nhiều script thực hiện ủy thác tự động Các lập trình viên và cộng tác viên thường gặp nhau khoảng một tuần để trình bày những đổi mới sáng tạo, thảo luận về sự phát triển mới nhất và tạo cơ hội giao lưu, vui vẻ.
Website http://www.kde.org
Giấy phép (cho các ứng dụng) GPL, QPL, MIT, Artistic
Giấy phép (cho các thư viện) LGPL, BSD, X11
Phiên bản được phân tích 3.1.3
Số lượng tệp hiện có là 310,000, bao gồm mã nguồn và tài liệu Ước tính tổng chi phí cho dự án đạt khoảng 255 triệu đô la, với thời gian thực hiện dự kiến là 9.41 năm (tương đương 112.98 tháng) Trung bình, dự án sẽ cần khoảng 200.64 lập trình viên để hoàn thành.
Số lượng các lập trình viên khoảng Khoảng 900 người được ủy thác
Số lượng người được ủy thác tích cực trong 1 năm Khoảng 450 (khoảng 50% tổng số)
Số lượng người được ủy thác tích cực trong 2 năm qua Khoảng 600 (khoảng 65% tổng số)
Số lượng người dịch khoảng (tích cực) Khoảng 300 người dịch cho hơn 50 ngôn ngữ
Số lượng các ủy thác (của các lập trình viên) trong
Khoảng 2,000,000 (con số ước lượng không bao gồm các ủy thác)
Số lượng các ủy thác (của những người dịch) trong
Khoảng 1,000,000 (con số ước lượng không bao gồm các ủy thác tự động)
Số lượng trung bình các ủy thác (tổng số) trong 1 ngày 1,700
Các công cụ, tài liệu và các sự kiện hỗ trợ phát triển CVS, các danh sách thư, website, site thông tin, các cuộc gặp hàng năm
Trong môi trường KDE, C++ chiếm ưu thế rõ rệt do đây là ngôn ngữ gốc của Qt Mặc dù đã có những nỗ lực đáng kể để cung cấp các ràng buộc cho phép phát triển bằng các ngôn ngữ khác, nhưng số lượng mã lệnh viết bằng các ngôn ngữ thiểu số vẫn còn hạn chế Tuy nhiên, điều này không có nghĩa là các ngôn ngữ này không được sử dụng, vì có nhiều dự án bên ngoài KDE áp dụng chúng.
Bảng 9 Các ngôn ngữ lập trình được sử dụng trong KDE
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
GNOME
Lịch sử của GNOME
Vào mùa hè năm 1997, Miguel de Icaza và Nat Friedman đã gặp nhau tại Redmond trong các hội thảo của Microsoft, đánh dấu một bước ngoặt quan trọng trong sự nghiệp của họ Cuộc gặp gỡ này đã truyền cảm hứng cho de Icaza để phát triển GNOME khi trở về Mexico cùng Federico Mena Quintero Họ quyết định tạo ra một môi trường desktop mới như một giải pháp thay thế cho KDE, nhận ra rằng việc tái triển khai một thư viện sở hữu độc quyền sẽ gặp nhiều khó khăn Từ đó, GNOME chính thức ra đời, thể hiện sự đổi mới trong công nghệ phần mềm.
Kể từ năm 1997, GNOME đã phát triển liên tục, với phiên bản 0.99 ra mắt vào tháng 11/1998 Phiên bản phổ biến đầu tiên, GNOME 1.0, được phát hành vào tháng 03/1999 và được phân phối rộng rãi với các bản phát tán GNU/Linux Tuy nhiên, phiên bản ổn định đầu tiên này không được đánh giá cao do nhiều lỗi tồn tại, khiến trải nghiệm của người dùng không thỏa mãn.
Vào tháng 10 năm 2000, GNOME 1.0.55 được xem là phiên bản ổn định đầu tiên của môi trường máy để bàn GNOME Các lập trình viên đã quyết định không sử dụng hệ thống đánh số phiên bản để tránh cạnh tranh với KDE GUADEC, hội nghị đầu tiên của người dùng và lập trình viên GNOME tại châu Âu, diễn ra tại Paris cùng năm, gần như trùng khớp với sự ra mắt của phiên bản GNOME mới, GNOME April Sau nhiều tháng tranh cãi trên các danh sách thư, Quỹ GNOME đã được thành lập vào tháng 10 năm đó.
GNOME 1.2 đã là một bước tiến về kiến trúc được sử dụng bởi GNOME, một kiến trúc mà nó đã tiếp tục được sử dụng trong GNOME 1.4 Kỷ nguyên này đã được đặc trưng bởi GUADEC thứ 2, mà nó diễn ra tại Copenhagen Những gì đã bắt đầu như một cuộc họp nhỏ của một ít các cao thủ, đã trở thành một sự kiện lớn mà nó đã gây được sự chú ý của toàn bộ nền công nghiệp phần mềm.
Trong khi chờ đợi, sự tự do của KDE đã được làm sáng tỏ nhờ sự thay đổi quan điểm từ Trolltech, khi công ty này cấp phép cho Qt theo một giấy phép đôi, áp dụng cho các ứng dụng tương tác với PMTD Hiện nay, cả GNOME và KDE đều là những môi trường máy tính để bàn tự do, cho thấy rằng sự phát triển của GNOME không chỉ khuyến khích việc tạo ra một môi trường máy để bàn tự do mà còn dẫn đến sự ra đời của hai môi trường như vậy.
Quỹ GNOME
Khi nghe về GNOME lần đầu, điều khó khăn nhất là hiểu tổ chức với hơn 1,000 cộng tác viên Dù có cấu trúc có vẻ hỗn loạn, GNOME đã thành công trong việc đạt được các mục tiêu phức tạp, điều mà ít dự án công nghệ thông tin làm được Được tạo ra với mục tiêu cung cấp môi trường thân thiện và mạnh mẽ, GNOME nhận ra cần thiết phải có một thực thể để khuyến khích việc sử dụng, phát triển và phổ biến dự án Kết quả là Quỹ GNOME được thành lập vào năm 2000, với tổng hành dinh tại Boston, Mỹ.
Quỹ GNOME là một tổ chức phi lợi nhuận và không phải là một nhóm các nhà công nghiệp; nó có các chức năng sau:
• Phối hợp các xuất bản phẩm.
• Quyết định những dự án nào là một phần của GNOME.
• Là người phát ngôn chính thức (cho báo chí và cho cả các tổ chức thương mại và phi thương mại) của dự án GNOME.
• Khuyến khích các hội nghị có liên quan tới GNOME (như GUADEC).
• Đại diện cho GNOME tại các hội nghị khác.
• Tạo ra các chuẩn kỹ thuật.
• Khuyến khích sử dụng và phát triển GNOME.
Quỹ GNOME đã nhận được tài chính để khuyến khích và thúc đẩy các chức năng quan trọng, điều mà trước đây không thể thực hiện một cách minh bạch.
Quỹ GNOME hiện có một nhân viên toàn thời gian phụ trách các nhiệm vụ hành chính và tổ chức trong một tổ chức phi lợi nhuận, bao gồm việc tổ chức các cuộc họp và hội nghị định kỳ Quỹ được chia thành hai ban chính: ban quản lý và ban tư vấn.
Ban Giám đốc của Quỹ GNOME bao gồm 14 thành viên được bầu chọn một cách dân chủ bởi các thành viên của quỹ Mô hình “theo chế độ nhân tài” yêu cầu các ứng viên đã có sự đóng góp cho dự án GNOME, không chỉ giới hạn ở mã nguồn mà còn bao gồm các nhiệm vụ như dịch thuật, tổ chức và phổ biến thông tin Các thành viên có thể tự đề cử mình vào ban giám đốc và thông qua đó, bầu ra đại diện của họ Hiện nay, việc bầu cử được thực hiện qua thư điện tử và nhiệm kỳ của các thành viên ban giám đốc kéo dài 1 năm, sau đó sẽ tiến hành bầu cử mới.
Để đảm bảo tính minh bạch của ban giám đốc, cần có một số điều chỉnh cơ bản, trong đó quan trọng nhất là giới hạn số lượng thành viên liên quan đến cùng một công ty không vượt quá 4 nhân viên Các thành viên ban giám đốc được chọn dựa trên khả năng cá nhân, không phải đại diện cho công ty Điều này nhằm tránh bất kỳ sự ngờ vực nào Ủy ban tư vấn của Quỹ GNOME, mặc dù không có quyền ra quyết định, đóng vai trò quan trọng trong việc giao tiếp với ủy ban quản lý Ủy ban này bao gồm các công ty thương mại trong ngành phần mềm và các tổ chức phi thương mại, với các thành viên hiện tại như Red Hat, Novell, Hewlett-Packard, Mandrake, Sun Microsystems, Red Flag Linux, Wipro, Debian và FSF Tất cả các công ty có hơn 10 nhân viên đều phải trả phí để tham gia vào ban tư vấn.
Giới công nghiệp làm việc xung quanh GNOME
GNOME đã nỗ lực tham gia vào ngành công nghiệp một cách sâu sắc, tương tự như sự tham gia tích cực của nhiều công ty khác Trong số đó, các trường hợp nổi bật bao gồm Ximian, Eazel, RHAD Labs của Red Hat và Sun Microsystems gần đây Bài viết sẽ mô tả động lực và những đóng góp quan trọng của từng công ty này đối với môi trường máy để bàn GNOME.
Ximian Inc., ban đầu được gọi là Helix Inc., là một công ty được thành lập vào năm 1999 bởi Miguel de Icaza và Nat Friedman, với mục tiêu tập hợp các lập trình viên hàng đầu của GNOME để tối đa hóa sự phát triển Công ty chú trọng vào việc phát triển ứng dụng Evolution, một hệ thống quản lý thông tin cá nhân tương tự Microsoft Outlook, bao gồm email, chương trình nghị sự và sổ địa chỉ Các sản phẩm của Ximian bao gồm máy để bàn Ximian, Red Carpet và MONO, mặc dù MONO không còn liên quan đến GNOME Ximian cũng phát triển ứng dụng cho phép Evolution tương tác với Exchange 2000 Server, mặc dù ứng dụng này gây tranh cãi do giấy phép không tự do Vào tháng 08/2003, Novell đã mua Ximian như một phần trong chiến lược đưa máy để bàn GNU/Linux vào thị trường.
Eazel, được thành lập vào năm 1999 bởi một nhóm cựu nhân viên của Apple, nhằm mục tiêu làm cho môi trường GNU/Linux dễ sử dụng như Macintosh, tập trung phát triển trình quản lý tệp Nautilus Tuy nhiên, do thiếu mô hình kinh doanh và khủng hoảng dotcom, Eazel đã phải tuyên bố phá sản vào ngày 15/05/2001, mặc dù đã kịp ra mắt phiên bản 1.0 của Nautilus Phiên bản này không đạt được tính ổn định mong đợi, nhưng hai năm sau sự phá sản, Nautilus đã phát triển thành một trình quản lý tệp hoàn chỉnh và được tích hợp vào GNOME, cho thấy sự sống sót của phần mềm sau khi công ty phát triển nó biến mất.
Red Hat đã thành lập Phòng thí nghiệm Phát triển Tiên tiến Red Hat (RHAD) nhằm nâng cao tính thân thiện và sức mạnh của máy để bàn GNOME Để đạt được mục tiêu này, Red Hat đã tập hợp những chuyên gia hàng đầu từ GNOME và cho họ tự do phát triển các giải pháp phù hợp Từ RHAD, ORBit, một triển khai cài đặt của CORBA cho dự án GNOME, đã ra đời với danh tiếng là “nhanh nhất ở phương tây” Bên cạnh đó, RHAD cũng đã đóng góp vào việc phát triển phiên bản mới của GTK+ và hệ thống cấu hình GNOME, GConf.
Sun Microsystems đã tham gia vào sự phát triển của GNOME vào giai đoạn sau, khi GNOME đã trở thành một sản phẩm chín muồi vào tháng 09/2000 Hãng dự định sử dụng GNOME làm hệ thống máy để bàn cho hệ điều hành Solaris, do đó đã thành lập một đội ngũ để làm việc với GNOME, tập trung vào tính khả dụng và tính truy cập của nó Đến tháng 06/2003, Sun công bố sẽ phân phối GNOME 2.2 cùng với phiên bản 9 của Solaris.
Hiện trạng của GNOME
Vào đầu năm 2007, GNOME đã phát hành phiên bản 2.18, đánh dấu sự trưởng thành của nhiều công nghệ chủ chốt như ORBit2 cho CORBA broker và GTK + cho môi trường đồ họa Một điểm nổi bật trong phiên bản này là thư viện hỗ trợ tính khả dụng, được đề xuất bởi Sun, giúp người dùng có vấn đề về khả năng tiếp cận dễ dàng sử dụng GNOME Hệ thống thành phần Bonobo vẫn để lại ảnh hưởng trong GNOME, trong khi chương trình quản lý thông tin cá nhân Evolution đang trong quá trình phát triển Tuy nhiên, thời gian đã chứng minh rằng kỳ vọng về Bonobo đã quá cao và việc tái sử dụng các nỗ lực phát triển của nó không đạt được mức độ phổ biến như mong đợi ban đầu.
Thư viện ATK là bộ công cụ trừu tượng giúp các ứng dụng trở nên dễ tiếp cận hơn, cho phép người dùng có khuyết tật như mù lòa, mù màu, hoặc khó khăn trong việc sử dụng chuột và bàn phím vẫn có thể sử dụng GNOME Sun chú trọng đến tính khả dụng của sản phẩm để đáp ứng các tiêu chuẩn về khả năng tiếp cận khi cung cấp dịch vụ cho chính phủ Mỹ Họ đã thực hiện công việc này một cách nghiêm túc, bao gồm cả việc có một lập trình viên mù trong đội ngũ phát triển GNOME Vào tháng 09/2002, kiến trúc khả năng tiếp cận của GNOME đã được vinh danh với giải thưởng Helen Keller Achievement.
Hình ảnh X quang của GNOME
Dữ liệu từ bảng 10 cho thấy tình trạng của CVS của GNOME vào ngày 14/08/2003, với hơn 9 triệu dòng mã lệnh trong kho Mặc dù có thể so sánh GNOME với KDE, nhưng cần lưu ý rằng sự khác biệt trong tổ chức giữa các dự án này làm cho việc so sánh trở nên khó khăn CVS của GNOME bao gồm GIMP, đại diện cho hơn 660,000 dòng mã lệnh, và thư viện GTK+ với 330,000 dòng mã lệnh Điều này giải thích tại sao GNOME có số lượng dòng mã lệnh cao hơn so với KDE, mặc dù ra đời sau 1,5 năm Ngoài ra, kho CVS của GNOME chứa hơn 225,000 tệp và đã được sửa đổi gần 2 triệu lần.
Để phát triển phần mềm tương tự như GNOME, một công ty cần ký hợp đồng với khoảng 250 lập trình viên trong hơn 11 năm, với chi phí ước tính khoảng 400 triệu USD GNOME có khoảng 1.000 lập trình viên có quyền truy cập vào hệ thống kiểm soát phiên bản CVS, trong đó chỉ có 20 người làm việc chuyên nghiệp cho dự án Trong năm qua, chỉ 25% trong số họ hoạt động tích cực, và 40% đã tham gia trong vòng 2 năm qua Trung bình, dự án ghi nhận gần 1.000 ủy thác mỗi ngày kể từ khi bắt đầu Các công cụ hỗ trợ phát triển của GNOME tương tự như của KDE, do đó không cần đi sâu vào chi tiết.
Bảng 10 Phân tích của GNOME
Website http://www.gnome.org
Bắt đầu của dự án Tháng 09/1997
Giấy phép GNU GPL and GNU LPGL
Phiên bản được phân tích 2.2
Dự kiến có khoảng 228,000 tệp, bao gồm mã nguồn và tài liệu, với tổng chi phí ước tính lên đến 400 triệu USD Thời gian thực hiện dự án được ước tính là 11.08 năm, tương đương 133.02 tháng, và cần khoảng 250 lập trình viên làm việc trung bình.
Số lượng các dự án phụ Hơn 700 modules trong CVS
Số lượng các lập trình viên khoảng Gần 1,000 với quyền truy cập ghi CVS
Số lượng người được ủy thác tích cực trong năm qua Khoảng 500 (khoản 55% của tổng số)
Số lượng người được ủy thác tích cực trong 2 năm qua Khoảng 700 (75% của tổng số)
Số lượng các ủy thác trong CVS 1,900,000
Số lượng trung bình các ủy thác (tổng) trong 1 ngày Khoảng 900
Các công cụ hỗ trợ phát triển CVS, các danh sách thư, website, site tin, gặp mặt hàng năm
Trong KDE, C++ là ngôn ngữ phổ biến nhất, trong khi GNOME chủ yếu sử dụng ngôn ngữ C Điều này xảy ra do thư viện chính của GNOME được viết bằng C, khiến ngôn ngữ này trở thành lựa chọn tự nhiên cho các lập trình viên Những lập trình viên muốn sử dụng ngôn ngữ khác phải chờ đợi các ràng buộc tương ứng được phát triển Ngôn ngữ tiên tiến nhất trong GNOME là ngôn ngữ mà nó được tích hợp, đó là C+.
Perl là ngôn ngữ lập trình thứ hai phổ biến trong cộng đồng GNOME, cho thấy khả năng lập trình đa dạng của nền tảng này Mặc dù sự triển khai của Perl không phổ biến như mong đợi, nhưng vẫn rộng rãi hơn so với Shell Ngoài ra, Python và Lisp cũng được chấp nhận rộng rãi trong GNOME, điều này chứng tỏ tầm quan trọng của chúng Ngược lại, Java chưa thực sự phát triển mạnh mẽ, có thể do một số liên kết chưa hoàn chỉnh.
Bảng 11 Các ngôn ngữ lập trình được sử dụng trong GNOME
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
Các nghiên cứu hàn lâm về GNOME
Hai nghiên cứu quan trọng nhất về GNOME trong lĩnh vực hàn lâm bao gồm: “Những kết quả từ nghiên cứu kỹ thuật phần mềm trong các dự án phát triển nguồn mở có sử dụng các dữ liệu công cộng.”
[158] và “Sự tiến hóa của GNOME” [123].
Nghiên cứu [158] là một trong những khảo sát đầu tiên về phần mềm trong lĩnh vực PMTD, tận dụng lợi thế từ việc các chi tiết phát triển thường được công khai Nghiên cứu này đã đo đếm nỗ lực phát triển và so sánh với các mô hình ước tính giá thành cùng các đo đếm nỗ lực và thời gian truyền thống Một trong những mô hình kinh điển được sử dụng để so sánh là mô hình COCOMO.
• [123] đi qua một cách vắn tắt các mục tiêu của GNOME và lịch sử ngắn gọn của nó, cũng như việc sử dụng công nghệ của dự án GNOME.
Apache
Lịch sử của Apache
Vào tháng 3/1989, Tim Berners-Lee, một nhà khoa học người Anh tại CERN, đã đề xuất một phương pháp mới để quản lý khối lượng thông tin khổng lồ từ các dự án của tổ chức này Phương pháp này hình thành mạng lưới tài liệu siêu liên kết, dẫn đến sự ra đời của World Wide Web (WWW) Đến tháng 11/1990, phần mềm WWW đầu tiên được công bố, bao gồm một trình duyệt với giao diện đồ họa và trình soạn thảo WYSIWYG Hai năm sau, danh sách các máy chủ WWW đã đạt khoảng 30, trong đó có NCSA HTTPd.
Lịch sử Apache bắt đầu khi Rob McCool rời NCSA vào tháng 3 năm 1995, với phiên bản Apache 0.2 ra mắt vào ngày 18/3/1995, dựa trên máy chủ NCSA HTTPd 1.3 Trong giai đoạn đầu, Apache chủ yếu là một tập hợp các bản vá cho máy chủ NCSA, cho đến khi Robert Thau phát hành Shambhala 0.1, một triển khai lại gần như hoàn toàn, tích hợp API cho các module, điều này đã góp phần vào sự thành công sau này của Apache.
Tên dự án Apache phản ánh triết lý phát triển và tổ chức của nó, dựa trên các giá trị của lập trình viên trong cộng đồng Apache Huyền thoại cho rằng tên Apache xuất phát từ việc máy chủ này ban đầu chỉ là một máy chủ được vá từ NCSA, hay còn gọi là máy chủ "patchy".
Phiên bản ổn định đầu tiên của Apache, Apache 1.0, được phát hành vào tháng 01/1996, với tính năng tải module trong thời gian thực và nhiều chức năng hấp dẫn khác Chỉ hai tháng sau, phiên bản 1.1 ra mắt, tích hợp các module xác thực cho cơ sở dữ liệu như MySQL Những cột mốc quan trọng tiếp theo bao gồm việc tuân thủ chuẩn HTTP 1.1 trong Apache 1.2 vào tháng 04/1997, hỗ trợ nền tảng Windows NT bắt đầu từ tháng 07/1997 với Apache 1.3, và thống nhất tệp cấu hình trong một tệp duy nhất vào tháng 10/1998 với Apache 1.3.3 Hiện tại, Apache 2 vẫn đang trong giai đoạn thử nghiệm và hứa hẹn nhiều cải tiến hơn nữa.
Vào tháng 06/1998, IBM quyết định sử dụng Apache làm động cơ cho sản phẩm WebSphere thay vì phát triển HTTP riêng, điều này được xem như một sự chứng thực lớn cho dự án Apache và phần mềm mã nguồn mở nói chung, mặc dù cần điều chỉnh một chút giấy phép gốc của Apache để thực hiện.
Sự phát triển của Apache
Máy chủ Apache HTTP là dự án chính của Quỹ Phần mềm Apache, được thiết kế theo mô-đun để phục vụ nhiều dự án vệ tinh, một số lớn hơn cả Apache Máy chủ này chứa nhân hệ thống với các chức năng cơ bản, trong khi các chức năng bổ sung được cung cấp bởi các mô-đun khác như mod_perl và Jakarta Bài viết sẽ tập trung vào quá trình phát triển của máy chủ HTTP mà không đề cập đến các mô-đun khác.
Sự phát triển của máy chủ Apache HTTP bắt nguồn từ nỗ lực của nhóm lập trình viên nhỏ gọi là nhóm Apache, được hình thành từ những người đã làm việc cùng nhau trong dự án trong hơn 6 tháng Các lập trình viên mới được mời tham gia nhóm thông qua sự đồng thuận của các thành viên hiện tại Ban đầu, nhóm có 8 lập trình viên, con số này đã tăng lên 12 và hiện tại là 25 thành viên.
Nhóm Apache chịu trách nhiệm phát triển máy chủ web và đưa ra các quyết định quan trọng về sự phát triển Cần phân biệt nhóm này với các lập trình viên trong nhóm cốt lõi, những người luôn hoạt động tích cực Tính tự nguyện của công việc thể hiện qua sự tham gia của hầu hết lập trình viên trong nhóm Apache Nhóm cốt lõi được xác định là những người có thể đảm nhận nhiệm vụ tại Apache trong một giai đoạn nhất định Quyết định chủ yếu do các lập trình viên trong nhóm cốt lõi thực hiện, tập trung vào việc biểu quyết đưa mã nguồn vào, đặc biệt liên quan đến thay đổi và thiết kế Họ cũng thường có quyền truy cập ghi tới kho CVS, đảm bảo mã nguồn đầu vào đạt chất lượng và đúng đắn.
Hình ảnh X quang của Apache
Vào ngày 18/04/2003, các phiên bản máy chủ Apache HTTP đã sẵn sàng tải về từ kho CVS của dự án Apache Mặc dù không tính đến số lượng các module, dự án Apache vẫn cho thấy sự nhỏ gọn so với các trường hợp nghiên cứu khác Điều này nhấn mạnh tính module hóa của Apache, với những ưu điểm như nhân nhỏ và dễ quản lý Kho CVS của dự án chứa hơn 4 triệu dòng mã lệnh, con số này thấp hơn nhiều so với các dự án lớn như KDE và GNOME.
Phiên bản 1.3 của Apache có khoảng 85,000 dòng mã lệnh, tương đương với công sức của 20 lập trình viên làm việc toàn thời gian trong 1 năm rưỡi Tổng chi phí cho dự án này ước tính khoảng 4 triệu USD Việc phát triển phiên bản này đã được thực hiện để cải thiện hiệu suất của máy chủ web.
Apache, tới 60 ủy thác khác nhau có thể đã cần thiết, trong khi số lượng các lập trình viên cung cấp đầu vào, theo tính toán, có thể khoảng 400.
Bảng 12 Phân tích của Apache
Website http://www.apache.org
Bắt đầu của dự án 1995
Giấy phép Giấy phép PMTD Apache
Phiên bản được phân tích 2.2.4
Số lượng các tệp 2,807 Ước tính giá thành $ 7,971,958 Ước tính thời gian thực hiện 2.52 năm (30.27 tháng) Ước tính số lượng trung bình các lập trình viên 23.4
Số lượng các lập trình viên khoảng 60 ủy thác (400 lập trình viên)
Các công cụ hỗ trợ phát triển CVS, danh sách thư, hệ thống báo cáo lỗi
Apache 1.3 được viết hầu như hoàn toàn bằng ngôn ngữ C và không có bất kỳ ngôn ngữ lập trình nào khác, đặc biệt nếu chúng ta tính tới thực tế là hầu hết các dòng lệnh được viết trong ngôn ngữ thứ 2, Shell, tương ứng với các tệp cấu hình và hỗ trợ sự biên dịch.
Bảng 13 Các ngôn ngữ lập trình được sử dụng trong Apache
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
Mozilla
Lịch sử của Mozilla
Lịch sử của Mozilla rất phong phú và gắn liền với sự phát triển của World Wide Web (WWW) Nếu theo dõi những cá nhân và tổ chức đã góp phần vào sự hình thành của Mozilla, chúng ta sẽ trở về những ngày đầu của Internet với sự ra đời của trình duyệt hoàn chỉnh đầu tiên Trình duyệt này, Mosaic, được phát triển bởi NCSA vào năm 1993, đã mở ra một kỷ nguyên mới Nhiều thành viên trong đội phát triển, dẫn dắt bởi Marc Andreessen và Jim Clark, đã thành lập một công ty nhỏ để tiếp tục công việc này, mặc dù phải đối mặt với các vấn đề về bản quyền và hạn chế kỹ thuật của Mosaic.
Microsoft đã phát triển trình duyệt Netscape Communicator, từng là người dẫn đầu thị trường trình duyệt Internet trước khi sự xuất hiện của Microsoft Internet Explorer.
Netscape Inc không chỉ đổi mới công nghệ thông qua trình duyệt của mình mà còn tạo ra một chiến lược thị trường độc đáo, dồn đối thủ vào thế khó Trình duyệt WWW của hãng được phát hành miễn phí, một động thái chưa từng thấy trong môi trường doanh nghiệp thời điểm đó Cách tiếp cận này gây bất ngờ và thể hiện sự khéo léo trong chiến lược của Netscape, mặc dù chỉ có Microsoft mới đủ sức vượt qua với những chiến thuật cạnh tranh mạnh mẽ hơn, có thể ảnh hưởng tiêu cực đến thị trường tự do.
Vào năm 1997, thị phần của Netscape giảm mạnh do sự bùng nổ của Microsoft Internet Explorer, khiến Netscape Inc tìm kiếm các giải pháp mới để khôi phục vị thế của mình Kỹ sư Frank Hecker đã xuất bản một báo cáo kỹ thuật vào năm 1998, đề xuất rằng việc phát hành mã nguồn của trình duyệt sẽ là giải pháp hiệu quả nhất, nhờ vào sự hỗ trợ từ cộng đồng phát triển phần mềm mã nguồn mở, như đã được Eric Raymond mô tả trong tác phẩm "Nhà thờ lớn và cái chợ".
Vào tháng 1 năm 1998, Netscape Inc đã công bố kế hoạch phát hành mã nguồn trình duyệt của mình, đánh dấu một bước ngoặt quan trọng trong lịch sử phần mềm mã nguồn mở Đây là lần đầu tiên một công ty công bố toàn bộ mã nguồn của một ứng dụng từng là sản phẩm sở hữu độc quyền, theo giấy phép phần mềm mã nguồn mở Ngày phát hành chính thức được ấn định vào 31 tháng 3 năm 1998.
Trong 2 tháng giữa tháng 1 và 3, mọi người tại Netscape đã tích cực một cách điên cuồng (“Việc giải phóng mã nguồn: lịch sử của Mozilla”, 1999) [134] Ở mức độ kỹ thuật, đã cần thiết để liên hệ với các công ty mà đã làm những module để hỏi họ về sự đồng ý của họ để thay đổi giấy phép: nếu câu trả lời là tiêu cực, thì module đó phải bị giới hạn Bổ sung thêm, tất cả các phần được viết trong Java phải được triển khai lại, vì nó đã được coi rằng Java là không phải tự do Họ sau đó đã quyết định gọi dự án tự do này là Mozilla, chỉ vì các lập trình viên của Netscape đã gọi thành phần chính của họ là Mozilla, và miền Mozilla.org đã được mua để xây dựng một cộng đồng các lập trình viên và các cộng tác viên dựa xung quanh website này Ở cuối của quá trình này, hơn 1,5 triệu dòng mã lệnh đã được tung ra
Tên gọi Mozilla là một trò chơi chữ hài hước từ đội phát triển của Netscape Inc., kết hợp giữa Godzilla - con quái vật nổi tiếng trong phim kinh dị Nhật Bản từ những năm 50 - và khái niệm Mosaic Killer, nhằm thể hiện trình duyệt mới này như một công nghệ tiên tiến, thay thế cho Mosaic đã lỗi thời.
Netscape đã gặp khó khăn với ba giấy phép hiện có, không thuyết phục được lãnh đạo của họ về tính tương thích với bản chất thương mại Họ mong muốn một giấy phép linh hoạt hơn để có thể hợp tác với các bên thứ ba và bảo vệ lợi ích tài chính Mặc dù không có kế hoạch ban đầu để tạo ra giấy phép mới, Netscape cuối cùng đã quyết định rằng đây là cách duy nhất để đạt được mục tiêu của mình Điều này dẫn đến việc hình thành Giấy phép Công cộng Netscape (NPL), dựa trên nguyên tắc của các giấy phép phần mềm tự do nhưng lại cung cấp quyền bổ sung cho Netscape, khiến nó trở thành giấy phép không tự do theo quan điểm của FSF Sau khi bản dự thảo NPL bị chỉ trích, Netscape đã phản hồi bằng cách phát hành Giấy phép Công cộng Mozilla (MPL), tương tự NPL nhưng không có quyền bổ sung cho Netscape Cuối cùng, mã nguồn của Netscape được phát hành theo NPL, trong khi mã nguồn mới được phân phối theo MPL hoặc giấy phép tương thích, và các sửa đổi đối với mã nguồn ban đầu cũng theo giấy phép này.
Hiện tại, Mozilla chấp nhận đóng góp theo ba giấy phép: MPL, GPL và LGPL Việc thay đổi giấy phép không hề đơn giản, vì họ cần tìm kiếm sự đồng ý từ tất cả những người đã đóng góp mã nguồn Để cấp phép cho toàn bộ mã nguồn, một website đã được tạo ra với danh sách 300 lập trình viên “bị mất tích” nhằm tìm kiếm sự giúp đỡ từ cộng đồng Tính đến tháng 05/2007, họ vẫn đang tìm kiếm hai trong số các lập trình viên này.
Việc phát triển mã nguồn ban đầu của Netscape Communicator phức tạp hơn dự kiến, với điều kiện khởi đầu kém và phiên bản không hoàn chỉnh do thiếu sự đồng ý từ các nhà phát triển bên thứ ba Hệ thống gặp khó khăn trong việc hoạt động, bên cạnh đó là những lỗi tồn đọng từ Netscape và chu kỳ phát hành không hiệu quả, không đáp ứng được nhu cầu của cộng đồng Internet Tình hình trở nên tồi tệ hơn khi Jamie Zawinsky, một trong những lập trình viên quan trọng, quyết định rời bỏ dự án sau khi bày tỏ sự thất vọng và cô đơn trong một bức thư vào năm 1999.
Vào ngày 15/07/2003, Netscape, hiện thuộc sở hữu của America On Line, đã thông báo ngừng phát triển trình duyệt Netscape và không còn hỗ trợ dự án Mozilla Để giải quyết tình hình, Netscape đã thành lập Quỹ Mozilla và đóng góp 2 triệu USD Tất cả mã nguồn theo NPL đã được hiến tặng cho Quỹ này và phân phối lại dưới các giấy phép trước đây của dự án Mozilla: MPL, LGPL và GPL.
Vào ngày 10/03/2005, Quỹ Mozilla thông báo rằng họ sẽ không phát hành phiên bản chính thức nào của Bộ Ứng dụng Mozilla, thay vào đó, sẽ tập trung vào Mozilla SeaMonkey, bao gồm trình duyệt web, trình thư điện tử, sổ địa chỉ, trình soạn thảo HTML và chat IRC Dự án Mozilla cũng phát triển nhiều ứng dụng độc lập nổi bật như Mozilla Firefox (trình duyệt web), Mozilla Thunderbird (trình thư điện tử), Mozilla Sunbird (lịch), Mozilla Nvu (trình soạn thảo HTML), Camino (trình duyệt cho Mac OS X) và Bugzilla (công cụ theo dõi lỗi).
Dự án này hiện đang tiến triển tích cực sau một thời gian dài đầy nghi ngờ, nhờ vào sự linh hoạt và khả năng chuyển đổi của các ứng dụng Mặc dù yêu cầu nhiều tài nguyên thời gian thực, chúng, đặc biệt là Firefox, thường được sử dụng kết hợp với OpenOffice.org trên các máy tính để bàn của người dùng cuối.
Hình ảnh X quang của Mozilla
Nghiên cứu về Firefox, ứng dụng nổi bật nhất trong dự án, cho thấy rằng một công ty muốn phát triển phần mềm tương tự có thể cần đầu tư khoảng 111 triệu USD Thời gian phát triển dự kiến là khoảng 7 năm, với đội ngũ lập trình viên toàn thời gian khoảng 120 người.
Bảng 14 Hiện trạng của Mozilla Firefox
Website www.mozilla-europe.org/es/products/firefox/
Bắt đầu của dự án 2002
Giấy phép MPL/LGPL/GPL
Số dòng mã lệnh 2,768,223 Ước tính giá thành $ 111,161,078 Ước tính thời gian thực hiện 6.87 năm (82.39 tháng) Ước tính số lượng trung bình các lập trình viên 120
Số lượng các lập trình viên khoảng 50 người được ủy thác
Các công cụ hỗ trợ phát triển CVS, các danh sách thư, IRC, Bugzilla.
C++ và C là hai ngôn ngữ lập trình phổ biến nhất, trong khi Perl cũng được sử dụng rộng rãi nhờ vào các công cụ phát triển của dự án Mozilla như BugZilla và Tinderbox Điều đáng chú ý là có một lượng lớn mã lệnh được viết bằng ngôn ngữ assembly trong các ứng dụng dành cho người dùng cuối Một nghiên cứu mã nguồn cho thấy nhiều tệp được lập trình bằng ngôn ngữ assembly để đạt hiệu quả tối ưu.
Bảng 15 Các ngôn ngữ được sử dụng trong Mozilla Firefox
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
OpenOffice.org
Lịch sử của OpenOffice.org
Vào giữa những năm 1980, StarDivision được thành lập tại Đức với mục tiêu phát triển bộ ứng dụng văn phòng StarOffice Vào mùa hè năm 1999, Sun Microsystems mua lại StarDivision và cam kết đầu tư mạnh mẽ vào StarOffice nhằm chiếm lĩnh một phần thị trường mà Microsoft đang thống trị Đến tháng 06/2000, Sun Microsystems đã phát hành phiên bản 5.2 của StarOffice, cho phép người dùng tải về miễn phí từ Internet.
Mặc dù StarOffice đã đạt được một số thành công, nhưng thị trường chủ yếu bị chi phối bởi gói văn phòng của Microsoft Để thay đổi chiến lược, Sun đã quyết định tận dụng lợi thế của phần mềm mã nguồn mở, tương tự như Netscape với dự án Mozilla, nhằm tăng cường tầm quan trọng và triển khai cho các hệ thống của mình Kết quả là, các phiên bản tương lai của StarOffice sẽ được phát triển dựa trên OpenOffice.org, một sản phẩm mã nguồn tự do, theo các giao diện lập trình ứng dụng (API) và định dạng tệp tiêu chuẩn, nhằm tạo ra một triển khai cài đặt chuẩn hơn.
Tổ chức của OpenOffice.org
OpenOffice.org hướng tới việc xây dựng một cấu trúc ra quyết định mà tất cả các thành viên trong cộng đồng đều cảm thấy tham gia Hệ thống này được thiết kế để đạt được sự đồng thuận cao nhất trong quá trình ra quyết định Dự án OpenOffice.org được chia thành nhiều dự án phụ, mỗi dự án được quản lý bởi các thành viên, cộng tác viên và một lãnh đạo duy nhất Các thành viên có thể tham gia vào nhiều dự án khác nhau, nhưng không ai được lãnh đạo hơn một dự án cùng lúc Các dự án này được phân loại thành ba loại khác nhau.
Các dự án được chấp nhận có thể thuộc lĩnh vực kỹ thuật hoặc phi kỹ thuật Mỗi lãnh đạo của những dự án này sẽ có một phiếu bầu khi cần đưa ra quyết định mang tính toàn cầu.
Các dự án ngôn ngữ bẩm sinh của OpenOffice.org đang thực hiện công tác quốc tế hóa và bản địa hóa, với hơn 25 đội ngũ tham gia dịch các ứng dụng sang nhiều ngôn ngữ và quy ước khác nhau Tuy nhiên, các dự án này không có quyền biểu quyết trong các quyết định toàn cầu.
Các dự án vườn ươm được khuyến khích bởi cộng đồng và thường là các thí điểm nhỏ, có thể trở thành dự án chính thức sau 6 tháng Để đảm bảo hiệu quả, cộng đồng OpenOffice.org cần đảm bảo rằng các dự án được chấp nhận dựa trên sự quan tâm thực sự, vì tỷ lệ thất bại của các dự án mới trong lĩnh vực PMTD rất cao Tổng cộng, các dự án vườn ươm có quyền biểu quyết trong các quyết định được đưa ra.
Hình ảnh X quang của OpenOffice.org
Bộ văn phòng OpenOffice.org có khoảng 4 triệu dòng mã lệnh được phân bổ qua 45,000 tệp.
Mô hình COCOMO ước tính rằng việc phát triển một "mô phỏng" của OpenOffice.org có thể cần tới 180 lập trình viên làm việc toàn thời gian.
Trong 8 năm, theo ước tính của COCOMO, chi phí phát triển có thể lên tới khoảng 215 triệu USD Kết quả này được trình bày dựa trên nghiên cứu mã nguồn của phiên bản ổn định 2.1 của OpenOffice.org.
Bảng 16 Hiện trạng của OpenOffice.org
Website http://www.openoffice.org
Bắt đầu của dự án Tháng 06/20000 (các phiên bản tự do đầu tiên)
Giấy phép LGPL và SISSL
Dự kiến, dự án này bao gồm 5,197,090 dòng mã lệnh với tổng chi phí ước tính là 215,372,314 USD Thời gian thực hiện ước tính khoảng 8.83 năm (tương đương 105.93 tháng), với số lượng lập trình viên trung bình là 180 và tổng số lập trình viên được ủy thác lên đến 200 người.
Các công cụ hỗ trợ phát triển CVS, các danh sách thư
Trong số các ngôn ngữ lập trình được sử dụng trong OpenOffice.org, C++ là ngôn ngữ chính Đặc biệt, việc Sun mua lại một công ty khác đã dẫn đến việc tích hợp một lượng lớn mã nguồn Java vào bộ văn phòng này, vượt qua cả số lượng mã nguồn của ngôn ngữ C.
Bảng 17 Các ngôn ngữ lập trình được sử dụng trong OpenOffice.org
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
Red Hat Linux
Lịch sử của Red Hat
Red Hat Software Inc được thành lập vào năm 1994 bởi Bob Young và Marc Ewing với mục tiêu biên dịch và thương mại hóa phát tán GNU/Linux mang tên Red Hat Linux Phiên bản 1.0 ra mắt vào mùa hè năm 1995, tiếp theo là phiên bản 2.0 vào mùa thu cùng năm, giới thiệu công nghệ RPM, trở thành tiêu chuẩn cho các gói trong hệ thống GNU/Linux Năm 1998, phiên bản 5.2 của Red Hat được phát hành, đánh dấu bước tiến quan trọng trong lịch sử phát triển của hãng Để tìm hiểu chi tiết về các phiên bản khác nhau của Red Hat, hãy tham khảo bài viết “Sự thật đằng sau những cái tên của Red Hat”.
Trong phiên bản 1.1 của Nền tảng Chuẩn Linux (Linux Standard Base), RPM đã được chọn làm trình quản lý gói chuẩn để đảm bảo tính tương thích nhị phân giữa các phát tán GNU/Linux Trong khi đó, dự án Debian tiếp tục sử dụng định dạng gói riêng của mình, và nhiều phát tán khác phụ thuộc vào hệ thống quản lý gói của Debian Để chuẩn hóa định dạng này, một công cụ chuyển đổi mang tên alien đã được phát triển.
Trước khi hệ thống quản lý RPM ra đời, việc cài đặt phần mềm trên các phát tán GNU/Linux chủ yếu dựa vào thủ tục menu, khiến cho việc sửa đổi cài đặt, đặc biệt là bổ sung gói phần mềm mới, trở nên khó khăn RPM đã cải thiện tình hình này bằng cách cho phép người dùng quản lý gói phần mềm của riêng họ, giúp việc cài đặt, xóa bỏ và cập nhật gói phần mềm trở nên dễ dàng hơn Hệ thống gói RPM hiện vẫn là hệ thống quản lý gói phổ biến nhất trong các phát tán GNU/Linux khác nhau, với 65 trong số 118 phát tán sử dụng RPM vào tháng 05/2003, chiếm khoảng 55% tổng số Trong khi đó, định dạng gói của Debian (deb) chỉ được sử dụng trong 16 phát tán, tương đương với khoảng 14% tổng số.
Red Hat không chỉ nổi tiếng với phần mềm dựa trên Linux, mà còn ghi dấu ấn mạnh mẽ trên thị trường chứng khoán khi cổ phiếu của hãng đạt mức cao nhất trong lịch sử Phố Wall vào tháng 08/1999 Tuy nhiên, sau bốn năm, giá trị cổ phiếu đã giảm mạnh, xuống chỉ còn 1/100 so với đỉnh điểm trước khủng hoảng dotcom Mặc dù vậy, sự thành công ban đầu đã giúp Red Hat thu hút sự chú ý của truyền thông, mặc dù không chuyên sâu về công nghệ thông tin Đến cuối năm 2002, Red Hat đã báo cáo lợi nhuận dương lần đầu tiên trong lịch sử, cho thấy khả năng vượt qua những thách thức mà nhiều công ty khác gặp phải Một cột mốc quan trọng là việc mua lại Cygnus Solutions vào tháng 11/1999, công ty đã chứng minh khả năng kiếm tiền thông qua chiến lược phát triển phần mềm dựa trên GNU, đặc biệt là các công cụ như GCC và GDB, đáp ứng nhu cầu của khách hàng trong thị trường trình biên dịch phức tạp.
Vào tháng 09/2003, Red Hat quyết định tập trung vào phát triển phiên bản doanh nghiệp của mình và đã chuyển giao phiên bản cộng đồng cho Fedora Core, một dự án mã nguồn mở độc lập.
Vào tháng 6 năm 2006, Red Hat đã mua lại công ty JBoss, qua đó trở thành đơn vị chủ chốt trong việc phát triển máy chủ ứng dụng nguồn mở J2EE, một trong những sản phẩm quan trọng nhất trong lĩnh vực này.
Hiện trạng của Red Hat
Hiện tại, Red Hat chủ yếu cung cấp các sản phẩm như Fedora Core và Red Hat Network, cùng với dịch vụ cập nhật phần mềm qua Internet Mặc dù các dịch vụ này chủ yếu tập trung vào người dùng cuối và chưa thực sự đáp ứng nhu cầu của doanh nghiệp, chúng vẫn đóng vai trò quan trọng trong việc quảng bá thương hiệu và nâng cao chiến lược marketing của Red Hat.
Chiến lược thương mại của Red Hat chủ yếu dựa vào các sản phẩm thiết kế cho doanh nghiệp, mặc dù những sản phẩm này ít nổi tiếng hơn Tuy nhiên, chúng đóng góp một phần doanh thu lớn hơn nhiều so với các sản phẩm ngôi sao nổi bật của hãng.
Red Hat cung cấp một phiên bản hướng doanh nghiệp mang tên Red Hat Enterprise Linux AS, đi kèm với hỗ trợ cho khách hàng mua phần mềm Đối với người dùng thương mại, Red Hat Enterprise Network tương đương với Red Hat Network, bao gồm quản lý hệ thống và lựa chọn cập nhật Ngoài ra, Red Hat cũng cung cấp dịch vụ tư vấn công nghệ thông tin và chương trình cấp chứng chỉ tương tự như Microsoft trong lĩnh vực Windows.
Bức tranh X quang của Red Hat
Red Hat đã đạt cột mốc 50 triệu dòng mã lệnh, trở thành một trong những phát tán phần mềm lớn nhất, vượt qua kích thước của các hệ điều hành sở hữu độc quyền Phiên bản 8.1 của Red Hat có 792 gói, và phiên bản mới nhất có thể đã vượt qua 800 gói, cho thấy sự gia tăng số lượng gói qua các phiên bản Mô hình COCOMO đã được áp dụng để ước tính đầu tư và nỗ lực cần thiết cho việc phát triển phần mềm, với mỗi ứng dụng trong các gói của Red Hat được ước tính độc lập Để phân tích thời gian thiết kế tối ưu, gói lớn nhất đã được chọn, vì tất cả các gói là độc lập và có thể được thiết kế đồng thời Do đó, thời gian thiết kế tối ưu cho Red Hat tương tự như thời gian của các dự án khác trong chương này.
Theo mô hình COCOMO, việc thiết kế và phát triển Red Hat Linux 8.1 từ con số 0 có thể yêu cầu khoảng 7,5 năm và một đội ngũ khoảng 1,800 lập trình viên Tổng chi phí cho dự án này ước tính lên tới khoảng 1,800 triệu USD.
Bộ Quốc phòng Tây Ban Nha đã phân bổ 1,800 triệu USD cho việc nâng cấp tàu sân bay cho máy bay trực thăng, đánh dấu ngân sách lớn nhất từ trước đến nay Trong số đó, một nửa số tiền sẽ được đầu tư để mua 24 chiếc máy bay trực thăng, cho thấy giá trị tương đương của Red Hat với 48 chiếc máy bay trực thăng chiến đấu Đáng chú ý, 1,800 triệu USD cũng là tổng doanh thu mà bộ phim Titanic đã kiếm được.
Bảng 18 Hiện trạng của Red Hat Linux
Website http://www.redhat.com
Bắt đầu của dự án 1993
Số dòng mã lệnh Hơn 50,000,000
Số lượng các gói 792 Ước tính giá thành $ 1,800,000,000 Ước tính thời gian thực hiện 7.35 năm (88.25 tháng) Ước tính số lượng trung bình các lập trình viên 1,800
Số lượng các lập trình viên khoảng Các nhân viên của Red Hat (chỉ tích hợp chung) Các công cụ hỗ trợ phát triển CVS, các danh sách thư
Trong Red Hat, sự đa dạng ngôn ngữ lập trình nổi bật hơn so với các ứng dụng PMTD chính, với C chiếm hơn 60% tổng số dòng mã Tiếp theo là C++ với hơn 10 triệu dòng mã, và Shell đứng sau một khoảng lớn Đáng chú ý, sau Perl là Lisp, chủ yếu do sự sử dụng trong Emacs, tiếp theo là ngôn ngữ assembly, chiếm khoảng 1/4 tổng số ngôn ngữ liên quan đến Linux, và cuối cùng là Fortran, ngôn ngữ đang có xu hướng giảm sử dụng.
Bảng 19 Các ngôn ngữ lập trình được sử dụng trong Red Hat
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
Debian GNU/Linux
Hình ảnh X quang của Debian
Debian GNU/Linux là một trong những bản phân phối phần mềm tự do lớn nhất, hoạt động theo cách phối hợp và được xem là một trong những sản phẩm phần mềm ấn tượng nhất từ trước đến nay Phiên bản 4.0, ra mắt vào tháng 04/2007 với tên gọi Etch, bao gồm hơn 10,000 gói nguồn và chứa hơn 288 triệu dòng mã lệnh.
Số lượng mã lệnh trong Debian 3.0 lên tới 105 triệu dòng, theo mô hình COCOMO, chi phí để phát triển phần mềm tương tự có thể lên đến 3,600 triệu USD Việc phát triển Debian đòi hỏi tính toán chi tiết cho từng gói phần mềm, dẫn đến thời gian phát triển kéo dài khoảng 7 năm Trong suốt quá trình này, trung bình khoảng 4,000 lập trình viên đã được huy động để xây dựng các gói phần mềm cùng một lúc.
Bảng 20 Hiện trạng của Debian
Website http://www.debian.org
Bắt đầu của dự án 16/08/1993
Giấy phép Những giấy phép thỏa mãn cho DFSG
Phiên bản được sử dụng Debian 4.0 (còn được gọi là Etch)
Số lượng các gói 10,106 Ước tính giá thành $ 10,140 triệu Ước tính thời gian thực hiện 8.84 năm
Số lượng những người duy trì khoảng Khoảng 1,500
Các công cụ hỗ trợ phát triển Các danh sách thư, hệ thống báo cáo lỗi
Ngôn ngữ lập trình phổ biến nhất trong Debian 4.0 là C, chiếm hơn 51% tổng số dòng mã, mặc dù tầm quan trọng của nó đang giảm dần theo thời gian, từ 80% trong các phiên bản đầu C++ là ngôn ngữ thứ hai được sử dụng nhiều, nhưng sự suy giảm của C chủ yếu do sự gia tăng của các ngôn ngữ scripting như Perl, Python và PHP Ngoài ra, các ngôn ngữ như Lisp và Java cũng thỉnh thoảng được sử dụng, mặc dù Java không được hỗ trợ đầy đủ trong Debian do chính sách không chấp nhận mã nguồn phụ thuộc vào máy ảo độc quyền của Sun.
Chương trình Khung công việc của Ủy ban châu Âu lần thứ 6 đã phân bổ ngân sách 3,600 triệu USD cho nghiên cứu và phát triển xã hội thông tin Đồng thời, Telefónica cũng dự kiến đầu tư số tiền này vào Đức để triển khai các dịch vụ UMTS.
Bảng 21 Các ngôn ngữ lập trình được sử dụng trong Debian GNU/Linux 4.0
Ngôn ngữ lập trình Số dòng mã lệnh (triệu dòng) Phần trăm
Bảng 22 chỉ ra cách mà những ngôn ngữ quan trọng nhất được phát triển trong Debian.
Bảng 22 Các ngôn ngữ được sử dụng nhiều nhất trong Debian
Ngôn ngữ Debian 2.0 Debian 2.1 Debian 2.2 Debian 3.0
Có những ngôn ngữ thiểu số nhưng lại đạt vị thế cao trong phân loại do số lượng gói yêu cầu lớn Chẳng hạn, Ada chỉ có trong 3 gói (GNAT, libgtkada và ASIS) nhưng đã chiếm tới 430,000 dòng mã trong tổng số 576,000 dòng của Debian 3.0 Tương tự, Lisp chỉ xuất hiện trong GNU Emacs và XEmacs, nhưng lại có hơn 1,200,000 dòng mã trong khoảng 4 triệu dòng của toàn bộ phát tán.
So sánh với các hệ điều hành khác
Có một câu tục ngữ rằng tất cả những so sánh đều khập khiễng, và điều này đặc biệt đúng khi so sánh PMTD với PMSHĐQ Hình ảnh X quang chi tiết của Red Hat Linux và Debian là ví dụ điển hình của PMTD, nhờ vào việc truy cập vào mã nguồn và các thông tin khác Điều này là cơ sở cho việc nghiên cứu các dòng lệnh, gói, và ngôn ngữ lập trình của các phiên bản khác nhau Tuy nhiên, ưu điểm của PMTD không chỉ dừng lại ở đó; nó còn tạo điều kiện thuận lợi cho các bên thứ ba, từ các đội nghiên cứu đến những người quan tâm, trong việc phân tích các hệ thống này.
Trong các hệ thống sở hữu độc quyền, việc thực hiện một nghiên cứu như vậy là rất khó khăn Các số liệu được cung cấp dưới đây xuất phát từ chính các công ty phát triển PMSHĐQ, do đó, chúng ta không thể đảm bảo tính chính xác của chúng Thêm vào đó, chúng ta không rõ liệu các số liệu này có liên quan đến mã nguồn vật lý hay không, hay có bao gồm các dòng trống và bình luận Hơn nữa, chúng ta cũng không thể xác định nội dung chính xác trong phần mềm, vì vậy không biết liệu các phiên bản cụ thể của Microsoft Windows có bao gồm Microsoft Office hay không.
Trong bối cảnh đã thảo luận, việc so sánh giữa Red Hat và Debian sẽ giúp chúng ta hiểu rõ hơn về vị trí của các phân phối này Cả Debian và Red Hat, đặc biệt là Red Hat, được coi là những bộ sưu tập phần mềm lớn nhất mà nhân loại từng thấy.
Các con số được trích ra bên dưới tới từ Mark Lucovsky [168] cho Windows XP và Bruce Schneier
[200] cho tất cả các hệ thống khác Bảng 23 đưa ra một sự so sánh, từ nhỏ nhất cho tới lớn nhất.
Bảng 23 So sánh với các hệ thống sở hữu độc quyền
Hệ điều hành Ngày xuất bản Số dòng mã lệnh (khoảng)
Eclipse
Lịch sử của Eclipse
Nhiều chương trình của Eclipse đã được IBM triển khai trước khi dự án Eclipse ra đời, với VisualAge là tiền thân sử dụng Smalltalk trong môi trường phát triển Envy Sau sự xuất hiện của Java vào những năm 90, IBM đã phát triển một máy ảo hỗ trợ cả Smalltalk và Java Tuy nhiên, sự phát triển nhanh chóng của Java và ưu điểm của nó trong việc tập trung vào Internet đã khiến IBM quyết định từ bỏ máy ảo đôi và xây dựng một nền tảng mới dựa trên Java Sản phẩm cuối cùng, Eclipse, đã tiêu tốn của IBM khoảng 40 triệu USD vào năm 2001.
Cuối năm 2001, IBM và Borland đã thành lập quỹ Eclipse phi lợi nhuận, mở ra cơ hội cho thế giới phần mềm mã nguồn mở (PMNM) Nhóm doanh nghiệp này đã kết nối với nhiều công ty phát triển phần mềm toàn cầu quan trọng như Oracle, Rational Software, Red Hat, SuSE, HP, Serena, Ericson và Novell, ngoại trừ Microsoft và Sun Microsystem.
Microsoft đã bị loại bỏ do sự độc quyền của hãng trên thị trường, trong khi Sun Microsystem phát triển IDE riêng của mình, NetBeans, trở thành đối thủ chính của Eclipse Tên gọi Eclipse được chọn với mục tiêu tạo ra một IDE có khả năng "làm lu mờ" Visual Studio của Microsoft.
“làm lu mờ mặt trời” (Sun Microsystem).
Phiên bản ổn định mới nhất của Eclipse hiện có sẵn cho các hệ điều hành như Windows, Linux, Solaris, AIX, HP-UX và Mac OS X Để sử dụng Eclipse, người dùng cần cài đặt một máy chủ ảo Java (JVM) trong hệ thống, với lựa chọn tốt hơn là môi trường thời gian thực Java (JRE) hoặc bộ công cụ lập trình Java (JDK) của Sun Tuy nhiên, vào đầu năm 2007, JDK vẫn chưa được phát hành miễn phí, mặc dù Sun đã thông báo rằng JVM của họ sẽ trở thành mã nguồn mở.
Hiện trạng của Eclipse
Tất cả công việc của nhóm Eclipse được tổ chức trong các dự án khác nhau, với mỗi dự án có thể chia thành các dự án phụ và các thành phần Các dự án cấp cao được quản lý bởi Ban Quản Lý Dự Án (PMC) của Quỹ Eclipse Dưới đây là danh sách các dự án cấp cao.
Eclipse là nền tảng cơ bản cho các thành phần còn lại, cung cấp sự tự do, khỏe mạnh và hoàn chỉnh với chất lượng tốt cho sự phát triển của các nền tảng máy trạm giàu (RCP) và các công cụ tích hợp (plug-ins) Nền tảng này hỗ trợ thời gian thực, góp phần nâng cao hiệu suất và khả năng tương tác trong quá trình phát triển phần mềm.
Eclipse, được biết đến với tên gọi Equinox, là một triển khai cài đặt của đặc tả kỹ thuật OSGi (Open Services Gateway Initiative) OSGi mô tả một kiến trúc hướng dịch vụ (SOA) cho các ứng dụng, cho phép các thành phần phần mềm tương tác linh hoạt và hiệu quả.
• Các công cụ (ETP, dự án các công cụ của Eclipse) Hàng loạt các công cụ và các thành phần cho nền tảng Eclipse
• Web (WTP, dự án các công cụ web) Các công cụ để phát triển các ứng dụng web và JEE (Java Enterprise Edition - Phiên bản Java cho doanh nghiệp).
Dự án thử nghiệm và các công cụ thực thi (TPTP) cung cấp các công cụ đo đạc và thử nghiệm hiệu quả, giúp lập trình viên theo dõi ứng dụng của họ Những công cụ này không chỉ nâng cao năng suất làm việc mà còn đảm bảo chất lượng sản phẩm.
• Các báo cáo Web (BIRT, các công cụ báo cáo và tri thức doanh nghiệp) Hệ thống tạo báo cáo Web.
• Việc mô hình hóa (EMP, dự án mô hình hóa Eclipse) Các công cụ phát triển dựa theo mô hình.
• Dữ liệu (DTP, nền tảng các công cụ về dữ liệu) Hỗ trợ cho các công nghệ quản lý các dữ liệu.
Các thiết bị nhúng, như DSDP, là nền tảng phát triển phần mềm chuyên dụng cho các ứng dụng chạy trên phần cứng hạn chế Những công cụ này hỗ trợ quá trình phát triển ứng dụng cho các thiết bị nhúng, giúp tối ưu hóa hiệu suất và tài nguyên của hệ thống.
• Kiến trúc hướng dịch vụ (SOA) Các công cụ cho việc phát triển các dự án hướng dịch vụ.
• Công nghệ Eclipse Nghiên cứu, phổ biến và phát triển nền tảng Eclipse.
Các nguyên tắc mà chúng chỉ dẫn cho sự phát triển của cộng đồng Eclipse là như sau:
• Chất lượng Phần mềm được phát triển tại Eclipse phải đáp ứng được các chuẩn về chất lượng của kỹ thuật phần mềm.
Nền tảng Eclipse và các công cụ liên quan cần phải phát triển linh hoạt để đáp ứng nhanh chóng các yêu cầu của người sử dụng.
• Chế độ nhân tài Ai đó mà càng đóng góp nhiều, thì các trách nhiệm của anh ta hoặc chị ta càng nhiều.
Hệ sinh thái Eclipse sẽ nhận được những tài nguyên quý giá từ cộng đồng nguồn mở, nhằm hỗ trợ cho nhóm các công ty thuộc Eclipse Những tài nguyên này sẽ được sử dụng một cách có lợi cho toàn bộ cộng đồng.
Qui trình phát triển của Eclipse bao gồm các pha rõ ràng Bắt đầu với pha đề xuất, nơi cá nhân hoặc công ty thể hiện sự quan tâm đến việc khởi xướng một dự án Nếu được chấp thuận, dự án sẽ được phân loại là dự án chính hoặc dự án phụ Tiếp theo, tính khả thi và chất lượng của dự án sẽ được đánh giá Sau giai đoạn thử nghiệm, dự án sẽ trải qua một cuộc rà soát cuối cùng Nếu vượt qua, dự án sẽ được phê duyệt và chính thức gia nhập cộng đồng Eclipse, tiến vào pha triển khai.
Hình ảnh X quang của Eclipse
Eclipse được phân phối dưới giấy phép EPL (Eclipse Public License), được công nhận là tự do bởi FSF và OSI Giấy phép này cho phép người dùng sử dụng, sửa đổi, sao chép và phân phối các phiên bản mới của sản phẩm EPL kế thừa từ CPL (Common Public License), một giấy phép được phát triển bởi IBM, trong khi EPL là sản phẩm của sự hợp tác giữa các công ty trong nhóm Eclipse.
Đánh giá đầu tư và nỗ lực vào Eclipse là một thách thức do mã nguồn của hệ sinh thái này phân tán trong nhiều dự án và kho phần mềm khác nhau.
Kết quả áp dụng mô hình COCOMO cho nền tảng Eclipse đã cung cấp cơ sở quan trọng cho việc phát triển các trình cài cắm bổ sung (plug-ins) trong hệ thống.
Bảng 24 Phân tích về Eclipse
Website http://www.eclipse.org
Bắt đầu của dự án 2001
Giấy phép Giấy phép Công cộng Eclipse (EPL)
Phiên bản được phân tích 3.2.2
Số lượng các tệp 15,426 Ước tính giá thành $ 85,831,641 Ước tính thời gian thực hiện 6.22 năm (74.68 tháng) Ước tính số lượng trung bình các lập trình viên 102.10
Số lượng các lập trình viên khoảng 133 người được ủy thác
Các công cụ hỗ trợ phát triển CVS, các danh sách thư, hệ thống theo dõi lỗi
Bảng sau chỉ ra các ngôn ngữ lập trình trong Eclipse 3.2.2:
Bảng 25 Các ngôn ngữ lập trình được sử dụng trong Eclipse
Ngôn ngữ lập trình Số dòng mã lệnh Phần trăm
10 Các nguồn tự do khác
“Nếu bạn muốn tạo ra một cái bánh táo từ bàn tay trắng, thì bạn trước hết phải tạo ra vũ trụ đã”
Các ý tưởng đằng sau các chương trình tự do có thể được áp dụng cho các nguồn thông tin khác có thể sao chép điện tử Tuy nhiên, sự khác biệt trong cách thức hoạt động của các nguồn thông tin này dẫn đến việc chúng không phát triển mạnh mẽ như các chương trình Cụ thể, việc sao chép các chương trình chỉ yêu cầu người dùng thực hiện thao tác đơn giản, trong khi các dạng thông tin khác cần trải qua một quá trình tốn kém, từ việc học tài liệu đến sản xuất phần cứng theo ngôn ngữ phù hợp, trước khi trở nên hữu ích.
Những tài nguyên tự do quan trọng nhất
Các tài liệu khoa học
Khoa học tiến bộ nhờ vào việc các nhà nghiên cứu công bố kết quả nghiên cứu của họ trên các tạp chí, giúp công chúng tiếp cận thông tin Sự phổ biến này không chỉ tạo dựng uy tín cho các nhà nghiên cứu mà còn cho phép họ phát triển hồ sơ theo dõi, từ đó nâng cao vị thế và trách nhiệm của mình Đồng thời, uy tín này cũng giúp họ giành được các hợp đồng nghiên cứu, mang lại doanh thu cho các dự án của họ.
Mô hình kinh doanh này đã chứng minh hiệu quả cao, với yêu cầu đảm bảo chất lượng công việc và phổ biến tài liệu rộng rãi Tuy nhiên, sự phổ biến bị cản trở bởi số lượng lớn tạp chí hiện có, với chi phí cao chỉ phù hợp cho những ngân sách lớn Chất lượng của tài liệu được đảm bảo nhờ vào việc được xem xét bởi các chuyên gia hoặc đồng nghiệp.
Trong bối cảnh hiện nay, nhiều tạp chí trực tuyến đã xuất hiện, đáng chú ý là tạp chí "Ngày thứ hai Đầu tiên" và dự án Thư viện Công của Khoa học (PLOS) Danh sách các tạp chí Truy cập Mở ngày càng phong phú Tuy nhiên, có những lo ngại về chất lượng và tính minh bạch của các tài liệu được xuất bản, cũng như nguy cơ bị đánh cắp nội dung mà không ghi nhận công sức của tác giả Dù vậy, việc các tác giả có trách nhiệm trích dẫn nguồn gốc và đưa tài liệu qua quy trình rà soát đồng nghiệp trước khi xuất bản có thể giúp giải quyết những vấn đề này.
PMTD và khoa học có mối tương quan chặt chẽ, vì mô hình phát triển của PMTD yêu cầu sự phổ biến rộng rãi, đánh giá từ các đồng nghiệp (được giả định là chuyên gia) và việc tái sử dụng các kết quả nghiên cứu.
Luật pháp và chuẩn
Các tài liệu tự nhiên điều chỉnh xác định cách thức thực hiện nhằm cải thiện sự cùng tồn tại giữa mọi người và đảm bảo các chương trình, máy móc hoạt động hiệu quả Việc phổ biến rộng rãi những tài liệu này là cần thiết, vì bất kỳ cản trở nào đều có thể gây phản tác dụng Do đó, chúng được đối xử đặc biệt, như được nêu trong Luật Sở hữu trí tuệ của Tây Ban Nha.
Những đề xuất pháp lý, điều chỉnh và phác thảo của chúng, cùng với các quyết định của cơ quan nhà nước và bản dịch chính thức, không thuộc về sở hữu trí tuệ.
Sự tương tự về công nghệ của các luật này thường liên quan đến các qui tắc tiêu chuẩn hoặc chuẩn mực, đặc biệt trong lập trình và giao tiếp giữa các máy tính Việc duy trì sự phổ biến của các giao thức này là cần thiết để các chương trình có thể hoạt động hiệu quả và hợp tác với nhau Tuy nhiên, các cơ quan quản lý như ISO và ITU thường bán các chuẩn và quy định của họ, ngay cả ở định dạng điện tử, đồng thời cấm việc phân phối lại chúng.
Mặc dù việc hợp thức hóa một phần nào đó có thể được xem là cần thiết để bù đắp chi phí, nhưng sự phổ biến tự do của các tiêu chuẩn sẽ mang lại hiệu suất cao hơn Điều này đặc biệt đúng với các chỉ dẫn của W3C và các tài liệu RFC (yêu cầu cho các bình luận) liên quan đến chuẩn Internet, vốn đã tồn tại từ đầu và có thể được đọc bằng bất kỳ trình soạn thảo văn bản nào.
Sự thành công của các giao thức Internet không chỉ dựa vào tính sẵn có, mà còn nhờ vào mô hình phát triển mở, cho phép mọi người tham gia và sử dụng các danh sách thư Qui trình này được mô tả trong tài liệu “Qui trình của các chuẩn Internet - sự rà soát lại lần 3” và “Tao của IETF”.
11 Tổ chức Quốc tế về Tiêu chuẩn hóa
12 Liên minh Truyền thông Quốc tế
13 Nhóm các công ty về World Wede Web
Một chỉ dẫn mới cho đội đặc nhiệm về kỹ thuật Internet” [136].
Việc sửa đổi các văn bản luật và điều chỉnh có thể bị hạn chế nếu dẫn đến sự nhầm lẫn Cụ thể, một RFC chỉ nên được sửa đổi để làm rõ hoặc bổ sung các bình luận, và việc này cần có sự cho phép rõ ràng từ W3C.
Giấy phép là tài liệu pháp lý không thể sửa đổi, nhưng có thể tạo ra điều chỉnh mới dựa trên giấy phép hiện có Tuy nhiên, điều này có thể dẫn đến sự truyền bá những điều chỉnh không tương thích, gây nhầm lẫn và tạo điều kiện cho các công ty thống trị thị trường thực hiện biến đổi không tương thích Trong lĩnh vực Internet, hiện tượng này diễn ra phổ biến Hơn nữa, nhiều luật pháp của các quốc gia thường được sao chép từ nước khác với những sửa đổi nhỏ để phù hợp với đặc thù địa phương.
Mô hình kinh doanh cho các luật và điều chỉnh có thể được hình thành từ sự hợp tác của nhiều chuyên gia như nhà làm luật, luật sư, cố vấn pháp lý và quan tòa Họ có trách nhiệm thiết kế, phiên dịch và tăng cường các quy định pháp lý Ngoài ra, các phòng thí nghiệm cung cấp chứng chỉ tuân thủ cho những điều chỉnh cũng đóng vai trò quan trọng Các cơ quan điều chỉnh cần thiết phải tồn tại để thúc đẩy các tiêu chuẩn, đặc biệt là trong bối cảnh các doanh nghiệp cần sản phẩm tương thích với quy định.
Theo cách tương tự, để có một định nghĩa rõ ràng về PMTD hoặc PMNM, cũng cần thiết phải làm việc để định nghĩa các chuẩn mở Bruce Perens đã đưa ra một định nghĩa dựa trên các nguyên lý cốt lõi.
1 Tính sẵn sàng: nếu có thể, các chuẩn mở phải là sẵn sàng cho tất cả để đọc và triển khai.
2 Tối đa hóa sự lựa chọn của người sử dụng đầu cuối.
3 Các chuẩn mở phải là tự do cho tất cả để triển khai mà không có chi phí bản quyền hoặc phí nào (các chứng thực về tuân thủ có thể liên quan tới một thứ phí, dù Bruce Perens khuyến cáo rằng nên có các công cụ tự chứng thực tự do sẵn sàng).
4 Không có sự phân biệt đối xử có lợi cho một nhà triển khai cài đặt nào so với những người khác.
5 Những quyền mở rộng hoặc phụ thêm (không chứng thực được).
6 Tránh thực tế ăn cắp bởi các nhà sản xuất áp đảo Tất cả các mở rộng sở hữu độc quyền phải có một triển khai cài đặt theo chuẩn mở.
Bách khoa toàn thư
Vào năm 1999, Richard Stallman đã đề xuất ý tưởng về một "Bách khoa toàn thư tự do và tài nguyên học tập" như một phương tiện để bảo vệ tri thức và cung cấp quyền truy cập toàn diện vào tài liệu học tập Bách khoa toàn thư này có thể được xây dựng từ các bài báo do cộng đồng đóng góp, không có sự kiểm soát tập trung, cho phép nhiều tác nhân thực hiện các nhiệm vụ khác nhau, bao gồm việc rà soát và kiểm tra bài viết Nó không chỉ bao gồm văn bản mà còn cả đa phương tiện và phần mềm giáo dục tự do Một số sáng kiến đã được triển khai nhằm hiện thực hóa ý tưởng này, trong đó có Nupedia, mặc dù dự án này không thành công do yêu cầu định dạng phức tạp và quy trình biên soạn nghiêm ngặt.
Wikipedia, hậu bối thành công hơn nhiều của Nupedia, là một bách khoa toàn thư tự do đa ngôn ngữ dựa trên công nghệ wiki, cho phép viết và chỉnh sửa cộng tác bởi các tình nguyện viên Sự thành công của Wikipedia đến từ cấu trúc linh hoạt, giúp giảm bớt những rào cản mà Nupedia gặp phải, gần gũi hơn với ý tưởng của Stallman Từ "wiki" có nguồn gốc từ tiếng Hawaii, có nghĩa là "nhanh" Công nghệ wiki cho phép bất kỳ ai sửa đổi tài liệu một cách dễ dàng Đến tháng 02/2007, Wikipedia đã có hơn 1,500,000 bài viết bằng tiếng Anh.
Wikipedia là một dự án của tổ chức phi lợi nhuận Wikimedia, mà nó cũng có các dự án sau, dựa vào cùng mô hình như của Wikipedia:
Wiktionary là một dự án cộng tác nhằm xây dựng một từ điển tự do đa ngôn ngữ, cung cấp định nghĩa, từ nguyên học và cách phát âm cho các ngôn ngữ khác nhau theo nhu cầu.
Wikibooks là một dự án nhằm cung cấp sách giáo khoa, sổ tay hướng dẫn và tài liệu sư phạm miễn phí cho mọi người Dự án này hướng tới việc đáp ứng nhu cầu học tập và nghiên cứu của bất kỳ ai mong muốn tiếp cận các nguồn tài liệu giáo dục.
Wikiquote (http://www.wikiquote.org) là một kho tàng chứa đựng các câu thành ngữ nổi tiếng từ nhiều ngôn ngữ khác nhau, kèm theo các nguồn gốc của những câu nói này khi có thể.
Wikisource là một thư viện trực tuyến chứa các văn bản gốc thuộc miền công cộng hoặc được phát hành dưới giấy phép tài liệu tự do GNU (GFDL).
Wikispecies là một kho tài liệu phong phú về các loại động vật, thực vật, nấm, vi khuẩn và tất cả các dạng sự sống đã được biết đến Đây là nguồn thông tin hữu ích cho những ai muốn tìm hiểu về sự đa dạng sinh học trên hành tinh của chúng ta.
• Wikinews (http://wikinews.org/) [68] Đây là một nguồn của các nội dung tin tự do trong đó người sử dụng là những người soạn thảo.
• Commons (http://commons.wikimedia.org/) [19] Đây là một kho các nội dung tự do của hình ảnh và đang phương tiện tự do.
• Wikiversity (http://wikiversity.org/) [72] Đây là một nền tảng giáo dục mở và tự do, dựa trên các dự án dạy học ở tất cả các mức giáo dục
• Meta-Wiki (http://meta.wikimedia.org/) [48] Đây là website mà hỗ trợ tất cả các dự án của Quỹ Wikimedia.
Bách khoa toàn thư Ngắn gọn về Toán học có khái niệm hạn chế về tự do, chỉ có thể truy cập trên Internet Nó là một mô hình phát triển yêu cầu tất cả các đóng góp phải được đề xuất cho một ủy ban soạn thảo trước khi xuất bản.
Các khóa học
Các trường đại học ngày nay không chỉ là nơi cung cấp kiến thức mà còn đóng vai trò như những doanh nghiệp sản xuất và phân phối tài liệu học tập miễn phí, bao gồm ghi chép, slide, bài tập và phần mềm hỗ trợ giảng dạy Xu hướng này phản ánh một sự chuyển biến trong cách thức tiếp cận giáo dục, với mục tiêu làm cho tài nguyên học tập trở nên dễ tiếp cận cho tất cả mọi người Các lý do chính cho việc này bao gồm cam kết của các trường đại học trong việc thúc đẩy giáo dục mở và sự phát triển của công nghệ, cho phép họ chia sẻ kiến thức một cách rộng rãi.
• Thỏa mãn nhiệm vụ của trường, như một đại lý phân phối kiến thức.
• Giá thành thấp của các tư liệu đang tồn tại sẵn sàng trên toàn thế giới.
• Thực tế là những tư liệu này không thể thay thế việc dạy học bằng con người.
• Ý tưởng về các tư liệu này được công khai mà có thể lôi cuốn được các sinh viên và đóng góp cho uy tín của đại học.
• Khả năng tạo ra một cộng đồng các giáo viên mà họ rà soát lại và cải tiến các tư liệu này.
Sáng kiến nổi bật nhất trong lĩnh vực giáo dục mở là dự án của MIT, với mục tiêu cung cấp hơn 2,000 nguồn tài liệu được tổ chức thành các danh mục dễ dàng truy cập, nhằm tạo ra một hệ thống học tập thống nhất và mạch lạc.
Các bộ sưu tập và các cơ sở dữ liệu
Việc tổ chức và biên dịch thông tin theo các tiêu chí xác định tạo ra sản phẩm giá trị, bất chấp bản chất thông tin Sản phẩm này phản ánh công sức của các tác giả và phải tuân theo các hạn chế về quyền truy cập, sửa đổi và phân phối nội dung Do đó, để có thông tin tự do, chúng ta cũng cần hướng tới việc có các bộ sưu tập tự do.
Dự án Thư mục Mở (ODP) là một nền tảng quan trọng giúp phân loại và tổ chức thông tin trên Internet, cho phép người dùng bình luận và truy cập các liên kết Được vận hành bởi Netscape và duy trì bởi các tình nguyện viên, ODP sử dụng một kiến trúc có tôn ti trật tự để đảm bảo tính chính xác và chất lượng của thông tin.
Thư mục đầy đủ có thể được sao chép tự do dưới định dạng RDF và được xuất bản với các sửa đổi nhất định, tương tự như cách mà Google và nhiều máy tìm kiếm khác thực hiện Netscape, chủ sở hữu của thư mục này, đã đảm bảo một "hợp đồng xã hội của Dự án Thư mục Mở", điều này đã khơi nguồn cho sự phát triển của Debian Hợp đồng này tạo điều kiện cho các đóng góp bên ngoài, đảm bảo rằng Dự án Thư mục Mở sẽ luôn duy trì tính tự do, với các chính sách công cộng tự điều chỉnh bởi cộng đồng và người sử dụng là ưu tiên hàng đầu.
Các bộ sưu tập PMTD có thể thu hút sự quan tâm của chúng ta, nhờ vào việc điều chỉnh các chương trình sao cho chúng được biên dịch một cách hiệu quả, giúp chúng chạy mượt mà và dễ dàng.
Phần cứng
Có 2 khía cạnh chính có liên quan trong sự tự do về phần cứng Khía cạnh đầu tiên là nhu cầu cho các giao diện và các tập hợp lệnh sẽ là tự do, theo một cách mà mọi người có thể tạo ra được một trình điều khiển thiết bị hoặc một trình biên dịch cho một kiến trúc Khía cạnh thứ 2 là việc phải có đủ thông tin và năng lượng sẵn sàng cho việc tạo lại được một thiết kế phần cứng, việc sửa đổi nó và kết hợp nó với những thứ khác Những thiết kế này có thể được coi là phần mềm theo một ngôn ngữ phù hợp (VHDL, Verilog, …) Tuy nhiên, việc làm cho chúng làm việc được không dễ dàng, vì chúng phải được sản xuất ra, mà nó là đắt giá và chậm chạp Tuy nhiên, có những sáng kiến theo nghĩa này, trong số đó chúng ta có thể nhắc tới OpenCores (http://www.opencores.org) [52], cho các mạng tích hợp.
Văn học và nghệ thuật
Cuối cùng, khi xem xét các nguồn tự do, chúng ta không thể bỏ qua nghệ thuật và văn học, bởi mục tiêu chính của chúng không phải là lợi nhuận mà là giá trị thẩm mỹ.
Nghệ sĩ có thể trao quyền tự do cho mọi người sao chép, sửa đổi hoặc phân phối tác phẩm của họ vì nhiều lý do Đầu tiên, điều này giúp tăng cường sự nổi tiếng và phổ biến tác phẩm, từ đó tạo ra cơ hội thu nhập từ các hoạt động khác như phối hợp và tác phẩm ủy thác Thứ hai, nó khuyến khích sự thử nghiệm và sáng tạo trong nghệ thuật Trong bối cảnh này, sự đổi mới thường diễn ra từ từ và có thể khó phân biệt giữa việc ăn cắp ý tưởng và việc tạo ra tác phẩm theo xu hướng nghệ thuật hiện có.
Sự sáng tạo và làm sáng tỏ không phải là một, và chúng không giống như âm nhạc hay văn học Âm nhạc, hội họa, nhiếp ảnh và điện ảnh có thể được thực hiện ngay lập tức trên máy tính, trong khi điêu khắc không thể áp dụng theo cách tương tự Trong nghệ thuật và văn học, có rất ít sáng kiến nguồn mở, và những sáng kiến hiện có thường rất khác nhau Một ví dụ điển hình là các tiểu thuyết của tập thể Wu Ming.
Các giấy phép cho những tài nguyên tự do khác
Giấy phép tài liệu tự do GNU
Một trong những giấy phép copyleft nổi tiếng nhất cho tài liệu kỹ thuật là của FSF Richard Stallman đã nhận thức rằng tài liệu khác với chương trình, do đó ông đã phát triển một giấy phép cho các tài liệu đi kèm với chương trình và các tài liệu mang tính kỹ thuật, nhằm mục đích giáo dục Để hỗ trợ sự phát triển của các phiên bản dẫn xuất, một bản sao minh bạch của tài liệu cần được cung cấp cho bất kỳ ai cần, như được nêu trong phần 3.2.5, cùng với các bản sao mờ đục, tương ứng với mã nguồn và các đối tượng của chương trình.
Giấy phép được thiết lập nhằm bảo vệ quyền tác giả và đảm bảo rằng ý tưởng của tác giả không bị hiểu sai Do đó, các tác phẩm dẫn xuất cần có tiêu đề khác biệt so với phiên bản gốc, trừ khi quyền thể hiện đã được cấp Bản gốc phải được ghi rõ nơi có thể truy cập, đồng thời danh sách tác giả gốc và những người đã thực hiện sửa đổi cũng cần được nêu rõ Tất cả ghi chú về sở hữu trí tuệ phải được bảo lưu, cùng với việc giữ lại sự công nhận và cống hiến, cũng như tôn trọng lịch sử của tác phẩm khi có sửa đổi mới Cuối cùng, để tôn trọng giấy phép, cần chỉ định các phần không thay đổi và văn bản bao trùm mà không ai có quyền sửa đổi, ngay cả khi giấy phép chỉ cho phép các văn bản phi kỹ thuật được coi là phần bất biến.
Giấy phép này đã gây ra nhiều tranh cãi trong cộng đồng PMTD, đặc biệt là về việc liệu có nên loại bỏ các nội dung theo giấy phép này khỏi Debian hay không, hoặc chỉ định chúng là không tự do và không chính thức Mặc dù không có các phần bất biến, các công việc dẫn xuất vẫn có thể tuân theo các khái niệm của giấy phép này và có thể được bổ sung sau Có ý kiến cho rằng các phần bất biến có thể đã lỗi thời hoặc không chính xác, nhưng vẫn cần được giữ lại Quan trọng là giấy phép này không tương thích với các chỉ dẫn về PMTD của Debian, đặt ra câu hỏi liệu tài liệu có phải tuân theo những chỉ dẫn này hay không, bao gồm cả việc các văn bản giấy phép không thể được sửa đổi.
Các phiên bản đầu của văn bản này được phát hành theo giấy phép GFDL, nhưng các tác giả đã quyết định chuyển sang giấy phép Chung Sáng tạo, phù hợp hơn với đặc tính của cuốn sách Do đó, văn bản này có hai giấy phép.
Các giấy phép chung sáng tạo
Chung Sáng tạo - Creative Commons (http://creativecommons.org) là một tổ chức phi lợi nhuận được thành lập vào năm 2001 bởi các chuyên gia về sở hữu trí tuệ và pháp luật trong xã hội thông tin Mục tiêu của tổ chức là thúc đẩy sự sáng tạo, bảo tồn và tăng cường khả năng truy cập các nguồn tri thức cho cộng đồng Creative Commons dựa trên ý tưởng rằng một số cá nhân có thể không muốn sử dụng toàn bộ quyền sở hữu trí tuệ mà pháp luật trao cho họ, nhằm tạo điều kiện thuận lợi cho việc phổ biến tri thức rộng rãi hơn.
Giấy phép Chung Sáng tạo đầu tiên cho các tác phẩm sáng tạo, với nhiều phiên bản khác nhau, đã bắt đầu xuất hiện vào cuối năm 2002 Những giấy phép này được thiết kế nhằm mục đích thúc đẩy việc chia sẻ và sử dụng sáng tạo một cách hợp pháp.
• Đủ mạnh để chịu được một sự soi xét của tòa án, tại nhiều quốc gia.
• Đủ đơn giản cho những người không phải là luật sư để sử dụng.
• Đủ phức tạp để được xác định bởi các ứng dụng web khác nhau.
Các giấy phép khác nhau cho phép người sáng tạo lựa chọn những dạng tự do nào được phép, tách biệt khỏi việc sao chép, tuân theo với 4 điểm:
Trong phiên bản 1.x của các giấy phép Chung Sáng tạo, đã có 11 dạng giấy phép, mà chúng đã kết hợp
Bốn đặc tính cơ bản đã được đề cập, trong đó 98% tác giả chọn "thẩm quyền" Kết quả là, theo phiên bản 2.x của các giấy phép Chung Sáng tạo, thẩm quyền trở thành một yêu cầu bắt buộc, điều này dẫn đến việc giảm thiểu sự tự do sáng tạo.
11 dạng giấy phép xuống còn 6, là như sau:
Bảng dưới đây trình bày phác thảo các loại giấy phép cùng với các biểu tượng tương ứng, thường dẫn đến kết luận của giấy phép, được quản lý trên trang web của Creative Commons.
Bạn có thể sử dụng biểu tượng 14 chung thay vì biểu tượng đại diện cho giấy phép, nhưng cần phải liên kết với giấy phép do tác giả chọn Mã HTML cho đường liên kết này đến giấy phép có thể được lấy từ Creative Commons Khi giấy phép đã được chọn và biểu tượng tương ứng được thêm vào, tác phẩm của bạn sẽ được cấp phép.
Chứng thư chung là một tóm tắt về giấy phép, kèm theo các biểu tượng phù hợp Tóm tắt này sẽ được hiển thị khi nhấp vào liên kết từ Chung Sáng tạo (Creative Commons) [21].
Mã pháp lý là văn bản pháp lý toàn diện, cung cấp thông tin chi tiết về cơ sở pháp lý của giấy phép Tài liệu này có thể được truy cập thông qua tóm tắt đã nêu ở trên.
Mã số là mô tả RDF (Resource Description Framework), cho phép các máy tìm kiếm và ứng dụng khác nhận diện giấy phép cùng các điều khoản sử dụng.
Vào tháng 02/2007, phiên bản 3.0 của giấy phép Chung Sáng tạo đã được phát hành, sửa chữa nhiều lỗi đã được xác định Phiên bản mới không còn dựa vào mô hình của Mỹ mà chuyển sang thuật ngữ của Công ước Berne Các quyền về đạo đức và quyền quản lý xã hội được nhấn mạnh đặc biệt, phản ánh các sự thống trị khác nhau trong từng phạm vi quyền hạn Văn bản của chứng thư chung và mã pháp lý đi kèm cũng được chỉnh sửa để làm rõ rằng quyền tác giả không cho phép người được cấp phép ngụ ý hay cảm nhận rằng họ có mối quan hệ nào với người cấp phép Chung Sáng tạo cũng cung cấp nhiều dạng giấy phép khác cho các ứng dụng cụ thể.
Không phải tất cả các giấy phép Chung Sáng tạo đều được xem là tự do, vì các khu vực liên kết tới PMTD yêu cầu bốn quyền tự do cơ bản trước khi xác định giấy phép Benjamin “Kako” Hill, một lập trình viên của Debian và Ubuntu, đã thành lập trang web Freedomdefined.org với mục tiêu định nghĩa rõ ràng hơn về văn hóa tự do Trong số sáu giấy phép cơ bản của Chung Sáng tạo, chỉ có hai giấy phép thực sự được coi là tự do: Thẩm quyền (BY) và Thẩm quyền.
- Chia sẻ (BY-SA), thì cái sau của nó cũng có copyleft.
[1] Aap Project: http://www.a-a-p.org
[2] Ada Core Technologies: http://www.gnat.com/
[3] Alcôve: http://www.alcove.com
[4] Alcôve-Labs: http://www.alcove-labs.org
[5] Alioth: http://alioth.debian.org
[6] Anjuta: http://www.anjuta.org
[7] The Apache Ant Project: http://ant.apache.org
[8] Arch Revision Control System: http://www.gnu.org/software/gnu-arch/
[9] artofcode LLC: http://artofcode.com/
[10] Autoconf: http://www.gnu.org/software/autoconf
[12] Bazaar GPL Distributed Version Control Software: http://bazaar-vcs.org/
[13] Berlios The Open Source Mediator: http://berlios.de
[14] Bitkeeper Source Management: http://www.bitkeeper.com
[15] Bruce Perens: http://perens.com/OpenStandards/Definition.html
[16] Caldera: http://www.sco.com
[17] Cisco Enterprise Print System: http://ceps.sourceforge.net/
[18] Code::blocks: http://www.codeblocks.org
[19] Commons: http://commons.wikimedia.org/
[20] Concurrent Version System: http://ximbiot.com/cvs/
[21] Creative Commons http://creativecommons.org
[22] Directory of Open Access Journals: http://www.doaj.org
[23] Eclipse - An Open Development Platform: http://www.eclipse.org
[24] eCos: http://sources.redhat.com/ecos/
[25] eCos license 2.0: http://www.gnu.org/licenses/ecos-license.html
[26] First Monday Peer Rewiewed Journal on the Internet: http://firstmonday.org
[27] Free Software Foundation: http://www.fsf.org
[28] Freedom Defined (Free Cultural Works): http://freedomdefined.org/
[29] Fundación Wu Ming: http://www.wumingfoundation.com
[31] Gettext: http://www.gnu.org/software/gettext
[32] GNU Automake: http://www.gnu.org/software/automake
[33] GNU Emacs: http://www.gnu.org/software/emacs/
[34] GNU Libc: http://www.gnu.org/software/libc
[35] GNU Libtool: http://www.gnu.org/software/libtool
[36] GNU Make: http://www.gnu.org/software/make/make.html
[37] GNU Troff: http://www.gnu.org/software/groff/groff.html
[38] "Have you seen these hackers?": http://www.mozilla.org/MPL/missing.html
[39] "History of TeX": http://www.math.utah.edu/software/plot79/tex/history.html
[40] IBM Public License Version 1.0: http://opensource.org/licesenses/ibmpl.php
[41] Jam Product Information: http://www.perforce.com/jam/jam.html
[42] KDevelop: http://www.kdevelop.org
[44] The Linux Documentation Project: http://www.tldp.org
[45] LinuxCare: http://www.levanta.com
[46] Mailman, the GNU Mailing List Manager: http://www.list.org
[47] The Malone Bug Tracker: https://launchpad.net/products/malone
[48] Metawiki: http://meta.wikimedia.org/
[49] Mozilla Public License 1.1: http://www.mozilla.org/MPL/MPL-1.1.html
[50] Mozilla Tinderbox: http://www.mozilla.org/tinderbox.html
[51] NetBeans: http://www.netbeans.org
[52] Open Cores: http://www.opencores.org
[53] Open Directory Project Social Contract:
[54] Open Source Initiative: http://www.opensource.org
[55] Public Library of Science: http://www.publiclibraryofscience.org
[56] Red Hat: http://www.redhat.com
[57] Savannah: http://savannah.gnu.org and http://savannah.nongnu.org
[58] Slashdot: News for Nerds http://slashdot.org
[59] Sleepycat License: http://www.sleepycat.com/download/oslicense.html
[60] Sleepycat Software: http://www.sleepycat.com/
[61] SourceForge: Open Source Software Development Website: http://sourceforge.net
[62] Subversion: http://subversion.tigris.org
[63] Texinfo - The GNU Documentation System:
[64] Tigris.org: Open Source Software Engineering: http://tigris.org
[65] W3c Document License: http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231
[66] Wiktionary: http://www.wiktionary.org
[67] Wikibooks: http://www.wikibooks.org/
[69] Wikipedia: http://www.wikipedia.org
[70] Wikiquote: http://www.wikiquote.org
[71] Wikispecies: http://species.wikimedia.org/
[73] X Window System Release 11 License: http://www.x.org/Downloads_terms.html
[74] Ximian: http://www.novell.com/linux/ximian.html
[75] Zope Corporation: http://www.zope.com/
[76] Zope Public License 2.0: http://www.zope.org/Resources/ZPL
[77] Law on Intellectual Property Spanish Royal Legislative Decree 1/1996, of 12th April (April
[78] Affero General Public License, 2002: http://www.affero.org/oagpl.html
[79] Law on Intellectual Property Spanish Law 23/2006, of 7th July (July 2006):
[80] Flossimpact Study Technical Report, European Comission, 2007: http://flossimpact.eu
[81] ISO JTC 1/SC 34 Standard Generalised Markup Language (SGML, ISO 8879), 1986:
[82] Antoniades, I.; Samoladas, I.; Stamelos, I.; Bleris, G L "Dynamical simulation models of the open source development process" En: Koch [157]. http://wwwai.wu-wien.ac.at/~koch/oss-book/
[83] Bailey, E C (1998) Maximum RPM Taking the Red Hat package manager to the limit. http://rikers.org/rpmbook/
[84] González Barahona, J M (2000) "Software libre, monopolios y otras yerbas" Todo
Linux (3) http://sinetgy.org/~jgb/articulos/soft-libre-monopolios/
[85] González Barahona, J M (2002) "¿Qué se hace con mi dinero?" Todo Linux (17). http://sinetgy.org/~jgb/articulos/sobre-administracion/
[86] González Barahona, J M.; Robles, G Libre Software Engineering Web Site. http://libresoft.dat.escet.urjc.es/
[87] González Barahona, J M.; Robles, G (2003, mayo) "Unmounting the code god assumption" En: Proceedings of the Fourth International Conference on eXtreme Programming and Agile Processes in Software Engineering Genoa, Italy.
[88] Gonzỏlez Barahona, J M.; Robles, G.; Ortuủo Pộrez, M A.; Rodero Merino,
L.; Centeno González, J.; Matellán Olivera, V.; Castro Barbero, E M.; De las Heras
Quirós; P "Anatomy of two GNU/Linux distributions" En: Koch [157]. http://wwwai.wu-wien.ac.at/~koch/oss-book/
[89] Barnson, M P The Bugzilla guide. http://www.bugzilla.org/docs214/html/index.html
[90] Baudis, P "Cogito manual page". http://www.kernel.org/pub/software/scm/cogito/docs/
[91] Bezroukov, N (1998, diciembre) "A second look at the cathedral and the bazaar" First
Monday, 4(12). http://www.firstmonday.org/issues/issue4_12/bezroukov/index.html
[92] Bodnar, L (2003) "Linux distributions Facts and figures". http://www.distrowatch.com/stats.php?section=packagemanagement
[93] Boehm, B W (1981) Software Engineering Economics Prentice Hall.
[94] Bradner, S (1996, october) "The Internet standards process Revision 3 (rfc 2026, bcp
9)". http://www.ietf.org/rfc/rfc2026.txt
[95] Cederqvist, P.; GNU (1993) "CVS - concurrent versions system" http://www.gnu.org/ manual/cvs/index.html
[96] Collins-Sussman, B.; Fitzpatrick; B W.; Pilato, C M (2004) Version control with
Subversion O'Reilly & Associates (http://www.ora.com). http://svnbook.red-bean.com/
[98] Dachary, L (2001) "Savannah, the next generation". http://savannah.gnu.org/docs/savannah-plan.html
[99] Autonomous Government of Andalucía (2003, March) Decree 72/2003, of 18th
March, on Measures to Promote the Knowledge Society in Andalucía. http://www.andaluciajunta.es/SP/AJ/CDA/Ficheros/ArchivosPdf/DecretoConocimiento.pdf
[100] De Boor, A Pmake A tutorial http://docs.freebsd.org/44doc/psd/12.make/paper.html
[101] De Icaza, M "The story of the GNOME Project". http://primates.ximian.com/~miguel/gnome-history.html
The French Senate is hosting a forum on a proposed law aimed at promoting the use of the Internet and free software within government administration This initiative seeks to enhance digital accessibility and efficiency in public services For more information, visit the official Senate website.
[103] De las Heras Quirós, P.; González Barahona, J M (2000) "Iniciativas de las administraciones públicas en relación al software libre" Bole TIC, ASTIC magazine (14).
[104] Debian "Debian free software guidelines". http://www.debian.org/social_contract.html#guidelines
[105] Debian Debian policy manual. http://www.debian.org/doc/debian-policy/
[106] Debian "Debian social contract". http://www.debian.org/social_contract.html
[107] Schriftenreihe der KBSt (2003, July) Leitfaden für die migration von basissoftwarekomponenten auf serverund arbeitsplatzsystemen Technical report, Koordinierungsund
Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung
(KBSt). http://www.kbst.bund.de/download/mlf_v1_de.pdf
[108] DiBona, C.; Ockman, S.; Stone, M (ed.) (1999) Open sources Voices from the open source revolution O'Reilly & Associates. http://www.oreilly.com/catalog/opensource/
[109] Open Directory Project http://dmoz.org
[110] Ehrenkrantz, J R (2003, May) "Release management within open source projects".
In: Proceedings of the 3rd Workshop on Open Source Software Engineering at the 25th International Conference on Software Engineering Portland, USA
[111] European Council (1991) Council Directive 91/250/CEE of 14th May 1991, on the legal protection of computer programs. http://europa.eu.int/scadplus/leg/es/lvb/l26027.htm
[112] Feller, J.; Fitzgerald, B; Hissam, S.; Lakhani, K (ed.) (2003) Making sense of the bazaar O'Reilly.
[113] Fogel, K.; Bar, M (2001) Open source code development with CVS (2nd edition).
Paragliph Press. http://cvsbook.red-bean.com
[114] Electronic Frontier Foundation Open Audio. http://www.eff.org/IP/Open_licenses/eff_oal.html
[115] Free Software Foundation GPLv3. http://gplv3.fsf.org
[116] Free Software Foundation LGPLv3 First discussion draft. http://gplv3.fsf.org/pipermail/info-gplv3/2006-July/000008.html
[117] Free Software Foundation (1985): "The GNU Manifesto". http://www.gnu.org/philosophy/
[118] Free Software Foundation (1991, junio) GNU General Public License, version 2. http://www.fsf.org/licenses/gpl.html
[119] Free Software Foundation (1999, February) GNU Lesser General Public License, version 2.1. http://www.fsf.org/licenses/lgpl.html
[120] Free Software Foundation "Free software definition". http://www.gnu.org/philosophy/free-sw.html
[121] Free Software Foundation "Free licenses". http://www.gnu.org/licenses/license-list.html
[122] Garbee, B.; Koptein, H.; Lohner, N.; Lowe, W.; Mitchell, B.; Murdock, I.;
Schulze, M.; Small, C "A brief history of Debian" In the package: Debian-history.
[123] Germán, D (2002, May) "The evolution of GNOME" In: Proceedings of the 2nd Workshop on Open Source Software Engineering at the 24th International Conference on Software Engineering. Florida, USA
In their 2003 paper presented at the 3rd Workshop on Open Source Software Engineering during the 25th International Conference on Software Engineering in Portland, USA, Germán and Mockus explore the automation of measuring open source projects Their research highlights the significance of developing automated tools to enhance the evaluation and analysis of open source software, contributing to improved project management and quality assessment within the open source community.
I don't know!
[126] Ghosh, R A.; Glott, R.; Krieger, B.; Robles, G (2002) Free/libre and open source software: Survey and study Part iv: "Survey of developers". http://www.infonomics.nl/FLOSS/report/FLOSS_Final4.pdf
[127] Ghosh, R A.; Prakash, V V (2000, July) "The orbiten free software survey" First
Monday, 5(7). http://www.firstmonday.dk/issues/issue5_7/ghosh/index.html
[128] Godfrey, M W.; Tu, Q (2000, August) "Evolution in open source software A case study" In: Proceedings of the 2000 International Conference on Software Maintainance.
[129] González, J A (2002, March) "Carta al congresista Villanueva". http://www.gnu.org pe/mscarta.html
[130] Goosens, M.; Rahtz, S (1999) The LaTeX Web Companion Addison Wesley.
[131] Grad, B (2002, January-March) "A personal recollection: IBM's unbundling of software and services" In: IEEE Annals of the History of Computing, 24(1):64-71.
[132] Working Group on Libre Software (1999) "Free software / open source Information society opportunities for Europe?". http://eu.conecta.it/paper.pdf
[133] GrULIC "Legislation on the use of free software by the State ". http://proposicion.org.ar/doc/referencias/index.html.es
[134] Hamerly, J; Paquin, T.; Walton, S (1999) "Freeing the source The story of Mozilla". http://www.oreilly.com/catalog/opensources/book/netrev.html
[135] Hammel, M J (1991, December) "The history of xfree86" Linux Magazine. http://www.linux-mag.com/2001-12/xfree86_01.html
[136] Harris, S (2001, August) The Tao of IETF A novice's guide to the Internet engineering task force (RFC 3160, FYI 17). http://www.ietf.org/rfc/rfc3160.txt
[137] Harrison, P (2002) "The rational street performer protocol". http://www.logarithmic.net/pfh/RSPP
[138] Hasan, R "History of Linux". http://ragib.hypermart.net/linux/
[139] Hauben, M.; Hauben, R (1997) Netizens On the history and impact of Usenet and the
Internet IEEE Computer Society Press.
[140] Healy, K.; Schussman; A (2003, January) "The ecology of open source software development" http://opensource.mit.edu/papers/healyschussman.pdf
[141] Hecker, F (1998, May) "Setting up shop The business of open-source software". http://www.hecker.org/writings/setting-up-shop.html
[142] Hecker, F (1998) "Setting up shop The business of open-source software". http://www.hecker.org/writings/setting-up-shop.html
[143] Hertel, G.; Niedner, S.; Herrmann, S (2003) "Motivation of software developers in open source projects An Internet-based survey of contributors to the Linux kernel". http://opensource.mit.edu/papers/rp-hertelniednerherrmann.pdf
[144] Himanen, P (2001) The hacker ethic and the spirit of the information age Random
House. http://www.hackerethic.org
[145] Hunt, F.; Johnson, P (2002) "On the Pareto distribution of SourceForge projects.
Technical report" Centre for Technology Management, Cambridge University Engineering
Department, Mill Lane, Cambridge CB2 1RX. http://www-mmd.eng.cam.ac.uk/people/fhh10/Sourceforge/Sourceforge%20paper.pdf
[146] Open Source Initiative "History of the OSI". http://www.opensource.org/docs/history.php
[147] Hamilton, J R (US ambassador to Peru) (2002, June) "Carta al presidente del Congreso de la República". http://www.gnu.org.pe/lobbyusa-congreso.html
[148] Jones, P (2000, May) "Brook's law and open source The more the merrier?". http://www-106.ibm.com/developerworks/opensource/library/osmerrier. html?dwzone=opensource
[149] Jorgensen, N "Incremental and decentralized integration in FreeBSD" In: Feller et al.
[112] http://www.dat.ruc.dk/~nielsj/research/papers/bazaar-freebsd.pdf
[150] Brooks, F P (1975) The mythical man-month Essays on software engineering Addison-
[151] Kalt, C (2000, April) "Internet relay chat: architecture (RFC 2810)". http://www.ietf.org/rfc/rfc2810.txt
[152] Kelsey, J.; Schneier, B (1998, November) "The street performer protocol" In: Third
USENIX Workshop on Electronic Commerce Proceedings USENIX Press. http://www.counterpane.com/street_performer.html
[153] Kelsey, J.; Schneier, B (1999, June) "The street performer protocol and digital copyrights". First Monday, 4(6). http://www.firstmonday.dk/issues/issue4_6/kelsey/
[154] Kelty, C M (2001, December) "Free software/free science" First Monday, 6(12). http://firstmonday.org/issues/issue6_12/kelty/index.html
[155] Khatib, J "OpenIPCore Hardware General Public License". http://www.opencores.org/OIPC/OHGPL_17.shtml
[156] Knuth, D (1989) The TeXbook Addison Welsley.
[157] Koch, S (ed.) (2003) Free/open source software development Idea Group Inc. http://wwwai.wu-wien.ac.at/~koch/oss-book/
[158] Koch, S.; Schneider, G (2000) "Results from software engineering research into open source development projects using public data" In: Diskussionspapiere zum Tọtigkeitsfeld
Informationsverarbeitung und Informationswirtschaft, H.R Hansen und W.H Janko (Hrsg.), Nr.
[159] Kovács, G L.; Drozdik, S.; Succi, G.; Zuliani, P (2004) "Open source software for the public administration" In: Proceedings of the 6th International Workshop on Computer
Science and Information Technologies (CIST 2004) Budapest, Hungary.
[160] Krishnamurthy, S (2002, May) "Cave or community? An empirical examination of
100 mature open source projects" First Monday, 7(6). http://www.firstmonday.dk/issues/issue7_6/krishnamurthy/index.html
[161] Laffitte; Trégouet; Cabanel (1999) Proposition de loi numéro 495 Senate of the
Republic of France. http://www.senat.fr/consult/loglibre/texteloi.html
[162] Laffitte; Trégouet; Cabanel (2000) Proposition de loi numéro 117 Senate of the
Republic of France. http://www.senat.fr/consult/loglibre/texteloi.html
[163] Lamport, L (1994) LaTeX user's guide and reference manual (2nd edition) Addison
[164] Lancashire, D (2001, December) "Code, culture and cash The fading altruism of open source development" First Monday, 6(12). http://www.firstmonday.dk/issues/issue6_12/lancashire/index.html
In their 1997 paper, "Metrics and Laws of Software Evolution: The Nineties View," Lehman, Ramil, and Wernick explore the principles governing the evolution of software systems They discuss various metrics that can be used to assess software development and maintenance, emphasizing the importance of understanding software dynamics The authors highlight key laws of software evolution that have emerged from empirical studies, providing insights into the trends and challenges faced by software engineers Their findings contribute to a deeper comprehension of software metrics, which are crucial for improving software quality and productivity in the industry.
[166] Leiner, B M.; Cerf, V G.; Kahn, R E.; Clark, D D.; Kleinrock, L.; Lynch,
D C.; Postel, J.; Roberts, L G.; Wolff, S (1997) "A brief history of the Internet" In:
Communications of the ACM. http://www.isoc.org/internet/history/brief.shtml
[167] Netcraft Ltd August 2003 Web Server Survey, 2003. http://news.netcraft.com/archives/2003/08/01/august_2003_web_server_survey.html
[168] Lucovsky, M (2000) "From NT OS/2 to Windows 2000 and beyond A software-engineering odyssey". http://www.usenix.org/events/usenix-win2000/invitedtalks/lucovsky_html/>
[169] McGraw, G "Building secure software: how to avoid security problems the right way".
Cited by: David A Wheeler in http://www.dwheeler.com/sloc/
[170] McKusick, M K (1999) "Twenty years of Berkeley Unix From AT&T owned to freely redistributable" In: DiBona et al [108]. http://www.oreilly.com/catalog/opensources/
[171] SUN Microsystems (2000) "Sun microsystems announces availability of StarOffice source code on OpenOffice.org". http://www.collab.net/news/press/2000/openoffice_live.html
In a significant case study presented at the 22nd International Conference on Software Engineering (ICSE 2000), Mockus, Fielding, and Herbsleb analyzed the development of the Apache server, highlighting key insights into open source software practices This research, published by ACM Press in June 2000, provides valuable understanding of collaborative software development processes and the dynamics within the open source community.
[173] Molenaar, B "What is the context of charityware?". http://www.moolenaar.net/Charityware.html
[174] MIT OpenCourseWare. http://ocw.mit.edu
[175] Nagel, L W (1996, september) "The life of SPICE" In: 1996 Bipolar Circuits and Technology Meeting Minneapolis, MN, US http://www.icsl.ucla.edu/aagroup/Life%20of%20SPICE.html
[176] Narduzzo, A.; Rossi, A (2003, May) "Modularity in action: GNU/Linux and free/ open source software development model unleashed". http://opensource.mit.edu/papers/narduzzorossi.pdf
[177] Newman, N (1999) "The origins and future of open source software". http://www.netaction.org/opensrc/future/
[178] Nupedia. http://www.nupedia.com
[179] Villanueva Nỳủez, E (2002, April) "Letter to Microsoft Peru". http://www.gnu.org.pe/rescon.html
[180] Danish Board of Technology (2002, October) "Open-source software in e-Government, analysis and recommendations drawn up by a working group under the danish board of technology Technical report".
[181] Open Source Initiative "Open source licenses". http://www.opensource.org/licenses/index.html
[182] Pareto, W (1896) "Course of Political Economy" Lausanne.
[183] Perens, P.; The Open Source Initiative (1998) "The open source definition" http:/
/www.opensource.org/docs/definition_plain.html
[184] GNU Peru "Proyectos ley de software libre en la Administración pública del Gobierno peruano, Congreso de la República". http://www.gnu.org.pe/proleyap.html