Một lễ hội CNTT sẽ được tổ chức tại St. Petersburg trong tuần này . Một trong những diễn giả sẽ là Richard Stallman. cũng tham gia lễ hội và tất nhiên chúng tôi không thể bỏ qua chủ đề phần mềm miễn phí. Đó là lý do tại sao một trong những báo cáo của chúng tôi được gọi là . Nó sẽ được dành riêng cho lịch sử phát triển của Embox như một dự án nguồn mở. Trong bài viết này, tôi muốn nói về những ý tưởng chính mà theo tôi, ảnh hưởng đến sự phát triển của các dự án nguồn mở. Bài viết, giống như báo cáo, dựa trên kinh nghiệm cá nhân.
Hãy bắt đầu với điều gì đó đơn giản, với định nghĩa của thuật ngữ mã nguồn mở. Rõ ràng, dự án nguồn mở là dự án có một trong các giấy phép cho phép truy cập vào mã nguồn của dự án. Ngoài ra, một dự án mở có nghĩa là các nhà phát triển bên thứ ba có thể thực hiện các thay đổi. Nghĩa là, nếu một số công ty hoặc nhà phát triển xuất bản mã sản phẩm của họ, một phần hoặc toàn bộ, thì điều này vẫn chưa khiến sản phẩm này trở thành một dự án nguồn mở. Và cuối cùng, bất kỳ hoạt động nào của dự án đều phải dẫn đến một loại kết quả nào đó và tính mở của dự án ngụ ý rằng kết quả này không chỉ được sử dụng bởi chính các nhà phát triển.
Chúng tôi sẽ không đề cập đến các vấn đề của giấy phép mở. Đây là một chủ đề quá lớn và phức tạp đòi hỏi phải điều tra chuyên sâu. Khá nhiều bài viết và tài liệu hay đã được viết về chủ đề này. Nhưng vì bản thân tôi không phải là chuyên gia trong lĩnh vực bản quyền nên tôi chỉ nói rằng giấy phép phải đáp ứng được mục tiêu của dự án. Ví dụ: đối với Embox, việc lựa chọn giấy phép BSD thay vì giấy phép GPL không phải là ngẫu nhiên.
Thực tế là một dự án nguồn mở sẽ cung cấp khả năng thực hiện các thay đổi và ảnh hưởng đến sự phát triển của dự án nguồn mở ngụ ý rằng dự án đó được phân phối. Quản lý nó, duy trì tính toàn vẹn và hiệu suất khó khăn hơn nhiều so với một dự án được quản lý tập trung. Một câu hỏi hợp lý được đặt ra: tại sao lại mở dự án? Câu trả lời nằm ở tính khả thi về mặt thương mại; đối với một loại dự án nhất định, lợi ích của phương pháp này lớn hơn chi phí. Nghĩa là, nó không phù hợp với tất cả các dự án và cách tiếp cận mở thường được chấp nhận. Ví dụ, thật khó để tưởng tượng việc phát triển một hệ thống điều khiển cho nhà máy điện hoặc máy bay dựa trên nguyên lý mở. Tất nhiên là không, những hệ thống như vậy nên bao gồm các mô-đun dựa trên các dự án mở, vì điều này sẽ mang lại một số lợi thế. Nhưng phải có ai đó chịu trách nhiệm về sản phẩm cuối cùng. Ngay cả khi hệ thống hoàn toàn dựa trên mã của các dự án mở, nhà phát triển, sau khi đóng gói mọi thứ vào một hệ thống và thực hiện các bản dựng và cài đặt cụ thể, về cơ bản sẽ đóng nó lại. Mã có thể được cung cấp công khai.
Ngoài ra còn có rất nhiều lợi ích cho các hệ thống này từ việc tạo hoặc đóng góp cho các dự án nguồn mở. Như tôi đã nói, mã hệ thống cuối có thể vẫn được công khai. Tại sao, bởi vì rõ ràng là khó có ai có cùng một chiếc máy bay để thử nghiệm hệ thống. Điều này đúng, nhưng cũng có thể có ai đó muốn kiểm tra một số phần nhất định của mã, hoặc chẳng hạn, ai đó có thể phát hiện ra rằng thư viện đang được sử dụng không được cấu hình hoàn toàn chính xác.
Lợi ích thậm chí còn lớn hơn nếu công ty phân bổ một số phần cơ bản của hệ thống vào một dự án riêng. Ví dụ: một thư viện hỗ trợ một số loại giao thức trao đổi dữ liệu. Trong trường hợp này, ngay cả khi giao thức dành riêng cho một lĩnh vực chủ đề nhất định, bạn có thể chia sẻ chi phí duy trì phần hệ thống này với các công ty khác trong lĩnh vực đó. Ngoài ra, các chuyên gia có thể nghiên cứu phần này của hệ thống trong phạm vi công cộng sẽ cần ít thời gian hơn để sử dụng nó một cách hiệu quả. Và cuối cùng, việc tách một phần thành một thực thể độc lập mà các nhà phát triển bên thứ ba sử dụng cho phép chúng tôi cải thiện phần này vì chúng tôi cần cung cấp các API hiệu quả, tạo tài liệu và tôi thậm chí không nói về việc cải thiện phạm vi thử nghiệm.
Một công ty có thể nhận được lợi ích thương mại mà không cần tạo các dự án nguồn mở; chỉ cần các chuyên gia của công ty đó tham gia vào các dự án của bên thứ ba được sử dụng trong công ty là đủ. Rốt cuộc, tất cả các lợi ích vẫn còn: nhân viên hiểu rõ hơn về dự án, do đó họ sử dụng nó hiệu quả hơn, công ty có thể tác động đến hướng phát triển của dự án và việc sử dụng mã gỡ lỗi được tạo sẵn rõ ràng giúp giảm chi phí của công ty.
Lợi ích của việc tạo các dự án nguồn mở không dừng lại ở đó. Hãy coi một thành phần quan trọng của kinh doanh là tiếp thị. Đối với anh, đây là một hộp cát rất tốt cho phép anh đánh giá hiệu quả các yêu cầu của thị trường.
Và tất nhiên, chúng ta không được quên rằng một dự án mã nguồn mở là một cách hiệu quả để tuyên bố mình là người vận chuyển bất kỳ chuyên môn nào. Trong một số trường hợp, đây là cách duy nhất để thâm nhập thị trường. Ví dụ: Embox bắt đầu như một dự án tạo RTOS. Có lẽ không cần phải giải thích rằng có rất nhiều đối thủ cạnh tranh. Nếu không tạo cộng đồng, đơn giản là chúng tôi sẽ không có đủ nguồn lực để đưa dự án đến với người dùng cuối, tức là để các nhà phát triển bên thứ ba bắt đầu sử dụng dự án.
Cộng đồng là chìa khóa trong một dự án nguồn mở. Nó cho phép bạn giảm đáng kể chi phí quản lý dự án, phát triển và hỗ trợ dự án. Chúng ta có thể nói rằng không có cộng đồng thì không có dự án nguồn mở nào cả.
Rất nhiều tài liệu đã được viết về cách tạo và quản lý một cộng đồng dự án nguồn mở. Để không kể lại những sự thật đã biết, tôi sẽ cố gắng tập trung vào trải nghiệm của Embox. Ví dụ, quá trình tạo cộng đồng là một vấn đề rất thú vị. Nghĩa là, nhiều người nói về cách quản lý một cộng đồng hiện có, nhưng những khoảnh khắc hình thành cộng đồng đó đôi khi bị bỏ qua, coi đây là điều hiển nhiên.
Quy tắc chính khi tạo cộng đồng dự án nguồn mở là không có quy tắc nào cả. Ý tôi là không có quy tắc chung nào, giống như không có viên đạn bạc, nếu chỉ vì các dự án rất khác nhau. Bạn khó có thể sử dụng các quy tắc tương tự khi tạo cộng đồng cho thư viện ghi nhật ký js và một số trình điều khiển chuyên dụng cao. Hơn nữa, ở các giai đoạn phát triển khác nhau của dự án (và do đó là cộng đồng), các quy tắc sẽ thay đổi.
Embox bắt đầu như một dự án sinh viên vì nó có quyền truy cập vào sinh viên từ bộ phận lập trình hệ thống. Trên thực tế, chúng tôi đang bước vào một số cộng đồng khác. Chúng tôi có thể thu hút sự quan tâm của những người tham gia cộng đồng này, các sinh viên, đến thực hành công nghiệp tốt trong chuyên môn, công việc khoa học của họ trong lĩnh vực lập trình hệ thống, các khóa học và bằng cấp. Nghĩa là, chúng tôi tuân theo một trong những quy tắc cơ bản khi tổ chức cộng đồng: thành viên cộng đồng phải nhận được thứ gì đó và mức giá này phải tương ứng với sự đóng góp của người tham gia.
Giai đoạn tiếp theo của Embox là tìm kiếm người dùng bên thứ ba. Điều rất quan trọng là phải hiểu rằng người dùng là những người tham gia đầy đủ vào cộng đồng nguồn mở. Thường có nhiều người dùng hơn nhà phát triển. Và để muốn trở thành người đóng góp cho một dự án, trước tiên họ phải bắt đầu sử dụng nó bằng cách này hay cách khác.
Những người sử dụng Embox đầu tiên là Khoa Điều khiển học Lý thuyết. Họ đề nghị tạo một phần sụn thay thế cho Lego Mindstorm. Và mặc dù đây vẫn là những người dùng địa phương (chúng tôi có thể gặp họ trực tiếp và thảo luận về những gì họ muốn). Nhưng đó vẫn là một trải nghiệm rất tốt. Ví dụ: chúng tôi đã phát triển các bản demo có thể cho người khác xem vì robot rất thú vị và thu hút sự chú ý. Kết quả là chúng tôi đã có được những người dùng bên thứ ba thực sự bắt đầu hỏi Embox là gì và cách sử dụng nó.
Ở giai đoạn này, chúng tôi phải suy nghĩ về tài liệu, về phương tiện giao tiếp với người dùng. Không, tất nhiên, chúng tôi đã nghĩ đến những điều quan trọng này trước đây, nhưng nó còn quá sớm và không mang lại hiệu quả tích cực. Hiệu quả khá tiêu cực. Để tôi cho bạn một số ví dụ. Chúng tôi đã sử dụng googlecode, có wiki hỗ trợ đa ngôn ngữ. Chúng tôi đã tạo các trang bằng nhiều ngôn ngữ, không chỉ tiếng Anh và tiếng Nga, những ngôn ngữ mà chúng tôi khó giao tiếp, mà còn cả tiếng Đức và tiếng Tây Ban Nha. Kết quả là, khi được hỏi bằng những ngôn ngữ này trông rất buồn cười nhưng chúng tôi không thể trả lời gì cả. Hoặc họ đưa ra các quy tắc về viết tài liệu và nhận xét, nhưng vì API thay đổi khá thường xuyên và đáng kể nên hóa ra tài liệu của chúng tôi đã lỗi thời và gây hiểu lầm nhiều hơn những gì nó giúp ích.
Kết quả là mọi cố gắng của chúng ta, kể cả sai lầm, đều dẫn đến sự xuất hiện của người dùng bên ngoài. Và ngay cả một khách hàng thương mại cũng xuất hiện, người muốn RTOS của riêng mình được phát triển cho mình. Và chúng tôi phát triển nó vì chúng tôi có kinh nghiệm và một số nền tảng. Ở đây bạn cần nói về cả những khoảnh khắc tốt và xấu. Tôi sẽ bắt đầu với những cái xấu. Vì nhiều nhà phát triển tham gia vào dự án này trên cơ sở thương mại nên cộng đồng vốn đã khá bất ổn và chia rẽ, điều này tất nhiên không thể làm ảnh hưởng đến sự phát triển của dự án. Một yếu tố nữa là định hướng của dự án được đặt ra bởi một khách hàng thương mại và mục tiêu của anh ta không phải là phát triển thêm dự án. Ít nhất đây không phải là mục tiêu chính.
Mặt khác, có một số khía cạnh tích cực. Chúng tôi có người dùng bên thứ ba thực sự. Đó không chỉ là khách hàng mà còn cả những người được hướng tới hệ thống này. Động lực tham gia dự án ngày càng tăng. Suy cho cùng, nếu bạn cũng có thể kiếm tiền từ một công việc kinh doanh thú vị thì điều đó luôn tốt đẹp. Và quan trọng nhất, chúng tôi đã nghe thấy một mong muốn từ khách hàng, điều mà vào thời điểm đó có vẻ điên rồ đối với chúng tôi, nhưng đó hiện là ý tưởng chính của Embox, đó là sử dụng mã đã được phát triển trong hệ thống. Bây giờ ý tưởng chính của Embox là sử dụng phần mềm Linux mà không cần Linux. Nghĩa là, khía cạnh tích cực chính góp phần vào sự phát triển hơn nữa của dự án là việc nhận ra rằng dự án được người dùng bên thứ ba sử dụng và nó sẽ giải quyết được một số vấn đề của họ.
Vào thời điểm đó, Embox đã vượt ra ngoài phạm vi một dự án sinh viên. Yếu tố hạn chế chính trong việc phát triển dự án theo mô hình sinh viên là động lực của người tham gia. Sinh viên tham gia khi đang học và khi tốt nghiệp phải có động lực khác. Nếu động lực không xuất hiện, học sinh chỉ cần ngừng tham gia dự án. Nếu tính rằng sinh viên trước hết cần được đào tạo thì hóa ra khi tốt nghiệp họ sẽ trở thành chuyên gia giỏi, nhưng đóng góp của họ cho dự án do thiếu kinh nghiệm nên không lớn lắm.
Nói chung, chúng ta dễ dàng chuyển sang điểm chính cho phép chúng ta nói về việc tạo một dự án nguồn mở - tạo ra một sản phẩm có thể giải quyết các vấn đề của người dùng. Như tôi đã giải thích ở trên, đặc tính chính của một dự án nguồn mở là cộng đồng của nó. Hơn nữa, các thành viên cộng đồng chủ yếu là người dùng. Nhưng chúng đến từ đâu khi không có gì để sử dụng? Vì vậy, hóa ra, giống như với một dự án không phải nguồn mở, bạn cần tập trung vào việc tạo MVP (sản phẩm khả thi tối thiểu) và nếu nó thu hút người dùng thì một cộng đồng sẽ xuất hiện xung quanh dự án. Nếu bạn tham gia vào việc tạo cộng đồng chỉ thông qua PR cộng đồng, viết wiki bằng tất cả các ngôn ngữ trên thế giới hoặc sửa quy trình làm việc git trên github, thì điều này khó có thể thành vấn đề trong giai đoạn đầu của dự án. Tất nhiên, ở những giai đoạn thích hợp, đây không chỉ là những điều quan trọng mà còn là những điều cần thiết.
Để kết luận, tôi muốn chỉ ra , theo ý kiến của tôi, phản ánh kỳ vọng của người dùng từ một dự án nguồn mở:
Tôi đang suy nghĩ nghiêm túc về việc chuyển sang hệ điều hành này (ít nhất hãy thử. Họ đang tích cực theo đuổi nó và làm những điều thú vị).
PS Bật Chúng tôi sẽ có tối đa ba báo cáo. Một về nguồn mở và hai về nhúng (và một về thực tế). Tại gian hàng, chúng tôi sẽ tiến hành một lớp học tổng thể về lập trình bộ vi điều khiển bằng cách sử dụng . Như thường lệ, chúng tôi sẽ mang phần cứng đến và để bạn lập trình nó. Cũng sẽ có một nhiệm vụ và các hoạt động khác. Hãy đến với lễ hội và gian hàng của chúng tôi, sẽ rất vui.
Nguồn: www.habr.com