Visual Studio Code tasarım kusuru (2022)

• Visual Studio Code, MIT lisanslı kaynak kod ile Microsoft’un dağıttığı özel lisanslı ürün arasında ayrım yapıldığı için VSCodium ve OpenVSCode Server gibi fork’lar resmî ekosistemle çatışıyor
• Resmî build, product.json içine telemetri, gallery, logo gibi Microsoft’a özgü ayarları ekleyerek dağıtılıyor; topluluk build’leri ise “clean” build oluyor ama Visual Studio Code Marketplace’e bağlanamıyor
• VSCodium ve OpenVSCode Server, resmî sürümdeki telemetriyi kaldırıyor ya da hiç içermiyor; ancak eklentilerin kendi veri toplaması ve Marketplace erişim kısıtları nedeniyle kullanıcıların beklediği VS Code deneyimini birebir sunmaları zorlaşıyor
• Pylance, C# eklenti yol haritası ve C/C++ araç lisansı örneklerinde olduğu gibi Microsoft eklentileri ve dil sunucuları resmî ürün ve hizmetlere bağlandığında, Gitpod, GitLab, Datacoves, OpenBB, Foam gibi rakip hizmetlerin aynı işlevleri yasal olarak sunması zorlaşıyor
• OpenVSX, açık dil araçları geliştirme ve açık kaynak bakımcılarına destek alternatifler arasında gösteriliyor; ancak Microsoft varsayılanları özel araçlara çevirdiğinde topluluk ve rakip ürünler aynı anda işlev farkı, yapılandırma farkı ve hukuki kısıtları üstlenmek zorunda kalıyor

---

Kaynak kod açık ama ürün farklı dağıtılıyor

• Visual Studio Code, çıkışından 7 yıl sonra yazılım geliştirmede fiilî standart editör hâline geldi
• Microsoft, Visual Studio Code’un kaynak kodunu MIT lisansıyla yayımladı; ancak kullanıcıların indirdiği Visual Studio Code ürünü ayrı bir özel lisans altında dağıtılıyor
• Visual Studio Code bakımcılarının açıklamasına göre Microsoft build’i, vscode deposu klonlandıktan sonra Microsoft’a özgü product.json dosyasının üzerine yazılmasıyla oluşturuluyor
  • Bu dosya telemetri, gallery, logo gibi Microsoft’a özgü özellikler içeriyor
  • Bu şekilde üretilen build, Microsoft lisansı ile dağıtılıyor
• Yazının temel eleştirisi, bu ayrımın Microsoft’un açık kaynak topluluğunu bölmesindeki ana mekanizma olması

VSCodium ve OpenVSCode Server’ın karşılaştığı sınırlamalar

• VSCodium, topluluk odaklı özgür lisanslı bir masaüstü dağıtımı
  • upstream MIT projesini otomatik olarak takip ediyor ve ikili build’ler üretiyor
  • Resmî sürümde bulunan telemetri kaldırılmış build’ler sunuyor
  • Varsayılan product.json içinde Microsoft uç noktaları tanımlı olmadığından, Microsoft özelleştirmeleri içermeyen “clean” bir build oluşturuluyor
• Aynı kod tabanını kullanan VSCodium bile tüm veri toplamayı tamamen engelleyemiyor
  • Eklentiler bağımsız olarak veri toplayabildiği için, kurulan eklentilere dikkat etmek gerekiyor
• OpenVSCode Server, Gitpod’un temelini oluşturan özgür lisanslı bir sunucu dağıtımı
  • upstream MIT projesini otomatik olarak takip ediyor
  • gp-code/main dalında bazı overlay özelleştirmeleri bulunuyor
  • Resmî sürümün telemetrisi yer almıyor
• Her iki dağıtım da Microsoft Visual Studio Code Marketplace’e bağlanamıyor ve bu kısıt ekosistemde kopuşa yol açıyor

Microsoft’un hizmet odaklı dönüşümü ve geliştirici araçları stratejisi

• Microsoft yaklaşık 9 yıl önce yazılım sunma biçimini değiştirmeye başladı
  • Özel QA ekibinin build’leri test ettiği modelden, sprint tabanlı geliştirme, rolling release ve Insider Build telemetri geri bildirimine dayalı modele geçti
• Aynı dönemde yaşanan kurumsal yeniden yapılanmalarla Microsoft bir hizmet şirketine dönüştü
  • Azure bu dönemde AWS’ye gerçek bir rakip olacak kadar büyüdü
• Tüketici açısından en büyük değişim, kurulumlu on-premise ürünlerden Microsoft’un sunduğu hizmet tüketim modeline doğru müşteri tabanının kayması oldu
• Geliştirici araçlarında da abonelik dışı IDE’lerin azalmakta olduğu bir eğilimden söz ediliyor
  • Apple’ın Xcode’u, başka gelir kaynakları olduğu için istisna olarak anılıyor
• Visual Studio Code, geliştirici araçları ekosistemini uçtan uca tüketim odaklı hizmet modeline taşıyan giriş kapısı olmakla eleştiriliyor
  • GitHub Codespaces, Visual Studio Online, Microsoft Dev Box ve Microsoft Azure DevTest Labs ile bağlantılı mevcut hizmetlerin white label bir sürümü olarak tanımlanıyor

GitHub Codespaces ve Microsoft DevDiv

• Microsoft, 2018’de GitHub’ı satın aldı ve 2019’da Visual Studio Online’ı duyurdu
  • Bu yapı, yerelde “codespace” barındırmaya yarayan bileşenleri de içeriyordu
  • Sonrasında Codespaces ekibi dâhil ilgili parçalar GitHub’a taşındı
• GitHub Codespaces, GitHub bünyesine geçmiş bir DevDiv projesi olarak tanımlanıyor
• Nat Friedman’ın CEO’luktan ayrıldığı gün, Microsoft içindeki yeniden yapılanma e-postası paylaşıldı
  • Julia Liuson, Microsoft Developer Division başkanı olarak terfi etti
  • GitHub CEO’su Thomas Dohmke’nin Julia Liuson’a raporladığı bir yapı oluştu
  • Developer Division içinde Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, Azure geliştirici SDK’ları, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache ve Spring Cloud yer alıyor
• Söz konusu e-postaya göre Visual Studio ve Visual Studio Code, 2014’ten bu yana 16 kattan fazla kullanım artışı kaydetti
• Julia Liuson, terfisinden önce .NET topluluğunu bölen son dakika değişikliklerini uygulayan kişi olarak anılıyor
  • The Verge alıntısına göre Microsoft içinden anonim bir kaynak, bu değişikliği iş odaklı bir karar olarak görüyor

“Tasarlanmış kopuş” gibi işleyen ekosistem yapısı

• Gitpod gibi rakip ürünlerin Visual Studio Code ekosistemi içinde var olabildiği, ancak Microsoft’un istediği anda hukuki risk oluşturarak pazarı bölebileceği eleştirisi yapılıyor
• Visual Studio Code’un açık kaynak kodu kullanıcıları çekiyor, ancak rakip hizmetlerin resmî Visual Studio Code veya GitHub Codespaces kadar sorunsuz bir deneyim sunmasını zorlaştırıyor
• Sadece Gitpod değil; GitLab, Datacoves, OpenBB, Foam gibi VS Code kaynak kodunu temel alıp Microsoft veya GitHub ile rekabet etmek isteyen şirketler de aynı sorunlarla karşılaşıyor
• Microsoft araçlarına bağımlı kalındığında, rakip hizmetlerin yasal olarak sunmakta zorlanacağı alanlar arasında şunlar sayılıyor
  • Microsoft .NET C#
  • Python’un genel amaçlı kullanım ve veri bilimi pazarı
  • Project Jupyter ve veri bilimi pazarının büyük kısmı
  • C veya C++
  • Java’nın da, Microsoft araçları RedHat araçlarının seviyesine yaklaşırsa sıradaki hedef olabileceği öngörülüyor
• TIOBE endeksine göre bu diller ve ekosistemlerden 5’i en popüler alanlar arasında yer alıyor; ayrıca Microsoft’un TypeScript üzerinden, 7. sıradaki JavaScript üzerinde buna yakın bir denetime sahip olduğu söyleniyor

Varsayılanların değiştirilmesi ve özel eklenti sorunu

• Microsoft’un yeterli benimsenme sağladıktan sonra eklenti güncellemeleriyle özel teklifleri varsayılan hâle getirebileceği eleştiriliyor
• Python topluluğunda, açık kaynak Microsoft Python Language Server sonlandırıldı ve özel Pylance varsayılan oldu
  • Visual Studio Magazine alıntısına göre Microsoft kullanıcıları zorla geçirmedi, ancak Pylance’ı yeni varsayılan olarak ayarladı
  • Python eklentisi VS Code Marketplace’te yaklaşık 50 milyon indirme sayısına ulaştı ve ikinci en popüler Jupyter eklentisinin yaklaşık iki katı olarak anılıyor
• .NET topluluğunda da C# eklentisi yol haritası üzerinden benzer bir varsayılan değişimi yaşandığı örnek gösteriliyor
• Open.NET gibi alternatif araçlar geliştirilse bile, kullanıcıların platforma göre ayrı yapılandırma bağlaması gerekiyor
  • Masaüstünde devcontainer.json içine ms-dotnettools.csharp eklenebiliyor
  • Gitpod’da ise gitpod.yml içine henüz var olmayan açık bir araç eklemek gerekiyor; bu da fark yaratıyor
• Microsoft’un resmî ekosisteminde ise aynı devcontainer.json yapılandırması, masaüstü Visual Studio Code ile GitHub Codespaces’te aynen çalışarak tek bir yapılandırma kaynağı sağlıyor

Lisansın yarattığı hukuki kısıtlar

• Gitpod, GitLab, Datacoves, OpenBB, Foam gibi hizmetler kısıtları aşarak ms-dotnettools.csharp gibi Microsoft eklentilerini servislerinde sunarsa, Microsoft hukuk ekibinden sert yasal müdahaleler görebilecekleri uyarısı yapılıyor
• Rakip bulut geliştirme ortamı kullanıcılarının bu eklentileri elle kurması bile lisans ihlali sayılabilir
• Microsoft C/C++ eklentisinin lisans metni, yazılımın yalnızca Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server ve bunların sonraki Microsoft ürünleri ve hizmetleriyle birlikte kurulup kullanılabileceğini belirtiyor
• Bu koşul nedeniyle, resmî Microsoft dağıtımı olmayan VS Code tabanlı ürünlerin kullanıcıların beklediği Microsoft dil araçlarını aynı şekilde sunması zorlaşıyor

Yanıt yönü: OpenVSX ve açık dil araçları

• İnşa edilmekte olan yazılım geliştirme araçlarının geleceğinin kapalı bir yöne gittiği eleştirisi yapılıyor
  • Bazı bileşenler OSI tanımını karşılasa bile, bütün bileşen grafiği bunu karşılamayabilir
• Açık kaynak, başlangıçta özel on-premise yazılımları dengeleyen ve dosya biçimlerinin açıklığını koruyan finansal bir araç olarak tanımlanıyor
  • Aynı zamanda açık kaynakla para kazanmanın neden zor olduğuna da bağlanıyor
• Özel SaaS’a karşı hesaplama özgürlüğünün açıklığını güvence altına alacak yeni bir hareketin ya da 1970’lerdeki özgür yazılım hareketinin yeniden değerlendirilmesinin gerekebileceği öne sürülüyor
• Gitpod’un Open-Source Sustainability Fund girişimi, ekosistemdeki bu kopuş sorununa verilen yanıtlardan biri olarak gösteriliyor
  • 1,5 yıl içinde açık kaynak topluluğundaki dil sunucusu araçlarının bakımcılarına 32 bin doların üzerinde kaynak dağıtıldı
• Gitpod, Visual Studio Code açık kaynak ekosistemindeki Marketplace sorununu kısmen çözmek için Open VSX oluşturdu ve bunu Eclipse Foundation’a bağışladı
• Bundan sonraki en büyük görev, Microsoft’un topluluğu özel dil sunucularına taşıdığı her alanda açık dil araçları geliştirmek olacak

Sonradan eklenen düzenlemeler

• 31 Ağustos 2022 tarihli düzenleme, Microsoft’un VSCode’u geliştirip özel ücretsiz bir dağıtım ve özel ücretsiz eklentiler sunduktan sonra, dil bazında en iyi deneyimi kapalı bir VSCode sürümüne bağladığını özetliyor
• 16 Aralık 2022 tarihli düzenleme, GitLab’ın VSCode MIT tabanlı Web IDE ve uzaktan geliştirme deneyiminin de aynı sorunları yaşadığını ekliyor
• 13 Ekim 2023 tarihli düzenleme, Google’ın Project IDX’inin de VSCode MIT tabanlı olduğunu ve .NET ile Python’da Visual Studio Code LSP’nin aynı şekilde çalışmasının beklenemeyeceğini, bunun yasal da olmadığını belirtiyor
• 24 Nisan 2025 tarihli düzenleme ise Microsoft’un Windsurf ve Cursor gibi yapay zeka kodlama asistanı rakiplerini baskılamak için VSCode ekosistemini kasıtlı olarak bozduğunu ileri sürüyor
  • Aynı gün Microsoft’un rakip bir ürün duyurması ve C/C++ eklentisinin VS Code fork’larına erişimini kısıtlaması birlikte anılıyor

[unsure4000]

vim ya da zed kullanmayı düşünüyordum.

Ben opacity ayarlı bir terminal kullanıyorum,
nvim'in arka plan rengini kaldırmanın bir yolunu bilen var mı?
Bunu da çözersem nvim'i mutlaka denemek istiyorum...

[siscof]

kitty terminal kullanıyorsanız, aynı arka plan rengini kullanırsanız şeffaflık uygulanacaktır.
Ya da böyle bir eklentiyi değerlendirmeyi de düşünebilirsiniz..

https://github.com/xiyaowong/transparent.nvim

[unsure4000]

Teşekkür ederim. Bir bakacağım.

[unsure4000]

Başarılı oldu. Teşekkür ederim. İyi günler dilerim.

[GN⁺]

Hacker News görüşleri

• Bir açıdan bu durum bir fırsat da olabilir. VSCode ekosistemi birçok bakımdan oldukça kırılgan
  cpptools bazı yönlerden harika, ama sık sık hatalı çalışıyor, fiilen debug edilmesi imkânsız ve diğer eklentilerin de bundan çok daha iyi olmasını beklemek zor
  Daha büyük sorun, güvenlik modelinin çok zayıf olması: eklentiler sandbox’a alınmıyor ve uzak depolara erişen istemci de tasarım gereği son derece güvensiz
  Yalnızca şirket koduna bakarken deponun size saldırma ihtimali konusunda daha az endişelenebilirsiniz, ama kötü niyetli eklentiler elbette endişe kaynağı olmalı; geliştirme araçlarına fazla kolay güvenmeye alışmış durumdayız
  LLM’lere asla güvenilmemeli; kullanıcıya saldırmaya çalışabilecek bir LLM’ye doğrudan depoya yazma ya da VSCode’un bazı bağlamlarında JS kodu çalıştırma yetkisi vermek güvenli değil
  Daha iyi bir ekosistemde cpptools’un karşılığı olan aracın internet erişim yetkisi olmazdı; dolayısıyla telemetri de olmaz, yalnızca çalışma alanını okuma, kendi önbellek dosyalarını oluşturma ve UI üzerinde işlem yapma gibi şeyleri yapabilmeliydi

  • VSCode, tasarım gereği geliştirme ortamının gerçek durumunu gizliyor; takılan kullanıcılara yardım ederken çoğu zaman hangi bilgisayara giriş yaptıklarını, dosyanın dosya sisteminde nerede olduğunu, hangi Python yorumlayıcısını kullandıklarını, hatta HTTPS_PROXY’nin neye ayarlandığını bile bilmedikleriyle karşılaşıyorum
    SSH eklentisi de kullanıcının bağlandığı her istemci için bir sunucu süreci başlatıyor ve bağlantı kesildikten sonra durumun korunması da tutarlı görünmüyor
    Sonuçta VSCode kullanırken kendi yarattıkları sorunları düzeltmelerine yardımcı olmaya çok zaman harcıyorum
  • VSCode güvenlik modeli bizim bilgi güvenliği ekibimiz için de büyük bir endişe kaynağı
    Marketplace’teki tüm eklentilere açık erişim izni vermek ile tamamen kilitleyip eklentileri yalnızca yerel dosyalarla kurdurmak arasında bir ara seçenek yok
    İkincisi, VSCode bakımına ciddi bir yük bindiriyor
  • compile_commands.json’a sahipseniz ya da bunu üretebiliyorsanız —özellikle CMake ile bu nispeten kolay— ve clangd’nin bunu görmesini sağlayabiliyorsanız, clangd eklentisi benim için çok daha iyiydi
  • Uzak depolara erişen istemci tasarım gereği son derece güvensizse, üçüncü taraf eklenti güvenliği açısından en iyi editörün hangisi olduğunu merak ediyorum
    Kullandığım Emacs’te de tedarik zinciri saldırılarını engelleyecek pek bir mekanizma yok ve çoğu kişi eklentileri doğrudan Git depolarından alan topluluk eklenti toplayıcılarını kullanıyor
    Yine de Emacs kullanıcılarının aldıkları eklentilerin kaynak koduna gerçekten bakma oranının çok daha yüksek olması gibi çok küçük bir avantaj olabilir
  • Eklentilerin sandbox’a alınmadığı doğruysa bu oldukça şaşırtıcı
    Microsoft yıllardır “güvenlik her şeydir ve şu anda en önemli konudur” diyor; SSH anahtarları gibi şeyler çalındığında etkisi en büyük olacak kullanıcı kitlesi ve güvenliği en çok önemsemesi gereken geliştirici kitlesi için böyle temel bir şeyi bile sağlamamış olmaları garip
    İnsanların rastgele eklentiler kurduğu ve Visual Studio Code’un “dil desteği” adı altında keyfi eklentiler önerdiği durum, sanılandan çok daha kötü görünüyor

• cpptools eklentisiyle ilgili iyi bir thread var: https://github.com/microsoft/vscode-cpptools/discussions/126...
  Kaynaktan derleme sürecini derinlemesine kurcalamadım, ama bu yazıya bakınca bunun tamamen imkânsız olduğu izlenimi doğuyor
  Bir kod tabanının OSS lisanslı olduğunu ve derleme bağımlılıklarının da OSS lisanslı olup olmadığını ifade edecek yeni bir terime ihtiyaç duyulacak gibi

  • Bu gerçekten ciddi. Microsoft ileride o thread’i gömerse gelecekte insanlar ne hakkında konuştuğumuzu merak edecek
  • Debian, dağıtımı üç bileşene ayırır: main özgür yazılım, non-free özgür olmayan yazılım, contrib ise özgür yazılım olup main dışındaki, genellikle özgür olmayan yazılıma bağımlı olan şeylerdir
    contrib teriminin kendisini sevmiyorum ama bu sınıflandırma oldukça makul görünüyor
  • Yalnızca bu birkaç küçük yorum bile daha büyük ekosistemin karşılaştığı sorunu tam olarak ortaya koyuyor; bunun sanılandan çok daha hızlı ve çok daha kötü hâle gelmesi muhtemel
  • VSCode açık kaynak değil, bu eklenti de açık kaynak değil
    Windows’taki birçok F/OSS ve macOS’teki neredeyse tüm F/OSS; MSVC, Xcode, Apple framework’leri ve GUI araç takımları gibi tescilli derleme bağımlılıklarına sahip, ama yine de kendileri F/OSS olabilir
    Ancak bu vakada sorun bu değil; bakımcı gibi görünen bir Microsoft çalışanının “lisansımız, eklentinin alternatif VS Code dağıtımlarında kullanılmasını da yasaklıyor; yalnızca Microsoft’un yaptığı resmi dağıtımda kullanılabilir” dediği bir durum söz konusu
    Bu basbayağı tescilli yazılım
    Özgür yazılım tanımındaki özgürlük 0, programı istediğiniz amaç için çalıştırma özgürlüğüdür; VSCode’un üçüncü taraf dağıtımları resmi dağıtımla aynı eklenti haklarına veya uyumlu eklentilerle kullanılma hakkına sahip değilse, kodun bir kısmının lisansından bağımsız olarak özgürlük 3’ü de geçemez
    “Dil sunucusu ikili dosyasını kendi paketinizin parçası olarak yeniden dağıtmaya çalışıyorsanız runtime lisansı bunu yasaklıyor” ifadesi, açık kaynak tanımının 1. koşulu olan yeniden dağıtım ölçütünü karşılamadığı anlamına gelir; değiştirilmiş dağıtımlara orijinalle aynı hakları tanımayan VSCode da 3. koşul olan türetilmiş çalışmalar ölçütünü karşılamaz
    VSCode ve bu eklenti, ikisi de açık kaynak değil; bazı açık kaynak bileşenler içeren tescilli yazılımlar
    Özgür yazılım tanımı: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
    Açık kaynak tanımı: https://opensource.org/osd
    Bu tanımların sıradan sözlük anlamları değil, belirli toplumsal ve teknik amaçlara sahip olarak hareket içinde üretilmiş terimler olduğunu belirtmek de önemli
  • Anladığım kadarıyla bu eklenti, EDG’den ticari lisansla alınmış tescilli bir C++ front-end’i kullanıyor
    Aynı front-end Visual Studio IDE’de de yer alıyor
    Alternatif olarak clangd tabanlı, tamamen açık kaynak bir C++ eklentisi olduğunu biliyorum; ama yanılıyor olabilirim

• “Microsoft’un ücretsiz olarak sunduğu özgür yazılım yeterince açık değil” iddiası, günümüz ölçütlerine göre bile oldukça tuhaf geliyor
  Eskiden “ücretsiz IDE” denince Eclipse ya da bir sürü eklentiyle donatılmış Vim kastedilirdi
  Görünüşe göre Microsoft açık alternatifleri engelliyor olmaktan çok, bu alternatifler sadece daha kötü; çalışanlarına maaş ödeyip aynı zamanda kâr etmek zorunda olan bir şirketin yaptığı yazılımı kullanırken zaten işin doğasında böyle taraflar var
  Microsoft’un en iyi yazılımının kaynak kodunu almaya hakkı olduğunu hissedenler, bağımsız bir kâr amacı gütmeyen kuruluşun sürdürdüğü gerçek açık kaynağın neye benzediğine bakabilir
  Çalışır ve belki gerçek bir hata ayıklayıcısı da vardır, ama çok geçmeden geri dönmek isteme olasılığınız yüksektir
  İnsanlar ücretsiz aldıkları yazılımı fazlasıyla doğal karşılıyor. Çok da uzun olmayan bir süre önce bir IDE için yüzlerce, hatta binlerce dolar ödemek gerekiyordu; birkaç yıl sonra yeni sürüme ihtiyaç duyduğunuzda da yükseltme ücreti öderdiniz

  • Microsoft’un açık alternatifleri engellemediğini söylemek zor
    VSIX uzantıları bir ölçüde açık standart olmalı, ancak Pylance gibi Microsoft uzantıları Microsoft derlemesi olmayan VS Code’da çalıştıklarını algıladıklarında aktif biçimde çalışmayı reddediyor
  • “Microsoft’un ücretsiz olarak sunduğu özgür yazılım yeterince açık değil” ne yazıdan bir alıntı ne de yazının iddiası
    Asıl mesele daha çok geliştiricilerin kandırıldığı ve Microsoft’un hedefinin kritik parçaları kapatmak olduğu yönünde
  • Asahi Linux projesine bakınca benzer bir durum görülüyor. Muazzam işler yapıyorlar ama 3 yıllık bir dizüstüyle temel özellik eşdeğerliğini yakalama işi bile hâlâ sürüyor
    Özellik eşdeğerliği tamamlandığında sırada performans sorunu kalacak ve bunun ne zaman çözüleceği de bilinmiyor
    Açık kaynak yazılım fikri güzel, ama günümüzde en iyi yazılımı neredeyse her zaman ancak para ödeyerek elde edebiliyorsunuz
  • Benim sorunum Microsoft’un büyük planını bilmiyor olmam
    Emacs ve Vim kullanmanın bedelini biliyorum. Teoride tamamen ücretsiz olsalar da pratikte zaman, sabır ve adanmışlık maliyeti var; yaptığım tercihle benim, topluluğun ve sektörün fayda gördüğünü biliyorum
    Eskiden IntelliJ kullanırken de JetBrains’in nasıl para kazandığını tam olarak biliyordum. Lisans ücreti ödüyor ve her yıl yeniliyordum
    Peki Microsoft’un hesabı ne? Böyle güzel ve düzgün bir aracı tamamen “ücretsiz” veriyor; gelecekte bunun karşılığında ben hangi bedeli ödeyeceğim?
    Piyasa değeri Almanya’nın GSYH’sine denk gelen dev bir şirketin, sırf geliştiricileri sevdiği için muazzam kaynak harcayıp “ücretsiz” bir kod düzenleyici yaptığına inanmak zor; geliştiriciler en azından biraz kuşkucu olmalı
  • “Microsoft’un en iyi yazılımı” ifadesi şaka gibi geliyor
    Bence Microsoft yazılımı kâbus gibi bir çöp yığınına daha yakın
    Yazının ana noktası, kapalı kaynak yazılımın açık kaynakmış gibi davranmasının onu kullanmak istemeyenleri bile etkilemesi; bunu kaçırıyorsunuz
    Örneğin Azure DevOps mu GitHub Actions mı, onu bile kullanmak istemiyorum; ama çalıştığım kurum projeyi GitHub’a koymak zorunda olduğu için mecburen kullanıyorum
    Sonuç olarak emeğim ve bilgim Microsoft’un kullanıcıları sömürmesine hizmet ediyormuş gibi hissediyorum
    Tek teselli bunun ücretli iş olması; kişisel olarak GitHub kullanmıyorum ve başkalarına da böyle yapmalarını önereceğim

• VS Code’u geliştiren 50’den fazla tam zamanlı çalışanın yıllık yaklaşık 20 milyon dolarlık bütçesini nasıl gerekçelendireceğine dair bir model sunmuyorsanız, bu eleştiri “onların mühendislik çıktısını bizim şirket alıp ürünün sadece yüzeyini değiştirerek, kendi geliştirme maliyeti olmadan daha ucuza satıp kâr etmeyi biraz zorlaştırdılar diye sinirleniyoruz” gibi duyuluyor

  • Microsoft’un çeşitli departmanlarda dahili kullanım için kendi IDE’sini geliştirmesi ve esnek, modern bir araç için bütçe ayırması anlaşılabilir
    Bunu açık kaynak olarak yayımlarsa diğer toplulukların güvenini kazanır; ücretsiz kod ve hata denetimi, ayrıca Microsoft ekosistemi dışından uzantı yazımı ve desteği elde eder; Microsoft da bunu kullanmaya devam edebilir
    Pek karmaşık bir mesele gibi görünmüyor
  • Bu benim sorunum değil. Benim sorunum, mesleki yetkinliğimi Microsoft’un süregelen iyi niyetine bağımlı hâle getirmemek
    Tarihsel olarak bu, eskimeye giden garantili bir yoldu
    Onların mühendislik çıktıları olmasa da Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox vb. var
    Microsoft’un cömert battaniye hediyesi, ancak yanında çiçek hastalığı gelmiyorsa ilgimi çeker
  • Onların iş modelinin kötü olması benim kaygım değil. Onlar yanlış kararları sömürülen yoksul bir çocuk değil
    Yalnız bunun büyük bir sürprizmiş gibi haber yapılması biraz komik. Başından beri belliydi; sadece kavga etmeye değer görünmediği için umursanmadı
    BSD/MIT lisanslı geliştiricilerin sömürülmesi meselesi, telemetriyi kapatınca Microsoft’un iş modelinin sarsılabilmesi meselesi kadar ilgimi çekmiyor
    Herkes “büyük şirket abisi bizi fark edecek” diye düşünerek neyin içine girdiğini bilerek seçti; gerçekten de fark edildiler, o yüzden tebrikler
    Ben AGPL’den daha zayıf bir lisansla hiçbir şey yayımlamam, ama nihayetinde yazılımdan çok daha fazla önemsediğim şeyler var

• Hâlâ sorunun ne olduğunu anlamaya çalışıyorum
  Microsoft’un daha iyi bir cpptools/C++ eklentisi geliştirdiği, ama birçok Microsoft bileşeni kapalı olduğu için tamamen OSS bir sürüm derlenemediği anlamına geliyor gibi duruyor
  Kullanıcılar herhangi bir web arayüzünde yerel eklentileri kullanamayacaklarını fark ettiğinde bunun web arayüzü tarafındaki insanların sorunu hâline geldiğini mi söylemek istiyorlar, emin değilim
  İnsanlar OSS yerine freeware kullanmak istiyorsa bu hayal kırıklığı yaratabilir, ama bunun gerçekten bir sorun olup olmadığından emin değilim
  Bir yanıt varsa, kimin sorumlu olduğunu daha net duyurmak olmalı gibi görünüyor
  Açık kaynak satıcıları, sunduklarının açık kaynak ve açık bir ekosistem olduğunu daha açık biçimde belirtmeli; tüm eklentilerin böyle olmadığını ve Microsoft’un alternatif eklentisinin de böyle olmadığını geliştiricilere anlatmalı
  Büyük eklenti projeleri ortak bir irade gösterirse, marketplace açıklamalarına vscode-cpptools’un OSI onaylı bir lisansa sahip olmadığı, incelenmemiş çok sayıda binary blob içerdiği ve Microsoft’un yerel açık kaynak derlemelerde ya da web hizmetleri için VSCode sunumunda yeniden dağıtıma izin vermediği gibi bir bilgilendirme ekleyebilirler
  Hem hukuken hem kültürel olarak Microsoft, birkaç OSS projesi kendi lisans koşullarını Microsoft’un koşullarıyla karşılaştırdı diye marketplace erişimini engellemek istemeyecektir
  Apple da şu anda marketplace davalarıyla uğraşıyor ve Microsoft da bir marketplace ya da başka bir antitröst davası istemeyecektir

  • Basit bir örnek vermek gerekirse, tek bir public fonksiyondan oluşan bir API yapıp bu API’yi kapalı kaynak lisanslı bir binary olarak derlersiniz
    Sonra yine tek public fonksiyonlu başka bir API yaparsınız; o fonksiyon da yalnızca o kütüphane binary’sine extern çağrısı yapar
    İkinci API’yi GitHub’a MIT lisansıyla koyar ve açık kaynak ilan edersiniz
    Geniş açıdan bakınca, yazılım işlevselliğinin %100’ü kapalı kaynak derlenmiş binary’nin içindeyse buna açık kaynak demek yanıltıcı reklam sayılmalı mı, mesele bu
    Başka bir deyişle, biri sömürücü nedenlerle açık kaynağın amacının ötesine geçtiğinde çizgiyi kimin çekeceği meselesi
    cpptools işlevselliğinin %100 kapalı olup olmadığını bilmiyorum, ama pratikte MIT lisanslı olduğu söylenen deponun içinde kabul edilmesi gereken üç ayrı lisans daha var

• Asıl meselenin ne olduğunu anlamak için fazla fazla metin okumak gerekiyor ve “parçalanmış ekosistem” kavramı açıklamasız biçimde birkaç kez geçiyor
  “Parçalamak için tasarlanmış sinekkapan” gibi ifadelerin ne anlama geldiğini hiç anlamıyorum
  VS Code, Microsoft’tan ücretsiz indirip kullanabileceğiniz bir IDE; Microsoft’un kontrol etmediği sihirli bir açık kaynak platform ya da ekosistem değil, bir ürün
  Herkes “genel amaçlı” geliştirici hizmetleri yapmak istiyor, ama iş IDE yapmaya ya da bunu finanse etmeye gelince sanki bunu istemiyorlar ya da iş fazla zor geliyor
  Bu Microsoft’un suçu değil

• Microsoft’u savunmaya çalışmıyorum, ama devasa bir kod tabanını ücretsiz sundular ve onun üzerine çoğu ücretsiz olan bir ürün yaptılar
  Fork ederseniz yalnızca Microsoft sunucularına erişemezsiniz; bence bu yeterince adil
  Ayrıca Monaco ezici derecede iyi bir editör olduğu için frontend’ler onu kullanıyor. Eskiden CodeMirror ya da Ace en iyi seçenekken onlar kurulurdu
  Monaco’nun ortaya çıkışının arkasında devasa bir ana plan olmasından ziyade, bağımsız bir proje hâline getirilirse sayısız web arayüzünü mümkün kılacağı fırsatını görmüş olmalarına daha yakın duruyor

• “Gelecekte üretilecek yazılım geliştirme araçlarının geleceği tamamen kapalıyken, bazı bileşenler OSI tanımını karşılıyor diye insanlar büyük resmi kaçırıp bunu sorun etmiyor” noktası çok büyük bir sorun
  Özellikle VC yatırımı almış birçok şirketin açık kaynak terimini fazlasıyla gevşek kullanması; dili ve anlamı, hatta açık kaynak hareketinin ruhunu kötü yönde değiştiriyor
  YC de açık kaynak olduğunu iddia eden ama o ruha hiç uymayan birçok şirketi destekliyor

  • Sorun şirketlerin bunu yapmasından çok, kullanıcıların ve geliştiricilerin pek umursamaması ya da bu kaygıları paylaşmaması
    Ruh ya da etik gibi ahlaki tartışmalar pek ilgili değil
    Önemli olan, yazılım lisanslarının hukuki belgeler olması ve yorumlarının anlam kazandığı yerin mahkemeler olması
    VS Code ile ilgili çok dava var gibi görünmüyor ve Microsoft genelde bu tarafı düzenli tutuyor
    Hukuki anlamda VS Code yeterince güvenli görünüyor. Bazı eklentilerin OSS lisanslı olmadığı ya da tamamen kapalı kaynak olduğu doğru, ama hoşunuza gitmiyorsa kullanmazsınız
    Daha da ötesi, kendi açık kaynağınızı yapıp düzeltebilirsiniz. Açık kaynak bir hak değil, üreticinin takdiriyle verilen bir ayrıcalıktır; talep edilebilecek bir şey değildir
    VS Code, çok sayıda OSS bileşeni içeren kapalı kaynak bir üründür ve bu bileşenler çok olduğu için tamamen OSS olan VS Codium da vardır
    Bu OSS bileşenlerin birçoğu başka ürünlerde de kullanılıyor, bazıları tamamen açık kaynak
    VS Code ekosisteminin değeri, bu bileşen ve ürün ekosisteminin gelişmesini sağlamasında yatıyor

• Kimsenin VS Code'u bedava almaya hakkı yok. Aslında kimsenin hiçbir şeyi bedava almaya hakkı yok
  Alternatif, şişkin ticari IDE'lere para ödemek
  VS Code fena değil; genel amaçlı, ücretsiz ve fork edilebilecek kadar açık
  İnsanlar bunun mühendislik açısından şaşırtıcı bir ürün olduğunu unutuyor. Koda baktığınızda, bedavaya çıkacak seviyede değil
  Microsoft ya da başka herhangi bir şirket kimseye ücretsiz bir şey borçlu değil; bu hak görme duygusunun kontrol altına alınması gerekiyor

  • Doğru, en iyisi üzerine bir fiyat etiketi koymak. Buradaki insanlar da VSCode'dan yeterince fayda sağlıyor, para verirler
    Sorun, ücretsiz sunulan şeyin fiilen sizi hukuki sorumluluk ve üst sınırı olmayan mali sorumluluk bataklığına düşürecek şekilde tasarlanmış olması
    Özellikle VSCode gibi tek seferlik satın alma olmayan, eklentiler ve güncellemeler üzerinden Microsoft'a sürekli bağımlı kalmanız gereken bir hizmette bu daha da böyle; gerçekten de böyle tasarlanmış
    Bir kez temizce ödeyip bitirebileceğiniz kolay bir seçenek oluşturmak yerine, kullanıcının direnç seviyesine göre uzun vadede belirsiz miktarlarda para çekmeyi seçmişler
  • JetBrains ürünleri değerliydi, bu yüzden yıllarca para ödedim. Eclipse'in özellikleriyle karşılaştırıldığında çok ilerideydi ve buna para vermeye değerdi
    Açık kaynak konusunda da hep söylerim: arkasında büyük para olmayan bir framework'ü benimseme konusunda şüpheciyim
    İnternetteki rastgele dâhi bir mühendisin kaprislerine bağlı olmak riskli
    Microsoft VSCode'dan para kazanacak. Google'ın Chrome'dan para kazanması kadar doğrudan olmayacak sadece
  • Gerçekten mühendislik açısından şaşırtıcı mı? Şişkin tarayıcı teknolojileriyle ve peçete üzerinde tasarlanmış gibi duran bir dille zar zor çalışan bir IDE yapmak, dondurma çubukları ve sakızla 1 millik bir yaya köprüsü inşa etmek kadar “etkileyici” bence

• OSS'nin harika olduğunu düşünüyorum ama VS Code kullanmamın nedeni bu değil
  Eclipse gibi bir canavar olmayan, kullanılabilir bir editöre ihtiyaç duyma sorunumu çözdüğü için kullanıyorum
  Bu alanda Sublime gibi başka seçenekler de var ama VS Code bana hep en az araya giren seçenek gibi geldi
  Daha önce benzer Adobe Brackets de vardı ama nedense çok yavaş ve çok hatalıydı
  OSS meraklısıysanız yazıdaki tespitler yerinde. Ama sonuçta kaynak kod var ve isterseniz kendi marketplace'inizi de işletebilirsiniz
  Zaman ve para gerektirir, ama bu fikre inanıyorsanız dev şirketlere bağımlı kalmayıp yatırım yapmalısınız
  Sahip olamayacağınız kapalı bir eklenti varsa yazık, ama birileri OSS sürümünü yapabilir
  Genel olarak yazıya katılıyorum; ama Microsoft'un bunu açık kaynağa olan inancı yüzünden yaptığı gibi bir hayalim yok ve en kötü durumda başka seçenekler olduğu için sorun değil