Yerel-öncelikli yazılım (2019)

• Yerel-öncelikli yazılım, bulut tabanlı iş birliği ile kişisel veri sahipliğinin avantajlarını aynı anda hayata geçirmeyi amaçlayan bir yaklaşımdır
• Mevcut bulut uygulamaları gerçek zamanlı iş birliği ve erişilebilirlik konusunda güçlüdür, ancak veri sahipliği ve uzun vadeli erişilebilirlik gibi sorunlara yol açar
• Yerel-öncelikli yazılım, yerel depolamayı verinin birincil saklama yeri olarak kabul eder ve senkronizasyon ile iş birliği özelliklerini ek olarak sunar
• Bu tür yazılımlar hız, çevrimdışı destek, gizlilik ve kullanıcı kontrolü gibi alanlarda avantaj sağlar; ancak gerçek zamanlı iş birliği veya çoklu cihaz senkronizasyonu gibi konularda uygulama zorlukları da vardır
• Yerel-öncelikli yazılımı gerçeğe dönüştürmek için çeşitli mevcut teknik modeller karşılaştırılıp analiz edilmekte, gelecekte daha ideal modellerin geliştirilme olasılığı araştırılmaktadır

---

Bulut uygulamalarının ve veri sahipliğinin sınırları

• Kullanıcıların çoğu Google Docs, Figma, Slack gibi çeşitli bulut uygulamaları üzerinden belge yazma, tasarım, iş birliği gibi farklı amaçlarla çalışır
• Bu hizmetlere tarayıcı veya mobil uygulama üzerinden erişilir ve çoğu veriyi sunucuda saklar
• Bulut tabanlı yazılımlar, iş birliği ve veriye her yerden erişim açısından avantajlıdır; ancak bir uygulamaya ne kadar çok zaman yatırılırsa içindeki verinin değeri de o kadar artar
• Uzmanlarla yapılan görüşmeler, bulut uygulamalarının işlevsel faydalarının arkasında sahiplik kaybı ve uzun vadeli erişim belirsizliği gibi kritik dezavantajlar bulunduğunu gösteriyor
• Kullanıcının bizzat ürettiği materyalleri ve verileri koruma ve sahiplenme hakkının sınırlı olması, hem psikolojik bir huzursuzluk hem de pratik riskler yaratır

Veriye gerçekten sahip olmanın anlamı

• Bulutta saklanan veri "size aitmiş" gibi görünse de, fiilî yönetim ve erişim kontrolü yetkisi bulut hizmeti sağlayıcısındadır
• Hizmetin durdurulması veya sunucu arızası durumunda veriye erişilememesi ve uzun vadeli veri korumanın zorlaşması söz konusudur
• Sorunun özü gerçek fikrî mülkiyetten çok, kullanıcının hissettiği veri sahipliği ve kontrol duygusudur
• Veriyi yerelde saklayan eski tarz uygulamalar (metin editörleri, sürüm kontrolü, çeşitli araçlar) tam veri sahipliği ve özerklik sağlar

Bulut ve yerelin artı-eksi yönlerinin karşılaştırılması

• "Bulut uygulaması = iş birliği ve erişilebilirlik", "yerel uygulama = sahiplik ve özerklik"
• İki seçenekten birini seçmek yerine, hibrit bir yaklaşımın en iyi birleşimini aramak gerekir
• Veri sahipliği ile gerçek zamanlı iş birliği birbiriyle zorunlu olarak çelişmez; ikisini de sağlayan bir yazılım modeli tasarlanabilir
• Bu model yerel-öncelikli yazılım olarak tanımlanır ve temel yapı olarak yerel depolama, ağ ve yardımcı sunucuların birleşimi önerilir

Yerel-öncelikli yazılımın 7 ideali

• Bulut uygulamalarında sunucu verinin “ana kopyası” işlevini gördüğünden, her istek sunucuya gidip gelmeyi gerektirir ve kullanıcı deneyiminde gecikme yaratır
• Buna karşılık yerel-öncelikli yazılım, yerel depolamadaki kopyayı verinin birincil sürümü olarak ele alır; (sunucu üzerinden yapılan) senkronizasyon ikincil olarak işlenir
• Bu bakış açısı değişimi, yanıt hızı, çevrimdışı destek ve veri üzerindeki kontrol gibi alanlarda somut faydalar sağlar

1. Hız (yüksek tepki hızları)

• Yerel-öncelikli uygulamalar tüm işlemleri yerel dosya sisteminde yürüttüğü için, sunucu isteği bekleme gecikmesi olmadan anında kullanıcı tepkiselliği sağlayabilir
• Senkronizasyon arka planda sessizce yürütülür, böylece kullanıcı deneyimi hiçbir anda kesintiye uğramaz

2. Çoklu cihaz senkronizasyonu

• Modern kullanıcılar birden fazla cihazda çalıştığı için, yerel-öncelikli uygulamalarda da cihazlar arası veri senkronizasyonu zorunludur
• Dosya düzeyinde senkronizasyon tek kullanıcı için kolay olabilir; ancak birden çok kişinin eşzamanlı düzenlemesinde çakışma (conflict) sorunları ortaya çıkar

3. Çevrimdışı öncelik

• Yerel-öncelikli yazılım, çevrimdışıyken bile verinin her zaman oluşturulmasına ve düzenlenmesine olanak tanır; ağ geri geldiğinde otomatik senkronizasyon yapılır
• Bluetooth, yerel WiFi gibi farklı yöntemlerle cihazlar arasında veri paylaşımı ve senkronizasyon mümkündür
• Gerçek çevrimdışı desteği için yerel kurulumlu çalıştırılabilir dosya biçimi tercih edilir

4. İş birliği ve çakışma yönetimi

• Mevcut yöntemlerde (e-posta eki, sürüm kontrol araçları vb.) birden fazla kişinin aynı dosya üzerinde aynı anda çalışması durumunda çakışma ve manuel birleştirme zorlukları vardır
• Bulut uygulamaları (Google Docs vb.) gerçek zamanlı eşzamanlı düzenleme ile iş birliğinin zorluğunu ve çatışmayı en aza indirir
• Yerel-öncelikli yazılımda da gerçek zamanlı iş birliği, değişiklik önerisi ve onay gibi çeşitli iş birliği akışlarını uygulama olasılığı vardır; bu alan önemli bir teknik meydan okumadır

5. Verinin uzun vadeli korunması

• Yerel-öncelikli uygulamalar kullanıldığında, yazılım üreticisi ortadan kalksa bile veriye erişim hakkı korunur
• Yaygın dosya biçimleri (metin, PDF, JPEG vb.) uzun süre uyumluluğunu koruyabilir; uyumsuz biçimlere ise sanal makine veya emülatörle erişmek mümkün olabilir
• Verinin gerçekten uzun vadeli korunması olmadan, dijital karanlık çağ sorunu (gelecekte insanların bugünün verilerine erişememesi veya onları yorumlayamaması) gerçeğe dönüşebilir

6. Gizlilik ve güvenlik

• Bulutun merkezi yapısı, hacklenme ve iç çalışan suistimali gibi çeşitli güvenlik olaylarına açıktır
• Kişisel bilgi veya hassas veriyle çalışan uzmanlar, yerel-öncelikli yapıda uçtan uca şifreleme ile güvenlik ve veri bağımsızlığı elde edebilir
• Google gibi büyük şirketler verileri içeride çeşitli şekillerde kullanabilirken, yerel-öncelikli yazılım veri öznesine kontrol hakkı verir

7. Kullanıcı sahipliği ve kontrolü

• Bulut hizmeti sağlayıcısı veri erişimini keyfî biçimde engelleyebilir veya kısıtlayabilir (hatalı otomatik işaretleme, politika değişikliği vb.)
• Yerel-öncelikli ortamda veriyi kullanma, değiştirme, yedekleme ve saklama gibi tüm haklara kullanıcı doğrudan karar verir
• Bu mesele yalnızca yasal telif hakkı değil, kullanıcının fiilî özerkliği ve veri üzerindeki kontrolüdür

Çeşitli yazılım modellerinin karşılaştırılması

• E-posta eki + yerel dosya: hız, çevrimdışı çalışma, uzun vadeli koruma ve kontrol açısından güçlü; ancak iş birliği ve cihaz senkronizasyonu açısından kullanışsız
• Bulut web uygulamaları (Google Docs, Trello vb.): gerçek zamanlı iş birliği ve erişilebilirlik çok güçlü; ancak hız, çevrimdışı kullanım, sahiplik ve gizlilik açısından zayıf
• Dosya senkronizasyon hizmetleri (Dropbox vb.): hız, çevrimdışı kullanım, uzun vadeli koruma ve kontrol açısından güçlü; ancak iş birliği ve mobil ortamda sınırlı
• Sürüm kontrol sistemleri (Git vb.): hız, çevrimdışı kullanım, uzun vadeli koruma ve kontrol açısından çok güçlü; ancak metin dışı dosyalar ve gerçek zamanlı iş birliğinde zayıf
• Mobil istemciler (Firebase, CloudKit vb.): senkronizasyon ve çevrimdışı kullanımda güçlü; ancak kişisel veri, gizlilik ve hizmetin uzun vadeli devamlılığı açısından sınırlı
• Çoklu ana kopya çoğaltma modeli (VT sistemleri, örn. CouchDB): çevrimdışı kullanım ve senkronizasyonda güçlü; ancak iş birliği, gizlilik ve kontrol gibi idealleri gerçekleştirmekte zorlanır veya yetersiz kalır

Yazılım geliştiricisi bakış açısı ve gelecek yönü

• İdeal yerel-öncelikli yazılım, çevrimdışı çalışma, çoklu cihaz senkronizasyonu, gerçek zamanlı iş birliği, gizlilik ve kullanıcı kontrolünü en baştan tasarlayıp uygulamalıdır
• Ancak pratikte tüm bu idealleri aynı anda karşılayan açık teknolojiler henüz yoktur
• Güncel bilgisayar bilimi araştırmalarında geliştirilen yeni teknolojiler (örn. Conflict-free Replicated Data Types(CRDTs), dağıtık veri senkronizasyon yöntemleri vb.), gelecekte yerel-öncelikli yazılımın hayata geçirilmesinde temel rol oynayabilir

Sonuç

• Yerel-öncelikli yazılım, dijital çağda iş birliği ile bağımsızlık, gizlilik ve veri egemenliği arasında denge kurabilecek önemli bir yönelimdir
• Uzmanlara, üreticilere ve yaratıcı kişilere veri üzerinde sahiplik hissi ve uzun vadeli koruma sunar; ayrıca tüm sektörlerde olumlu değişim yaratma potansiyeli taşır
• Bundan sonra bu idealleri gerçekleştirecek daha iyi altyapıların, geliştirme araçlarının, mimarilerin ve algoritmaların araştırılmaya ve denenmeye devam etmesi gerekir

[GN⁺]

Hacker News görüşleri

• Buna yüzde yüz katılıyorum. Ben de bu sorunları çözmek için bir şeyler geliştiriyorum ve verilerimi buluta koyup sadece abonelik ücreti ödeme modelinden bıktım. Şu anda bir fitness tracking uygulaması yapıyorum ve Sublime modelini uygulamayı planlıyorum. Başta bir kez satın alma, birkaç yıl güncelleme, tüm cihazlarla senkronizasyon ve ömür boyu kullanım. Sonrasında güncelleme istenirse yeni sürümü yeniden satın almak yeterli. Yeterince iyi kalitedeyse o haliyle yıllarca kullanılabilmesi hedefim. Yazılımın %90’ı için bu modeli isterim. Makul bir fiyata alınabilmeli, ürünün kendisi iyi olmalı ve bulut entegrasyonu olmasa da düzgün çalışabilmeli. Bu modelin avantajı sadece veri gizliliği değil. Araçlar vb. tarafında hâlâ çözülmesi gereken şeyler var ama teknik temel yeterince güçlü. Local-first yazılımın en büyük avantajı sağlıklı teşvik yapısı. Çünkü ödül reklamdan, kullanıcı takibinden ya da “etkileşim” maksimizasyonundan değil, doğrudan ürünün kendisinden geliyor. Gerçekten kullanıcı odaklı bir yazılım hissi veriyor.

  • Obsidian’ın not uygulaması modeli de gerçekten çok iyi bir örnek. İstemci ücretsiz, senkronizasyon hizmeti ise isteğe bağlı satılıyor. Notların Markdown dosyaları olması da güçlü bir taraf; yani istemciye mecbur kalmıyorsunuz.

  • Bulut altyapısı kullanmadan senkronizasyonu nasıl yapmayı planladığınızı merak ettim.

  • Kesinlikle katılıyorum. Uygunsa fitness tracking uygulamanızın tech stack’ini de merak ettim. Özellikle cihazlar arası senkronizasyonu nasıl ele aldığınızı.

  • Reklamla gelir elde eden tamamen yerel uygulamalar da çok, o yüzden “reklam yok” her zaman geçerli değil.

• Şu anda Berlin’de Ink and Switch’in düzenlediği Local-first Software konferansı (https://www.localfirstconf.com/) oldukça canlı geçiyor ve bu yıl Kasım’da San Francisco’da Sync Conf (https://syncconf.dev/) da ortaya çıktı. Son konferanslarda makalenin ortak yazarları bizzat panel yaptı; local-first yazılımı geliştirme araçları bağlamında neler öğrendiklerini anlatmaları çok faydalıydı. Panel videosunu özellikle tavsiye ederim. Toplulukta şu sıralar “Sync”, local-first’in temel bileşeni olarak yerleşiyor; senkronizasyon motorları gibi developer tool’lar ise local-first özelliklerini destekleyen araçlar, ama kendi başlarına local-first sayılmıyorlar. Son birkaç yılın tüm konuşmaları da buraya yüklenmiş. Gerçek zamanlı ve asenkron iş birliğini destekleyen araçların geliştirilmesi hızla sürüyor ve yapay zekanın yükselişiyle bu tür senkronizasyon motorlarına ihtiyaç duyulan bir pazar ortamı oluşuyor. Yapay zeka uygulamaları doğası gereği çok kullanıcılı iş birliği ortamları olduğundan, senkronizasyon motoru topluluğunun teknik temeline ihtiyaç duyulan bir döneme giriyoruz.

• Bu konuyla ilgili geçmişte de çok canlı tartışmalar olmuştu; merak ediyorsanız okumaya değer: 2019-05, 191 yorum
  2019-11, 241 yorum
  2020-07, 9 yorum
  2020-08, 134 yorum
  2021-02, 90 yorum
  2022-06, 30 yorum
  2023-10, 50 yorum

• Her uygulamanın kendi senkronizasyon platformuna sahip olması gerekmiyor. Bu eğilim biraz da mobil uygulamaların programlar arası bileşenleştirme ve modülerlik zorluklarından doğmuş gibi görünüyor. Gerçekten local-first istiyorsanız dosya sistemini kullanabilirsiniz. Kullanıcı açısından da git, box gibi mevcut çözümler arasından seçim yapabilmek mümkün. Her uygulamanın kendi senkronizasyon kaydına zorlaması, neredeyse SaaS kadar opak ve bozulmaya açık olduğu için yük oluşturuyor.

  • Her uygulamanın bir sync engine’e ihtiyaç duymadığına katılıyorum ama dosya sisteminin local-first için her derde deva bir çözüm olduğunu düşünmüyorum. Bunun iki sebebi var. İlki concurrency. Sadece “gerçek local-first” yeterliyse herhangi bir senkronizasyon çözümü kullanılabilir; ama ben bunun ötesini istiyorum. Örneğin eşimle ikimiz bağlantı yokken kendi telefonlarımızda bağımsız düzenlemeler yapalım ve bunlar sonra otomatik olarak düzgünce birleşsin istiyorum. DropBox benzeri gerçekten doğal bir senkronizasyon deneyimi. İkincisi, daha iyi bir sync deneyimi için senkronizasyon motorunun veri yapısını ve anlamını derinden bilmesi gerekiyor. git ya da box, bu tür anlamsal eşzamanlı düzenleme beklentilerinde ciddi sınırlara sahip.

  • Pratikte sadece dosya sistemi kullanan bir yaklaşım denedim ama istemciler arasında dosyanın ne zaman düzenlenmesine izin verileceğini koordine etmek zor olduğundan, dosya çakışmaları eninde sonunda kaçınılmaz oluyor.

• Çevrimiçi bağımlılığı olan sistemler kaçınılmaz olarak bakım ve işletim maliyeti getirir. Local-first ya da local-only bir tasarım değilse, uzun ömürlü ve güvenilir bir sistem kurmak mümkün değil. Bağlantılı beyaz eşyalar ve otomobiller de pratiklik açısından gerçekten aptalca mühendislik örnekleri.

  • Bütün bu gidişatın kökünde abonelik geliri var. Abonelik modeline sahip şirketler, diğerlerine göre daha fazla gelir elde ediyor ve yatırım da daha kolay alıyor; sonuçta piyasada onlar kazanıyor. Local-first yazılımın kaybolmasının nedeni de bu.

• Ben ise bulut güvenilirliği sorununu teknik olarak, yani merkezi yapılardan kaçarak çözmeye çalışma yaklaşımına biraz eleştirel bakıyorum. Eskiden kapalı yazılımın denetlenemezlik ve güvenilmezlik sorunlarını iş modeliyle çözmeye çalışıyorduk; açık kaynak geliştirme, bakım sözleşmeleri vb. Bulut sorunu için de benzer iş modeli çözümleri gerektiğini düşünüyorum. Örneğin kullanıcı haklarını açıkça tanımlayan standart sözleşmeler ve lisanslar oluşturulabilir, piyasa da sadece bu tür sertifikalı lisansları uygulayan sağlayıcıları tercih etmeye yönlendirilebilir. Kullanıcının verisini taşıma hakkı, veri kullanımının şeffaf biçimde açıklanması, hizmet sonlandırıldığında izlenecek süreç gibi pek çok madde eklenebilir. Elbette en büyük sorun, sağlayıcıların bunu neden kabul edeceği. Sağlayıcılar müşteri kaybından korktukları için böyle bir lisans sunarken yalnızca yıllık abonelik şartı koyabilir veya ek ücret isteyebilir.

  • İş ya da siyaset kaynaklı sorunlar teknik çözümle ele alınabiliyorsa, bunun daha sağlam bir yol olduğunu düşünüyorum. Çünkü çıkar çatışmalarını doğrudan teknik düzeyde engelleyebilirsiniz. client-side encryption bunun klasik örneği. Gizlilik politikalarına ya da bürokratik kurallara güvenmek için fazla çok teşvik, fazla zor denetim var. Eğer veriler matematiksel olarak sunucuda okunamayacak şekilde şifrelenmişse, büyük bir endişe ortadan kalkar. Ama tabii sunucuda veriyi gerçekten işlemek istiyorsanız, o zaman kendi sunucularınızı kullanmanız gerekir.

  • Örneğin kapanış durumunu sözleşmelerle çözdüğünüzü varsayalım. Bulut hizmeti veren şirket iflas edip size haber verir ve verileri dışa aktarmaya izin verirse, geriye çoğu zaman sadece dev bir JSON dosyası kalır. Siz kendiniz bir uygulama yazmazsanız ya da biri sizin için yazmazsa, bunun pratikte pek faydası olmaz. Niyet iyi olsa da, ömrünü tamamlamış bir uygulamanın verilerini uzun vadede kullanılabilir kılan yerel bir uygulamanın sunduğu şeyin gerisinde kalıyor.

  • Veri taşınabilirliği garantisi maddeleri de pratikte büyük ölçekli veri taşımayı kolaylaştırmıyor; bu iş zor ve zaman alıyor. Kriz anında aceleyle yapılırsa daha da kötü oluyor. Aynı sürüm açık kaynak veritabanları arasında bile hizmetten hizmete pek çok değişken bulunduğu için kolay değil. Sonuçta veriyi baştan kendi ortamınızda tutmak ve gerekirse sistemi “fişten çekmek” daha gerçekçi bir alternatif. BYOC (bring your own cloud) ile açık kaynağın birleşimi burada mümkün. Bizim şirket de BYOC veri ürünleri işletiyor, bu yüzden bunun gerçekten uygulanabilir olduğunu deneyimledim.

  • Bir bulut hizmetinin kapanması durumunda sorumluluğu sözleşmeyle tanımlasanız bile, şirket gerçekten kapanma kararı aldığında bunu fiilen nasıl uygulatacağınız ve yöneteceğiniz pek net değil.

  • Mesele sadece iş modeli değil; verinin güvenliği de başlı başına bir sorun. Abonelik ya da bulut modellerinden kaçınmamın temel sebeplerinden biri verilerimi koruma isteği. Yerel şifreleme olmadan gönderilen veri, gerçekten her an ele geçirilebilir.

• Bu yazı bana ferahlatıcı geldi. Daha fazla uygulamanın local-first olması gerektiğini düşünüyorum. Kullanıcı bulut senkronizasyonu istemiyorsa, bu seçeneğin mutlaka garanti edilmesi lazım. Benim geliştirdiğim Brisqi (https://brisqi.com) de bu offline-first felsefesi üzerine kurulu. local-first bir uygulama temelde çevrimdışıyken süresiz biçimde tam işlevli çalışan bir yapı demek. Çevrimdışı deneyim varsayılandır; bulut sync ise ek bir iyileştirmedir. Geçici cache tabanlı uygulamalar offline-first sayılmaz. Veriyi yerel veritabanında saklamalısınız; gerçek offline-first, verinin internetten bağımsız olarak kalıcı olmasıdır. “offline-first” dediğini söyleyen uygulamaların çoğu aslında sadece offline-tolerant, yani sınırlı çevrimdışı desteğe sahip. offline-first uygulama geliştirmek, online-only web uygulaması yapmaktan çok daha zor. Çevrimdışı-çevrimiçi geçişlerde veri kaybı olmadan güvenilir senkronizasyon sağlayan bir mekanizma şart. Benim bunu nasıl tasarladığıma dair yazı burada: https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...

• Bu ilkeler tüketici ürünlerine odaklansa bile yine de anlamlı. Biz şu anda Sentinel Devices(www.sentineldevices.com) bünyesinde, SCADA ve endüstriyel otomasyon gibi verinin asla dışarı çıkarılamadığı sahalar için tamamen yerelde çalışan; analiz ve karar alma süreçlerinin tamamının müşterinin kendi ekipmanı üzerinde yürüdüğü bir yapı geliştiriyoruz. Dış sunucu hiç sağlamıyoruz. On-device ilkesine bu kadar odaklanan bir yapı, hem müşteriler hem de sağlayıcılar için adeta ezber bozucu bir deneyim yaratıyor. Pek çok veri/yapay zeka şirketi, müşterinin sahasında hizmet vermenin zor olduğunu düşündüğü için bu pazarı görmezden geliyor. Oysa biz çoğu zaman “bağlantı yok, her şey tamamen yerelde işleniyor” diye özellikle vurgulamak zorunda kalıyoruz ki müşteriler tam olarak anlasın. Tüketici tarafında local-first daha tanıdık hale gelirse, endüstriyel alanda da dönüşüm daha hızlı olabilir.

  • SCADA sektöründe bile son dönemde her şeyi buluta itme eğilimi var. “Fabrikanızı akıllı telefonunuzdan yönetin” gibi sloganlar kullanılıyor. Ama bunun sonucu, sıradan bir hobi hacker’ının bile fabrika kontrolüne erişebilmesi riskinin artması.

  • Bu alan gerçekten çok ilginç, çalışmalarınızı destekliyorum. Yalnız bir şey merak ettim: Kariyer sayfanıza baktım, tüm pozisyonlar yalnızca onsite görünüyor. Bunun nedeni local-first geliştirme için gerçekten fiziksel olarak sahada olma ihtiyacı mı, yoksa daha çok yönetimsel bir tercih mi?

• Benim projelerim (selfhostblocks, skarabox) de NixOS tabanlı ve herkesin kolayca self-hosting yapabilmesini hedefliyor. https, SSO, LDAP, yedekleme, ZFS snapshot’ları gibi neredeyse her şeyi deklaratif olarak sunuyor. Vaultwarden, Nextcloud gibi veri depolama araçlarını destekliyor ve Home assistant gibi servisleri de kapsıyor. YUNoHost’a rakip bir çizgide ama hedefi daha iyi. SelfHostBlocks, farklı paket yapı taşları şeklinde özgürce genişletilebilen ve self-host edilebilen bir yapı sunuyor. Bir framework’ten çok kütüphane yaklaşımı gibi. Aynı zamanda NAS’a alternatif ve tamamen açık kaynak. Teknik bilgisi olanlar için kolay olabilir ama hedef, nix ya da CLI bilmeyen sıradan kullanıcıların da bunu donanıma kurabilmesini sağlamak.

  • Bu tür projeleri gerçekten destekliyorum. Müthiş FOSS alternatifleri çok fazla ama pratikte yalnızca teknik kişiler tarafından kolay kurulabiliyor; en fazla “docker compose up” düzeyine kadar. Sıradan kullanıcı için bu hâlâ büyük bir eşik. Self-host edilebilen pek çok uygulama web app + DB + server + frontend yapısında, ama ben çoğu zaman bunları zaten tek bir cihazda kullanıyorum. Aslında tam yerel bir masaüstü programı bana yeterli olurdu ama geliştirici değilseniz o bile çok zor. Yüksek kaliteli self-hosted FOSS ile gerçek kullanıcılar arasında belirgin bir uyumsuzluk var. Bu boşluğu kapatan daha fazla projeye ihtiyaç var. Ben de selfhostblocks’u deneyeceğim, gelişimini merakla takip edeceğim.

  • hledger dahil olması harika. Düz metin muhasebe araçlarına yeni başlayanlara biraz yabancı gelebilir ama gerçekten mükemmel bir yazılım.

  • Bunu bu kadar temiz ve düzenli yaptığınız için gerçekten teşekkürler.

• Yazıyı hızlıca gözden geçirince temel noktaların çoğuna değinildiğini gördüm ama ilk paragrafın motivasyonu biraz zayıf geldi. Sanki “elmalı turta lezzetli ve besleyici ama bir gün aniden yanıp yok olabilir, sevdiğim önlüğümü de yanında götürebilir” gibi bir şey okuyormuşum hissi verdi.