Làm thế nào tôi có thể tìm thấy một dự án nguồn mở tốt để tham gia? [đóng cửa]


152

Tôi mới bắt đầu làm việc một năm trước và tôi muốn tham gia một dự án nguồn mở vì những lý do tương tự như bất kỳ ai khác: giúp tạo ra thứ gì đó hữu ích và phát triển các kỹ năng của tôi hơn nữa.

Vấn đề của tôi là, tôi không biết làm thế nào để tìm một dự án mà tôi sẽ phù hợp.

Làm thế nào tôi có thể tìm thấy một dự án thân thiện với người mới bắt đầu? Những thuộc tính nào tôi nên tìm kiếm? Các dấu hiệu cảnh báo rằng một dự án có thể không phù hợp là gì? Có công cụ nào ngoài đó để giúp khớp mọi người với các dự án nguồn mở không?

Có một câu hỏi tương tự ở đây , nhưng câu hỏi đó liên quan đến việc làm và chỉ giới hạn ở PHP / Drupal.


9
Thật tuyệt, tôi vừa xem ArsTechnica và thấy câu hỏi này là một bài báo. Đây là liên kết. arstechnica.com/business/guides/2012/03/ cường
Evan Plaice

Câu trả lời:


111

Đó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.


bạn có thể đề nghị một số trang web phổ biến về vấn đề này?
Aditya P

2
@AdityaGameProgrammer Tôi muốn nhấn mạnh hơn vào việc tìm kiếm một dự án cụ thể không phải là trang web lưu trữ nguồn mở. Các trang web lưu trữ chỉ là nơi bán phá giá cho các dự án nguồn mở và một số dự án sẽ chuyển sang các trang khác nhau nếu có thể tìm thấy các tính năng tốt hơn (nghĩa là giấy phép cụ thể được hỗ trợ, hỗ trợ kiểm soát phiên bản tốt hơn, trình theo dõi lỗi tốt hơn, v.v.). Tôi đã đặt tên cho một vài. IMHO, github, mã google và sourceforge là phổ biến nhất. Launchpad (sử dụng kiểm soát phiên bản bazaar) là nơi bạn sẽ tìm thấy hầu hết sự phát triển của Ububtu / linux.
Evan Plaice

2
@AdityaGameProgrammer (cont) Github, sourceforge và google code đều là những khối lượng lớn của các dự án. Bởi vì sourceforge đã tồn tại lâu hơn nên có thể bạn sẽ tìm thấy nhiều dự án chết / mồ côi hơn. Việc tìm một dự án để tham gia sẽ dễ dàng hơn rất nhiều nếu bạn dành chút thời gian để xem xét những gì bạn quan tâm đầu tiên. Ngoại lệ là, nếu bạn đang muốn lưu trữ dự án của riêng bạn. Sau đó, dành một chút thời gian để mua sắm xung quanh cho các tính năng phù hợp nhất với quy trình phát triển thông thường của bạn.
Evan Plaice

Cảm ơn. Những nỗ lực trước đây của tôi trong việc tìm kiếm một người trên sourceforge dẫn tôi đến một số lượng lớn các dự án chết / mồ côi.
Aditya P

28

Dưới đây là những gì tôi đề nghị làm để tìm thấy kết hợp hoàn hảo của bạn:

  1. Nếu bạn có một dự án nguồn mở mà bạn đã sử dụng, biết và quan tâm, thì đó nên là ứng cử viên đầu tiên của bạn để thử. Nếu không hãy nghĩ về những gì bạn muốn làm nói chung và tìm kiếm một dự án trong lĩnh vực này.

  2. Khi bạn đã tìm thấy một dự án tiềm năng, đừng vội vã vào nó. Hãy cố gắng sử dụng nó cho mình. Là nó tốt trong hành động như nó có vẻ từ mô tả và đánh giá? Nếu không, nó không phải là một trình dừng hoàn chỉnh; có lẽ đó là một cơ hội để bạn nhảy vào và thực sự tạo ra sự khác biệt. Sau tất cả, không ai cần một nhà phát triển khác cho một sản phẩm hoàn hảo. Nhưng nó sẽ cung cấp cho bạn một cái nhìn sâu sắc quan trọng cho dù bạn muốn tham gia dự án này, trong khi bạn có được trải nghiệm đầu tiên với công nghệ mới trong lĩnh vực mà bạn quan tâm.

  3. Ngoài ra trước khi bắt đầu đầu tư quá nhiều thời gian vào dự án và tìm hiểu về nó, hãy cân nhắc quanh quẩn trong danh sách gửi thư của dự án, diễn đàn, thậm chí hệ thống theo dõi lỗi trong vài tuần. Nếu bạn sẽ bắt đầu đóng góp cho dự án một cách thường xuyên, bạn sẽ dành nhiều thời gian ở đó.

Hình ra: bạn có thích treo xung quanh đó không, hay nó là một vật cản cho bạn? Có cảm giác như dự án này có một cộng đồng tốt và tràn đầy năng lượng hay nó đang dần chết đi? Những người cốt lõi ở đó dường như khuyến khích và cố vấn những người mới đến hoặc bạn sẽ tự mình làm?

Thực hiện các bước này cho một số dự án, có khả năng trong các lĩnh vực khác nhau và bạn sẽ ít gặp phải sự thất vọng xảy ra khi bạn tham gia vào một nhóm sai. Một trải nghiệm như vậy có khả năng ngăn cản bạn làm lại trong tương lai.

Một vài suy nghĩ nữa:

Nếu dự án mà bạn thực sự quan tâm là một dự án cao cấp với rất nhiều nhà phát triển và hoạt động xung quanh nó, có lẽ bạn sẽ khó có được một danh tiếng đủ để có được, nói, cam kết quyền hoặc vai trò thú vị trong cộng đồng. Trong trường hợp này, hãy xem xét tham gia một dự án spin-off liên quan với tầm nhìn thấp hơn. Ví dụ, thay vì cố gắng bắt đầu đóng góp cho jQuery, hãy thử tìm plugin jQuery phù hợp với bạn. Sau đó, bạn có thể xem xét "di chuyển lên".

Nếu bạn thích một dự án nhưng cảm thấy bị đe dọa bởi quy mô, độ phức tạp hoặc yêu cầu chất lượng mã của nó, hãy xem xét bắt đầu từ các vai trò hỗ trợ, như kiểm tra, bảo trì tài liệu hoặc xác minh báo cáo lỗi. Nếu bạn hỏi trong danh sách gửi thư dự án, loại trợ giúp nào họ cần nhất vào lúc này, họ sẽ rất vui lòng hướng dẫn bạn đến đó. :)

Bằng cách này, bạn sẽ học được dự án và xây dựng danh tiếng của mình ở đó đồng thời đóng góp nhiều hơn cho nó so với khi bạn bắt đầu gửi các bản vá dưới tiêu chuẩn sẽ bị từ chối nhiều lần cho đến khi chúng sẵn sàng.

Điều cuối cùng và quan trọng nhất: nếu bạn bị bỏng ở một nơi, hãy tiếp tục; đừng bỏ cuộc

Mong rằng sẽ giúp.


2
+1 cho "xem xét bắt đầu từ vai trò hỗ trợ." Viết bài kiểm tra thực sự dễ dàng và xem xét kỹ các bài kiểm tra cho một ý tưởng tốt về những gì mã đang cố gắng thực hiện. Tài liệu là một cách tốt để có được sự hiểu biết về 'bức tranh lớn hơn' và việc xác minh các lỗi là một điểm tốt để ngăn chặn băng vào. Làm việc trên những thứ mà các nhà phát triển thường bỏ qua chứng tỏ rằng trọng tâm của bạn là cải thiện dự án và những đóng góp của bạn không chỉ dựa vào bản ngã. Các vấn đề bản ngã có thể làm cho cuộc sống của những người duy trì dự án trở nên khó khăn vì vậy họ coi chừng những điều đó.
Evan Plaice

9

Tôi thực sự khuyên bạn nên tìm một dự án nguồn mở có sự quan tâm chân thành của bạn và bạn tích cực sử dụng .

Lý do rất đơn giản: Nó tạo ra sự khác biệt giữa việc vặt và sở thích.

Có một cái nhìn vào máy tính của bạn. Phần mềm nào bạn đã đặt trên đó là Nguồn mở? Một dự đoán sẽ là Chrome hoặc Firefox, hoặc có thể là Open Office hoặc ứng dụng khách Instant Messenger. Chúng có hoàn hảo không hay chỉ có một vài thứ nhỏ bé mà bạn muốn thay đổi nếu có thể?

Nếu có, thì bây giờ là lúc để làm một cái gì đó về nó.


8

Tôi sẽ đề nghị tìm (hoặc bắt đầu) một dự án giống như mọi người đã làm trong nhiều năm, bắt đầu sử dụng phần mềm Nguồn mở để thực hiện. Điều đó có vẻ tầm thường với bạn, thậm chí có thể đơn giản hóa hơn. Tuy nhiên, thật khó để mô tả sự hài lòng của việc sử dụng một cái gì đó, tìm một lỗi, lấy nguồn và sửa nó. Hoặc, có lẽ thay đổi nó để nó hoạt động theo cách bạn muốn nó hoạt động.

Ngoài ra, đừng chỉ hack vì mục đích 'tham gia'. 95% các bản vá của tôi đối với nhân Linux sẽ không bao giờ nhìn thấy ánh sáng, tôi biết chắc chắn rằng không ai muốn chúng ngoài tôi và có lẽ tôi buộc phải trải qua đánh giá tâm thần nếu có bất kỳ hacker hạt nhân có thẩm quyền nào khác nhìn thấy chúng. Nhưng tôi vẫn thích việc thực hiện của mình piglatin_printk()bắt đầu như một trò đùa ngày 1 tháng 4 vài năm trước :)

Mặc dù có, nhận được mã của bạn và quá trình suy nghĩ của bạn trước nhiều người có thẩm quyền khác là vô giá, vì vậy học cách giao tiếp và cộng tác. Một dự án solo là một cách tuyệt vời để cho bạn thấy những gì không nên làm. Gợi ý, có nhiều thứ hơn là chỉ sử dụng phần mềm kiểm soát phiên bản, danh sách gửi thư và trình theo dõi lỗi.

Để bắt đầu, tôi khuyên bạn nên đào xung quanh Ohloh để tìm phần mềm mà trước tiên bạn có thể quan tâm đến việc sử dụng . Tải về nó, xây dựng nó, chơi với nó. Sau đó đi lấy một cái gì đó khác. Cuối cùng, bạn sẽ muốn cải thiện một cái gì đó, hoặc nhận ra rằng bạn có mong muốn thực hiện một cái gì đó hoàn toàn khác với những gì bạn tìm thấy.

Một điều khác giúp làm việc cho một công ty thân thiện mở. Công ty của tôi sử dụng Xen rộng rãi, vì vậy họ không gặp vấn đề gì với tôi khi tìm ra các lỗi thú vị và sửa chúng, vì dù sao chúng tôi cũng cần phải làm điều đó. Họ cũng không ngại nhân viên tham gia vào những thứ như thông số kỹ thuật của RFC và dự thảo, vì cuối cùng chúng ta sẽ sử dụng kết quả.


+1 piglatin_printk ()? Âm thanh vui nhộn. Tôi muốn thấy điều đó trong hành động. Không có gì ngạc nhiên khi hầu hết các bản vá Linux Kernel của bạn đã bị từ chối, không có nhiều chỗ để vui chơi / sáng tạo trong một dự án quan trọng. May mắn thay, có rất nhiều dự án nhỏ hơn có rào cản chấp nhận mã thấp hơn nhiều - ngay cả khi các đóng góp cần một số công việc trước khi được cam kết.
Evan Plaice

1
@EvanPlaice Họ không bị từ chối, chỉ không bao giờ gửi;)
Tim Post

7

OpenHatch được tạo riêng cho việc này.

Để trích dẫn:

OpenHatch là một tổ chức phi lợi nhuận dành riêng để kết hợp những người đóng góp phần mềm miễn phí tiềm năng với cộng đồng, công cụ và giáo dục.

Bạn có thể duyệt các dự án theo loại, công nghệ, mức độ kỹ năng cần thiết, v.v. và tìm những gì phù hợp với trình độ của bạn.


Trang web nhỏ tuyệt vời :) Người ta cũng có thể xem freecode.com
nha

4

Một điều mà tôi đã nhiều lần nhận thấy khi nói đến những người muốn bắt đầu phát triển nguồn mở là họ bị choáng ngợp trước sự phức tạp và tầm quan trọng của các dự án lớn. Tôi đã đối mặt với cùng một vấn đề vài năm trước, và từ kinh nghiệm của tôi, tốt nhất không nên nhìn vào các dự án lớn hơn ngay lập tức.

Sau khi dành thời gian để xem xét các dự án mà tôi có thể thích, tôi nhận ra rằng chúng vẫn nằm ngoài tầm với của tôi và sau đó tự mình bắt đầu thực hiện các dự án rất nhỏ. Tôi coi việc chỉ phát hành mã trên Github là bất kể liệu nó có thực sự phù hợp hay liệu người khác sẽ bắt đầu sử dụng nó. Cuối cùng, mọi người có thể bắt đầu quan tâm đến những gì bạn làm. Thậm chí nếu không, bạn sẽ có được sự tự tin và khả năng kỹ thuật để từ từ chuyển sang các dự án lớn hơn và phổ biến hơn.


3

Có một trang web mới dành riêng cho cái này được gọi là Mã 52 khuyến khích các nhà phát triển mới tham gia vào nguồn mở bằng cách bắt đầu một dự án OSS mới mỗi tuần.

Ý tưởng là nó sẽ có vẻ ít gây nản lòng hơn cho những người chưa bao giờ tham gia vào nguồn mở trước đây và hy vọng sẽ cảm thấy có xu hướng tham gia vào các dự án OSS khác.


1
Tôi đã xem xét nó và có một vài ghi chú để thêm. Code52 được lãnh đạo bởi 3 nhà phát triển từ công ty Readify, người tuyên bố đã giành được danh hiệu 'Đối tác của năm 2012 của Microsoft'. Mặc dù các dự án được lưu trữ trên GitHub, mỗi một dự án được viết bằng WinJS (tức là Win8 mục tiêu) và mang theo Giấy phép Công cộng của Microsoft. Từ một cái nhìn cursory MPL là bản sao trái nhưng mang một số hạn chế nhất định đòi hỏi các công cụ phái sinh phải kế thừa giấy phép tương tự hoặc tương tự. Tức là nó giống như giấy phép GPL hơn là giấy phép MIT hạn chế hơn nhiều.
Evan Plaice

Dự án trông rất hấp dẫn nhưng tôi không thể lay chuyển được cảm giác rằng đây là chương trình Sharecropping kỹ thuật số dành cho nhà phát triển mã nguồn mở mới được tạo bởi Microsoft để tạo ra hệ sinh thái Windows 8 mới mà không tốn một xu. Không nghe giống như một chiếc mũ thiếc đeo cổ nhưng MS không thực sự có danh tiếng tốt nhất khi tích hợp với Nguồn mở.
Evan Plaice

1
-1 Có vẻ như trang web này đã chết (không cập nhật thêm) trong một năm trước
Michael Durrant

3

Tôi khuyên bạn nên đọc: http://open-advice.org/ .

Nó nhằm mục đích giúp đỡ những người tạo và duy trì cộng đồng và những người không tự tin về cái nào họ muốn tham gia hoặc làm thế nào để làm như vậy.

Thất bại trong việc đó, hãy tìm một dự án có nhiệm vụ cộng hưởng với bạn, hoặc ngã ba và đóng góp cho một dự án đã hữu ích cho bạn.

Chúc may mắn.


3

Khi tôi bắt đầu, tôi đã tìm kiếm các lựa chọn trực tuyến và việc tìm kiếm thứ gì đó bạn có thể đắm mình khi mới bắt đầu là một thử thách.

Một số dự án khó đóng góp không phải vì chúng quá tiên tiến mà vì cộng đồng không được chào đón. Vì vậy, đừng nản lòng khi bạn va vào tường.

Trong quá trình tìm kiếm, tôi đã quyết định tập hợp một danh sách 10 dự án nguồn mở mà những người mới bắt đầu có thể bắt đầu hỗ trợ mà không cần nhiều quá trình căng thẳng. Đây là liên kết để sử dụng:

Mười dự án cho người mới bắt đầu để hỗ trợ và học hỏi từ

Tôi hy vọng bạn thấy nó hữu ích và bạn luôn có thể thêm nhiều hơn nếu bạn tìm thấy những thứ hay ho!


bạn có phiền giải thích thêm về những gì nó làm không và tại sao bạn lại đề nghị nó như trả lời câu hỏi được hỏi? "Câu trả lời chỉ liên kết" không được chào đón tại Stack Exchange
gnat

2

Tôi đề nghị tự mình bắt đầu một dự án về một chủ đề mà bạn quan tâm.

Rất nhiều có thể học được bằng cách làm việc trên một dự án nói chung. Không cần thiết phải xem cách người khác viết mã để tìm hiểu cách viết mã tốt hơn. Và đôi khi bạn thực sự sẽ thấy những điều không nên làm vì những người khác thường không có nhiều kinh nghiệm hơn bạn.

Nó thường giúp xem mã của người khác, nhưng bạn sẽ gặp mã của người khác trong dự án của riêng bạn chỉ thông qua các thư viện và các thành phần bạn sử dụng.

Kinh nghiệm sẽ dạy cho bạn những gì là thực hành tốt và xấu.


1
Trong khi tôi nghĩ rằng đây là một ý tưởng tuyệt vời, thực hiện nó như một dự án mới bắt đầu có thể đáng sợ. Đặc biệt là khi bạn không có đánh giá mã hoặc người khác có thể thêm đầu vào. Các dự án của riêng tôi đã trải qua nhiều lần viết lại và hàng ngàn dòng mã bởi vì không ai nói với tôi X là tốt hơn, một vấn đề tôi vẫn gặp phải. Tham gia một dự án đã thành lập sẽ tăng tốc học tập tốt hơn nhiều
TheLQ

@TheLQ: Nó phụ thuộc vào mức độ kinh nghiệm của bạn, tôi đoán, tự mình làm điều gì đó sẽ dạy cho bạn rất nhiều bài học và những điều bạn sẽ không học được bằng cách tham gia vào một nhóm đã hoàn thành nhiều việc. Theo tôi, có hàng hóa và mặt xấu về dự án của bạn hoặc của người khác.
Brian R. Bondy

@TheLQ Tôi hoàn toàn đồng ý. Đó là một kinh nghiệm rất quý giá khi tham gia một dự án đã có sẵn bởi vì nó cho bạn ý tưởng về cách các dự án nguồn mở được quản lý và cách cấu trúc của tổ chức. Sau khi thực hiện dự án thành công của người khác, bước nhảy vọt để tạo ra một dự án của riêng tôi là đi dạo trong công viên.
Evan Plaice

2

Tôi là chủ dự án trên mã google và tôi đang tìm kiếm người đóng góp. (Tuy nhiên, tôi sẽ không lạm dụng câu trả lời này cho quảng cáo.) Do đó, ý kiến ​​của tôi có thể thú vị với bạn.

Trước tiên bạn sẽ phải tìm hiểu những gì bạn quan tâm. Sau đó, phát triển một số chuyên môn trong một số lĩnh vực có liên quan đến sở thích của bạn . Sau đó tìm một dự án nơi chuyên môn của bạn được yêu cầu và cần thiết.

Dự án càng nhỏ, càng có ít người đóng góp, cơ hội mà những người đóng góp được tìm kiếm càng lớn và bạn có thể liên hệ trực tiếp với các tác giả / chủ dự án. Nói với họ a) chuyên môn của bạn là gì b) nơi bạn thấy nó có thể được áp dụng trong dự án c) những gì bạn nghĩ bạn có thể đạt được.

Hãy nhớ rằng: chỉ cần biết một hoặc hai ngôn ngữ lập trình chính không phải là chuyên môn.


Làm thế nào bạn sẽ khuyên ai đó đi về việc xác định những gì họ quan tâm hoặc xây dựng chuyên môn trong các lĩnh vực đó?
Adam Lear

2
@Anna Tôi không chắc là tôi hiểu câu hỏi của bạn. Ý tôi là có hàng trăm chủ đề - từ các công cụ cấp thấp như giao thức mạng hoặc hoạt động bên trong của GPU đến các chủ đề gần như trừu tượng, toán học (phân tích cú pháp, hệ thống loại, lý thuyết danh mục, v.v.). Thiên tài vĩ đại nhất sẽ không làm chủ được tất cả và sẽ rất vui khi có ai đó là chuyên gia trong lĩnh vực mà anh ta, thiên tài, không. Nhưng sở thích của bạn thực sự là gì, ai có thể nói điều đó ngoài bạn?
Ingo

1
Vâng, khám phá các sở thích có lẽ khá cá nhân (hoặc số tiền lời khuyên để "thử những thứ khác nhau và xem những gì bạn thích"), nhưng về việc đạt được chuyên môn thì sao? Bạn nói nó không chỉ là biết một vài ngôn ngữ. Vì vậy, đưa ra một chủ đề / chủ đề mới, bạn sẽ làm gì để đạt được chuyên môn đó? Đối với tôi, tham gia một dự án OSS sẽ là một phần của quá trình đó, nhưng nếu tôi đọc đúng bạn đang gợi ý rằng một người nên là một chuyên gia trước khi tham gia một dự án.
Adam Lear

Tôi sẽ làm gì? Đọc sách. Đọc các tệp PDF. Thảo luận với ai đó bạn biết, hoặc trong mạng. Hãy thử một cái gì đó. Thực hành. Trả lời tất cả các câu hỏi về SO đưa ra liên quan đến chủ đề đó. Rồi một ngày thông báo rằng ít ai biết rõ hơn bạn. - Đừng hiểu tôi theo nghĩa đen về "chuyên gia", nhưng hãy nhớ, trong các dự án nguồn mở, vì nó là tự nguyện, không có cách nào để buộc ai đó làm việc - vì vậy những người biết họ đang làm gì và ai muốn để làm điều đó được chào đón nhất.
Ingo
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.