Apache Cocoon: một trường hợp điển hình về tính bền vững

Apache Cocoon: a case study in sustainability

By Andrew Savory, Managing Director, Luminas Ltd, Published: 17 September 2007, Reviewed: 12 March 2012

Theo: http://www.oss-watch.ac.uk/resources/cs-cocoon

Bài được đưa lên Internet ngày: 12/03/2012

Lời người dịch: Trong loạt bài này, sẽ có 7 trường hợp điển hình các dự án nguồn mở thành công và đặc biệt chứng minh được tính bền vững của nó. Một trong số đó là dự án Apache Cocoon. Cocoon hiện được sử dụng trong các tập đoàn lớn: “Hệ thống có một uy tín khá cao trên thế giới về sự phát triển web và đã và đang được triển khai trong một số kịch bản CNTT-TT của các tập đoàn doanh nghiệp”. Trong Quỹ Phần mềm Apache (ASF) thì: “Trong ASF thì sự nhấn mạnh là rất nhiều vào đóng góp cá nhân hơn là đóng góp của các công ty (hoặc những người làm việc nhân danh các công ty). Không lập trình viên nào được ASF trả tiền trực tiếp cho công việc họ làm trong các dự án dù các lập trình viên có thể, tất nhiên, được các ông chủ của riêng họ trả tiền. Các vai trò mà một cá nhân có thể đóng trong một dự án và trong ASF như một tổng thể được định nghĩa rất rõ ràng, và điều này giúp cho các cá nhân hiểu được làm thế nào, khi nào và ở đâu họ có thể thực hiện được một sự đóng góp”. Để làm tài liệu cho Cocoon và các dự án khác của ASF, tốt nhất dùng Daisy CMS: “Sự tiến hóa mới nhất của tài liệu đang được phát triển bên trong Daisy CMS, nó hỗ trợ việc xuất bản cả lên website và cũng cả ở dạng sách”.

Vào nửa cuối năm 2006, Ban Hệ thống Thông tin Chung – JISC (Joint Information Systems Committee) đã ủy quyền một nghiên cứu thông qua Ban Dạy và Học (Teaching and Learning committee) của nó để xem xét các vấn đề xung quanh tính bền vững của phần mềm nguồn mở (PMNM). Báo cáo kết quả đã đưa ra cùng với 7 trường hợp điển hình thành công nhưng của các dự án nguồn mở rất khác nhau và đã xem xét mô hình bền vững của từng dự án. Từng trường hợp điển hình đã được nói từ quan điểm của người lập trình dẫn dắt hoặc một trong những cá nhân chính và đưa ra một sự thấu hiểu gây ngạc nhiên trong các yếu tố đã xác định sự thành công của từng dự án đó. Các trường hợp điển hình đó bây giờ được OSS Watch trình bầy như là những tài liệu đứng một mình trong một loạt bài.

Trường hợp điển hình này, xem xét dự án Apache Cocoon, được Andrew Savory, Giám đốc Quản lý của công ty Luninas, viết.

Mô tả ngắn gọn

Apache Cocoon là một khung phát triển Web - một gói các thành phần phần mềm Java được liên kết với nhau mà các lập trình viên Web có thể sử dụng để giúp họ xử lý nội dung dựa trên XML cho các website. Phần mềm này được xuất bản theo Giấy phép Apache (phiên bản 2.0, có nghĩa là mã nguồn có thể được sử dụng và phân phối trong cả các phương án nguồn mở và đóng.

Cocoon hiện là phiên bản 2.11 và khi nó tiến hóa, các giải pháp phức tạp hơn đang được phát triển, bao gồm một số cài đặt cao cấp và có nhiệm vụ sống còn trong các môi trường thông tin của các tập đoàn. Nó cũng từng được sử dụng trong một số dự án do JISC cấp vốn, bao gồm một hệ thống kho PMNM cho các ảnh cho BioMed, và trong dự án Virtual Norfolk.

Giới thiệu

Cocoon là khung web dựa vào Java được xây dựng xung quanh các khái niệm chia tách các lo ngại và phát triển web dựa vào thành phần. Cocoon tạo thuận lợi cho một tiếp cận như các trò chơi Lego để xây dựng các giải pháp web bằng việc cho phép lập trình viên lắp ráp các thành phần khác nhau với việc lập trình là ít nhất. Nó cũng cho phép phát triển song song tất cả các khía cạnh của một ứng dụng web, cải thiện tốc độ phát triển và làm giảm cơ hội của các xung đột.

Cocoon là một dự án của Quỹ Phần mềm Apache (ASF), một tổ chức phi lợi nhuận được hình thành ở Mỹ, thiết lập để hỗ trợ sự phát triển phần mềm cộng tác mở bằng việc cung cấp hạ tầng phần cứng, giao tiếp và nghiệp vụ. ASF là một thực thể pháp lý độc lập theo đó các công ty và cá nhân có thể quyên góp các tài nguyên và được đảm bảo rằng các tài nguyên đó sẽ được sử dụng vì lợi ích của công chúng. Chính ASF đưa ra cấu trúc và điều hành dự án Cocoon và vai trò của quỹ đưa ra một trường hợp điển hình thú vị về việc xem xét các quan điểm về sự điều hành của các dự án nguồn mở.

Dự án Cocoon tuân thủ chặt chẽ những gì đã trở thành nổi tiếng như là 'cách của Apache', theo đó nó tuân theo các nguyên tắc chỉ dẫn đằng sau ASF và cộng đồng các lập trình viên và những người sử dụng của nó:

• cộng tác phát triển phần mềm
• giấy phép tiêu chuẩn thân thiện với thương mại
• phần mềm chất lượng có một cách nhất quán
• tương tác dựa vào kỹ thuật, sự trung thực và sự tôn trọng
• triển khai trung thực các tiêu chuẩn
• an ninh như một tính năng bắt buộc

Lịch sử của dự án

Cocoon đã bắt đầu cuộc sống vào năm 1998 như một giải pháp để quản lý website java.apache.org (bây giờ là jakarta.apache.org). Ban đầu do sinh viên người Ý là Stefano Mazzocchi viết, nó đã được thiết kế để tận dụng các tiêu chuẩn khác nhau mới nhất từng có sẵn lúc đó. Nó đã sử dụng họ các Ngôn ngữ Kiểu bảng Mở rộng – XSL (Extensible Stylesheet Language) và XML mới được phát hành như một cách để tách bạch sự trình bày khỏi nội dung, vì thế cho phép bất kỳ ai cũng sửa đổi được nội dung mà không lo về cách mà nó sẽ được hiển thị. Giải pháp ban đầu từng là đơn giản (100 dòng lệnh) Java servlet chạy dưới máy chủ web Apache mà đã biến đổi một tệp XML được đưa ra thành HTML có sử dụng bảng kiểu XSL.

Tiếp sau sự quan tâm đáng kể từ danh sách thư của dự án khác của Apache, một biểu quyết chính thức đã được thực hiện để bắt đầu dự án Cocoon và Stefano đã đóng góp mã ban đầu. Qui trình hơi không chính thống một chút này từng rất khác với Vườn ươm Apache ngày nay, nó tìm cách để định nghĩa một qui trình và sự đo đếm chính thống cho những gì tạo ra một dự án Apache phù hợp.

Tại thời điểm viết bài này, đã có 3 phiên bản của Cocoon. Minh họa 1 chỉ ra sự tiến hóa của dự án trong vòng 8 năm qua.

Minh họa 1: Các phiên bản của Cocoon

Khoảng tháng 11/1999, công việc đã bắt đầu trong Cocoon 2.0 - một thiết kế lại hoàn toàn đã học được từ những sai lầm trong thiết kế và các vấn đề kiến trúc của Cocoon 1.0. Nó đã được thiết kế vì hiệu năng và tính mở rộng phạm vi, và đã nâng việc sử dụng các công nghệ XML và XSL lên một mức mới. Với cấu hình tập trung và lưu trữ tạm (caching) phức tạp, nó đã trở nên có khả năng tạo, triển khai và duy trì các ứng dụng máy chủ XML khỏe mạnh.

Vào năm 2003, công việc trong Cocoon 2.1 đã bắt đầu, một lần nữa học được từ những sai lầm trước đó. Cocoon 2.1 đã thể hiện một sự thay đổi từng chút một hơn là một thay đổi cách mạng giữa Cocoon 1 và Cocoon 2.

Tăng trưởng và phát triển

Phương pháp tách bạch nội dung khỏi trình bày này đã trở thành ngày một phổ biến như một cách thức làm việc, và dự án đã bắt đầu lôi cuốn được nhiều lập trình viên hơn. Cocoon đã tăng trưởng trong một hệ thống xuất bản đầy đủ dựa vào XML, bây giờ nó được sử dụng trong nhiều site sản phẩm khắp thế giới. Khi Cocoon tiếp tục tiến hóa thì nó đang được sử dụng để giải quyết các vấn đề ngày càng phức tạp hơn. Hệ thống có một uy tín khá cao trên thế giới về sự phát triển web và đã và đang được triển khai trong một số kịch bản CNTT-TT của các tập đoàn doanh nghiệp, ví dụ:

• việc điều khiển truyền thông tin trong các ngân hàng Thụy Sỹ và các nhà vận hành điện thoại di động của Pháp
• việc cung cấp các cổng thông tin cho các tổ chức lớn
• việc xuất bản các webisite cho các khu vực truyền thông và công cộng
• như là khung ứng dụng cho vài hệ thống quản lý nội dung phổ biến (như Hippo CMS, Daisy, Lenya).

Cấu trúc dự án: qui trình và điều hành

Mô hình điều hành đối với dự án Cocoon là một loạt các chỉ dẫn dựa vào sự hiểu biết về những thành công và thất bại cảu các dự án trước đó của Apache trong việc quản lý các cộng đồng của chúng. Như một trong những dự án ASF lớn hơn và đứng lâu hơn, các thực tiễn tốt nhất và các mẫu xã hội được quan sát thấy từ bên trong cộng đồng Cocoon cũng đã thông tin về cấu trúc điều hành hiện hành của ASF. Vì thế, để hiểu được cách mà dự án Cocoon làm việc, cần phải nhìn vào tổ chức rộng lớn hơn mà trong đó nó hoạt động.

Minh họa 2 chỉ ra sự sắp xếp của ASF và các dự án bên trong nó. Ở mức đỉnh là Ban Giám đốc, có trách nhiệm cho việc duy trì các công việc nghiệp vụ và theo dõi pháp lý của tất cả các phần của Quỹ tuân thủ một tập hợp các nội qui. Việc báo cáo cho Ban Giám đốc là một Ban Quản lý Dự án – PMC ( Project Management Committee) cho từng dự án bên trong Quỹ. Các PMC được Ban Giám đốc thành lập có trách nhiệm quản lý một hoặc nhiều cộng đồng.

Minh họa 2: Cấu trúc Quỹ Phần mềm Apache

Chúng đưa ra sự giám sát, đảm bảo các vấn đề pháp lý được giải quyết và các thủ tục được tuân thủ, và cũng có trách nhiệm về việc không đưa vào mã hoặc việc tạo mã. PMC có một chủ tịch được chỉ định, được bầu từ bên trong cộng đồng trên cơ sở xoay vòng từng theo năm, nhưng điều này là chỉ vì những lý do pháp lý và quan liêu - sự nhấn mạnh luôn nhằm vào cộng đồng ngang hàng.

Trong ASF thì sự nhấn mạnh là rất nhiều vào đóng góp cá nhân hơn là đóng góp của các công ty (hoặc những người làm việc nhân danh các công ty). Không lập trình viên nào được ASF trả tiền trực tiếp cho công việc họ làm trong các dự án dù các lập trình viên có thể, tất nhiên, được các ông chủ của riêng họ trả tiền. Các vai trò mà một cá nhân có thể đóng trong một dự án và trong ASF như một tổng thể được định nghĩa rất rõ ràng, và điều này giúp cho các cá nhân hiểu được làm thế nào, khi nào và ở đâu họ có thể thực hiện được một sự đóng góp.

Từng cộng đồng xoay quanh một kho mã nguồn, và hoạt động như một chế độ người tài lãnh đạo - theo nghĩa đen, được giá trị điều hành. Khi một cá nhân làm việc trong cộng đồng cảm thấy giành được vị trí của họ trong cộng đồng, họ được trao sự truy cập trực tiếp tới kho mã, vì thế làm gia tăng nhóm và làm gia tăng khả năng của nhóm để phát triển mã. Các vai trò được định nghĩa trong chế độ người tài lãnh đạo được chỉ ra trong Minh họa 3 như sau:

• Người sử dụng; ai đó mà sử dụng phần mềm của ASF. Họ có thể là một người sử dụng thụ động (thường tải về và làm việc với phần mềm) hoặc một người sử dụng tích cực (đưa ra các ý kiến phản hồi thông qua những gợi ý hoặc các báo cáo lổi), và họ có thể tham gia trong cộng đồng bằng việc giúp những người sử dụng khác thông qua các danh sách thư.
• Lập trình viên: một người sử dụng mà đóng góp cho dự án ở dạng mã hoặc tài liệu. Họ tích cực đóng góp trong danh sách thư các lập trình viên, đưa ra các sửa lỗi, các gợi ý và bình luận. Các lập trình viên cũng được biết như là những người đóng góp.
• Thành viên Ban Quản lý Dự án (PMC): một lập trình viên hoặc người đệ trình (committer) được bầu chọn do sự đóng góp của họ cho sự tiến hóa của dự án và cam kết được thể hiện của họ. Họ có quyền biểu quyết về các vấn đề có liên quan tới cộng đồng và đề xuất các lập trình viên khác cho chế độ người đề xuất.
• Thành viên ASF: tương tự như với một thành viên của PMC, thành viên ASF được đề cử vì những đóng góp và sự cam kết cho ASF như một tổng thể và cơ chế thành viên là chỉ theo lời mời. Họ tham gia xuyên vài dự án, và có quyền bầu Ban Giám đốc ASF.

Minh hoạc 3: Các vai trò trong chế độ người tài lãnh đạo

Có 2 cách thức cho các quyết định được thực hiện trong cộng đồng. Vì những người đề xuất đã được thừa nhận rồi như là các lập trình viên có trách nhiệm từ những người ngang hàng của họ, sự tin cậy lẫn nhau và áp lực ngang hàng là hiện diện để đảm bảo những người đề xuất hành động có trách nhiệm và biết khi nào là phù hợp để tự bản thân họ ra các quyết định và khi nào kêu gọi một biểu quyết.

Các quyết định nhỏ thường được thực hiện với giả thiets là 'mã nói', nghĩa là việc phát triển và việc đệ trình mã chứng minh cho một khái niệm hoặc đưa ra một giải pháp thường là hiệu quả hơn so với các thảo luận bất tận.

Đối với các quyết định quan trọng hơn, như những thay đổi về kiến trúc hoặc các tính năng mới chủ chốt, các biểu quyết được yêu cầu. Việc biểu quyết được triển khai theo sự đồng thuận lười, đó là, một quyết định được bắt faauf trong danh sách thư của dự án có đầu đề [BIỂU QUYẾT], và được kéo dài ít nhất 48 giờ đồng hồ trước khi người khởi xướng tính tổng - việc không trả lời được giả thiết là sự đồng ý ngầm không nói ra. Giai đoạn 48 giờ đồng hồ được thiết kế để tính tới bản chất phát triển phân tán, và để cho phép các lập trình viên ở các múi giờ khác nhau đóng các vai trò ngang bằng như nhau.

Các biểu quyết được đưa ra hoặc bằng việc đưa ra +1 (đồng ý với đề xuất), 0 (không có ý kiến) hoặc -1 (không đồng ý với đề xuất). Bất kỳ biểu quyết không đồng ý nào cũng phải được đi kèm theo những giải thích đầy đủ, để giảm sự trà xát trong cộng đồng và khích lệ thảo luận về các giải pháp tốt hơn.

Bất kỳ ai cũng có thể biểu quyết, dù chỉ các biểu quyết của những người đề xuất được tính. Các biểu quyết không phải của những người đề xuất được xem là 'không ràng buộc', nghĩa là, các khuyến cáo hoặc biểu đạt ưu tiên giúp những người đề xuất quyết định cái gì là tốt nhất cho cộng đồng.

Ngày nay, cộng đồng Apache Cocoon có khoảng 15-20 người đề xuất thường xuyên cho kho mã nguồn, với hơn 40 người đề xuất khác chỉ ra sự quan tâm liên tục và tham gia vào trong các cuộc thảo luận. Những người đề xuất tạo thành khoảng 10% những người tích cực trong các cuộc thảo luận trong các danh sách thư. Có hơn 1.000 người đăng ký vào các danh sách thư của Cocoon, nhận được trung bình hơn 50 thông điệp mỗi ngày.

GetTogether - Cùng có nhau

Cocoon nổi tiếng trong cộng đồng Apache như một trong những nhóm các lập trình viên lớn nhất và đầy khí lực nhất. Nó là một trong rất ít các dự án của Apache có hội nghị thường niên của riêng mình, Cocoon GetTogether. Việc tập hợp này một cách không chính thức những người sử dụng, các lập trình viên và các doanh nhân điển hình là cách mà cộng đồng Cocoon làm việc: sự kiện này được chia thành 2 ngày 'hacking' (vọc kỹ thuật) và một ngày các cuộc nói chuyện chính thức hơn, các bài trình bày và các triễn lãm.

Hai ngày hacking thường cho phép bất kỳ ai có quan tâm trong Cocoon chính thức nói về kiến trúc của Cocoon, sửa các lỗi, thảo luận về các tính năng mới, và gặp những người khác có liên quan trong dự án theo cách mặt đối mặt. Ngày cho các cuộc nói chuyện chính thức dành cho phổ biến các ý tưởng lớn, thực tiễn tốt nhất và ví dụ sử dụng Cocoon trong các ngữ cảnh nghiệp vụ khác nhau.

Bất kỳ sự kiện hay cuộc gặp mặt nào mà diễn ra đều hoàn toàn tự nguyện và được cấp tiền thông qua chi phí 'lệ phí' vào dự.

Cấu trúc dự án: mô hình bền vững

Điều mấu chốt đối với mô hình bền vững của ASF, và các dự án bên dưới cái ô ASF, là nhấn mạnh vào việc giảm các nguồn lực 'duy trì' (như, tiền, năng lượng, thời gian), trong khi nhấn mạnh vào các nguồn lực 'không duy trì' (như, vui vẻ, sự tôn trọng, tình bạn, tính trực quan).

Tính bền vững đạt được bằng việc loại bỏ một số ràng buộc truyền thống lên thời gian sống của một dự án (các nguồn lực duy trì), và tập trung vào các thuộc tính mà đã chứng minh được là tốt cho khả năng sống được dài hạn của dự án. Sức khỏe tốt của cộng đồng được đảm bảo bằng việc đưa ra một môi trường trung lập cho các lập trình viên để tương tác như những đồng nghiệp ngang hàng. Điều này từng đã và đang được xem là làm việc được không chỉ với cộng động Cocoon mà còn với nhiều dự án khác của Apache.

Vì ASF là một tổ chức độc lập, phi lợi nhuận, các công ty và cá nhân có thể quyên góp các nguồn lực và được đảm bảo rằng các nguồn lực đó sẽ được sử dụng vì lợi ích của cái chung. Thiết lập này cho phép ASF hỗ trợ cho sự phát triển phầm mềm mở, cộng tác bằng việc hỗ trợ hạ tầng phần cứng, phần mềm và nghiệp vụ mà sự phát triển như vậy đòi hỏi, vì thế loại bỏ được một số ràng buộc của nguồn lực duy trì mà thường gây trở ngại cho sự phát triển của nguồn mở. Điều này có nghĩa là không lập trình viên hoặc công ty đặc biệt nào phải đóng tiền để tham gia hoặc hỗ trợ cộng đồng phát triển Cocoon, có nghĩa là không công ty nào có lý do để thể hiện 'quyền sở hữu' với dự án. Điều này, tới lượt nó, đảm bảo sự trường tồn của dự án và sự ổn định của cộng đồng.

Giống như tất cả các dự án Apache, cộng đồng Cocoon bao gồm:

• các danh sách thư cho giao tiếp không đồng bộ, là cơ bản với những người sử dụng và các lập trình viên lan truyền khắp toàn cầu
• một kho mã truy cập được công khai mà bất kỳ ai cũng có thể đọc, và rằng các lập trình viên đệ trình có thể ghi vào
• các nguồn tài liệu tiến hóa liên tục trên website, wiki và bây giờ là một hệ thống quản trị nội dung (CMS) dựa trên Cocoon.

Tài liệu gốc ban đầu đã được phát triển như các tệp XML được lưu giữ bên cạnh mã, bên trong kho mã nguồn của dự án. Điều này đã chứng minh là một rào cản cho sự đóng góp đối với nhiều người sử dụng, và vì thế wiki của dự án đã được thiết lập cho sự phát triển tài liều trước khi chuyển nó vào tài liệu cốt lõi. Sự tiến hóa mới nhất của tài liệu đang được phát triển bên trong Daisy CMS, nó hỗ trợ việc xuất bản cả lên website và cũng cả ở dạng sách.

Có vài cuốn sách có sẵn về Apache Cocoon, nổi bật nhất là Cocoon: Building XML Applications and Cocoon Development Handbook (Cocoon: Xây dựng các ứng dụng XML và Sổ tay phát triển Cocoon).

Những phản ánh và tương lai

Giống như nhiều dự án nguồn mở, Cocoon được dẫn dắt ít bằng một lộ trình cụ thể và nhiều bằng những thay đổi xảy ra như là một kết quả của những đóng góp riêng lẻ. Những năm sắp tới, được mong đợi rằng Cocoon sẽ tiếp tục tiến hóa để cung cấp cho các nhu cầu ứng dụng Web bằng việc học từ các khung của các đối thủ, kế thừa những tính năng tốt nhất của họ ở những nơi phù hợp và áp dụng các tiếp cận mới trong thiết kế ứng dụng.

Vì những đóng góp là tự nguyện, có khả năng thiết lập ngày tháng chắc chắn cho việc khi nào các phiên bản nhất định sẽ được thực hiện, mà một kế hoạch được định nghĩa lỏng lẻo cho sự phát triển cho tương lai đang tồn tại dựa vào những thảo luận trong cộng đồng, và điều này bao quanh 2 phát hành chính tiếp sau:

Cocoon 2.x: trong loạt phát hành này kho mã sẽ được tổ chức lại để cho phép đối với một hệ thống xây dựng nhiều hơn theo module, làm cho dễ dàng hơn đối với người sử dụng để đóng góp ở mức thành phần hơn là làm việc với một cấu trúc nguyên khối lớn. Phát hành này được xem như là một bước chắc chắn cho phát hành chính tiếp sau của Cocoon.

Cocoon 3: trong phiên bản này, được mong đợi rằng Cocoon sẽ hoàn toàn chuyển sang một hệ thống thành phần Java theo module, dựa xung quanh OSGi. Phiên bản này sẽ cho phép 'việc cắm nóng' các thành phần - có khả năng để lựa chọn và thay đổi chức năng trong khi Cocoon đang chạy.

Công việc cũng sẽ tiếp tục duy trì Cocoon 2.1 để đảm bảo rằng các lỗi sống còn được sửa, mà không cần bổ sung thêm chức năng chủ chốt.

Các chi tiết của dự án

Nguồn ban đầu cho thông tin về Cocoon là trên website: http://cocoon.apache.org/

Phiên bản ổn định mới nhất: Apache Cocoon 2.2

Các bản tải về: http://cocoon.apache.org/mirror.cgi

Các danh sách thư: http://cocoon.apache.org/mail-lists.html

Hiện trạng

Vì vẫn với các tác giả gốc ban đầu, Apache Cocoon tiếp tục được quản lý và phát triển bằng việc sử dụng cấu trúc được mô tả ở trên. Những tiên đoán cho tương lại của Apache Cocoon v3 dường như sẽ giữ nguyên với công việc xử lý hướng tới một hệ thống theo module một cách đầy đủ. Trong khi chờ đợi, sự phát triển các phiên bản 2.x xử lý với việc tái cấu trúc kiến trúc để cho phép một điểm vào dễ dàng hơn cho những người sử dụng mới bằng việc áp dụng một hệ thống theo module hơn.

Hoạt động trong dự án đã chậm lại đáng kể từ thời cực thịnh của nó, với nhiều yếu tố trình bày web của Cocoon được cập nhất mới nhất vào năm 2008. Tuy nhiên, sự phát triển tiếp tục bất chấp sự ra đi của một số đáng kể các lãnh đạo cộng đồng, và các dánh sách thư của nó vẫn là sống động. Vì thế có thể tranh cãi rằng Cocoon hợp thức hóa mô hình cộng đồng phát triển phần mềm như được mô tả trong tài liệu này.

In the latter half of 2006, the Joint Information Systems Committee (JISC) commissioned a study via its Teaching and Learning committee to examine the issues surrounding sustainability of open source software. The resulting report drew together seven case studies of successful but very different open source projects and examined each project’s sustainability model. Each of these case studies has been told from the point of view of the lead developer or one of the key personnel and gives a fascinating insight into the factors that have determined the success of each project. These case studies are now presented by OSS Watch as stand alone documents in a series.

This case study, examining the Apache Cocoon project, has been written by Andrew Savory, Managing Director, Luminas Ltd.

Brief description

Apache Cocoon is a Web development framework—a package of interlinked Java software components that Web developers can use to help them process XML-based content for websites. The software is published under the Apache License (version 2.0), which means that the source code can be used and distributed in both open and closed source variants.

Cocoon is currently at version 2.1.11 and as it evolves, more complex solutions are being developed including a number of high profile and mission critical installations in corporate information environments. It has also been used in a number of JISC-funded projects including an open source software repository system for images for BioMed1, and in the Virtual Norfolk2 project.

Introduction

Cocoon is a Java-based web framework built around the concepts of separation of concerns and component-based web development. Cocoon facilitates a Lego™-like approach to building web solutions by allowing the developer to assemble the various components with minimal programming. It also allows parallel development of all aspects of a web application, improving development pace and reducing the chance of conflicts.

Cocoon is a project of the Apache Software Foundation, a non-profit organisation incorporated in the USA, set up to support open collaborative software development by supplying the hardware, communication and business infrastructure. The ASF is an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the benefit of the public. It is the ASF that provides the structure and governance of the Cocoon project and the foundation’s role provides an interesting case study for considering perspectives on the governance of open source projects.

The Cocoon project closely follows what has become known as ‘the Apache way’ in that it follows the guiding principles behind the Apache Foundation and its community of developers and users:

• collaborative software development
• commercially-friendly standard licence
• consistently high quality software
• respectful, honest, technical-based interaction
• faithful implementation of standards
• security as a mandatory feature

Project history

Cocoon began life in 1998 as a solution to managing the java.apache.org website (now jakarta.apache.org). Originally written by the Italian student Stefano Mazzocchi, it was designed to take advantage of the very latest standards that were available at the time. It used the newly released Extensible Stylesheet Language family (XSL)3 and XML as a way of separating presentation from content, thus allowing anyone to edit the content without worrying about how it should be displayed. The initial solution was a simple (100 lines of code) Java servlet running under the Apache webserver that transformed a given XML file into HTML using an XSL stylesheet.

Following significant interest from another Apache project’s mailing list, a formal vote was taken to start the Cocoon project and Stefano contributed the initial code. This somewhat informal process was very different to today’s Apache Incubator4, which seeks to define a formal process and metrics for what makes a suitable Apache project.

At the time of writing there have been three releases of Cocoon. Illustration 1 shows the evolution of the project over the last eight years.

Illustration 1: Cocoon versions

Around November 1999, work began on Cocoon 2.0—a complete redesign that learned from the design mistakes and architectural issues of Cocoon 1.0. It was designed for performance and scalability, and raised the use of XML and XSL technologies to a new level. With centralised configuration and sophisticated caching, it became possible to create, deploy and maintain robust XML server applications.

In 2003, work on Cocoon 2.1 began, again learning from previous mistakes. Cocoon 2.1 represented a more incremental change rather than the revolutionary change between Cocoon 1 and Cocoon 2.

Growth and development

This method of separating the content from the presentation became increasingly popular as a way of working, and the project started to attract many more developers. Cocoon has grown into a full XML-based publishing system, which is now used in many production sites around the world. As Cocoon continues to evolve it is being used to solve increasingly complex problems. The system has a fairly high profile in the world of web development and has been implemented in a number of corporate enterprise ICT scenarios, for example:

• handling information transfer within Swiss banks and German mobile phone operators
• providing information portals for large organisations
• publishing websites for the media and public sectors
• as the application framework for several popular content management systems (e.g. Hippo CMS, Daisy, Lenya).

Project structure: process and governance

The governance model for the Cocoon project is a series of guidelines based on an understanding of the successes and failures of previous Apache projects in managing their communities. As one of the larger, longer-standing ASF projects, the best practices and social patterns observed from within the Cocoon community have also informed current ASF government structure. So, in order to understand the way the Cocoon project works, it is necessary to look at the wider organisation within which it operates.

Illustration 2 shows the layout of the Apache Software Foundation and the projects within it. At the top level is the Board of Directors, responsible for maintaining the business affairs and legal oversight of all parts of the Foundation subject to a set of bylaws5. Reporting to the Board is a Project Management Committee (PMC) for each of the projects within the foundation. The PMCs are established by the board to be responsible for the management of one or more communities. They provide oversight, ensure legal issues are addressed and procedures are followed, and are also responsible for the long-term health and development of the community as a whole. The PMC’s responsibilities do not include code or coding. The PMC has an appointed chair, elected from within the community on a yearly rotating basis, but this is for legal and bureaucratic reasons only—the emphasis is always on a community of peers.

Illustration 2: Apache Software Foundation structure

Within the ASF the emphasis is very much on individual contribution rather than the contribution of companies (or people working on behalf of companies). No developer is directly paid by the ASF for the work they do on projects although developers may, of course, be paid by their own employers. The roles that an individual may play within a project and within the ASF as a whole are very clearly defined, and this helps individuals to understand how, when and where they can make a contribution.

Each community revolves around a codebase, and operates as a meritocracy—literally, governed by merit. When an individual working within the community is felt to have earned their place in the community, they are granted direct access to the code repository, thus increasing the group and increasing the ability of the group to develop the code. The roles defined within the meritocracy are shown in Illustration 3 and are as follows:

• User: someone that makes use of ASF software. They may be a passive user (simply downloading and working with the software) or an active user (providing feedback via suggestions or bug reports), and they can participate in the community by helping other users via the mailing lists.
• Developer: a user who contributes to the project in the form of code or documentation. They actively contribute on the developer mailing list, provide fixes, suggestions and criticism. Developers are also known as contributors.
• Committer: a committer is a developer who has been recognised by the community and given write access (the ability to make updates to a project’s code) to the code repository, and who is also able to make short-term decisions for the project.
• PMC member: a developer or committer elected due to their contribution to the evolution of the project and their demonstrated commitment. They have the right to vote on community-related issues and to propose other developers for committership.
• ASF member: similar to a PMC member, the ASF member is nominated for commitment and contributions to the ASF as a whole and membership is by invitation only. They participate across several projects, and have the right to elect the ASF board.

Illustration 3: Roles within the meritocracy

There are two ways for decisions to be made within the community. Because the committers have already been recognised as responsible developers by their peers, mutual trust and peer pressure is in place to ensure committers act responsibly and know when it is appropriate to make decisions themselves and when to call a vote.

Minor decisions are usually made on the assumption that ‘code talks’, i.e. developing and committing the code to prove a concept or provide a solution is often more effective than endless discussions.

For more important decisions, such as architectural changes or major new features, votes are required. Voting is carried out by lazy consensus, that is, a discussion is started on the project mailing list titled [VOTE], and is left for at least 48 hours before the initiator sums up—a lack of response is assumed to be tacit agreement. The 48-hour period is designed to take into account the distributed nature of development, and to allow developers in different time zones to play equal roles.

Votes are cast by either providing a +1 (in favour of the proposal), a 0 (no opinion) or a -1 (against the proposal). Any negative votes must be accompanied with full explanations, to reduce friction within the community and to stimulate discussion of better solutions.

Anyone can vote, though only committer votes count. Non-committer votes are considered ‘non-binding’, i.e. recommendations or expressions of preference that help the committers decide what is best for the community.

There is no single individual identified as the ‘leader’ of the project. Early in the project’s life, Stefano Mazzocchi was recognised as a ‘benevolent dictator’ with a similar role to that of Linus Torvalds, in that he had responsibility for steering the project. This role rapidly evolved into one of ‘community catalyst’, providing oversight, advice and guidance. Over time, as the community has strengthened, the need for this role has reduced, and today Stefano is considered an emeritus member of the community6.

Today, the Apache Cocoon community is made up of roughly 15 to 20 regular committers to the code base, with over 40 other committers showing continued interest and participating in discussions. Committers make up roughly 10% of those active in discussions on the mailing lists. There are over a thousand subscribers to the Cocoon mailing lists, which receive on average more than 50 messages a day.

The GetTogether

Cocoon is well known amongst the Apache community as one of the largest and most vibrant groups of developers. It is one of very few Apache projects to have its own annual conference, the Cocoon GetTogether. This informal gathering of users, developers and business people is typical of the way the Cocoon community works: the event is split into two days of ‘hacking’ and one day of more formal talks, presentations and exhibits.

The two days of hacking typically allow anyone interested in Cocoon to informally talk about Cocoon’s architecture, to fix bugs, to discuss new features, and to meet the other people involved in the project face to face. The day of formal talks allows for the dissemination of big ideas, best practices, and examples of Cocoon usage in various business contexts.

Any events or meetings that take place are entirely voluntary and funded through ‘at-cost’ entry fees.

Project structure: sustainability model

The key to the Apache Software Foundation’s sustainability model, and to the projects underneath the ASF umbrella, is the emphasis on reducing ‘conservative’ resources (e.g. money, energy, time) whilst emphasising non-conservative resources (e.g. fun, respect, friendship, visibility)7.

Sustainability is achieved by removing some of the traditional constraints on the lifetime of a project (the conservative resources), and focusing on attributes that have proved to be good for long-term project viability. The good health of the community is guaranteed by providing a neutral environment for developers to interact as peers. This has been seen to work not just with the Cocoon community but also with many other ASF projects.

As the ASF is an independent, non-profit organisation, companies and individuals can donate resources and be assured that those resources will be used for the benefit of the public. This set-up allows the ASF to support open, collaborative software development by supplying the hardware, communication and business infrastructure that such development requires, thereby removing some of the conservative resource constraints that typically hinder open source development. This means that no particular developer or company has to pay to participate in or to support the Cocoon development community, which means that no one company has reason to express ‘ownership’ of the project. This, in turn, ensures the longevity of the project and the stability of the community.

Like all Apache projects, the Cocoon community consists of:

• mailing lists for asynchronous communication, which is essential with users and developers spread out across the globe
• a publicly-accessible code repository that anyone can read, and that committed developers can write to
• continually evolving sources of documentation on the website, the wiki and now a Cocoon-based CMS.

The original documentation was developed as XML files stored beside the code within the project’s source code repository. This proved to be a barrier to contribution for many users, and so the project wiki was established for the development of documentation prior to moving it into the core documentation. The latest evolution of the documentation is being developed within the Daisy CMS, which supports publishing both to the website and also in book form.

There are several books available about Apache Cocoon, the most prominent being Cocoon: Building XML Applications and Cocoon Development Handbook.

Reflections and future

Like many open source projects, Cocoon is driven less by a specific roadmap and more by changes that occur as a result of individual contributions. Over the coming years, it is expected that Cocoon will continue to evolve to cater for specific Web application needs by learning from competitors’ frameworks, inheriting their best features where appropriate, and adapting to new approaches in application design.

Because contributions are voluntary, it is impossible to set firm dates for when particular releases will be made, but a loosely-defined plan for future development exists based on discussions within the community, and this encompasses the next two major releases:

Cocoon 2.x: in this series of releases the code base will be re-organised to allow for a more modular system of building, making it easier for users to contribute at a component level rather than working with one large monolithic structure. This release is seen as a stepping-stone to the next major release of Cocoon.

Cocoon 3: in this release, it is expected that Cocoon will complete the move to a fully modular Java component system, based around OSGi8. This version will allow for ‘hotplugging’ of components—being able to select and change functionality whilst Cocoon is running.

Work will also continue on maintaining Cocoon 2.1 to ensure that critical bugs are fixed, but with no additional major functionality.

Project details

The primary source for Cocoon information is the website: http://cocoon.apache.org/

The latest stable release: Apache Cocoon 2.2

Downloads: http://cocoon.apache.org/mirror.cgi

The mailing lists: http://cocoon.apache.org/mail-lists.html

Current status

Since it was originally authored Apache Cocoon has continued to be managed and developed using the structure described above. The predictions for the future of Apache Cocoon V3 appear to be holding with work proceeding towards a fully modular system. In the meantime the 2.x development proceeds with restructuring the architecture to allow an easier entry point for new users by adopting a more modular system.

Activity on the project has slowed considerably since its heyday, with many elements of the Cocoon web presence updated last in 2008. However, development continues despite the departure of a significant number of community leaders, and its mailing lists are still lively. It can therefore be argued that Cocoon validates the community model of software development as described in this document.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com