Đóng góp nguồn mở đầu tiên của tôi là cho một thư viện mà trước đây tôi đã sử dụng (và sẽ phải chịu đựng rất nhiều nếu không có) trong một dự án được trả tiền trước đó. Trong quá trình sử dụng ban đầu, tôi đã phát hiện ra một lỗi trong mã nên tôi đã tạo một bản vá, tham gia dự án và gửi nó để xem xét.
Khoảng 8 tháng sau khi có thời gian rảnh tôi quyết định rằng tôi sẽ trả lại (và làm việc với các kỹ năng phát triển của mình) bằng cách đóng góp nhiều hơn cho dự án. Vì vậy, tôi đã nhân bản kho lưu trữ và bắt đầu làm quen với cơ sở mã. Sau một vài tuần gửi các bản sửa lỗi nhỏ cho cơ sở mã và theo dõi các yêu cầu tính năng, tôi đã chọn một yêu cầu tính năng để thêm một mô-đun khá đáng kể vào dự án.
Vì việc tạo ra nhiều bản sửa lỗi riêng lẻ khá tẻ nhạt đối với bất kỳ sự phát triển quan trọng nào, tôi đã nhân bản kho lưu trữ sang một nhánh trên git hub và bắt đầu thực hiện mã. Một vài tuần và vài nghìn dòng mã sau đó, người lãnh đạo dự án và tôi đã làm việc thông qua việc tích hợp và kiểm tra các bản sửa lỗi của tôi vào thư viện theo cách làm việc nhất quán với phần còn lại của cơ sở mã.
Đó là một quá trình vô giá mà tôi đã học được rất nhiều từ:
- Khi tôi bắt đầu, tôi không biết cách sử dụng Git, cuối cùng tôi có thể thành thạo tạo các nhánh theo dõi từ xa và hợp nhất hoặc đánh bật chúng vào nhánh chính mà không bị đổ mồ hôi.
- Tôi đã bắt đầu vào VS 2008 và cuối cùng đã chuyển sang Linux và Monodevelop để viết mã (vì VS bị chậm mã hóa và kết thúc dòng là một nỗi đau trong git). Nó chỉ ra rằng không có nhiều bạn không thể làm trong * nix mà bạn có thể làm trong * dows.
- Tôi chưa bao giờ thực sự thực hiện bất kỳ thử nghiệm đơn vị nào trước đây, Nunit là một miếng bánh để sử dụng và viết thử nghiệm đơn vị là những thứ khá cơ bản.
- Tôi đã phải học cách nuốt lưỡi và lắng nghe cũng như rèn luyện tính kiên nhẫn. Không có lý do nào để giữ vững lập trường của bạn trong một dự án nguồn mở vì mọi người tham gia đều có kiến thức (có thể hơn chính bạn) và có khả năng chấp nhận / từ chối ý tưởng của bạn dựa trên chất không phân phối. Nó cực kỳ khiêm tốn và bổ ích cùng một lúc.
- Chỉ cần có một con mắt của nhà phát triển lành nghề khác trên một cơ sở lớn mã của tôi đã chỉ ra những sai sót trong phong cách của tôi mà tôi chưa bao giờ xem xét trước đó (cũng như tôi đã chỉ ra những sai sót trong mã của anh ta). Đối với tôi, tôi đã học được rằng việc xác định các hằng số dễ dàng hơn / tốt hơn so với việc sử dụng một loạt các số ma thuật với nhận xét chi tiết.
Dự án cụ thể đó dựa trên việc tạo và giải mã các gói mạng trên tất cả các cấp giao thức mạng. Tôi có mối quan tâm cá nhân đối với mạng cấp thấp hơn nên thật tuyệt khi thảo luận với một nhà phát triển khác có chung sở thích và kiến thức trong miền.
Nếu bạn muốn chỉ bị ướt chân: hãy tìm một dự án mà bạn đã sử dụng; nhân bản kho lưu trữ; và bắt đầu xem liệu bạn có thể sửa một số lỗi và / hoặc thêm một số bài kiểm tra đơn vị. Có vẻ đáng sợ khi nhìn vào cơ sở mã hóa của người khác bằng đôi mắt mới nhưng đó là một kỹ năng cực kỳ quý giá để học hỏi. Gửi một số bản vá. Bạn có thể mong đợi mã của bạn sẽ được xem xét kỹ lưỡng lúc đầu. Đừng lo lắng về điều đó, đó là một phần bình thường của quá trình để có được sự tin tưởng của (các) quản trị viên dự án.
Sau khi thiết lập cơ sở bằng khen với (các) quản trị viên dự án bắt đầu tìm kiếm nhiều trách nhiệm hơn, như đề xuất các tính năng mới hoặc yêu cầu được chỉ định để thực hiện các yêu cầu tính năng.
Nếu bạn không thể tìm thấy một dự án đã có trên một trong các mạng kho lưu trữ nguồn mở chính (github, sourceforge, google code), hãy nghĩ đến một ứng dụng mà bạn thực sự muốn sử dụng chưa tồn tại và bắt đầu của riêng bạn.
Hãy chuẩn bị để khiêm tốn và mong muốn công việc sẽ bị từ chối để ủng hộ các sửa đổi tiếp theo. Chuyện hoang đường rằng bất kỳ ai cũng có thể thêm mã vào một dự án nguồn mở là hoàn toàn sai. Luôn có một người gác cổng giữa bạn và truy cập đẩy. Mã của bạn càng tốt, thì nó sẽ càng ít được xem xét kỹ lưỡng trong thời gian dài khi bạn có được sự tin tưởng của (các) quản trị viên dự án. Nếu đó là dự án của bạn, bạn sẽ là người gác cổng đó.
Cập nhật:
Tôi chỉ nghĩ về nó và nhận ra rằng tôi không buồn đề cập đến dự án nào mà rất nhiều câu trả lời của tôi đang tham khảo. Đối với những người muốn biết, đó là SharpPcap . Nhà phát triển chính Chris Morgan rất chuyên nghiệp và có quan điểm. Anh ấy làm một công việc quản lý dự án và dạy tôi rất nhiều về những gì nó cần để trưởng thành một dự án OSS.
Do hạn chế về thời gian cá nhân, tôi đã không thể đóng góp mã trong hơn một năm nhưng tôi vẫn cố gắng trả lại bằng cách ẩn trên Stack Overflow và thỉnh thoảng trả lời các câu hỏi về SharpPcap.