Pardus YN: Strateji

2 Nisan 2011 günü İstanbul Bilgi Üniversitesi‘nde, Linux Kullanıcıları Derneği ve İstanbul Bilgi Üniversitesi Bilgisayar Bilimleri Bölümü işbirliği ile düzenlenen Özgür Yazılım ve Linux Günleri‘nde, Pardus’un geçmişi, bugünü ve geleceği konusunda bir konuşma yapma ve Pardus kullanıcısı ve geliştiricisi konumundaki katılımcılarla bu konuları tartışarak irdeleme fırsatı buldum.

Bu ve izleyecek bir dizi günlük yazısı ile bu konuşmanın içeriğini, konuşma süresine sığdıramadığım bir dizi ilgili hususu ve özellikle önümüzdeki dönem için görüşlerimi paylaşmak istiyorum. İlk yazımızda hayli kısa bir durum değerlendirmesi ardından mevcut Pardus stratejisi ve planlanan/uygulamaya konulan değişiklikler üzerine odaklanacağım.

DURUM DEĞERLENDİRMESİ

2003 yılı Eylül ayında TÜBİTAK UEKAE bünyesinde Özgür Yazılım Geliştirme ve Üretim (ÖZGÜR) iç destekli stratejik projesinin başlatılması ile ilk adımları atılan Pardus, geçen 7,5 yıl içerisinde çok mesafe katetti. Sayısal olarak değerlendirdiğimizde 4 kişilik bir ekiple başlatılan proje, şu anda 35 kişiye yaklaştı ve 2011 sonunda 50 kişi hedefleniyor. Neredeyse olmayan bir bütçeden şu anda 25 milyon TL’lik bir proje portföyüne ulaşıldı, 2011 sonu itibarı ile 35 milyon TL hedefleniyor. 2010 yılı içerisinde dışkaynaklama ve altyüklenicilik yoluyla 1 milyon TL’ye yakın bedelde bir dizi iş çeşitli çözüm ortakları ve özgür yazılım firmalarına yaptırıldı.

Nitel değişiklikler de son derece önemli: Proje bir olurluk çalışması ve projelendirme çalışması olarak başlatıldı. Hemen ilk zamanlarda proje bir dağıtım geliştirme amacıyla yeniden yapılandırıldı. 2009 yılı itibarı ile kurumsal sürümün gündeme gelmesi ve ardından kurumsal yazılımı dizisi geliştirme hedefi kapsama dahil edildi. Aynı zamanlı olarak Türkiye’de özgür yazılımın yaygınlaştırılması ve bir özgür yazılım ekosisteminin geliştirilmesi yönünde çalışmalara da öncülük edilmeye başlandı.

2011 başına takvimlenen Pardus 2011 ve Pardus Kurumsal 2 sürümlerinin yayımlanması ardından ekip olarak zaman ve enerjimizi strateji, organizasyon ve politikalar açısından geldiğimiz noktayı değerlendirmek ve önümüzdeki 3-5 yılı planlamak için ayırabileceğimizi değerlendiriyoruz.

STRATEJİ

2004 yılının ikinci yarısında Pardus (o zamanki adı ile Ulusal Dağıtım’dan Uludağ) projesi son derece basit bir strateji belirlemişti:

  • Yaygın bir işletim sistemi dağıtımı geliştirmek,
  • Bu dağıtımı geliştiren organizasyonun sürdürülebilirliğini (finansal, insan kaynağı, teknolojik, vb açılardan) sağlamak,
  • Bunları teknolojik inovasyon yaparak gerçekleştirmek.

Geçen 6,5 yılda bu stratejiye uygun yapıların oluşturulduğunu, genel hatlarla bakıldığında hedeflere ulaşıldığını görüyoruz. Bununla birlikte, girişte sıraladığımız ilerleme belirteçleri bu strateji cümlelerinin artık fazla genel olduğu, daha odaklanmış bir strateji belirlenmesi ve uygulamaya konması gerektiğini gösteriyor.

Yaygın Dağıtım

Halen Türkiye’nin en çok kullanılan Linux dağıtımı olan Pardus artık iki farklı kulvarda iki farklı ürünle kullanıcılarla ulaşıyor olacak: Daha çok bireysel kullanıcıyı hedefleyen, teknolojik gelişmeleri daha yakından takip etmeyi hedefleyen, desteği daha çok camia modeli ile sağlanan Pardus 2000 serisi ile doğrudan kurumsal kullanıcıları hedefleyen, masaüstü yanında sunucu kullanımında da ciddi iddiası olan, kararlılık ve sürekliliği hedefleyen, desteği ciddi iş modellerine dayanan profesyonel kanallarla sağlayan Pardus Kurumsal. Artık Pardus’un “yaygınlık”ı hedeflemenin ötesinde bu iki kulvarda nasıl hareket edeceğini daha net belirlemesi ve ilan etmesi gerekiyor.

Bu bağlamda, Pardus 2000 serisini daha kullanıcı merkezli, 1.0 ve 2007 sürümlerindeki kadar kolay kullanımlı, 2007 ve 2008 sürümlerindeki kadar yenilikçi bir yörüngeye yerleştirmeyi hedefliyoruz. Pardus 2000 serisinin geliştirici camiasının sürece daha fazla dahil olduğu, daha açık ve daha katılımcı bir geliştirme ve yönetişim modeli ile oluşturulmasının altyapısını tanımlama aşamasındayız.

Pardus Kurumsal için ise ekosistem oluşturma hedefine paralel bir geliştirme ve yönetişim modeline evrilip, zamanla daha çok sahipli yazılım ürünleri için duymaya ve görmeye alıştığımız “ürün yöneticisi”, “pazarlama yöneticisi” benzeri profesyonel pozisyonların devreye girmesi planlanıyor.

Sürdürülebilir Organizasyon

Organizasyonun sürdürülebilirliğinin en önemli ayağı finansal kıstaslar ve bu alanda TÜBİTAK mevzuatının bize gösterdiği yol da sözleşmeli projeler. 2007 yılında Milli Savunma Bakanlığı için yapılan çalışmalar ile başlayan proje tarihçemiz 2010 yılı başında Enerji Piyasaları Düzenleme Kurumu projesi ile ivme kazandı. Şu anda mevcut 2 projemize ek olarak sözleşme aşamasında 4, hazırlık ve iş geliştirme aşamasında ise 10’un üzerinde projemiz mevcut. Makul bir sözleşmeye dönüşme oranı ile Pardus projesinin milli bütçeden sağlanan kaynağın ötesinde büyüyebileceği, sahada faaliyet göstererek gerçek talebe uygun ürünler geliştirebileceği bir yapıya ulaşabileceğini ümit ediyoruz.

Bu alanda kıstasların daha belirgin hale gelmesi, TÜBİTAK’ın hangi ve ne tip projelerde doğrudan yüklenici olacağı, bu projelerde nasıl bir dışkaynaklama ve altyüklenici politikası güdeceği; hangi ve ne tip projelerde doğrudan yer almayıp ekosistem firmalarını kullanma/önerme yoluna gideceğinin açık ve net bir şekilde tanımlanması ve ilan edilmesi gerekiyor. Neticede sürdürülebilirliğin çok önemli bir ayağı da sağlıklı ve güçlü bir ekosistem oluşturulması.

Mevcut eğilim TÜBİTAK’ın

  • belli bir büyüklüğün üzerinde, dolayısı ile karmaşık bir proje yönetimi gerektiren projelerde,
  • özgün çözümler gerektiren ve teknolojik inovasyon yaratılacak projelerde,
  • güvenlik kıstasları nedeniyle TÜBİTAK’ın görev alması gerekli olan projelerde

ana yüklenici olarak yer alması, bunun dışındaki işlerde gerekirse altyüklenici, bu da gerekmezse danışman ya da izleyici pozisyonunda bulunması yönünde. İlk gruptaki projelerde ağırlıklı olarak, ikinci ve üçüncü gruptaki projelerde de proje niteliğinin izin verdiği ölçekte altyüklenici kullanılması ve bilgi birikiminin ekosistem ile birlikte geliştirilmesi ve/veya ekosistem ile paylaşılması planlanıyor.

Teknolojik İnovasyon

Geçtiğimiz 7 yıl içerisinde Pardus teknolojilerinin gidişatına baktığımızda inovasyon konusunda, özellikle bu dönemin ilk yarısında bir sıkıntı yaşamadığımızı görebiliyoruz. Başta PiSi olmak üzere, YALI, Kaptan, Comar, ahenk, mudur serisi, bir dizi yönetici geliyor aklıma isim olarak. Ancak inovasyonun yalnızca fikri ortaya atıp ilk ürünü çıkarmakla sınırlı olmadığını, bu yeniliklerin sürdürülebilir olmaması durumunda çok anlamı kalmadığını da düşünüyorum.

Bu noktada network-manager uygulamacığını irdeleyelim biraz: Daha Pardus 1.0 zamanında, o zamanlar sahipliler dahil (Windows ve MacOS için konuşuyorum) herhangi bir işletim sisteminde bulunmayan, kolay kullanışlı ve çalışan/iş gören network-manager çok başarılı bir inovasyon örneği oluşturuyordu. Ancak zaman içerisinde, özellikle işgücü eksikliği sorunlarından hareketle, network-manager işlev olarak ilerleyemedi, teknolojik altyapı açısından ise açıkça geride kaldı. Pardus 2011 ve Pardus Kurumsal 2’de, ne yazık ki, network-manager kullanmıyoruz artık. Onun yerini GNOME altyapısı ve GNOME ve KDE4 arayüzleri (Pardus geliştiricilerinin ciddi katkısı ve müdahalesi ile) aldı. Kişisel görüşüm mevcut çözümlerin (Pardus, diğer Linux dağıtımları ve sahipli işletim sistemleri dahil) bizim network-manager ile karşılaştırıldığında kullanışlılık ve kolaylık açısından hala geride oldukları yönünde. Heyhat!

Diğer Pardus teknolojilerine baktığımızda, bu yazılımların da geliştiriciler ve kullanıcıların gereksinimlerine uygun bir hızla gelişemediğini tespit ediyoruz. Bunun önemli nedenlerinden birisi Pardus teknolojilerinin tümüyle (çok ufak istisnalar hariç) TÜBİTAK ekibi tarafından geliştiriliyor olması, bir camia oluşturma konusunda başarılı özgür yazılım projeleri kadar mesafe kaydedememesi kanımca. İlk sürümden bu yana 6 yıl geçmesine karşın Pardus teknolojilerini kullanan, Pardus temelli ikinci bir dağıtımın çıkmamış olması da bu eksikliğin bir göstergesi.

Pardus projesinin artık daha hesaplı inovasyon yapması, parlak bir fikri bir ürüne çevirirken bu ürünün sürdürülebilirliğini ciddi bir şekilde değerlendirmesi gerektiğini düşünüyorum. Yeni teknolojiler geliştirirken camia ve ekosistemi daha fazla içine alacak bir teknoloji yönetişimi yapısı kurulması yerinde olacak. Bunun yanında icrada yapılması gerekenler de var: Yol haritasının daha belirgin ve açık olması, kullanıcı ve geliştirici önerilerinin daha fazla dikkate alınması, bu teknolojilerinin geliştirilmesinde proje yönetimi pratiklerinin daha fazla kullanılması gibi…

Aslında tüm bu yazdıklarımız Pardus teknolojilerinin birer projeden daha çok birer ürün gibi görülmesi gereğine işaret ediyor. Geliştirme ve dağıtımın özgürlüğüne halel getirmeden, ama ürün ciddiyeti ve sürekliliğine sahip bir şekilde teknoloji geliştirirsek inovasyon konusunda bir sıkıntı yaşamayacağımızı tahmin ediyorum.

Doğal olarak tek çeşit ve tek bir ürün geliştirmek için, sözleşmeli projeleri son derece kuramsal bir seviyede ele alarak, inovatif fikirleri hızla çözüme dönüştürme heyecanı ile 6 yıl önce oluşturduğumuz organizasyon bu beklentileri karşılamaktan uzak. Pardus 2011 ve Pardus Kurumsal 2 geliştirilirken bu eksikliği ciddi bir şekilde hissettik. Şimdi sürümler tamamlandığına göre yapmamız gereken şekillenmeye başlayan bu yeni strateji ile uyumlu bir organizasyon ve camia yönetişimi yapısı oluşturmak. Bu konulara da önümüzdeki yazılarda değineceğim…

Six Success Factors for National Open Source Projects

I have participated to the 2nd International Free/Open Source Software Technologies Workshop in Riyadh, Saudi Arabia few weeks ago. The Workshop was organized by and took place in the King Abdulaziz City of Science and Technology (KACST), an impressive campus for advanced technology research and development. Before the Workshop, my expectation was that I was here to share my experience and expertise with the participants. Nevertheless, the talks have proven me wrong, that there were very interesting developments taking place in Arabic open source community, and at the end I’ve learned much more than I’ve “taught”.

On the first day of the Workshop I delivered a talk on Pardus, spending few minutes on the lessons we have learned from the successes and failures of the last 7 odd years. I think it may be wise to summarize this part of the talk for those that are or may in the future walk the same walk. The title has “national” in it, but the same success factors should apply to regional and local governments, companies and other organizations alike, after a simple conversion of scales and terms.

Here are the six success factors for your open source project:

FINANCE

You have to have enough of it, throughout the project. If at any point of time you are short in cash, you should expect lots of other problems arise, closely and remotely related. At the beginning the requirements are modest, and you may easily find a sponsor/investor for your project. But you have to grow as the demand grows, which sometime means lots of money and in short notice. You should warn your sponsors/investors beforehand, or have a B-plan in case they do not/cannot provide the necessary cash.

Pardus project has gained momentum throughout 2006 and 2007, where we had Pardus 1.0 and Pardus 2007, the former being a very impressive debut release and the latter being the distro of its time. We had to act fast and grow by the second half of 2006. But being an internally funded project in TUBITAK UEKAE, we were stuck to a team of 15 or so. We have requested central budget support from DPT for 2007, but some unfortunate events shut those doors close. We have even contacted VCs for outside funding, to no avail, “this may be a 20-50 million $ company, but surely not a billion $ company” we were told. At the end the necessary funding came in 2010, 3 years too late. And by then part of the momentum was lost, and lots of opportunities have been missed, and things have never been the same as late 2007.

TEAM

Being in software and/or services sector, your most important assets are your human resources. Both the quality and, as time proceeds, the quantity counts. The caliber of your product is very much correlated to the expertise, creativity and passion of your team. You have to take good care of your team, and be prepared to extend it without sacrificing the quality.

The first generation Pardus team in TUBITAK was top notch, very likely the dream team of open source in Turkey. They have conceptualized, designed and developed one of the best debut distros (Pardus 1.0) and the best distro ever (Pardus 2007). Unfortunately we have not been able to hold most of them with us afterwards. And again unfortunately the Turkish open source sector was not mature enough to make good use of them. We are happy to see them executing very serious work elsewhere, and a bit sad that they are not with us anymore.

Don’t get me wrong, we still have the most impressive team in open source in Turkey, and right now we have one first, one first-and-a-half and one second generation developer in the executive board of Pardus project. Nevertheless I’d like to have the dream team with us, guiding these fine youngsters; in spite of the potential manageability problems that we might have 😉

Among the things that you may control to have a good team and keep them are working environment (or lack of thereof), intellectual and/or technical challenges (which attract best of the breed), career path, other team members, and last but not the least the compensation.

PRODUCT

When I say “project” I mean a “product” project, such as a distro (like Pardus), some certain software, some service bundled to an existing open source product, etc. You have to keep in mind that the important word is product and not project. The number of successful open source products is much less than the number of successful open source projects. Definitely the process counts, but as an asset and not at the centerstage. You have to achieve and sustain the rigor, consistency, continuity, dependability, and, if you wish, marketability of a product as in proprietary software world, or in a market economy in general. You may not like this, but c’est la vie, these are the things that convince the ordinary user/customer to use your product, and not the competition .

We have had release managers for each release in Pardus, and the outcome depended much on the their (sometimes personal) choices. Pardus 1.0 and 2007 were releases to attract the (wo)man on the street, and it showed. Pardus 2009 and 2011 were, on the other hand, tried to satisfy the needs of the more advanced Linux users, and the ease of use was somehow sacrificed. If we had had some stronger product policy, maybe a product manager (we’ve tried to use some community representative to fill this void, but execution was not as brilliant as the idea), or even a marketing manager we would have a straighter evolution line. Now even our dedicated users are asking “why you released 2011, it’s almost 2009”, and they are right…

Again, don’t get me wrong, 2009 and 2011 are very fine Linux distros. Some usability studies say 2009 performing better in some end-user usability measures than its predecessors. Still, I personally think that, as compared to their contemporaries, 2009 and 2011 are steps backward in general audience attractiveness…

With these observations at hand, we are reorganizing our release policies and processes. We are going to put some brief but strict definitions for the target user of the Pardus 2000 series, the requirements for the product in order to be competitive for this target group, the technical requirements for the individual pieces in order to be in line with these general requirements and finally a new organizational/procedural structure in order to make all these policies work, without being dependent on any person… We hope to be back on track with Pardus 2012 and hope that the succeeding releases will get better…

COMMUNITY

There is one slogan I’ve heard from a former community manager “An open source project without a community is deficient.” and this may not be more true. You are likely to have your product (or a subset) to be available publicly with an open source license, and very likely you are not going to provide support for this “community edition”. As the name implies, the support for this edition is the community. In addition community is (or may be) part of QA, part of marketing, part of product management, part of several essential components of the product lifecycle. This is what make an open source software different than a proprietary competitor. The “community” includes your (outside) developers, your ecosystem (mostly companies) and your users. You have to take good care of your community in order to succeed and do so repeatedly. A strong community means a strong product. You have to support your community in order them to get flourished, but you have to keep in mind that eventually your community should become self sustained…

Regarding user communities, we have outsourced the community building and management task since the very early days. The contractor has performed surprisingly good in the first few years, and in some areas. Once a marketing consultant unofficially auditing us (in spite of the fact that he disagreed with outsourced community management) have given them full grade, even more… Still, things did not work as planned. As time passes the community folded onto itself, the newcomers were not as many as they used to be, the gap between the developers and users widened, and so on…

Very recently we have decided to do community management in house, assigned some big talent and hired an expert for the task. The first diligence they have carried out was not very optimistic: Apparently the user community has some problems with governance, always seeking external directives. Right now we are trying to encourage the community veterans to take hold of the control of the existing portal. Almost 4 years of hard work, and with a simple change of coordination everything starts trembling… Not very impressive, we would’ve paid much more attention to governance and self sustainability of the community, much earlier 🙁

We have tried to start some partnership programs almost 3 years back, but the outcome is not very convincing. The larger firms have not been interested much, the smaller ones lack the necessary means for marketing and product development. At the end, we had to become the main contractor and subcontract the parts to our partners. This works well for supporting the ecosystem, but neither is consistent with our business model nor in the benefit of the customer on the long run. As the current projects approach to end with successful results, we hope to have more interest from the existing IT companies.

Universities should be an important part of your community. One part they are the sources of the advanced users, which affect their surroundings in their professional and business life. One the other hand they may be your developers, with lots of youngsters looking for exciting and challenging projects. Our collaboration with one such university have been very fruitful, in the first year they have built the 64-bit infrastructure and right now they’re incorporating other desktop environments in Pardus. We definitely plan to extend this collaboration model into other universities…

USER

We have stressed the importance of the product before, but it never suffices. It may be possible to continue a project without financing, a team and a community; but if you do not have any users, you are doomed. Don’t forget you are responsible to create awareness about your product in the user base. Don’t expect the users flock to your site and start downloading. Once you have users do not try to shape them, instead listen to them. If what they are telling is completely out of line, you have reached wrong user base. If that makes sense consider reshaping your product accordingly so as to expand your user base.

As most of other software, Pardus has been designed and developed for a hypothetical user, initially. Apparently the hypothesis was accurate, and especially Pardus 2007 has been accepted by the targeted users. I have to add that the failure of Microsoft Vista helped much to this result. With later releases we have lost focus on the user, or the user base we have acquired by the earlier releases, and that showed in the slow (or non-existent) adoption rate. In addition, in relation to the community issues, we have somehow lost the direct connection with the user, which is also bad for the user adoption.

We have tried to keep in touch with the user base, using proxies (once under the name Product Manager, and once under the name Release Community Representative), which were right steps forward. Nevertheless the execution have not been as expected for neither one, due to several factors.

We have to reshape our relation to the user, especially for the “community edition” we are going to have. It is not clear yet how we are going to do that, but we are aware of the problem and working on it…

POLICY

The “National Open Source Project” is a supply-side action and most of the above success factors are also related to production and development. It is very likely that your product facing severe competition, very likely from proprietary software and very likely to hold some almost-monopoly position in the market. Hoping to have “fair” competition and market forces play their role for the better and more efficient product (that is yours, right?) take over the market share is highly optimistic (even wishful thinking). A reasonable demand-side support does not hurt… Policies to encourage migration to open source, to consider open source solutions before making an acquisition, to reuse already existing solutions, to use open standards, etc may be put in place so as to have a better Return on Investment for your project.

For Pardus this may be one of the weakest points. The e-Conversion Turkey master project have had actions related to use of open source in government, but it was for having something related to open source, and far from being some policy precursors. We, as the Pardus project, had to struggle to prevent Office Open XML from becoming and ISO standard or to keep Microsoft formats out of interoperability guidelines.

Without much policy backing, only eraly adopters and risk takers from the government have considered using Pardus and open source. And this cycle for adoption is slow in both time and growth. The enterprise users/customers are still only a handful after 6+ years.

These six factors are the ones that I think of utmost importance. If you have fulfilled all of them, but still your project is struggling, let me know. If you have spectacular success in your project, with one or few of the factors missing, let me know again. I’ll appreciate your help to keep this list accurate and up-to-date…