Phát hành phần mềm nguồn mở quá sớm [đã đóng]

Trách nhiệm đạo đức của việc phát hành phần mềm nguồn mở quá sớm là gì? Chẳng hạn, một sản phẩm gần hoàn chỉnh chưa được kiểm tra đầy đủ.

Kỳ vọng của lập trình viên là gì? Đợi cho đến khi nó được kiểm tra đầy đủ, hoặc phát hành ra nguồn mở và sau đó tiếp tục phát triển, thử nghiệm và tiến bộ hơn nữa?

Điều đáng sợ là phần mềm được mở nguồn và có khả năng dẫn đến các vấn đề cho người tiêu dùng.

Đây có phải là một nỗi sợ vô căn cứ?

Tôi tin ngược lại rằng bạn nên phát hành một phần mềm nguồn mở càng sớm càng tốt. Không có "quá sớm" cho điều đó (nhưng nó nên biên dịch).

^{Hoặc ít nhất là xuất bản mã nguồn rất sớm và liên tục (ví dụ: bằng cách đẩy thường xuyên trên github ), mà không đưa ra các bản phát hành chính thức .}

Tuy nhiên, điều rất quan trọng là gắn cờ nó ở giai đoạn alpha hoặc beta, và nếu có thể nói (ví dụ: trong một READMEhoặc TODOtệp, và trên một số blog, v.v ...) những gì còn thiếu, không được kiểm tra hoặc có hình dạng xấu. Bạn cũng nên sử dụng số phiên bản để truyền đạt thông tin đó.

Với phần mềm miễn phí , điều tốt nhất nên xảy ra là ai đó liếc vào mã nguồn và đề xuất cho bạn một bản vá nhỏ cải thiện nó. Đây là lý do tại sao bạn làm cho phần mềm của bạn miễn phí!

^{Do đó, bạn cần hiển thị công việc hàng ngày của mình trên phần mềm miễn phí! Những người đóng góp bên ngoài sẽ tức giận nếu bản vá của họ không hoạt động hoặc là bản sao của mã nguồn phần mềm gần đây của bạn.}

Điều bạn nên sợ là không ai quan tâm đến phần mềm của bạn (và đóng góp cho nó). Thu hút sự quan tâm từ bên ngoài đến một phần mềm miễn phí (đặc biệt là thu hút những người đóng góp bên ngoài) là một hành trình dài.

TL; DR:

Phát hành sớm. Phát hành thường xuyên.

Giai thoại cá nhân:

Tôi thực sự hào hứng với dự án mà tôi đang thực hiện. Giống như, thực sự phấn khích. Tôi không thể ngủ vào ban đêm phấn khích. Vì vậy, tôi đã đẩy đồng nghiệp của mình phát hành v1.0 nhanh hơn anh ta muốn.

Điều đó thật tồi tệ. Không có gì làm việc theo cách nó được yêu cầu. Có lỗi ở mỗi lượt, nhưng chúng tôi đã đăng nhập và sửa chúng. Chúng tôi thậm chí đã có một vài người chấp nhận sớm gửi các lỗi mà chúng tôi có thể không tìm thấy. Một hoặc hai tuần sau, chúng tôi đã phát hành một bản phát hành mới giải quyết rất nhiều vấn đề và sau đó quay lại để xây dựng các tính năng mới.

Phát hành sớm là điều tốt nhất chúng ta có thể làm. Nó đặt sản phẩm của chúng tôi trước người dùng thực sự. Thực hiện lỗi tiếp xúc này, chúng tôi có thể hoặc không thể tìm thấy và làm cho dự án của chúng tôi tốt hơn. Nó cũng cho những người chấp nhận sớm biết rằng chúng tôi nghiêm túc với dự án này. Sẽ có nhiều bản phát hành và phát triển tích cực.

Nó cũng có thể dễ dàng đi theo con đường khác. Chúng tôi có thể đã bỏ qua những báo cáo lỗi. Hoặc chúng ta không thể phản ứng nhanh chóng. Nó có thể là một câu chuyện khác nếu chúng tôi mất 3 tháng để phát hành v1.1 thay vì một vài tuần.

Nó giống như với phần mềm nguồn đóng. Truyền thông là quan trọng.

Thông báo cho người dùng trạng thái của phần mềm là gì và tại sao nó có sẵn để tải xuống.

Phần mềm sẽ luôn dẫn đến các vấn đề của khách hàng, bất kể nó có được kiểm tra đầy đủ hay không. Hầu hết khách hàng chấp nhận thực tế đó, và một số khách hàng không bao giờ làm. Nhưng nếu phần mềm sẽ dẫn đến nhiều vấn đề hơn mong đợi một cách hợp lý, có nghĩa vụ đạo đức phải thông báo cho khách hàng về rủi ro mà họ đang gặp phải. Thông tin phải ở cả dạng ngắn (nhãn "Alpha / Beta / EarlyAccess") và chi tiết: Danh sách các vấn đề đã biết, cách giải quyết và các cân nhắc đặc biệt, ví dụ: nếu có khả năng dữ liệu có thể bị hỏng.

* Xin lưu ý rằng người dùng đã được một số công ty phần mềm lớn đào tạo để nghĩ về "Beta" là trạng thái mà phần mềm khá vững chắc, vì vậy, nói với người dùng rằng phần mềm là "Beta" thường không đủ thông tin.

Không có trách nhiệm đạo đức nào. Không ai bị buộc phải sử dụng phần mềm nửa nướng của bạn.

Điều duy nhất cần quan tâm là uy tín của bạn.

Kinh nghiệm của tôi là có một sự cân bằng để đạt được.

Ngay bây giờ, tôi đang làm việc (với ý nghĩa trả lời các câu hỏi và cung cấp các đề xuất phát triển, mà không thấy bất kỳ mã nào) với nhà phát triển đang sản xuất một dự án FOSS rất thú vị sử dụng mã tôi đã viết. Việc phát hành công khai đã bị trì hoãn nhiều lần bởi việc thực hiện các thay đổi thiết kế sẽ giúp dự án tốt hơn trong thời gian dài, nhưng đòi hỏi phải viết lại mã đáng kể đã được viết và đã "hoạt động". Quan điểm của tôi là, đã có một bản phát hành hoạt động nhưng không hoàn hảo ngay khi có thứ gì đó hoạt động để trình bày, ý tưởng cho những thay đổi (và bản vá thực tế) có thể đến từ cộng đồng rộng lớn quan tâm đến dự án này hơn là tăng tốc về phía trước thay vì có các vấn đề xuất hiện từ từ, từng lúc một, khi nhà phát triển nghĩ về họ và yêu cầu phản hồi thiết kế từ bản thân tôi và các thành viên quan tâm khác của cộng đồng. Vì vậy, từ quan điểm này, tôi rất ủng hộ "phát hành sớm, phát hành thường xuyên".

Mặt khác, các bản phát hành chất lượng thấp có thể làm cho một dự án mới trở nên tồi tệ trước khi nó bắt đầu. Một số cạm bẫy tôi đã thấy bao gồm:

• Cây xương với định nghĩa giao diện nhưng không có mã.
• Mã không biên dịch thành công cho bất kỳ ai trừ nhà phát triển.
• Không có hướng dẫn về cách xây dựng / chạy chương trình.
• Không có tài liệu về những khía cạnh có thể được dự kiến ​​sẽ làm việc.
• Mô tả không rõ ràng về những gì chương trình thậm chí làm hoặc sẽ làm.
• Thiếu bất kỳ minh chứng về tính hữu dụng.

Đối với điểm cuối cùng, tôi nghĩ về những thứ như:

• Trình biên dịch / trình thông dịch thậm chí không thể biên dịch / chạy chương trình kiểu hello-world.
• Trình giả lập ít nhất không thể chạy một chương trình mẫu nào đó hoặc bằng cách khác chứng minh rằng nó đang làm gì đó.
• Công cụ xử lý hình ảnh không thể làm gì khác ngoài tải và lưu lại hình ảnh chưa sửa đổi.
• Trò chơi không có gì ngoài một màn hình tiêu đề.

Những loại vấn đề này cho vay một hình ảnh "phần mềm hơi" có thể khó rung chuyển trừ khi bạn rất cởi mở về việc thiếu mã làm việc để bắt đầu.

Cuối cùng, làm cho số phiên bản của bạn có ý nghĩa. Đừng gọi dự án của bạn là "1.0" cho đến khi nó thực hiện những gì người dùng mong đợi nó sẽ làm mà không gặp sự cố. Tôi luôn gặp may mắn khi sử dụng số phiên bản khoảng "0,5" cho lần phát hành công khai ban đầu và đi từ đó, nhưng tôi cũng đã thấy những thứ như "0,1" hoặc "0,10" có ý nghĩa.

Có một trường hợp khi phát hành phần mềm miễn phí có thể có hậu quả tiêu cực. Một số thông số kỹ thuật được cấp phép cho công chúng với điều kiện tất cả các triển khai được phân phối cho công chúng phải hoàn toàn phù hợp với đặc điểm kỹ thuật khi được công bố lần đầu tiên. Nhà xuất bản cấm bạn phân phối một cách thực hiện công việc đang tiến hành của thông số kỹ thuật. Nếu không có giấy phép thương lượng cụ thể từ nhà xuất bản của thông số kỹ thuật, bạn phải chia sẻ nó với bất kỳ ai cho đến khi vượt qua tất cả các bài kiểm tra. Điều này buộc một "mô hình nhà thờ" (như Eric S. Raymond gọi nó) về việc triển khai thông số kỹ thuật.

Một thông số theo giấy phép như vậy là Đặc tả ngôn ngữ Java . Hạn chế này áp dụng cho các nhà phát triển máy ảo tương thích với JVM, nhưng may mắn thay không áp dụng cho các nhà phát triển ứng dụng chạy trong JVM.

Bài viết " 4 chi tiết rõ ràng về 'Nguồn mở' .NET " của Liu Qihao & Ciaran O'Riordan đề cập đến khả năng diễn giải Lời hứa bằng sáng chế của Microsoft cho các thư viện .NET và các thành phần thời gian chạy để loại trừ việc triển khai CLR không hoàn chỉnh theo cách tương tự . Nhưng một lần nữa, điều này không áp dụng cho các ứng dụng chạy trong CLR.