Sự khôn ngoan trong việc sử dụng mã nguồn mở trong một sản phẩm phần mềm thương mại

Tôi đang xem xét việc sử dụng một số mã nguồn mở trong ứng dụng web ASP.NET của mình (cụ thể là dapper ). Quản lý không phải là một người hâm mộ, bởi vì nguồn mở được coi là rủi ro đã cắn chúng tôi trước đây. Rõ ràng các nhà phát triển trước đó đã phải viết lại mọi thứ sau khi các thành phần nguồn mở thất bại.

Ưu điểm dường như là:

• Nó thực hiện rất nhiều thứ đối với tôi có thể liên quan đến rất nhiều mã soạn sẵn hoặc giải pháp được đề xuất nhưng chậm hơn của Microsoft (Entity Framework).

Nhược điểm:

• Nó đủ phức tạp để nếu nó bị hỏng đột ngột trong sản xuất, tôi sẽ khó có thể sửa nó. Tuy nhiên, nó được sử dụng trên một trang web có lưu lượng truy cập cao hơn nhiều so với của tôi, vì vậy tôi không nghĩ rằng nó sẽ trở thành một phần rủi ro cao của dự án.

Sự đồng thuận ở đây là gì? Có phải là không khôn ngoan khi sử dụng mã nguồn mở trong dự án của tôi mà tôi không biết / hiểu cũng như tôi làm mã của riêng mình?

Đó là một lựa chọn mà bạn sẽ phải đưa ra dựa trên các trường hợp cụ thể. Bạn có thể giảm thiểu rủi ro bằng cách:

• kiểm tra khung kỹ lưỡng, tránh khả năng xảy ra những bất ngờ khó chịu cắn bạn trong môi trường sản xuất và
• sử dụng khớp nối lỏng lẻo để giảm thiểu số lượng mã phụ thuộc trực tiếp vào khung, do đó bạn có thể thay đổi thành triển khai của riêng mình nếu bạn không phải viết lại toàn bộ sản phẩm của mình.

Cuối cùng, với một dự án nguồn mở được sử dụng nhiều, bạn có thể sẽ dành nhiều thời gian hơn để tự viết hơn là sửa chữa một vài vấn đề bạn gặp phải.

Tôi sẽ đi xa hơn để nói rằng nếu phản ứng ban đầu của bạn là tự viết một cái gì đó thay vì xem người khác đã viết nó, bạn sẽ thất bại. Đừng xem nhẹ tất cả giờ làm việc và sửa lỗi đã đi vào các dự án nguồn mở chính thống.

Khi bạn bắt đầu tham gia vào lĩnh vực kinh doanh của mình, bạn sẽ khó khăn hơn để tìm OSS đáp ứng nhu cầu của bạn. Nhưng không cần phải thực hiện lại một sản phẩm ORM nào khác. Nếu dapper đủ phức tạp để bạn không thể gỡ lỗi và sửa mã của họ, làm thế nào bạn có thể biện minh cho việc dành tất cả thời gian cho người đàn ông viết nó từ đầu? Bên cạnh đó, bạn có thể (nên?) Luôn luôn nhìn ra ngoài các giải pháp NoQuery trong khi bạn ở đó.

Ngay cả Linus cũng thừa nhận anh đã cố gắng tìm một giải pháp SCM đáp ứng tất cả các tiêu chí của mình trước khi phát triển Git. Ít nhất anh ta đã có thể giải thích tại sao không có giải pháp nào hiện có đủ tốt.

Tại một số thời điểm trong cuộc sống, tôi đã ngừng muốn viết lại mọi thứ một mình và muốn tập trung vào giải quyết các vấn đề trong thế giới thực. Hầu hết các vấn đề cần được giải quyết trong một doanh nghiệp là tên miền cụ thể. Tìm cách viết ít mã không hơn.

Lưu ý: Tôi không phải là nhân viên của Microsoft. Ý kiến ​​là hoàn toàn cá nhân. Nhiều suy nghĩ là từ 5 - 7 năm qua sử dụng cả nguồn mở kết hợp với các nhà cung cấp lớn làm nhà phát triển.

Độc canh là tốt: Quy tắc cá nhân của tôi đối với ASP.NET là ưu tiên cho Microsoft và không chọn mã bên thứ 3 (mã nguồn mở hay không) trừ khi không có lựa chọn nào khác. Độc canh là bổ ích, bởi vì bạn đang được nhà cung cấp lớn mang theo, và số lượng người dùng lặp lại trải nghiệm tương tự là bất cứ lúc nào đủ lớn để nhận trợ giúp và tìm cách giải quyết.

Thị trấn ma: Vấn đề với nguồn mở vào năm 2012 là nó không còn là 2000 hay 2005 nữa. Số lượng dự án tiếp tục tăng, khi số lượng người dùng, nhận con nuôi, người đóng góp gần bằng năm trước. Khán giả được kéo dài mỏng. Nhiều dự án thú vị trở nên cũ kỹ, bị bỏ hoang. Không có thứ gọi là ngân sách dự án nguồn mở. Vì vậy, khi lãi suất kết thúc, không có ai thông báo trung thực rằng hỗ trợ đã kết thúc và tắt đèn. Các dự án không bao giờ chết để tập trung sự chú ý của công chúng vào một cái gì đó tốt hơn và mới. Vì vậy, nguồn mở sẽ luôn luôn phát triển và phân mảnh. Không có phản hồi dưới dạng phần thưởng tiền tệ hoặc cái chết tài chính, họ là những thực thể bất tử, tồn tại vì lợi ích của vinh quang vĩnh cửu.

20 độ phân tách: Mỗi việc bạn áp dụng thư viện mới sẽ tách bạn khỏi dòng chính, chuyển bạn sang thiểu số các trường hợp cạnh. Sau khi có 20 bước như chọn cấu hình bảo mật, sử dụng phiên bản cụ thể, khung, plugin, v.v ... Giải pháp của bạn trở thành một tổ hợp chi tiết duy nhất trên toàn cầu. Googling sẽ chỉ giúp đưa ra vấn đề hiếm gặp hay độc đáo như thế nào. Nó luôn luôn là một số vấn đề tự phục vụ, hoàn toàn là kỹ thuật. Thậm chí không bao giờ liên quan đến kinh doanh thực sự.

Chất lượng đến từ sự tập trung, tiền là không liên quan: Không có điểm nổi bật của phần mềm thương mại so với nguồn mở. Toàn bộ cộng đồng của các devellopers chỉ là một cộng đồng như mọi khi. Các nhà cung cấp lớn đơn giản có lợi thế về việc lão hóa mã lâu hơn, trong điều kiện tốt hơn, với đối tượng rộng hơn so với các nhóm nguồn mở.

Đồng thuận: Bạn hỏi nếu có sự đồng thuận. Có thể không. Thật không may, số lượng lớn người dùng nguồn mở quá chính trị. Sau tất cả các nguồn mở là một phong trào xã hội. Nguồn mở miễn dịch với phê bình, bởi vì rất thường xuyên có ý kiến ​​tiêu cực sẽ bị coi là chống công nghệ, tấn công cá nhân. Đồng thuận cá nhân của tôi: dính vào Microsoft.

Tôi đã làm việc trên một số dự án thành công cho một công ty lớn sử dụng các phần mềm nguồn mở đáng kể. Cụ thể, tôi đã sử dụng Curl, SQLite và Webkit cho một công ty rất lớn trong các dự án thành công được chuyển đến người dùng cuối. Như những người khác đã nói, đó chỉ là vấn đề cẩn thận về giấy phép và lý tưởng nhất là nhờ luật sư xem xét.

Có hàng trăm giấy phép nguồn mở, nhưng nhìn chung chúng thuộc hai loại, kiểu BSD và kiểu GPL. Giấy phép kiểu BSD không yêu cầu bạn mở mã nguồn của riêng bạn và thường chỉ có một số loại mệnh đề ghi công. Giấy phép kiểu GPL yêu cầu bạn phải mở mã nguồn của riêng bạn. Hầu hết các công ty (bao gồm cả của tôi) thường nhìn vào yêu cầu vì vậy bạn sẽ muốn tránh kiểu GPL. Dapper dường như sử dụng giấy phép Apache, theo kiểu BSD. Luôn luôn tìm hiểu các điều khoản giấy phép chung là gì trước khi bạn bắt đầu viết mã.

Ngoài ra còn có LGPL, đây là một trường hợp viền thú vị ở chỗ bạn có thể sử dụng chúng trong khi không mở mã của riêng mình nếu bạn hạn chế quyền truy cập vào ranh giới nhị phân. (Tức là chỉ truy cập thư viện dưới dạng thư viện động.) Việc sử dụng thư viện LGPL là rất khả thi, bạn chỉ cần cẩn thận hơn.

Theo kinh nghiệm của tôi, mã nguồn mở không có khả năng trở thành lỗi hoặc thất bại hơn các giải pháp trả tiền, hoặc, đối với vấn đề đó, các giải pháp của riêng bạn. Nếu bạn nhìn vào một số công cụ nguồn mở nổi bật hơn, chất lượng rất cao.

Bạn có thể muốn tránh các dự án nhỏ, hoặc không hoàn thành. Có thể rất hấp dẫn để lấy một thứ gì đó có vẻ đáp ứng nhu cầu của bạn, nhưng nếu chúng là thứ gì đó được kết hợp bởi một vài người, không bao giờ hoàn thành và không được hỗ trợ, thì có lẽ không đáng để bỏ công sức. (Trừ khi bạn sẵn sàng làm việc trực tiếp với mã.)

Bạn chưa bao giờ có thành phần độc quyền thất bại trước đây? Tôi đã gặp rất nhiều lỗi trong phần mềm từ các công ty lớn và nhỏ. Vấn đề này không phải là vấn đề với nguồn mở mỗi se, mà nó liên quan nhiều hơn đến sự trưởng thành của dự án.

Có vẻ như bạn muốn sử dụng các dự án trưởng thành cung cấp hỗ trợ. Một số dự án nguồn mở cung cấp hỗ trợ có trả tiền hoặc có một cộng đồng đủ lớn để bạn có thể nhận được câu trả lời trong một diễn đàn công cộng. Có lẽ bạn nên thực hiện các ưu tiên tiêu chí trưởng thành và hỗ trợ khi chọn thư viện, cho dù đó là nguồn đóng hay nguồn mở.

Bạn cần phải thừa nhận rằng bạn đang gặp nhiều rủi ro hơn nếu bạn quyết định sử dụng một dự án chưa trưởng thành hoặc một dự án với sự hỗ trợ hạn chế. Vì vậy, bạn cần xác định kế hoạch giảm thiểu rủi ro của bạn là gì. Ví dụ, bạn có thể thực hiện nhiều thử nghiệm hơn trên phần mềm của bên thứ ba.

Giả sử các vấn đề cấp phép không có vấn đề gì ở đây: nhìn nhanh vào Dapper, tôi nhận thấy nó chỉ có 2255 dòng mã được đọc tài liệu tốt . Đó là

• đủ lớn để bạn có thể đầu tư vài ngày hoặc vài tuần để tạo ra mã có chất lượng tương đương làm tương tự
• đủ nhỏ để bạn có thể hiểu những gì nó làm và sửa bất kỳ lỗi nào trong mã đó nếu chúng xuất hiện trong sản xuất

Nếu bạn định tự mình viết một cái gì đó tương tự và "phát minh lại bánh xe", bạn có nguy cơ cao hơn rằng mã của chính bạn sẽ xuất hiện lỗi trong sản xuất và bạn cũng sẽ thực sự "khó sửa".

Tuy nhiên, những gì bạn phải làm ở đây, nếu bạn giới thiệu một phần nguồn mở như vậy vào dự án của mình, thì bạn phải chịu trách nhiệm hoàn toàn cho mã đó, giống như bạn đã tự viết nó. Hãy chắc chắn rằng mã ở trạng thái bạn có thể duy trì nó, nếu cần thiết. Đừng đổ lỗi cho "các tác giả" của mã đó nếu một cái gì đó không hoạt động như mong đợi.

Trong một trong các dự án của chúng tôi, chúng tôi cũng đã giới thiệu một số thành phần nguồn mở, từ các kích thước nhỏ như Dapper đến các thư viện có khoảng 20K đến 30K dòng mã. Chúng tôi đã luôn phải thực hiện một số thay đổi, sửa một số lỗi, thu nhỏ thứ gì đó, v.v., nhưng điều đó vẫn ổn, vì chúng tôi mong đợi điều đó. Ngay cả thời gian để gỡ lỗi bao gồm, sử dụng nguồn mở đã giúp chúng tôi tiết kiệm rất nhiều công việc.

Một điều cần suy nghĩ ở đây: trong trường hợp của bạn, bạn đề cập rằng có một sự thay thế được chấp nhận rộng rãi từ một nhà cung cấp lớn có sẵn (MS Entity Framework, mà bạn không phải trả thêm bất kỳ khoản phí giấy phép nào!). Bạn không muốn sử dụng nó vì những cân nhắc về hiệu suất. Tôi thực sự khuyên bạn không nên để hiệu suất là điểm duy nhất hoặc chính được xem xét. Các câu hỏi bạn nên hỏi ở đây: Dapper có tất cả các chức năng bạn cần bây giờ và trong vòng đời dự kiến ​​của phần mềm của bạn không? Hoặc bạn có thể thấy trước rằng bạn sẽ nhanh chóng đạt đến giới hạn của Dapper và bạn sẽ phải thêm rất nhiều chức năng bị thiếu xung quanh nó, điều mà bạn có thể sẽ không phải làm nếu bạn quyết định sử dụng EF ở nơi đầu tiên? Nếu sau này là trường hợp, tôi khuyên bạn không nên sử dụng Dapper. Đồng thời tự hỏi: EF thực sự không đủ nhanh cho ứng dụng của bạn,

Theo tôi thấy, đó là một hành động cân bằng.

Nếu bạn khiến mình phụ thuộc vào một nhà cung cấp, gần như chắc chắn rằng sự hỗ trợ sẽ biến mất trong thời gian dài

• Bởi vì họ có các lập trình viên phải trả tiền, vì vậy họ cần tiếp tục tạo các phiên bản mới và đảm bảo rằng các phiên bản cũ không thể có được và không còn hoạt động (trên các nền tảng mới hơn) để các phiên bản mới sẽ có thị trường.

• Nếu họ không thể bán đủ để biện minh cho một mô hình kinh doanh, họ chuyển nó từ công ty A sang công ty B sang C, mỗi công ty thay đổi đủ để một lần nữa, bạn không thể sử dụng mô hình mới mà không cần lập trình lại, và bạn có thể ' t lấy cái cũ làm việc.

• Họ chỉ quyết định rằng họ sẽ không còn hỗ trợ vì quá nhiều rắc rối và không có tiền trong đó. Tất cả tiền trong ứng dụng mới.

Vì vậy, nếu bạn muốn xây dựng một cái gì đó không phải viết lại liên tục cứ sau vài năm, nguồn mở có thể là bạn của bạn.

Tôi nghĩ thật khôn ngoan nếu sự chuyên cần đầy đủ được thực hiện và có vẻ như bạn đã thực hiện một số bài tập về nhà liên quan đến lịch sử và hoạt động của một dự án cụ thể. Khả năng mở rộng / thêm các tính năng trong mã nguồn cũng là một pro lớn. Với thử nghiệm đầy đủ, bạn có thể giảm thiểu rủi ro về phía con. Thật khó để hiểu hoàn toàn tất cả các phụ thuộc trong mã của bạn, nhưng ít nhất trong trường hợp đó bạn sẽ có thể gỡ lỗi hoàn toàn và xem mã nếu cần thiết.

Hỏi quản lý tại sao nó đã thất bại trước đó, đã đủ siêng năng thực hiện chưa?

jquery có tùy chọn sử dụng giấy phép MIT, vì vậy nhiều trang web thương mại và chính phủ cũng sử dụng jquery. Trang web của Microsoft cũng sử dụng jquery! Vì vậy, mối quan tâm là cấp phép. Tránh sử dụng GPL / LGPL là đủ.

"Bao lâu để có được một sửa chữa cho một khiếm khuyết báo cáo?" Sau khi báo cáo lỗi, nó có thể được sửa trong vòng vài phút, vài giờ hoặc vài ngày. Đối với tình huống khẩn cấp, nhân viên có thể chỉ cần "git pull" để lấy nguồn và tự biên dịch nó. Anh ta chỉ cần báo cáo phiên bản như "v1.2.3-101-gd62fdae" cho ban quản lý, có thể theo dõi được.

Nguồn mở thực sự là về tính hợp pháp, không phải chất lượng mã. Có những sản phẩm nguồn mở tốt và xấu, giống như có những sản phẩm nguồn đóng tốt và xấu. Tôi tin rằng vấn đề nan giải của bạn là có nên sử dụng một dự án được phát triển bởi một cộng đồng tình nguyện viên hay không.

Bạn có chắc chắn rằng vấn đề quản lý là mối quan tâm kỹ thuật.

Tôi nói điều này vì pha trộn hệ điều hành và hoạt động thương mại là một lĩnh vực khai thác hợp pháp và hơn một người quản lý đã có "Hãy giải thích" từ nhóm / CEO hợp pháp hoặc tệ hơn, từ một tổ chức khác. Hầu hết các nhà quản lý mà tôi biết, ngay cả những người tích cực nắm giữ phần mềm hệ điều hành, (rất đúng) rất thận trọng để hiểu đầy đủ các tình huống pháp lý mà họ đang đưa ra nguồn gốc. Nếu bạn áp dụng phần mềm hệ điều hành và thực hiện các thay đổi, bạn có nghĩa vụ phải trả lại những thay đổi đó cho cộng đồng. Trong một số trường hợp, nghĩa vụ này là hợp pháp, trong những người khác về đạo đức. Trong một số giấy phép HĐH, mọi thứ bạn làm đều trở thành HĐH chỉ bằng cách liên kết với chúng.

Từ quan điểm kỹ thuật, đó thực sự chỉ là quyết định giữa các sản phẩm cạnh tranh - Đặt một số câu hỏi cơ bản - Bạn có thể nhận được sự hỗ trợ mà bạn cần cho gói bạn chọn không?, Bao lâu để khắc phục lỗi được báo cáo, chi phí cho mỗi lần là bao nhiêu nhà phát triển, mỗi năm hoặc một lần, v.v. Hệ điều hành có rất nhiều 0 trong cột $, nhưng thường có các khoảng trống trong các cột khác - chỉ bạn và sếp của bạn có thể quyết định là 0 có vượt quá trọng số hay không.

Và một điểm khác cần nhớ - "Không ai từng bị sa thải khi mua IBM". (tức là quản lý nói "Nếu bạn chi nhiều tiền thì đó phải là một sản phẩm tốt hơn một sản phẩm miễn phí"