Làm thế nào để phát triển phần mềm GNU duy trì kinh tế?


10

Tôi xin lỗi nếu câu hỏi này không có chủ đề, nhưng nó đồng thời là một câu hỏi kinh tế và lập trình. Nếu nó nên đi đến một cộng đồng SE khác, xin vui lòng cho tôi biết.

Về lý thuyết, phần mềm GNU hoàn toàn được phát triển bởi các tình nguyện viên trong thời gian rảnh hoặc bởi các công ty tự nguyện lập trình cho các lập trình viên để phát triển phần mềm GNU (bằng cách sử dụng thu nhập từ một lĩnh vực hoạt động khác của họ).

Tôi hiểu làm thế nào nó có thể hoạt động hoàn toàn tốt cho dự án quy mô nhỏ có thể được thực hiện trong một vài ngày cuối tuần mưa của một cá nhân (ví dụ như trò chơi sudoku), bởi vì sau tất cả lập trình máy tính là một sở thích cực kỳ thú vị và bổ ích, và tôi không gặp vấn đề gì khi thấy mọi người phát triển các chương trình vừa hoặc nhỏ trong thời gian rảnh và chia sẻ chúng với thế giới.

Vấn đề là quy mô này cực kỳ kém đối với các chương trình lớn hơn vì những lý do sau:

  1. Điều thú vị như lập trình là, khi dự án phải được thực hiện trở nên lớn hơn, thời gian cần thiết để thực hiện các chức năng mong muốn tăng lên cực kỳ nhanh chóng. Một chương trình quy mô lớn hơn cần một lượng thời gian đáng kinh ngạc để phát triển, ví dụ, có thể dễ dàng mất 15 năm thời gian rảnh và thời gian nghỉ để một cá nhân lập trình một hệ điều hành, và khi phần mềm của anh ta được phát hành, nó sẽ hoàn toàn lỗi thời .
  2. Vì những người khác viết chương trình theo cách khác mà bạn đã làm, việc đọc và hiểu mã của người khác mất rất nhiều thời gian, trong hầu hết các trường hợp cũng như viết mã của riêng bạn từ đầu. Sửa đổi mã của người khác và cố gắng cải thiện nó, vì nó được khuyến khích bởi triết lý GNU, gần như tốn thời gian như việc phát triển bản sao chương trình đã nói của bạn với chức năng bạn muốn thêm.
  3. Ngay sau khi 2 người trở lên sẽ phải hợp tác để phát triển một chương trình lớn hơn, điều này tạo ra rất nhiều vấn đề ra quyết định sẽ không bao giờ phát sinh trong một dự án phát triển đơn lẻ. Kết quả là, ví dụ, nếu một nhóm gồm 2 lập trình viên hợp tác cho một dự án sẽ mất 10 năm để một người đàn ông thực hiện, họ sẽ không thực hiện trong 5 năm nhưng có lẽ là 8.
  4. Nếu những người cộng tác cho cùng một dự án chỉ gặp nhau trên internet, thì một thành viên của dự án sẽ dễ dàng biến mất (vì anh ta mất hứng thú hoặc vì anh ta không thể truy cập internet được nữa), do đó, thậm chí còn hợp tác khó hơn

Vì vậy, trong khi tôi hiểu hoàn toàn các chương trình đơn giản có thể được phát triển với tư duy GNU, tôi hoàn toàn không thấy các chương trình lớn như GNU / Linux hay gcc có thể thực hiện được như thế nào trên mô hình này. gcc là khoảng 7 triệu dòng mã. Tôi biết các dòng mã không có ý nghĩa gì nhiều, vì trong giai đoạn sau của dự án, lập trình viên năng suất cao hơn là người thực sự sẽ loại bỏ các dòng mã (đơn giản hóa và / hoặc tối ưu hóa dự án), nhưng điều này mang lại cho một số lượng lớn một gcc dự án là.

Vậy theo lý thuyết, ai cũng có thể tự do sửa đổi gcc trong thời gian rảnh, nhưng trong thực tế? Nó được phát triển bởi những người rất chuyên nghiệp như một công việc, không phải là một sở thích. Bất cứ ai làm trình biên dịch như một sở thích cuối cùng sẽ từ bỏ vì chi phí / lợi ích không đáng là bao:

  • Phát triển một chương trình lớn là một dự án lớn dài hạn như vậy, họ muốn sử dụng thời gian rảnh của mình để có các hoạt động khác bổ ích hơn hoặc thú vị hơn trong ngắn hạn
  • Nếu họ muốn phát triển một chương trình lớn, họ muốn làm điều đó cho một công ty sẽ trả tiền cho họ hơn là làm miễn phí

Để thu hút mọi người quan tâm đến việc phát triển một chương trình như GNU / Linux, gcc hoặc Open Office trong thời gian dài, nó cần phải có phần thưởng. Vì vậy, câu hỏi của tôi là: Tại sao có người đóng góp cho dự án GNU lớn, nếu họ không nhận được tiền lương cho nó?


Bạn có thể cung cấp một số bằng chứng cho các điểm 2, 3 và 4 không? Tôi không đồng ý với điểm 2 nhất, nhưng 3 và 4 cũng là những quan điểm thú vị mà tôi chưa thực sự có kinh nghiệm khi phát triển phần mềm nguồn mở. Tôi sẽ cập nhật những kinh nghiệm của riêng mình khi có thời gian
christopherlovell

Giếng 2 phụ thuộc rất nhiều vào ngôn ngữ lập trình và nỗ lực đưa vào tài liệu về kiến ​​trúc của chương trình. Về bằng chứng, tôi có thể tìm thấy cái này , cái nàycái này
Bregalad

@Bregalad hai ví dụ của bạn trong nhận xét của bạn là hơn 9 tuổi. Phần mềm nguồn mở đã đi một chặng đường dài kể từ đó, được kích hoạt bởi sự phát triển của web và phổ biến các công cụ như git giúp chia sẻ và phát triển mã tốt, dễ đọc hơn rất nhiều.
christopherlovell

1
@Bregalad trong ví dụ khác của bạn từ SE / Lập trình viên, hầu như mọi câu trả lời được đánh giá cao đều tranh chấp lý do thứ hai của bạn về độ phức tạp cao hơn, cụ thể là đọc mã không nhất thiết khó hơn viết nó. Câu cuối cùng trong thời điểm này, rằng nhân bản một dự án từ đầu có thể dễ dàng hơn việc thêm vào nó, giả sử rằng bạn biết, thậm chí không đọc mã, cách thức hoạt động và cách tạo lại thuật toán. Tôi có thể nói với bạn từ kinh nghiệm rằng phát minh ra một thuật toán thanh lịch và hiệu quả cho một vấn đề là một nhiệm vụ khó khăn hơn nhiều so với việc mã hóa nó :)
christopherlovell

Câu trả lời:


5

Tôi muốn bắt đầu bằng cách nói rằng tôi không phải là lập trình viên và tôi chưa bao giờ đóng góp cho bất kỳ dự án nguồn mở nào. Tuy nhiên, tôi đã quan tâm đến nguồn mở trong một thời gian dài và tôi tin rằng tôi hiểu các khái niệm chung về nguồn mở và cách thức hoạt động của nó.

Để bắt đầu, tôi muốn nói rằng nguồn mở không có nghĩa là bạn không thể kiếm tiền trên phần mềm. Nó chỉ có nghĩa là mã phải được công khai. Các công ty như Red Hat và Canonical kiếm tiền không phải bằng cách bán phần mềm, mà bằng cách bán chuyên môn của họ. Nếu tôi không phải là công ty của tôi để chạy máy chủ Linux, tôi có thể nhận phần mềm miễn phí. Nhưng tôi cần ai đó cài đặt nó, thiết lập và hỗ trợ. Đây là nơi chuyên gia từ ví dụ Red Hat đến và kiếm tiền. Đối với công ty nó có ý nghĩa, bởi vì thuê chuyên gia riêng của họ có thể sẽ tốn kém hơn nhiều. Điều này cũng mang lại cho các công ty này một động lực để đóng góp mã. Họ muốn sản phẩm của họ tốt nên mọi người sẽ sử dụng nó và bởi dịch vụ của họ.

Nhưng hãy nói về quan điểm của bạn về khả năng mở rộng.

  1. Điều thú vị về nguồn mở là bạn không phải phát triển mọi thứ từ đầu. Một hệ điều hành như Ubuntu đã không được xây dựng bởi một người. Thay vào đó, rất nhiều người đã đóng góp cho các phần khác nhau của hệ thống (thực sự tôi nghĩ rằng thật khó để tìm thấy một người có tất cả các kỹ năng để tạo ra và vận hành hệ thống hiệu quả). Ví dụ, người Ubuntu không phát triển nhân Linux. Họ chỉ sử dụng một được phát triển bởi những người khác. Vì vậy, những gì không có nguồn mở có lẽ là không thể, bây giờ là có thể, bởi vì bạn có thể xây dựng trên các công việc của người khác.

  2. Đọc và hiểu mã người khác không tốn nhiều thời gian hơn viết của riêng bạn. Ít nhất là không trong nhiều trường hợp. Ngoài ra, bạn không cần phải hiểu tất cả các mã bạn sử dụng. Nếu tôi muốn viết một chương trình cho Linux, tôi không cần phải hiểu chi tiết tất cả các phần trong chương trình đó như thế nào. Tôi chỉ cần biết những gì họ làm. Sau đó tôi có thể lấy các phần này và đặt chúng cùng với các phần khác để tạo chương trình của tôi. Hoặc tôi có thể lấy một chương trình hiện có và sửa đổi nó cho nhu cầu của tôi.

  3. các công cụ như git và github giúp cộng tác cực kỳ dễ dàng. Bạn chỉ cần lấy mã và thực hiện sửa đổi. Sau đó, bạn gửi chúng cho người phụ trách dự án. Nếu nó tốt, nó sẽ được chấp nhận.

  4. mọi người đi vào và ra khỏi các dự án mọi lúc Nhưng nếu dự án là phổ biến, đủ sẽ làm việc với nó.

Dưới đây là một số lý do tại sao nguồn mở hoạt động.

  1. Tôi nghĩ lý do chính khiến phần mềm nguồn mở trở nên tốt là do số lượng lớn người làm việc trong dự án, đảm bảo mức độ chuyên môn mà tôi khó lưu trữ trong một nhóm nhỏ các nhà phát triển. Mặc dù nó có vẻ kỳ lạ, nhưng thực tế duy nhất này, dường như lớn hơn tất cả các vấn đề tiêu cực có thể phát sinh trong nguồn mở.

  2. Trong lập trình thương mại, dự án chết với công ty. Hãy nói với bạn bởi một số phần mềm từ một công ty sau đó đóng cửa. Sau đó, bạn sẽ gặp rắc rối, vì bạn sẽ không nhận được các bản cập nhật và sửa lỗi và bạn sẽ cần bằng phần mềm mới để theo kịp. Với mã nguồn mở, bạn có thể tìm một công ty khác để hỗ trợ phần mềm hoặc tự phát triển nó.

Nếu bạn vẫn quan tâm, tôi khuyên bạn nên đọc Nhà thờ và Chợ.


Tôi không đồng ý với bất kỳ điều gì bạn nói, nhưng thực sự, tôi không thể chấp nhận câu trả lời, vì nó không trả lời câu hỏi của tôi. Bạn dường như cố gắng thuyết phục tôi rằng GNU tuyệt vời như thế nào, nhưng không có ích gì vì tôi đã bị thuyết phục từ lâu. Bạn cũng nghiêm túc đánh giá thấp những khó khăn trong việc sửa đổi và điều chỉnh mã của người khác, cũng như điều phối nhiều người làm việc trong một dự án phần mềm. Tôi có thể đã phóng đại các vấn đề trong câu hỏi của mình, nhưng vẫn có thể là một vấn đề lớn. Tôi vẫn không biết làm thế nào phần mềm GNU lớn duy trì kinh tế.
Bregalad

Có lẽ bạn nên đăng nó trên stackoverflow và nhận được câu trả lời từ một số lập trình viên thực thụ. Họ có thể cung cấp cho bạn một câu trả lời dựa trên kinh nghiệm thực tế.
Rud Faden

1
Quan điểm của bạn về Red Hat là đứng vững, nhưng sau khi xem xét nhanh các đề xuất công việc của họ, hầu hết chúng đều liên quan đến bán hàng, tiếp thị và hỗ trợ kỹ thuật, và chỉ có một tỷ lệ nhỏ là mở cửa phát triển. (Điều này cho thấy một dấu hiệu tốt là thu nhập của họ đến từ đâu và cách phân phối doanh thu của họ). Ngoài ra, câu hỏi này có thể bị đánh dấu ngoài chủ đề trên Stack Overflow (mặc dù tôi sẽ phải đọc lại trợ giúp để chắc chắn)
Bregalad

@Bregalad Nhưng ngay cả khi bạn đang sửa đổi mã của người khác; bạn có một cộng đồng để thu hút, để hỏi họ cách thức hoạt động của một cái gì đó. (Đây có thể là một khái niệm xa lạ đối với các nhà phát triển phần mềm độc quyền hoặc thậm chí là kinh doanh nói chung, vì tập trung vào cá nhân hoặc tiền bạc, và không phải là sự cải thiện của phần mềm ... cho toàn bộ cộng đồng). Ngoài ra, những người trong cộng đồng cũng có mối quan tâm đến việc giữ cho phần mềm đó chạy vì họ cũng có thể sử dụng nó cho mục đích gì đó; nếu không thì tại sao họ lại đóng góp? (có thể nổi tiếng ... nhưng nếu dự án nguồn mở của bạn chết, điều đó sẽ giúp ích như thế nào?)
leeand00

@Bregalad Ngoài ra, dự án của một số công ty (các công ty sử dụng cũng như mã hóa phần mềm) chứ không phải là một điểm thất bại của một công ty phát triển phần mềm đảm bảo rằng bạn sẽ ít phải trích xuất Chuyển đổi và tải dữ liệu của mình vào một hệ thống khác khi một số công ty khác thất bại hoặc bị thị trường ăn mòn.
leeand00

2

Phát triển phần mềm nguồn mở được thực hiện vì nhiều lý do, nhưng đó là một sự hiểu lầm phổ biến rằng nó được thực hiện chủ yếu bởi những người có sở thích hoặc chuyên nghiệp nhưng là một dự án phụ. Tôi đang trả lời câu hỏi này cho nguồn mở nói chung, không phải phần mềm được cấp phép GNU nói riêng. Nhưng câu trả lời của tôi là bao gồm.

Giả sử tôi là nhà phát triển phần mềm (tôi) và tôi đang làm việc trong một dự án phần mềm phức tạp (tôi). Kiến trúc tốt chia một vấn đề thành các phần độc lập và khi quá trình phát triển diễn ra, các nhà phát triển sẽ thường nhận ra rằng một số phần họ cần là một phần phổ biến cho rất nhiều vấn đề. Dưới đây là một số con đường điển hình phía trước:

  1. Họ tự phát triển mảnh đó và nó trở thành tài sản của công ty. Hoặc họ mua một giải pháp nguồn đóng từ một công ty khác.
  2. Họ tìm thấy một dự án nguồn mở giải quyết vấn đề này và đó là một sự phù hợp hoàn hảo và giấy phép phù hợp. Họ chỉ kết hợp nó vào dự án của họ, có thể cần hoặc không cần nguồn mở tùy thuộc vào giấy phép và cách sử dụng. Họ không đóng góp lại cho dự án.
  3. Họ tìm thấy một dự án nguồn mở gần như giải quyết được vấn đề này nhưng có khiếm khuyết hoặc thiếu sót. Họ cải thiện nó và họ có thể đóng góp những cải tiến đó cho dự án cơ sở.
  4. Họ không tìm thấy bất cứ thứ gì họ thích đủ, vì vậy họ bắt đầu dự án của riêng mình và quyết định mở nguồn đó.

Ưu điểm của 2-4 là nhiều người cuối cùng đóng góp vào cả thiết kế và mã của dự án, và nó đi vào một loại hệ sinh thái nơi những ý tưởng mạnh mẽ tồn tại (bằng cách sinh sản nếu bạn muốn) và những người yếu không làm được. Sửa lỗi và bổ sung tính năng trở thành nỗ lực của cộng đồng. Trong các kịch bản # 2 và 3, các nhà phát triển áp dụng dự án được hưởng lợi từ các nguyên tắc kỹ thuật âm thanh và mã trưởng thành. 3 và 4 là tương quan. Trong kịch bản # 4, các nhà phát triển được hưởng lợi khi những người khác chấp nhận và cải thiện mã và trả lại (# 3). Thật thuận lợi khi đóng góp lại cho dự án để các cải tiến của bạn được củng cố khi các bản sửa lỗi và cải tiến khác vượt lên trên chúng, mà bạn tiếp tục được hưởng lợi. Theo kinh nghiệm của tôi, tất cả các kịch bản này là phổ biến.

Trong dự án phần mềm hiện tại của tôi, tôi là một trong khoảng 12 nhà phát triển và đã làm việc trên một hệ thống trong khoảng hai năm. Chúng tôi đã kết hợp khoảng 5.000 dự án nguồn mở! Chúng tôi chỉ sinh ra một vài dự án FOSS mới và đóng góp lại cho khoảng nửa tá. Chúng tôi không phải là công dân đặc biệt tốt trong trường hợp này (các công ty khác tốt hơn nhiều), nhưng điều này cho bạn thấy quy mô tuyệt vời về cách thức hoạt động của tất cả những điều này. Ngay cả trên các dự án nhỏ, đóng góp từ nguồn mở có thể dễ dàng đánh số trong hàng chục hoặc hàng trăm. Nếu chúng tôi không sử dụng bất kỳ phần mềm nguồn mở nào, chi phí phát triển sẽ tăng theo hệ số 100-10.000.

Khả năng mở rộng xảy ra do tính mô đun của thiết kế và cũng thông qua loại quy trình sinh tồn tốt nhất này, nơi mã có thể được tái cấu trúc, rẽ nhánh, v.v. Khả năng sống sót thường tốt hơn các lựa chọn thay thế độc quyền bởi vì ngay cả khi mã không còn được duy trì, nó vẫn ở ngoài đó và những người khác tìm thấy giá trị trong đó có thể duy trì ngã ba của chính nó. Các công ty đến và đi và nhân viên được thuê và nghỉ việc thậm chí nhanh hơn. Nếu bạn thêm một phụ thuộc phần mềm mà bạn không có mã nguồn hoặc chỉ có một nhóm nhỏ trong nhà để duy trì, bạn đã phải chịu rủi ro đáng kể. Các dự án lớn như nhân Linux, gcc, Android và các dự án khác thường có một số lượng lớn các công ty đóng góp tích cực.

Không đúng khi viết mã tốt và chính xác hơn đọc mã (trong hầu hết các trường hợp). Bạn cũng không phải đọc tất cả các phần mềm bạn đang sử dụng ngay cả khi bạn đang thực hiện sửa đổi. Bạn phải đi sâu vào các phần của nó và đọc rất nhiều, nhưng không phải toàn bộ. Tôi có thể nói nhiều hơn ở đây về các bài kiểm tra đơn vị, nhưng sẽ bỏ qua điều đó cho ngắn gọn.

Phần lớn các phần mềm nguồn mở không được mọi người phát triển trong thời gian rảnh. Thực tế là rất có lợi đến nỗi nó hoạt động mà không cần tối ưu hóa thị trường. Cá nhân tôi nghi ngờ một số cách tiếp cận dựa trên thị trường sẽ giúp ích rất nhiều, nhưng tôi không biết cách tiếp cận đó sẽ như thế nào. Mọi người tranh luận rằng có một thị trường nơi danh tiếng là tiền tệ, nhưng tôi không nghĩ đó là một mô hình chính xác. Một loại tiền tệ tại nơi làm việc là thời gian cần thiết để áp dụng một phần mềm mới. Bạn muốn tìm và sử dụng một cái gì đó hoạt động, đơn giản, có tài liệu tốt, v.v ... Vì vậy, giống như một người mua hàng bạn đang tìm kiếm sản phẩm chất lượng tốt nhất với thời gian đầu tư ít nhất.

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.