Làm thế nào để biết một dự án nguồn mở có đủ chín chắn để sử dụng trong một sản phẩm không?


15

Có một số dự án nguồn mở mà tôi muốn kết hợp vào một sản phẩm tại nơi làm việc. Chúng tôi không có băng thông cũng như chuyên môn về chủ đề để tự làm điều đó. Tôi tìm thấy những thứ này bằng cách tìm kiếm trong Google. Tôi không biết về bất kỳ "người chơi chính" nào sử dụng các dự án, nhưng tôi khá được khuyến khích bởi những gì tôi thấy.

Bây giờ, tôi hơi lo ngại về mức độ rủi ro mà tôi gặp phải khi sử dụng dự án nguồn mở của joe-blow. Nếu tôi mất 95% đường đến đó, có lẽ 5% còn lại là dễ dàng để thêm hoặc sửa chữa. Có lẽ nó không tầm thường.

Làm thế nào để mọi người đi đến việc xác định xem một dự án nguồn mở có đủ trưởng thành để sử dụng trong một sản phẩm không?

Đây không phải là một dự án sở thích, vì vậy sự ổn định, khả năng bảo trì, vv là tối quan trọng.


Bạn không bao giờ biết chắc chắn. Windows đã đủ trưởng thành chưa? Kiểm tra nó và cố gắng liên hệ với các nhà phát triển - liên hệ cá nhân (email?) Có thể nói nhiều về sự tỉnh táo / trưởng thành của dự án mà họ đã tạo.
SChepurin

3
Điều quan trọng duy nhất là nó có phù hợp với yêu cầu của bạn không. Nếu có, bạn chỉ cần sử dụng nó. Nếu nó không "trưởng thành" (định nghĩa gây tranh cãi), bạn có thể bắt đầu đóng góp vào mã / thảo luận / tài liệu / cộng đồng / lỗi / xyz để trưởng thành nó.
treecoder

1
Viết một bộ kiểm tra đơn vị thực sự tốt trước khi bạn đưa thư viện mới vào sản phẩm thực tế của mình.
Jim ở Texas

@greengit: Nó thậm chí không phải phù hợp với tất cả các yêu cầu miễn là không có sự thay thế nào phù hợp với chúng tốt hơn.
Jan Hudec

Câu trả lời:


17

Các tiêu chí tôi sử dụng, cung cấp rằng dự án phù hợp với yêu cầu của tôi:

  1. Có một cộng đồng tích cực, với những người có thể cung cấp hỗ trợ?
  2. Giấy phép có phù hợp với sự phát triển của tôi không?
  3. Sản phẩm vẫn đang được phát triển tích cực?
  4. Nó có phải là một khung thường được sử dụng?
  5. Tôi có thể tìm thấy bất kỳ đánh giá / bài đăng trên blog / vv của sản phẩm và cách mọi người đã tích hợp với nó không?

4 & 5 không thực sự giúp ích cho các dự án thích hợp mà có vẻ như là của bạn.

Điều quan trọng nhất là nó có đáp ứng yêu cầu của bạn không? Nếu bạn cảm thấy như vậy, điều tiếp theo cần làm là khai thác để kiểm tra dự án và xem liệu bạn có thể làm những gì bạn muốn nó làm không. Điều này sẽ mang lại cho bạn cảm giác về API của nó (nếu đó là thư viện) và cách thức hoạt động của nó.

Vào cuối ngày, nếu có một cái gì đó nguồn mở thực hiện 90% những gì bạn làm, hãy rẽ nhánh nó, thêm chức năng bổ sung và trả lại cho cộng đồng. Tôi đã làm điều này trước đây trên các dự án thương mại.


6
Không bao giờ quên rằng 95% được thực hiện có nghĩa là chỉ còn 95% để làm ....
mattnz

6
  1. Đối với khung, tôi thường chỉ đi với khung lớn và trưởng thành với nhiều mô-đun được viết sẵn và cộng đồng lớn. Nói chung, việc chọn một khung này so với khung kia sẽ không thực sự làm giảm số lượng công việc bạn cần dành cho mã của mình, một số khung có thể khuyến khích một mã đẹp hơn, các khung khác có thể thực hiện một số thao tác dễ dàng, nhưng chúng thường tổng hợp rất ít khác biệt so với nỗ lực phát triển toàn diện. Tuy nhiên, các khung phổ biến sẽ có nhiều mô-đun được viết sẵn hơn mà bạn có thể tận dụng và đó là cách bạn thường có thể tiết kiệm nhiều thời gian và công sức hơn.
  2. Đối với thư viện không có khung nhỏ, nói chung, bạn có thể tự sửa đổi nếu cần mà không gặp vấn đề gì, vì vậy, tôi thường coi cộng đồng là một phần thưởng bổ sung. Hầu hết các thư viện nhỏ chỉ được quản lý bởi một người duy nhất, nhưng họ vẫn tốt hơn là tự xây dựng. Tuy nhiên, đối với các thư viện lớn, việc có một cộng đồng trưởng thành, tích cực và tài liệu là điều cần thiết bởi vì bạn không thể tự mình thực hiện các thay đổi một cách dễ dàng.
  3. Giấy phép là điều cần thiết. Đối với thư viện một người, có thể bạn sẽ cần phải sửa đổi thư viện, do đó, điều cần thiết là giấy phép của họ cho phép bạn làm như vậy theo các điều khoản mà bạn đồng ý.

Đối với các thư viện nhỏ, bạn phải luôn cho rằng bạn sẽ cần rẽ nhánh và dự án đã bị hủy bỏ. Điều này thường không phải là một vấn đề, đặc biệt là nếu dự án được lưu trữ trên Github hoặc BitBucket, vì chúng khiến cho dự án của người khác trở nên dễ dàng một cách ngu ngốc. Đối với các thư viện nhỏ, bạn luôn có thể tự mình đảm nhận việc bảo trì dự án, nếu người bảo trì ban đầu không còn hoặc nếu họ dự định đi theo hướng dự án đến những nơi bạn không muốn đến.

Tôi ít quan tâm đến hoạt động của dự án, thư viện trưởng thành đã đạt được cảm giác "hoàn hảo" của họ nói chung sẽ chỉ cần sửa lỗi, vì vậy hoạt động của họ bị chậm lại. Hoạt động dự án chỉ quan trọng nếu thư viện liên quan đến mục tiêu đang phát triển tích cực, ví dụ, trình bao bọc cho dịch vụ bên ngoài sẽ cần được cập nhật liên tục khi dịch vụ bên ngoài phát triển, vì vậy việc phát triển tích cực là cần thiết, nhưng thư viện toán học sẽ không cần nhiều phát triển mới một khi nó có tất cả các tính năng cần thiết.

Đối với các thư viện lớn hơn, mọi thứ trở nên khó khăn hơn. Tiếp quản có liên quan nhiều hơn, may mắn thay, các thư viện lớn hơn thường không di chuyển nhanh như vậy, vì chúng thường trưởng thành hơn.

Như @Sam đã nói trong câu trả lời của mình, tôi đồng ý rằng điều quan trọng nhất trong việc đánh giá thư viện nguồn mở là mức độ phù hợp với yêu cầu của bạn. Khi bất kỳ vấn đề giấy phép nào được sắp xếp, việc sử dụng thư viện nguồn mở hiếm khi là một sai lầm vì bạn luôn có thể rẽ nhánh nếu mọi thứ đi về phía nam.


3

Nhìn vào trình theo dõi lỗi của dự án. Nếu bạn thấy rất nhiều vé được gửi bởi nhiều người khác nhau và phản hồi đến từ nhiều người khác nhau, thì đó là một dấu hiệu tốt. Nhiều vé lỗi hơn == cộng đồng người dùng lớn hơn == nhiều khả năng bạn đã sẵn sàng để sử dụng sản xuất.


2
Mặc dù đó chắc chắn là một cách để xem một dự án đang được sử dụng trong một số khả năng, bạn cần nhiều bối cảnh hơn là chỉ đơn giản là một số vé lỗi để biết liệu dự án có đủ tin cậy cho một hệ thống sản xuất hay không. Ví dụ, nếu phần lớn các vé lỗi đã được mở trong một thời gian và vẫn chưa được giải quyết, tôi sẽ không muốn kết hợp nó vào một hệ thống quan trọng trong kinh doanh.
Derek

Trên thực tế, tôi nghĩ sẽ ổn nếu thậm chí phần lớn vé đã được mở trong một thời gian và không được giải quyết. Đây có thể là một dấu hiệu cho thấy kích thước và sự tham gia của cơ sở người dùng hơn bất cứ điều gì về chính phần mềm. Thêm về chủ đề đó ở đây: rants.org/2010/01/bugs-users-and-tech-debt .
Karl Fogel

1

Tin tức không tốt, nhưng điều đó không có nghĩa là nó không chính xác: Bạn không biết.

Nếu có các triển khai tương tự trong sản xuất, bạn sẽ biết nó khả thi, nhưng như bạn đã nói không có "người chơi chính" nào sử dụng các dự án.

Nếu bạn đã phát triển trong nhà, thì bạn sẽ biết, nhưng như bạn đã nói, bạn không có tài nguyên.

Thật hợp lý khi muốn biết, nhưng ... bạn thì không.

Tôi hy vọng câu trả lời này có ích, bởi vì bạn nên có kế hoạch dự phòng cho việc rút phích cắm trên bất kỳ công nghệ nào mà bạn phụ thuộc nhưng không kiểm soát ... và biết rằng bạn không biết liệu nó có đáng tin hay không là một bước theo hướng đó.


1

Câu hỏi phải được đặt khác nhau. Điều bạn thực sự hỏi là sử dụng dự án nguồn mở này cách tốt nhất để phát triển sản phẩm là gì?

Điều đó nhất thiết liên quan đến không chỉ dự án nguồn mở được đề cập, mà còn cả các tùy chọn khác của bạn. Nếu tùy chọn khác duy nhất của bạn là tự viết mọi thứ, thì tốt hơn là bạn nên sử dụng dự án nếu bạn có thể hiểu mã của nó đủ để có thể sửa đổi nó.

Tất nhiên hơn câu hỏi khác đặt ra là liệu dự án của bạn có khả thi hay không. Tức là bạn cần ước tính nỗ lực bao gồm mọi rủi ro phải sửa chữa hoặc hoàn thành chức năng mà bạn hy vọng được cung cấp bởi mã nguồn mở. Nếu dự án không được sử dụng rộng rãi, bạn sẽ phải xem lại mã cho điều đó.

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.