Bu hafta St. Petersburg'da bir BT festivali düzenlenecek . Konuşmacılardan biri Richard Stallman olacak. Festivale biz de katılıyor ve elbette özgür yazılım konusunu da görmezden gelemeyiz. Bu yüzden raporlarımızdan birine . Açık kaynaklı bir proje olarak Embox'un gelişim tarihine adanacak. Bu yazıda açık kaynaklı projelerin gelişimini etkileyen ana fikirlerden bahsetmek istiyorum. Rapor gibi makale de kişisel deneyime dayanıyor.
Basit bir şeyle, açık kaynak teriminin tanımıyla başlayalım. Açıkçası, açık kaynaklı bir proje, projenin kaynak koduna erişime izin veren lisanslardan birine sahip olan bir projedir. Ayrıca açık proje, üçüncü taraf geliştiricilerin değişiklik yapabileceği anlamına gelir. Yani, bir şirket veya geliştirici, ürününün kodunu kısmen veya tamamen yayınlıyorsa, bu, bu ürünü henüz açık kaynaklı bir proje yapmaz. Ve son olarak, herhangi bir proje faaliyeti bir tür sonuca yol açmalıdır ve projenin açıklığı, bu sonucun yalnızca geliştiriciler tarafından kullanılmadığını ima eder.
Açık lisansların sorunlarına değinmeyeceğiz. Bu çok geniş ve karmaşık, derinlemesine araştırma gerektiren bir konudur. Bu konuyla ilgili pek çok güzel makale ve materyal yazıldı. Ancak ben telif hakkı alanında uzman olmadığım için yalnızca lisansın projenin hedeflerini karşılaması gerektiğini söyleyeceğim. Örneğin Embox için GPL lisansı yerine BSD'nin seçilmesi tesadüfi değildi.
Açık kaynaklı bir projenin değişiklik yapma ve açık kaynak projenin gelişimini etkileme yeteneğini sağlaması, projenin dağıtıldığı anlamına gelir. Bunu yönetmek, bütünlüğü ve performansı sürdürmek, merkezi yönetimli bir projeye kıyasla çok daha zordur. Makul bir soru ortaya çıkıyor: neden projeler açılıyor? Cevap ticari fizibilite alanında yatıyor; belirli bir proje sınıfı için bu yaklaşımın faydaları maliyetlerinden daha ağır basıyor. Yani her projeye uygun değildir ve açık yaklaşım genel olarak kabul edilebilirdir. Örneğin bir enerji santrali veya bir uçak için açık prensibe dayalı bir kontrol sistemi geliştirmeyi hayal etmek zordur. Hayır elbette bu tür sistemlerin açık projelere dayalı modüller içermesi gerekiyor çünkü bu bir takım avantajlar sağlayacaktır. Ancak nihai üründen birisinin sorumlu olması gerekir. Sistem tamamen açık projelerin koduna dayansa bile, her şeyi tek bir sistemde paketleyen ve belirli yapılar ve ayarlar yapan geliştirici, aslında onu kapatır. Kod herkese açık olabilir.
Açık kaynaklı projeler oluşturmanın veya katkıda bulunmanın da bu sistemlere birçok faydası vardır. Daha önce de söylediğim gibi, son sistem kodu kamuya açık kalabilir. Neden, çünkü herhangi birinin sistemi test etmek için aynı uçağa sahip olma ihtimalinin düşük olduğu açık. Bu doğrudur, ancak kodun belirli bölümlerini kontrol etmek isteyen biri olabilir veya örneğin birisi, kullanılan kitaplığın tam olarak doğru yapılandırılmadığını keşfedebilir.
Şirketin sistemin bazı temel kısımlarını ayrı bir projeye ayırması durumunda daha da büyük bir fayda ortaya çıkar. Örneğin, bir çeşit veri alışverişi protokolünü destekleyen bir kütüphane. Bu durumda protokol belirli bir konu alanına özel olsa bile sistemin bu parçasının bakım masraflarını bu alandaki diğer şirketlerle paylaşabilirsiniz. Ayrıca sistemin bu parçasını kamuya açık olarak inceleyebilen uzmanların, onu etkili bir şekilde kullanmak için çok daha az zamana ihtiyacı vardır. Ve son olarak, bir parçayı üçüncü taraf geliştiricilerin kullandığı bağımsız bir varlığa ayırmak, bu parçayı daha iyi hale getirmemize olanak tanıyor çünkü etkili API'ler sunmamız, belgeler oluşturmamız gerekiyor ve test kapsamının iyileştirilmesinden bahsetmiyorum bile.
Bir şirket açık kaynaklı projeler oluşturmadan ticari faydalar elde edebilir; uzmanlarının şirkette kullanılan üçüncü taraf projelere katılması yeterlidir. Sonuçta, tüm faydalar devam ediyor: Çalışanlar projeyi daha iyi tanıyor, dolayısıyla onu daha etkili kullanıyorlar, şirket projenin gelişim yönünü etkileyebilir ve hazır, hata ayıklamalı kodun kullanılması şirketin maliyetlerini açıkça azaltır.
Açık kaynaklı projeler oluşturmanın faydaları burada bitmiyor. Pazarlama gibi işin önemli bir bileşenini ele alalım. Onun için bu, pazar gereksinimlerini etkili bir şekilde değerlendirmesine olanak tanıyan çok iyi bir sanal alan.
Ve elbette, açık kaynaklı bir projenin kendinizi herhangi bir uzmanlığın taşıyıcısı olarak ilan etmenin etkili bir yolu olduğunu unutmamalıyız. Bazı durumlarda pazara girmenin tek yolu budur. Örneğin Embox, bir RTOS oluşturma projesi olarak başladı. Muhtemelen çok fazla rakibin olduğunu açıklamaya gerek yok. Bir topluluk oluşturmasaydık, projeyi son kullanıcıya ulaştırmak, yani üçüncü taraf geliştiricilerin projeyi kullanmaya başlaması için yeterli kaynağa sahip olamazdık.
Topluluk, açık kaynaklı bir projede anahtardır. Proje yönetimi maliyetlerini önemli ölçüde azaltmanıza, projeyi geliştirmenize ve desteklemenize olanak tanır. Topluluk olmadan açık kaynak projesinin de olmayacağını söyleyebiliriz.
Açık kaynak proje topluluğunun nasıl oluşturulacağı ve yönetileceği hakkında pek çok materyal yazıldı. Zaten bilinen gerçekleri tekrar anlatmamak için Embox deneyimine odaklanmaya çalışacağım. Örneğin topluluk oluşturma süreci çok ilginç bir konudur. Yani, çoğu kişi mevcut bir topluluğun nasıl yönetileceğini anlatıyor, ancak bunun bir veri olduğu düşünüldüğünde, yaratılma anları bazen gözden kaçırılıyor.
Açık kaynak proje topluluğu oluştururken ana kural, hiçbir kuralın olmamasıdır. Yani projeler çok farklı olduğu için de olsa, sihirli bir çözüm olmadığı gibi evrensel kurallar da yok. Bir js günlük kitaplığı ve bazı son derece uzmanlaşmış sürücüler için bir topluluk oluştururken aynı kuralları kullanmanız pek mümkün değildir. Dahası, projenin (ve dolayısıyla topluluğun) gelişiminin farklı aşamalarında kurallar değişir.
Embox bir öğrenci projesi olarak başladı çünkü sistem programlama bölümündeki öğrencilere erişimi vardı. Aslında başka bir topluluğa giriyorduk. Bu topluluğun katılımcılarının, öğrencilerin, uzmanlık alanlarındaki iyi endüstriyel uygulamalara, sistem programlama alanındaki bilimsel çalışmalara, kurs çalışmalarına ve diplomalara ilgi duymalarını sağlayabiliriz. Yani, bir topluluk düzenlemenin temel kurallarından birini izledik: topluluk üyeleri bir şeyler almalı ve bu fiyat, katılımcının katkısına karşılık gelmelidir.
Embox için bir sonraki aşama üçüncü taraf kullanıcıların aranmasıydı. Kullanıcıların açık kaynak topluluğunun tam katılımcıları olduklarını anlamak çok önemlidir. Genellikle geliştiricilerden daha fazla kullanıcı vardır. Ve bir projeye katkı sağlamak için önce onu öyle ya da böyle kullanmaya başlıyorlar.
Embox'ın ilk kullanıcıları Teorik Sibernetik Bölümü idi. Lego Mindstorm için alternatif bir aygıt yazılımı oluşturmayı önerdiler. Ve bunlar hala yerel kullanıcılar olmasına rağmen (onlarla bizzat görüşebilir ve ne istediklerini tartışabilirdik). Ama yine de çok iyi bir deneyimdi. Mesela robotların eğlenceli olması ve dikkat çekmesi nedeniyle başkalarına gösterilebilecek demolar geliştirdik. Sonuç olarak, Embox'ın ne olduğunu ve nasıl kullanılacağını sormaya başlayan gerçek üçüncü taraf kullanıcılarımız oldu.
Bu aşamada dokümantasyon, kullanıcılarla iletişim araçları üzerine düşünmemiz gerekiyordu. Hayır tabii ki daha önce bu önemli şeyleri düşündük ama henüz erkendi ve olumlu bir etki yaratmadı. Etki oldukça olumsuzdu. Size birkaç örnek vereyim. Wiki'si çok dilliliği destekleyen Googlecode'u kullandık. İletişim kurmakta zorluk çektiğimiz İngilizce ve Rusça'nın yanı sıra Almanca ve İspanyolca da dahil olmak üzere birçok dilde sayfalar oluşturduk. Sonuç olarak bu dillerde sorulduğunda çok saçma görünüyor ama hiçbir şekilde cevap veremiyoruz. Veya belge yazma ve yorum yapma konusunda kurallar getirdiler, ancak API oldukça sık ve önemli ölçüde değiştiğinden, belgelerimizin eski olduğu ve yardımcı olmaktan çok yanıltıcı olduğu ortaya çıktı.
Sonuç olarak tüm çabalarımız, hatta yanlış çabalarımız, dış kullanıcıların ortaya çıkmasına neden oldu. Hatta kendisi için kendi RTOS'unun geliştirilmesini isteyen ticari bir müşteri bile ortaya çıktı. Bunu geliştirdik çünkü tecrübemiz ve bazı temellerimiz var. Burada hem iyi anlardan hem de kötü anlardan bahsetmek gerekiyor. Kötü olanlardan başlayacağım. Pek çok geliştirici bu projeye ticari olarak dahil olduğundan, topluluk zaten oldukça istikrarsız ve bölünmüş durumdaydı, bu da elbette projenin gelişimini etkileyemezdi. Ek bir faktör de projenin yönünün bir ticari müşteri tarafından belirlenmesi ve onun hedefinin projenin daha da geliştirilmesi olmamasıydı. En azından asıl amaç bu değildi.
Öte yandan olumlu yönleri de vardı. Gerçekten üçüncü taraf kullanıcılarımız var. Yalnızca müşteri değil, aynı zamanda bu sistemin amaçlandığı kişiler de vardı. Projeye katılım motivasyonu arttı. Sonuçta, eğer ilginç bir işten de para kazanabiliyorsanız, bu her zaman güzeldir. Ve en önemlisi, müşterilerden o zamanlar bize çılgınca gelen ama şimdi Embox'ın ana fikri olan, yani sistemde önceden geliştirilmiş kodu kullanma arzusunu duyduk. Artık Embox'ın ana fikri Linux yazılımını Linux olmadan kullanmaktır. Yani, projenin daha da geliştirilmesine katkıda bulunan ana olumlu yön, projenin üçüncü taraf kullanıcılar tarafından kullanıldığının ve bazı sorunlarının çözülmesi gerektiğinin farkına varılmasıydı.
O zamanlar Embox zaten bir öğrenci projesinin kapsamının ötesine geçmişti. Projenin öğrenci modeline göre geliştirilmesindeki temel sınırlayıcı faktör katılımcıların motivasyonudur. Öğrenciler okurken katılıyorlar, mezun olduklarında da farklı bir motivasyon olması gerekiyor. Motivasyon ortaya çıkmazsa öğrenci projeye katılmayı bırakır. Öğrencilerin öncelikle eğitim almaları gerektiğini dikkate alırsak, mezun olduklarında iyi birer uzman haline geldiklerini ancak deneyimsizlikten dolayı projeye katkılarının çok büyük olmadığını görüyoruz.
Genel olarak, açık kaynaklı bir proje oluşturma - kullanıcılarının sorunlarını çözecek bir ürün oluşturma - hakkında konuşmamızı sağlayan ana noktaya sorunsuz bir şekilde geçiyoruz. Yukarıda açıkladığım gibi açık kaynak kodlu bir projenin ana özelliği topluluğudur. Ayrıca topluluk üyeleri öncelikle kullanıcılardır. Ama kullanılacak hiçbir şey olmadığında nereden geliyorlar? Dolayısıyla, tıpkı açık kaynak olmayan bir projede olduğu gibi, bir MVP (minimum uygulanabilir ürün) oluşturmaya odaklanmanız gerektiği ve eğer kullanıcıların ilgisini çekiyorsa, proje çevresinde bir topluluk ortaya çıkacağı ortaya çıktı. Yalnızca topluluk halkla ilişkiler yoluyla bir topluluk oluşturmakla, dünyanın tüm dillerinde bir wiki yazmakla veya github'da git iş akışını düzeltmekle ilgileniyorsanız, o zaman bunun projenin ilk aşamalarında önemli olması pek olası değildir. Elbette uygun aşamalarda bunlar sadece önemli değil, aynı zamanda gerekli şeylerdir.
Sonuç olarak belirtmek isterim bence, açık kaynaklı bir projeden kullanıcı beklentilerini yansıtıyor:
Bu işletim sistemine geçmeyi ciddi olarak düşünüyorum (en azından deneyin. Aktif olarak bunun peşinde koşuyorlar ve harika şeyler yapıyorlar).
PS Açık En fazla üç raporumuz olacak. Biri açık kaynakla ilgili ve ikisi gömülüyle ilgili (ve biri pratik). Standımızda mikrodenetleyicilerin programlanması konusunda bir ustalık sınıfı gerçekleştireceğiz. . Her zamanki gibi donanımı biz getireceğiz ve programlamanıza izin vereceğiz. Ayrıca bir görev ve diğer aktiviteler de olacak. Festivale ve standımıza gelin, çok eğlenceli olacak.
Kaynak: habr.com