Phát triển phần mềm tự do nguồn mở - Ngược lên dòng trên để về đích sớm

NHỮNG BÀI HỌC TỪ THỰC TIỄN

Cho tới bây giờ, hầu hết các công ty, tổ chức có liên quan tới việc phát triển phần mềm tự do nguồn mở (PMTDNM) tại Việt Nam đều thực hiện việc phát triển, tùy biến các PMTDNM có nguồn gốc của thế giới, dựa vào kho mã nguồn của thế giới, mà cụ thể hơn là dựa vào các kho mã nguồn PMTDNM của một cộng đồng, do một quỹ và/hoặc (các) công ty có trách nhiệm duy trì một PMTDNM cụ thể nào đó.

Trong quá trình tùy biến và/hoặc phát triển dựa vào các kho mã nguồn được nhập vào từ bên ngoài, các công ty, tổ chức phát triển các PMTDNM tại Việt Nam thường gặp phải một số khó khăn trong việc duy trì, nâng cấp và đồng bộ kho mã nguồn của riêng mình tạo ra khi tùy biến và hoặc bổ sung thêm mới (các) chức năng cho PMTDNM gốc ban đầu. Một trong những lý do cơ bản tạo ra những khó khăn đó nằm ở chỗ các công ty, tổ chức phát triển đã không đóng góp các mã nguồn tùy biến của mình trở ngược lại về dự án gốc ban đầu, tạo ra những khác biệt ngày càng lớn, ngày càng xa về tính năng và/hoặc tiêu chuẩn của PMTDNM dẫn xuất của chính công ty, tổ chức mình so với PMTDNM gốc ban đầu. Tới lượt chúng, theo thời gian, sự khác biệt này tạo ra những khó khăn cho chính các công ty, tổ chức phát triển mà trong một số trường hợp là rất khó và/hoặc không còn có khả năng để tích hợp kho mã nguồn của PMTDNM dẫn xuất của riêng công ty, tổ chức phát triển với kho mã nguồn của PMTDNM gốc ban đầu được nữa.

Một vài ví dụ điển hình cho việc này như:

• Khi bạn phát triển một trình điều khiển thiết bị cho nhân Linux mà không có đóng góp mã nguồn của bạn ngược trở lại cho dự án phát triển nhân Linux của thế giới, thì cứ mỗi lần có phiên bản nhân Linux mới phát hành thì bạn có thể phải viết lại hoàn toàn và/hoặc sửa lại nhiều đống mã nguồn mà bạn đã viết và đã chạy được tốt với phiên bản nhân cũ. Vì nhân Linux hiện nay cứ khoảng 70 ngày lại có một phiên bản nhân mới được phát hành, nên có thể chính lý do này làm nản lòng bạn khi liên tục phải viết lại và/hoặc sửa lại đống mã nguồn của trình điều khiển thiết bị mà bạn viết cho nhân Linux.
• Khi bạn phát triển một module có tính địa phương của quốc gia bạn, ví dụ như bộ gõ tiếng Việt, mà không có đóng góp mã nguồn của module đó ngược trở lại cho cộng đồng, công ty và hoặc quỹ có trách nhiệm duy trì phát tán gốc ban đầu mà bạn và cộng đồng địa phương sử dụng hàng ngày, ví dụ như Ubuntu hay Fedora chẳng hạn. Nhiều công ty, tổ chức của Việt Nam chúng ta chắc còn chưa quên khi từng phải tích hợp module bộ gõ tiếng Việt của mình mỗi khi có phiên bản mới của các phát tán như Ubuntu, Fedora được phát hành vài năm về trước.
• Khi bạn tiến hành công việc bản địa hóa cho các ứng dụng, tiện ích PMTDNM, ví dụ cụ thể như OpenOffice, LibreOffice, GNOME, KDE, Mozilla Firefox... mà không đóng góp các bản dịch đó ngược trở lại về từng dự án gốc có xuất xứ từ bên ngoài đó, thì có khả năng mỗi lần có phiên bản mới, bạn sẽ phải dịch lại từ đầu, hoặc tệ hơn nữa, là không có luôn ngôn ngữ của quốc gia bạn.
• Nói rộng ra, khi bạn tiến hành phát triển bất kỳ PMTDNM nào mà không có đóng góp trở ngược lại cho cộng đồng, chắc chắn bạn sẽ gặp khó khăn lớn cho chính sản phẩm dẫn xuất mà bạn đang dựa vào PMTDNM gốc để phát triển.

GIỚI THIỆU VỀ NGƯỢC LÊN DÒNG TRÊN

Ngược lên dòng trên là một khái niệm được sử dụng để mô tả qui trình đóng góp những sửa đổi mã nguồn trong nội bộ trở ngược lại cho một dự án nguồn mở, với mục tiêu để chúng được chấp nhận và được phân phối trong các phát hành trong tương lai của dự án. Nội dung của bài này đưa ra qui trình ngược lên dòng trên, những lợi ích cho tất cả các bên có liên quan (các công ty, các dự án, hệ sinh thái nguồn mở), và nhấn mạnh tới một số thực tiễn tốt nhất để đi theo.

Ngược lên dòng trên là một khía cạnh cơ bản của qui trình phát triển nguồn mở. Trong nguồn mở, điều này thường được sử dụng để mô tả qui trình nơi mà một cá nhân hoặc một công ty sửa đổi mã nguồn của một dự án nguồn mở cho phù hợp với một nhu cầu cụ thể, và sau đó đóng góp những sửa đổi của họ trở ngược lại cho dự án.

PMTDNM đang ngày càng được tích hợp vào trong các sản phẩm thương mại, được dẫn dắt bằng giá trị kỹ thuật, khả năng tăng tốc sự phát triển, hoặc để cải thiện thời gian đi tới thị trường. Kết quả là, nhiều công ty cũng đang tùy biến, sửa đổi PMTDNM để đáp ứng được những yêu cầu của các khách hàng. Các tổ chức phát triển mà còn chưa ôm lấy một cách đầy đủ sự tham gia tập thể của nguồn mở có thể duy trì những nhánh nội bộ riêng rẽ của những dự án đó, vì nó có thể là một cách dễ dàng để bắt đầu khi tiêu dùng PMTDNM.

Trong khi các cây phát triển trong nội bộ một cách riêng rẽ có thể là bước khởi đầu cho sự phát triển của một sản phẩm hoặc để chứng minh khái niệm, thì sự duy trì dài hạn có thể nhanh chóng trở thành đắt giá. Điều này đặc biệt đúng nếu PMTDNM sẽ được cập nhật thông qua vòng đời của sản phẩm, khi mã nguồn tùy biến sẽ cần phải được thích nghi với những thay đổi trong dự án nguồn mở dòng chính. Vì các lập trình viên trong các dự án nguồn mở có thể nhận thức được về những sửa đổi đang được thực hiện cho mã nguồn được phát hành của họ đằng sau những cánh cửa đóng, thì sẽ không có sự đảm bảo nào rằng sự phát triển thường lệ sẽ không phá vỡ các dẫn xuất nội bộ của mã nguồn đó.

Để nhận thức được đầy đủ những lợi ích của việc tiêu dùng PMTDNM, nhiều công ty đang chọn đi theo một triết lý “ngược lên dòng trên trước”. Điều này có nghĩa rằng những sửa đổi nội bộ sẽ được đánh giá để được chấp nhận đưa vào trong cây phát triển chính.

Bài viết này mô tả một qui trình điển hình cho việc ngược lên dòng trên cho mã nguồn nội bộ, trình bày những lợi ích của ngược lên dòng trên và đưa ra chỉ dẫn thực tế và những thực tiễn tốt nhất.

QUI TRÌNH NGƯỢC LÊN DÒNG TRÊN

Ngược lên dòng trên là qui trình đóng góp mã nguồn được phát triển một cách độc lập hoặc nội bộ trở ngược lại cho dự án nguồn mở gốc ban đầu, với mục tiêu làm cho nó được tích hợp vào trong cây phát triển chính của dự án nguồn mở. Trong khi từng dự án nguồn mở có tập hợp các qui trình và các tiêu chí chấp nhận của riêng mình, thì việc tuân theo qui trình chung được minh họa trong Hình 1 có thể cải thiện được khả năng rằng sự đóng góp của bạn sẽ được đánh giá hoặc có thể được chấp nhận trong một cây phát triển chính của dự án nguồn mở.

Hình 1: Qui trình điển hình cho việc xác định và ngược lên dòng trên cho mã nguồn nội bộ.

Qui trình được bắt đầu trong một tổ chức phát triển bằng việc giành được sự phê chuẩn nội bộ để đóng góp những sửa đổi trở ngược lại cho dự án bằng việc tuân thủ các chính sách và thủ tục nguồn mở của công ty. Tiếp sau, hãy xác định những sửa đổi nội bộ đang được thực hiện cho PMTDNM mà có thể được đệ trình trở ngược lại cho dự án, và xác định những sửa đổi nào là những ứng viên phù hợp cho việc ngược lên dòng trên. Khi mã nguồn tương ứng đã được xác định, hãy lên kế hoạch cho một chiến lược đệ trình, đặc biệt nếu mã nguồn là một đệ trình lớn, là phức tạp, hoặc có một tác động chủ chốt lên dự án. Mục tiêu là để tránh việc lấn át người duy trì của dự án và những người tham gia dự án với một đệ trình lớn mà là khó để hiểu, kiểm thử và/hoặc tích hợp.

Tiếp theo, hãy đảm bảo không có những phụ thuộc vào mã nguồn riêng, nội bộ. Nếu có, thì chúng phải được giải quyết trước khi có việc đệ trình mã nguồn cho dự án. Hơn nữa, hãy chắc chắn rằng những sửa đổi không tình cờ tạo ra bất kỳ rủi ro nào về an ninh hoặc phá vỡ mã nguồn khác.

Hãy chuẩn bị mã nguồn để đệ trình, đảm bảo rằng nó sử dụng kiểu dạng bản vá và lập trình của dự án, và hãy kiểm tra tính hợp lệ mà nó áp dụng một cách sạch sẽ đối với cây mã nguồn của dự án. Hãy tách bạch mã nguồn trong các phần logic nhỏ nhất có thể, như với bất kỳ sự đóng góp nguồn mở nào khác, và sau đó tuân theo qui trình đệ trình của dự án.

Sự đệ trình thường bắt đầu với một thảo luận trong danh sách thư của dự án. Hãy đề xuất các đóng góp, hỏi về những khuyến cáo, trả lời những câu hỏi, và đánh giá khả năng được chấp nhận từ những câu trả lời. Nếu sự tích hợp là phức tạp, thì hãy giao tiếp với người duy trì qua danh sách thư của dự án và hỏi tư vấn về cách xử lý. Một khi mã nguồn được chấp nhận, hãy tiếp tục duy trì nó bên trong dự án, và làm việc với những người khác để cải thiện chức năng đó.

Điều quan trọng phải nhớ rằng mỗi dự án có thể khác nhau trong cách mà mã nguồn được đệ trình, được kiểm thử và được chấp nhận. Nếu qui trình đó là không rõ ràng, hãy yêu cầu trợ giúp và giám sát các danh sách thư của dự án đối với các công ty khác đang làm thứ y hệt, và xử lý tương tự theo.

NHỮNG LỢI ÍCH CỦA NGƯỢC LÊN DÒNG TRÊN

Mã nguồn được chấp nhận ngược lên dòng trên đưa ra vài lợi ích cho dự án nguồn mở, cho các công ty đệ trình mã nguồn tới các dự án dòng trên, và cho hệ sinh thái nguồn mở nói chung.

Dưới đây là một danh sách các ưu điểm của việc ngược lên dòng trên.

1. Ít mã nguồn hơn phải duy trì trong nội bộ. Một khi mã nguồn trong nội bộ trở thành một phần của cây mã nguồn chính, thì nỗ lực cần thiết để duy trì mã nguồn còn lại có thể thấp đi đáng kể, vì kho mã nguồn nội bộ là nhỏ hơn. Hơn nữa, mã nguồn đã được ngược lên dòng trên sẽ tiến hóa với dự án, làm giảm đi khối lượng các nỗ lực được yêu cầu nhằm duy trì một cây phát triển song song.

2. Nhiều người đóng góp hơn. Khi mã nguồn được chấp nhận ngược lên dòng trên, thì nó trở thành một phần nhìn thấy được của dự án. Điều này cho phép những lập trình viên khác đóng góp cho nó, đệ trình những tính năng mới, mở rộng chức năng hiện có và kiểm thử nó.

3. Chất lượng mã nguồn tăng qua sự rà soát lại ngang hàng. Mã nguồn được đệ trình cho một dự án nguồn mở thường nhận được sự rà soát lại ngang hàng đáng kể như một phần của qui trình đệ trình thông thường. Điều này có được trong một chu trình đóng góp ý kiến phản hồi dẫn tới sự cải thiện của mã nguồn, và cuối cùng mã nguồn chất lượng cao hơn sẽ được sử dụng trong các sản phẩm thương mại.

4. Tích hợp và kiểm thử nhanh hơn. Việc ngược lên dòng trên làm đơn giản hóa và tăng tốc cho qui tình tích hợp PMTDNM hoặc các cập nhật mới. Khi việc duy trì một cây phát triển riêng rẽ (Hình 2), thì chu trình tích hợp có thể bị chậm vì sự tích hợp, kiểm thử và gỡ rối các lỗi không được dự kiến trước đòi hỏi phải duy trì mã nguồn trong nội bộ. Nếu những thay đổi trong dự án ngược lên dòng trên đã đứt đoạn với mã nguồn trong nội bộ, thì trách nhiệm của các lập trình viên trong nội bộ phải sửa và kiểm tra bất kỳ sự đứt đoạn nào trước khi sản phẩm đó có thể được xuất ra ngoài. Vì mã nguồn ngược lên dòng trên đã trở nên nhìn thấy được đối với phần còn lại của dự án, nên khả năng của những đứt đoạn không được dự kiến trước đó sẽ giảm.

Hình 2: Xem ở mức cao đối với một qui trình phát triển điển hình: Sự thích nghi trong nội bộ của mã nguồn riêng có thể dẫn tới các chu trình phát triển dài hơn.

Ngược lên dòng trên có thể giúp tránh được những đứt đoạn đó trong mã nguồn, vì những tính năng ngược lên dòng trên sẽ được kiểm thử trong dự án dòng chính, và bất kỳ vấn đề nào cũng sẽ được thấy và được sửa trước khi có một phát hành dự án. Hơn nữa, chỉ một lượng mã nguồn nhỏ hơn sẽ cần thiết phải được duy trì trong nội bộ, làm giảm lượng mã nguồn tùy biến được duy trì một cách tách biệt có thể làm nhẹ bớt đáng kể những nỗ lực tái tích hợp.

Hình 3: Qui trình phát triển tương tự với việc ngược lên dòng trên để làm giảm sự thích nghi trong nội bộ, làm cho các chu trình phát triển ngắn hơn và thời gian đưa ra thị trường nhanh hơn.

5. Tác động tới đường lối của dự án. Đối với các công ty dựa vào PMTDNM để xây dựng một sản phẩm, mã nguồn ngược lên dòng trên là một cách thức hiệu quả để đưa ra sự lãnh đạo kỹ thuật bên trong một dự án, khi nó có thể chỉ dẫn đường lối của dự án và đảm bảo giữ gìn được sự bền vững. Sự tương tác với những người tham gia dự án ở bên ngoài cũng có thể làm tăng khả năng những người khác sẽ nhận thức được về các nhu cầu của công ty, và họ có thể có khả năng hơn để giúp triển khai những tính năng và chức năng mới nếu họ có quan tâm tới chúng.

6. Giảm các chi phí đạt được sự tuân thủ. Sự tuân thủ giấy phép là một khía cạnh sống còn của bất kỳ chiến lược tiêu dùng nguồn mở nào. Việc ngược lên dòng trên làm giảm lượng mã nguồn nội bộ phải được theo dõi một cách độc lập từ dự án nguồn mở cha.

Để có thêm thông tin về sự tuân thủ, xin hãy tới thăm Chương trình Tuân thủ Mở của Quỹ Linux tại: http://www.linuxfoundation.org/programs/legal/compliance. Chương trình này đưa ra một số nguồn tài nguyên để giúp các công ty đạt được sự tuân thủ một cách có hiệu quả.

7. Giảm các rủi ro của chuỗi cung ứng. Những đóng góp ngược lên dòng trên còn làm được nhiều hơn là giảm những nỗ lực phát triển và tích hợp và các chi phí cho người đệ trình. Chúng còn có thể là biện pháp có hiệu quả để đảm bảo sự ổn định trong một chuỗi cung ứng nguồn mở của công ty.

Việc kết hợp phần mềm ở bên ngoài trong một sản phẩm đòi hỏi một sự tập trung thận trọng về tính ổn định của chuỗi cung ứng phần mềm. Những đóng góp ngược lên dòng trên có thể bù đắp cho những rủi ro từ đường hướng hoặc tính bền vững của dự án, vì những đóng góp mã nguồn có thể đưa ra một ảnh hưởng tích cực trong đường hướng của dự án. Bằng việc đưa ra chỉ dẫn thông qua những đệ trình mã nguồn, một công ty có thể đảm bảo rằng những phiên bản trong tương lai của PMTDNM sẽ tiếp tục cung cấp được giá trị cho qui trình phát triển của họ.

8. Tăng cường cho dự án. Những đóng góp ngược lên dòng trên giúp đưa ra sự ổn định cho dự án nguồn mở vì chúng là một dấu hiệu rõ ràng rằng dự án là hữu dụng và quan trọng. Sự hỗ trợ mạnh mẽ từ các công ty đóng góp có xu hướng thu hút được những người tham gia khác, làm gia tăng tiếp tục tính bền lâu của dự án.

NHỮNG THỰC TIỄN TỐT NHẤT CỦA NGƯỢC LÊN DÒNG TRÊN

Có nhiều cách thức để đóng góp cho những thay đổi ngược lên dòng trên cho một dự án nguồn mở. Điều sau đây được khuyến cáo như là những điểm khởi đầu:

1. Thiết kế và triển khai mã nguồn với ngược lên dòng trên trong đầu

Không phải tất cả những sửa đổi là phù hợp cho sự đóng góp trở ngược lại cho một dự án. Ví dụ, mã nguồn với những phụ thuộc sở hữu độc quyền sẽ không thể được giải quyết một cách tự do, mã nguồn với những vấn đề về an ninh hoặc tính ổn định, hoặc mã nguồn mà không được xây dựng trong các công cụ nguồn mở tiêu chuẩn tất cả có thể sẽ là có vấn đề khi đệ trình.

Những cải tiến chức năng cải thiện mã nguồn gốc ban đầu để làm cho nó ổn định hơn, hiệu năng tốt hơn, hoặc mềm dẻo hơn có xu hướng sẽ là những ứng viên tốt hơn. Chúng có thể thường được đóng góp mà không có việc gây rủi ro cho các nguồn của các ưu điểm cạnh tranh, và có thể sẽ có được sự cuốn hút rộng rãi hơn vượt ra ngoài các lập trình viên của riêng một công ty. Điều này là lý tưởng cho dự án, khi nó không chỉ cải thiện được tập hợp các tính năng, mà còn cho người đệ trình, khi mà nó làm gia tăng khả năng những người khác sẽ giúp duy trì mã nguồn được đóng góp đó.

2. Đảm bảo sự đóng góp là hữu dụng đối với những người khác. Những người duy trì của dự án thường nhìn vào số lượng những người sử dụng cho một tính năng được đóng góp. Mã nguồn mà cải thiện được chức năng của dự án đối với một số lượng rộng lớn những người sử dụng thường được ưu tiên hơn mã nguồn với khả năng áp dụng bị hạn chế.

3. Hãy luôn tham gia trong sự phát triển ngược lên dòng trên. Việc duy trì mã nguồn ngược lên dòng trên chỉ giống như việc duy trì bất kỳ sự đệ trình nào khác cho một dự án nguồn mở. Trong khi những người khác có thể đóng góp những thay đổi và những sửa lỗi, thì họ không có trách nhiệm phải làm thế. Hãy lên kế hoạch để giữ các nhân viên đã tham gia vào sự phát triển mở, đặc biệt trong quá trình chuyển tiếp ngược lên dòng trên. Có thể mất thời gian để xây dựng một đơn vị những người đóng góp từ bên ngoài.

4. Cung cấp tài liệu. Hãy lập tài liệu cho mã nguồn một cách bao quát, và đưa ra những trường hợp điển hình và các chứng minh khái niệm, đặc biệt nếu tính năng mới là phức tạp. Nếu mục tiêu là để tuyển mộ các lập trình viên từ bên ngoài để bù đắp sau này cho các chi phí phát triển trong nội bộ, hãy làm cho nó dễ dàng đối với họ để hiểu được cách mà tính năng đó được sử dụng.

5. Ngược lên dòng trên vì những lý do đúng đắn. Việc ngược lên dòng trên không phải là một chiến lược từ bỏ mã nguồn, trừ phi công ty đã được cam kết rồi với một cộng đồng ở bên ngoài có thiện chí để duy trì nó. Mã nguồn không được duy trì thường bị loại bỏ khỏi một dự án khi nó trở nên rõ ràng không có ai có thiện chí sửa các vấn đề.

6. Lắng nghe các ý kiến phản hồi, và hành động dựa vào đó

Khi đệ trình mã nguồn nội bộ ngược lên dòng trên, điều quan trọng phải có trách nhiệm đối với những ý kiến phản hồi và những câu hỏi, khi những lập trình viên và những người duy trì khác có thể không quen thuộc với những động lực tiến hành những thay đổi đó. Hãy sẵn sàng chuẩn bị và trả lời những câu hỏi, và giải thích cơ sở của tính năng đó.

Những ý kiến phản hồi ngay thẳng bộc trực và sự rà soát lại ngang hàng là nền tảng cho mô hình phát triển nguồn mở. Nếu một người duy trì yêu cầu những thay đổi đối với sự đệ trình để làm cho nó tương thích được hơn với dự án cha, hãy đánh giá và triển khai ý kiến phản hồi đó. Đi theo sự dẫn dắt của người duy trì của dự án có thể đòi hỏi những sửa đổi cho sự đệ trình, nhưng sẽ làm gia tăng khả năng những người khác tham gia dự án sẽ giúp duy trì mã nguồn trong tương lai.

7. Tuân theo kiểu lập trình phù hợp. Nhiều dự án có những chỉ dẫn tiêu chuẩn cho cách mà mã nguồn sẽ được định dạng và được đệ trình. Một số dự án cũng có chỉ dẫn rất cụ thể về cách mà mã nguồn nên được cấu trúc. Điều quan trọng phải đảm bảo rằng những đóng góp ngược lên dòng trên khớp được với những chỉ dẫn đó, vì sự không tôn trọng có thể dẫn tới một sự từ chối từ người duy trì của dự án.

8. Tuân theo các qui trình được thiết lập của dự án. Hầu hết các dự án nguồn mở đã chi tiết hóa những chỉ dẫn cho việc đệ trình các bản vá và qui trình rà soát lại. Những qui trình này thường được thực hiện một cách nghiêm túc, và những đệ trình cho dự án phải tuân theo chúng sát sao. Chủ đề này được đề cập tới chi tiết hơn trong một xuất bản phẩm khác của Quỹ Linux, “Hiểu biết về mô hình phát triển nguồn mở”.

Kết luận

Bài viết này đã trình bày khái niệm về ngược lên dòng trên, một khía cạnh cơ bản của qui trình phát triển nguồn mở. Việc ngược lên dòng trên là qui trình của việc đệ trình những sửa đổi trong nội bộ đối với PMTDNM ngược trở lại cho dự án để đưa vào trong cây phát triển chính. Qui trình này có thể giảm được đáng kể các chi phí bằng việc giảm thiểu mã nguồn được duy trì trong nội bộ. Bằng việc tuân thủ các thực tiễn tốt nhất và làm việc bên trong các qui trình của dự án, việc ngược lên dòng trên có thể làm cho các chi phí duy trì thấp hơn, sự phát triển các tính năng nhanh hơn và các sản phẩm tốt hơn.

Cùng trong loại bài này, chúng ta đã đi qua các bài: (1) Tìm hiểu mô hình phát triển phần mềm tự do nguồn mở; (2) Vòng đời tính năng và những đặc tính của mô hình phát triển nguồn mở; kỳ sau chúng ta sẽ đề cập tới việc thiết lập chiến lược phần mềm nguồn mở để có thể từng bước áp dụng được mô hình phát triển của nó vào trong công việc hàng ngày của công ty và/hoặc tổ chức.

Trần Lê

Bài đăng trên tạp chí Tin học & Đời sống số tháng 05/2012, trang 64-68.