Open source không có gì đáng sợ

Về tác giả: Anna Chiara Bellini, một nữ lập trình viên với hàng chục năm kinh nghiệm lập trình, giảng viên tại trường đại học Bologna (Ý).

Đối với một developer, luôn bắt kịp xu thế công nghệ là một niềm đam mê đầy phấn khởi. Mỗi ngày, các ngôn ngữ lập trình mới, các framework và thiết bị mới đều thu hút sự chú ý của chúng ta và gắn liền với những buổi trò chuyện, những forum, chat group mà chúng ta tham gia. Tuy nhiên, cộng đồng developer chúng ta được tạo nên từ những con người chứ không phải các công cụ và sẽ hấp dẫn hơn nhiều nếu chúng ta khám phá các khía cạnh xã hội của nó.

Tại Toptal, chúng tôi có một vài cuộc đàm luận thú vị về việc phụ nữ đóng góp bao nhiêu vào mã nguồn mở và điều gì ngăn trở họ đóng góp nhiều hơn thế, và chúng tôi đã tìm hiểu vấn đề này. Là một trong những người tham gia đàm luận cùng Breanden Beneschott và Bozhidar Batsov, tôi ngạc nhiên bởi Bozhidar là một trong top người đóng góp nhiều nhất vào các mã nguồn mở trên Github (Xem danh sách thành viên tích cực của Github). Còn tôi thì sao? Nếu bạn kiểm tra tài khoản Github của tôi, phần lớn là các project nhỏ tôi sử dụng trên lớp học cho các sinh viên của mình. Đó chỉ là những project dang dở và chắc chắn là không đại diện được cho các kỹ năng và chuyên môn của tôi. Nếu người ta xem xét về việc thuê tôi dựa trên những gì họ thấy từ tài khoản github thì chắc là cuộc sống của tôi sẽ rất khó khăn. Thế nhưng trên thực tế, tôi là một lập trình viên chuyên nghiệp với hơn 20 năm kinh nghiệm, công việc hàng ngày của tôi sử dụng các phần mềm mã nguồn mở nhiều tới mức tôi không nhớ hết. Đã từng có một thời gian tôi bị hacker tấn công hệ thống Linux, chỉnh sửa tất cả các router và NAS mà tôi đã mua. Chờ đợi hàng tháng trong danh sách chờ của Raspberry Pi khiến tôi rất bực bội và phải tự mình thực hiện chỉnh sửa mọi thứ như tôi muốn. Tuy vậy, không có sự chỉnh sửa hay kiểm thử nào trong số những điều tôi đã thực hiện trên Github trở thành mã nguồn mở. Ngoại trừ một lần tôi sửa một lỗi trong một trong những phiên bản đầu tiên của Tomcat, tôi chẳng bao giờ đóng góp vào các dự án mã nguồn mở. Bạn có tò mò vì sao lại thế?

Bạn có thể nghĩ là do tôi không có thời gian hoặc không hứng thú nhưng tôi biết là không phải những lí do đó. Với những dự án cá nhân của tôi, tôi cho rằng chẳng ai thực sự quan tâm tới những gì tôi đã làm, nhưng vấn đề chủ yếu nằm ở suy nghĩ của tôi về việc công khai đề xuất ý tưởng với mọi người và những điều xảy ra sau đó, nó khiến tôi sợ hãi rất nhiều. Nếu code của tôi không đủ tốt thì sao? Nếu tôi không hiểu đúng vấn đề thì sao? Nếu pull request của tôi bị từ chối thì sao? Và nếu người ta chỉ muốn troll tôi thì sao?

Thực hiện một vài cuộc gọi cho những người bạn lập trình viên của mình, hầu hết là nữ, tôi nhận thấy mình không phải là người duy nhất gặp vấn đề như vậy, nhưng đối với một kỹ sư thì không có vấn đề mà chỉ có giải pháp, phải không nào?

Và dưới đây là một vài vấn đề quan trọng cần giải quyết bởi vì đóng góp vào một dự án mã nguồn mở có thể tạo ra những khác biệt ấn tượng:

• Trong suốt sự nghiệp của bạn: nhiều khách hàng sẽ xem xét tất cả các hoạt động mạng xã hội của bạn trước khi quyết định thuê bạn; tài khoản GitHub và hồ sơ LinkedIn nằm trong top của danh sách này, ngoài ra còn có profile của bạn trên Facebook, Twitter. Bạn nên sử dụng chúng một cách khôn ngoan.
• Đối với kỹ năng kỹ thuật của bạn: tham khảo một nền tảng mã nguồn được viết bởi các lập trình viên khác (thường là những lập trình viên giỏi) có thể dạy cho bạn nhiều điều. Khả năng xử lý một mã nguồn tệ cũng thách thức bạn và dạy cho bạn nhiều điều không kém.
• Với các kỹ năng mềm: Phần mềm mã nguồn mở là một quá trình hợp tác, hầu hết các dự án thú vị đều được thực hiện bởi một đội ngũ. Học cách làm việc với những lập trình viên khác thông qua các công cụ mà mọi người đều sử dụng để hòa nhập với đội, để giao tiếp một cách hiệu quả, đó là những điều giúp bạn trở thành một lập trình viên xuất sắc không chỉ ở mặt kỹ năng.
• Với cộng đồng: mỗi một bit bạn đóng góp vào một dự án mã nguồn mở đều được ghi nhận. Đóng góp càng nhiều càng tốt dù chỉ là sửa một lỗi chính tả trong phần dịch ngôn ngữ cũng giúp sản phẩm cuối cùng tốt hơn.
• Với mạng lưới của bạn: Bạn có thể gửi hàng trăm đơn xin việc tới các công ty nhưng không thể có tác dụng bằng việc có những kết nối cá nhân với các đồng nghiệp. Tham gia tích cực vào một dự án mã nguồn mở sẽ đảm bảo bạn có thể gặp gỡ mọi người và đạt được sự tôn trọng từ họ, nhờ đó uy tín của bạn sẽ tăng dần, đây là vốn quý vô giá đối với bất kỳ chuyên gia nào.

Đây là một phần kinh nghiệm cá nhân của tôi trong việc chống lại nỗi sợ hãi. Đăng bài viết này cũng là một phần trong đó. Tôi viết bài viết này hi vọng tất cả những ai ngại ngùng viết blog hoặc e ngại đóng góp sẽ thấy rằng cuối cùng mọi thứ không đáng sợ như họ nghĩ. Hơn nữa, kinh nghiệm này cũng có ý nghĩa trong việc giúp đỡ những người yêu thích việc đóng góp vào các dự án mã nguồn mở nhưng không biết phải bắt đầu từ đâu. Ngay bây giờ, hãy bắt đầu từ những điều cơ bản

Phần mềm mã nguồn mở là gì? Có thể tìm thấy nó ở đâu?

Phần mềm mã nguồn mở, gọi tắt là OSS, là bất kì phần mềm nào được công bố cùng mã nguồn của nó bao gồm các điều khoản cho phép bạn chỉnh sửa và phát hành lại nó. Nó có thể được phân phối ở bất cứ đâu: trên website, qua danh sách thư điện tử, … Ngữ cảnh phổ biến nhất và được chúng ta quan tâm nhất là khi cơ sở mã được duy trì trên một kho hợp tác. Ở đây chúng ta tập trung vào GitHub, tuy nhiên có một số lựa chọn khác như SourceForge hay Bitbucket. GitHub rất thân thiện, có lượng người dùng vô cùng lớn, có thể sử dụng với bất kỳ loại mã nguồn nào và với bất kỳ môi trường phát triển nào bạn dùng. Quan trọng là GitHub cũng phổ biến đối với các dự án không mở mã nguồn. Cơ hội nằm ở chỗ dự án của khách hàng tiếp theo của bạn có thể được lưu trữ ở đây, biết cách hoạt động và làm việc với GitHub cũng là một kỹ năng hữu ích.

Nếu tôi không biết lập trình thì thế nào?

Nếu bạn đang đọc bài viết này thì có vẻ bạn cũng muốn học lập trình. Bạn có thể tìm thấy nhiều khóa học tuyệt vời trên một vài trang web miễn phí và các trang web tính phí. Bạn nên chọn một ngôn ngữ lập trình để học, có thể là PHP hay JavaScript chẳng hạn.

Với kết nối Internet và một trình duyệt web, bạn đã có mọi thứ để có thể bắt đầu. Bạn có thể tham khảo thêm một số khóa học tại Coursera, Codecademy, PluralSight, …

Nếu tôi không biết Git thì sao?

Như đã nhắc tới trước đó, biết Git là một điều quan trọng, do đó bạn cần tìm hiểu về Git. Kể cả khi bạn đã đang làm việc với Git, bạn vẫn nên dành chút thời gian tìm hiểu sâu hơn về nó, không thể biết được có bao nhiêu điều bạn còn chưa biết về Git cho tới khi bạn thực sự học được những điều đó. Ví dụ như nếu bạn chưa thể tự tin giải thích ý nghĩa câu lệnh rebase, hãy học thêm về Git.

Làm cách nào để tôi chọn một dự án trên GItHub?

Có thể bạn đã từng sử dụng một vài OSS trong công việc. Chọn lựa một framework quen thuộc là một khởi đầu tốt bởi bạn đã quen thuộc với các tính năng và cách hoạt động của nó. Khi bạn đào sâu vào mã nguồn, bạn sẽ học được hiều hơn, bạn sẽ hiểu rõ hơn logic của nó. Nếu có một công nghệ hay một công cụ mà bạn đặc biệt ưa thích, hãy tìm các dự án có nhắc tới nó hoặc bản thân dự án xây dựng công cụ đó. Cuối cùng, bạn có thể kiểm tra các dự án trên GitHub Showcases và bắt đầu bằng cách chọn một chủ đề mà bạn quan tâm.

Ví dụ, tìm kiếm nhanh với “Raspberry” trên GitHub cho thấy hơn 17 nghìn kho dự án (repositories). Nhìn vào đó sẽ rất hoang mang nên bạn hãy tìm các dự án được cộng đồng đánh giá tốt và hệ thống theo dõi vấn đề tốt (issue tracking). Khi chọn lựa dự án, hãy kiểm tra các con số sau:

• Contributors (người đóng góp): đặt mục tiêu vào các dự án có trên 10 người đóng góp. Điều này đảm bảo rằng dự án đủ hấp dẫn và không chỉ là sự cố gắng một đội ngũ nhỏ. Nếu bạn mới làm quen với OSS hay không giỏi về kỹ thuật lắm, giới hạn các tìm kiếm của bạn trong các dự án có tối đa 50 người đóng góp; cộng đồng lớn hơn thì cơ sở mã nguồn cũng lớn hơn và dự án càng phức tạp.
• Commits: Chọn các dự án có ít nhất một nghìn commit và các hoạt động gần nhất diễn ra trong khoảng một tuần trở lại. Một dự án không có hoạt động nào trong khoảng một tháng hay lâu hơn đã quá cũ và bạn sẽ không nhận được hồi đáp sớm nếu đóng góp vào nó. Có các hoạt động hàng ngày là dấu hiện của một dự án được chăm chút.
• Issues: Isssue là các vấn để mở, các lỗi được thông báo hoặc các yêu cầu áp dụng tính năng mới. Các issue sẽ cho bạn một điểm khởi đầu và là một thước đo tốt về sự quan tâm tới dự án.

Tuy nhiên, hãy tìm ra ngôn ngữ chính của dự án. Dành thời gian để đọc các cuộc thảo luận để xem xét sự thân thiện và tính giáo dục trong các bình luận. Một vài dự án nổi tiếng với việc có một cộng đồng hung hãn, chắc chắn đó không phải là điểm khởi đầu tốt cho bạn.

Tôi đã chọn ScyllaDB, một dự án lưu trữ dữ liệu dạng cột vì tôi có một niềm đam mê với dữ liệu-bất kể thứ gì liên quan tới nó. Tôi chưa từng làm việc với nó nhwung tôi hi vọng có thể tìm hiểu sâu vào cơ sở mã nguồn của nó. Làm việc với nó có thể đơn giản hơn khi sử dụng các công cụ có sẵn nhưng tôi coi đây là một thử thách, một cơ hội để học một điều mới mẻ. Hơn nữa nó phù hợp với các tiêu chí tôi đã liệt kê, dự án này có 18 người đóng góp, 6500 commit (thời điểm viết bài này thì các hoạt động gần nhất diễn ra trong khoảng 23 giờ), 178 vấn để được mở và đang hoạt động.

Vậy bây giờ tôi sẽ làm gì?

Đầu tiên, sao chép (clone) một repository và cài đặt phần mềm (Git, Sourcetree, SmartGit, …) trên máy tính của bạn để lấy ý tưởng về một phần cách hoạt động của nó. Sau đó bắt đầu đọc các issue. Khi bạn cảm thấy sẵn sàng, hãy thử tạo lại issue đó trên máy tính của bạn và phân tính xem điều gì khiến phần mềm hoạt động sai.

Một cách bắt đầu khác là tìm một thứ gì đó mà bạn có thể cải tiến hay chỉnh sửa. Có thể bạn thấy một lỗi hiển thị, một font chữ không thẳng hàng chẳng hạn. Tôi đã chọn sửa một lỗi nhỏ, cụ thể là một tên biến được sử dụng sai trong tài liệu hướng dẫn của mã nguồn.

Đó có vẻ là một vấn đề rất nhỏ nhưng tài liệu sai còn tệ hơn là không có tài liệu hướng dẫn. Người dùng sẽ cài đặt ScyllaDB và làm theo các bước hướng dẫn, họ sẽ mù quáng tin vào những gì đã được viết trên tài liệu và rồi gặp phải rất nhiều sự thất vọng. Với tôi thì đây là một điều vừa khớp với năng lực của mình và sửa lỗi đó đòi hỏi tôi phải theo dõi cả quá trình và làm quen với cơ sở mã nguồn. Sửa lỗi là một điều nhàm chán nhưng lại là khởi đầu tuyệt vời để tìm cách đến với một dự án.

Tạo một phân nhánh (fork)

Điều này có thể không quan trọng nhưng ở thời điểm đó, với dự án ScyllaDB thì tôi chẳng là ai cả; sẽ rất nguy hiểm nếu cho phép tôi thực hiện các thay đổi lên mã nguồn mà không có sự giám sát. Điều mà tôi cần làm là tạo một “fork” ở tài khoản GitHub của tôi. Đây là ScyllaDB fork của tôi. Đó là sân chơi riêng của tôi và tôi có quyền làm bất cứ điều gì với mã nguồn, tôi có thể sửa các file theo ý mình. Nếu tôi muốn tạo riêng cho mình một phiên bản của ScyllaDB và tùy chỉnh nó theo mục đích công việc của riêng tôi, tôi có thể làm việc đó ở đây. Tạo một fork rất đơn giản, chỉ việc truy cập trang chủ của dự án và ấn vào nút “fork”. Không có gì phải sợ đâu.

Đến lúc sửa lỗi rồi

Bây giờ là thời điểm để kiểm thử mã nguồn này trên máy tính của bạn và tạo ra các thay đổi cần thiết. Đầu tiên, hãy chắc rằng bạn đã cài đặt Git client trên máy của bạn. Sau đó thêm SSH public key của bạn vào GitHub, hãy chắc rằng nó được nạp bởi ssh-agent của bạn. Việc lấy mã nguồn về máy của bạn rất đơn giản, chỉ cần dùng lệnh git clone và trỏ đường dẫn tới fork của bạn thay vì nhánh chính:

git clone git@github.com:acbellini/scylla.git

Bây giờ bạn nên kiểm thử dự án trên nhánh chính, như vậy bạn sẽ xây dựng code trên máy của bạn và kiểm thử nó theo cùng một cách. Hãy ghi nhớ rằng bạn sẽ phải fork bất kỳ dự án GitHub nào khác nếu dự án của bạn phụ thuộc các dự án đó. Trong trường hợp của tôi, tôi phải fork seastar, scylla-ami và scylla-swagger-ui.

Lỗi mà tôi cần sửa khá đơn giản; tài liệu hướng dẫn nằm trong conf/scylla.yaml nhắc tới 3 đường dẫn thư mục có thể cấu hình: một dành cho các file dữ liệu, một dành cho các commit log (lưu lịch sử các commit) và cuối cùng, nhìn có vẻ như không dùng tới, dành cho cache, tất cả các đường dẫn này đều được mặc định là các thư mục con của $CASSANDRA_HOME:

Xem xét kỹ hơn vào mã nguồn cho thấy các giá trị mặc định là khác nhau được nhắc tới trong issue #372 mà tôi đã chọn để bắt đầu, lẽ ra không nên sử dụng $CASSANDRA_HOME. Tôi xác nhận lại giả thuyết của mình bằng cách kiểm tra mã nguồn với một vài thiết lập khác nhau, thử bỏ một số thiết lập từ file cấu hình và kiểm tra xem các thư mục nào đang được sử dụng. Sau khi đã tin chắc rằng tất cả mọi thứ chính xác, tôi có thể add, commit và push file đã được chỉnh sửa:

git add conf/scylla.yaml

git commit –m ‘Correct default directories values in conf/scylla.yaml #372’

git push

Lưu ý : mã số của issue có một dấu # ở phía trước trong commit message, điều này giúp GitHub tự động liên kết code của tôi với issue mã tôi đánh dấu.

Một điểm quan trọng nữa cần ghi nhớ là khi tôi quan sát mã nguồn, tôi nhận thấy thư mục thứ ba, thư mục dành cho cache, thực sự không được sử dụng. Tôi thực sự muốn làm thêm một việc, loại bỏ cấu hình này hoặc thêm một chú thích rằng thiết lập này thực tế không dùng tới. Tuy nhiên việc này nằm ngoài phạm vi của issue #372, sẽ là một sai lầm nếu tôi commit thêm những thứ không liên quan này. Hãy nhớ tập trung vào nhiệm vụ chính của issue.

Vào thời điểm này mã nguồn đã được sửa và nằm trên GitHub, trên nhánh riêng của tôi. Đây chính là điểm bắt đầu của những điều đáng sợ: đề nghị đội ngũ ScyllaDB chấp nhận mã nguồn của tôi. Công việc này gọi là pull request.

Bước cuối cùng: pull request

Tôi thích cách tạo các pull request trực tiếp từ giao diện website của GitHub. Đối với tôi thì cách đó trực quan và ít gặp lỗi hơn là thực hiện từ giao diện dòng lệnh. Tất cả những gì tôi cần làm là tạo pull request bằng cách ấn nút nhỏ màu xanh bên cạnh tên nhánh của tôi:

Lưu ý: các chú thích được tự động tạo bởi GitHub. Nhánh của tôi bây giờ có thêm một commit nhưng từ khi tạo ra fork của tôi thì đã có thêm 14 commit ở kho dự án gốc, do đó tôi cần kích vào icon màu xanh ở bên trái để so sánh với dự án gốc.

May mắn thay, commit của tôi không bị xung đột với 14 commit kia do đó GitHub xác nhận tôi có thể tiếp tục. Tôi không cần thêm bất kỳ chú thích hay lời nhắn nào cho commit này. Lời nhắn cho commit rất ngắn gọn, nó cho thấy sự thay đổi mã nguồn mà tôi tạo ra liên quan tới cái gì. Khi tôi kích vào nút cuối cùng để hoàn thành yêu cầu, tôi tự hỏi sao vài ngày trước tôi lại thấy sợ như thế? Chẳng có con quái vật nào đang gầm gừ, cũng chẳng phải là lửa địa ngục đang cháy bừng bừng. Thành thật mà nói, chẳng có gì đáng sợ hết. Trong trường hợp tôi đã sai về issue mà mình chọn, vậy thì các thay đổi kia sẽ không được chấp nhận, cũng chỉ thế mà thôi.

Nếu lúc này bạn kiểm tra thông tin issue, bạn có thể thấy GitHub tự động thêm chú thích rằng có một pull request tham chiếu tới issue này. Đây chính là nhờ ký hiệu #372 mà tôi viết trong commit message. Điều này sẽ tránh cho những người khác tốn thời gian đi sửa những thứ đã được sửa.

Lưu ý cuối cùng

Sau khi thực hiện pull request, ta sẽ phải chờ cho nó được chấp nhận. Tôi sẽ nhận được thông báo khi có điều gì đó xảy ra. Khoảng thời gian chờ này có thể là vài ngày thậm chí vài tuần; sẽ có ai đó kiểm tra lại mã nguồn của tôi, kiểm thử xem nó có hoạt động như mô tả hay không, sửa lại một vài vấn đề và cuối cùng là đảm bảo các sửa đổi này không ảnh hưởng xấu tới các chức năng còn lại của toàn hệ thống. Tất cả những vấn đề ấy sẽ tốn thời gian của một người nào đó, vậy nên hãy kiên nhẫn. Cuối cùng, khi pull request của tôi được chấp nhận, ScyllaDB sẽ có thêm một người đóng góp, ít đi một vấn đề và tôi sẽ có được đóng góp đầu tiên vào OSS. Giờ là lúc bạn tự mình trải nghiệm cảm giác đó, không có gì đáng sợ đâu, cứ thử xem!

Topdev via Toptal Blog – Open Source: It’s Not That Scary!.