Open source ca canal de vânzări pentru un studio mic

Un depozit public este singurul activ de marketing pe care îl avem și care lucrează și atunci când nimeni nu se uită la el. O pagină de vânzare are nevoie de reclame ca să fie văzută. Un articol de blog are nevoie de o poziție în căutare și apoi o pierde încet. O unealtă care rezolvă o problemă reală se instalează, iar fiecare instalare lasă o urmă pe care cineva poate ajunge înapoi la studioul care a scris-o. Acesta este tot argumentul: publicarea este distribuție, iar distribuția se acumulează.

Avem un studio mic în București, așa că nu este povestea despre cum a ajuns cineva celebru prin open source. Este ce facem noi cu două unelte proprii, ce câștigă un business de servicii din ele și ce nu. Unde o afirmație este impresia noastră și nu o măsurătoare, o spunem.

Ce face un depozit public pentru un business de servicii

Trei lucruri, în ordinea în care se întâmplă.

Dovada competenței. Un client nu poate audita o propunere, dar poate deschide un depozit. Istoricul de commit-uri arată cum lucrezi când nu prezintă nimeni nimic. Testele arată dacă îți crezi propriile afirmații. Modul în care denumești lucrurile, mesajele de eroare și răspunsurile la issue-uri arată cum tratezi oamenii care încă nu îți plătesc. Aproape nimeni nu citește tot. Cei care pot citi cod citesc destul, iar aceia sunt cei care semnează.

Un demo care e mereu pornit. Unealta noastră pentru configurație pornește cu npx open-gsd-core-config-manager. VoiceSynth pornește cu o linie de Python și un flag de backend. Fără cont, fără perioadă de probă, fără apel de programat. Un potențial client poate decide dacă lucrul este serios înainte să vorbească cu noi, iar asta răstoarnă ordinea obișnuită a unei discuții de vânzare.

Cereri care vin fără ofertă. Primul mesaj este des o întrebare despre un flag sau un raport de eroare, nu o cerere de ofertă. Cineva care ți-a rulat deja codul s-a calificat singur mai bine decât ar putea orice formular. Aici vorbim de impresie, nu de măsurătoare: depozitele noastre au câteva luni și nu putem arăta încă o conversie de la depozit la contract.

Ce nu face un depozit public

Nu va bate un buget de marketing la capitolul vizibilitate. Un depozit nu este un canal de căutare în sensul unei pagini scrise pentru un cuvânt cheie. Căutarea GitHub este folosită de oameni care știu deja ce caută, ceea ce e util și în același timp o limită. Dacă nimeni nu caută problema, depozitul așteaptă.

Majoritatea depozitelor nu primesc aproape nicio atenție, iar ale noastre sunt un exemplu cinstit. În momentul în care scriem, ambele depozite linkate mai jos au zero stele și zero fork-uri. Unul are 383 de commit-uri, celălalt șapte. Stelele măsoară cât de distribuilă pare un proiect, nu dacă aduce de lucru studioului din spate.

Nu creează cerere. Dacă problema nu costa deja pe cineva timp sau bani, publicarea unei soluții îți lasă o factură de întreținere fără interes pe măsură.

Nu înlocuiește nici vânzarea. Scurtează partea din discuție în care un necunoscut decide dacă poți construi, iar prețul, scopul și încrederea rămân aceleași.

Pornește de la o problemă pentru care ai fost deja plătit

Regula noastră este o unealtă pentru fiecare problemă pe care un client ne-a plătit deja să o rezolvăm. O problemă care a costat pe cineva bani are o formă: intrări, moduri de eșec, soluția provizorie folosită înainte, locurile unde se strică. Forma aceea este mare parte din README.

Unealta noastră pentru configurație există pentru că config.json din GSD are peste două sute de chei imbricate, iar sensul majorității stă în codul sursă. Am petrecut destule ore în fișierul acela ca să știm ce greșeli face lumea. Articolul de pe site despre tratarea unui fișier de configurație ca un API este argumentul; unealta este același argument cu o comandă atașată.

Constrângerea care contează mai mult decât toate celelalte este materialul de client. Publici abstractizarea, niciodată clientul: fără nume, fără date, fără capturi din panoul lor, fără cod care nu îți aparține. Dacă unealta funcționează doar cu schema lor privată, nu este o unealtă publică. Rescrie-o pentru o problemă pe care o au și alții sau ține-o privată. Când lucrarea a fost făcută pe contract, verifică cui îi aparține rezultatul înainte să publici o linie din ea.

README-ul începe cu problema și cu o comandă

Un README care se deschide cu o listă de funcții este scris pentru autor. Unul care se deschide cu problema și cu o comandă este scris pentru omul care decide dacă merită să piardă zece minute.

Al nostru începe cu o singură frază: înțelege și editează în siguranță orice config.json din GSD fără să citești codul sursă gsd-core. Apoi comanda. Acesta este modelul de copiat: pentru ce este, apoi ce trebuie tastat. Funcțiile vin după, și mai puține decât ai crede.

Pune limitele în README. Documentația VoiceSynth spune care backend-uri sunt implementate, care au nevoie de un pachet extern și care sunt doar schelet, pentru că o matrice care promite mai mult decât codul este o coadă de suport pe care ți-ai creat-o singur. O limitare scrisă costă un paragraf și scutește luni de răspunsuri.

README-ul trebuie să spună și licența, și ce promiți despre issue-uri, ambele în primul ecran, nu într-un fișier pe care nu îl deschide nimeni.

Documentația are nevoie de propriul site

README-ul este locul unde cineva decide. Site-ul de documentație este ce se linkuiește. Motoarele de căutare îl indexează, răspunsurile de pe forumuri lipesc un link direct către o pagină, iar o pagină al cărei titlu se potrivește cu întrebarea este mai ușor de citat decât un fișier lung dintr-un depozit.

Avem două de acest fel: gsd.danubelabs.net și tts.danubelabs.net. Ambele se deschid cu ce face unealta și cu comanda care o pornește. Site-ul GSD documentează 201 chei canonice și promite de la primul ecran că fiecare cheie este explicată, validată și reversibilă. Site-ul VoiceSynth are instalare, CLI și interfață grafică, o matrice de backend-uri derivată din sursă, limite și întrebări frecvente. Designul nu este punctul. Fiecare pagină răspunde la o întrebare anume sub propriul titlu, așa că poate fi găsită și linkuită separat de depozit.

Costul este un al doilea lucru care trebuie ținut în pas cu fiecare versiune. Sunt trei moduri cinstite de a-l gestiona: generezi partea de referință din cod, ții textul scurt sau accepți că unele pagini rămân în urmă și le datezi. Deriva este o cheltuială recurentă, nu o sarcină pe care o termini.

Alege licența care se potrivește cu intenția

Licența este o decizie de business îmbrăcată în costum juridic. Cele două direcții se spun simplu, iar choosealicense.com le pune într-o frază fiecare: MIT lasă oamenii să facă aproape orice cu proiectul tău, inclusiv să facă și să distribuie versiuni cu sursă închisă, iar GPLv3 permite același lucru cu excepția asta.

Folosim MIT pentru ambele unelte pentru că scopul este adoptarea. Cineva ar trebui să poată băga unealta în produsul lui, inclusiv comercial, fără să ne întrebe. Asta transformă un depozit în distribuție. Dacă unealta ar fi și produsul pe care îl vindem, MIT ar fi alegerea greșită.

Copyleft-ul se potrivește când valoarea pe care o vinzi este o versiune găzduită de tine, iar codul este exact ce ar copia un concurent. GPLv3 ține derivatele distribuite deschise. Dacă oamenii ajung la software prin rețea, fără să primească o copie, citește textul AGPL, nu un rezumat ca paragraful acesta.

Există și a treia opțiune, source-available. Publici codul, lași lumea să îl citească, să îl ruleze și să îl evalueze, dar nu permiți redistribuirea versiunilor modificate. Una dintre aplicațiile noastre desktop se publică așa. Nu este open source și nu o numim așa, dar este o alegere cinstită când codul este produsul.

Întreținerea face parte din preț

Fiecare depozit public este o promisiune făcută unor necunoscuți, iar promisiunea se plătește în ore. Triaj de issue-uri, actualizări de dependențe, schimbări venite de la proiectele upstream, rapoarte de securitate care sosesc pe mail privat și întrebarea recurentă despre un sistem de operare vechi.

Stabilește promisiunea înainte să publici și scrie-o în README. Fie un termen de răspuns pe care chiar îl poți ține, fie o frază simplă care spune că issue-urile sunt citite, că reparațiile se fac când se poate și că nu promitem suport. Ambele sunt acceptabile. Tăcerea nu este, pentru că oamenii o citesc ca suport și apoi se enervează când se dovedește că nu era nimic.

Bugetează orele explicit. La noi înseamnă o trecere periodică prin dependențe, ținerea documentației în pas cu versiunile și citirea issue-urilor. Nu este uriaș, dar se repetă, și iese din aceeași săptămână ca munca pentru clienți.

Măsoară recomandările, mențiunile și lucrul câștigat

Sunt patru lucruri care merită urmărite și niciunul nu este numărul de stele.

• Traficul de recomandare din statistici. Sesiuni care vin de pe github.com, de pe npm și de pe domeniul de documentație. Numărul poate fi mic. Întrebarea este dacă e peste zero și dacă urcă.
• Mențiunile. Linkuri de pe alte site-uri, pachete care depind de al tău, o linie în README-ul altcuiva. Acestea sunt cele care aduc oameni ani la rând.
• Cererile care numesc depozitul. Un mesaj în care omul spune că ne-a găsit prin unealtă merită marcat în orice folosești pentru lead-uri, pentru că este singura atribuire curată pe care o vei avea.
• Timpul investit față de lucrul câștigat. Ore pe lună față de contractele semnate pe care le poți lega de o unealtă. Atribuirea va fi incompletă, iar un raport aproximativ este tot suficient ca să decizi dacă mergi mai departe.

Nu optimiza stelele. O stea costă un click și îți spune cât de distribuilă pare proiectul, ceea ce este altă întrebare decât dacă îl folosește cineva. Un depozit cu o mie de stele și zero recomandări nu ți-a adus nimic pe care să poți emite factură.

Un depozit fără utilizatori este un cost, iar ștergerea este permisă

Modul de eșec nu este o licență controversată sau un README urât. Este unealta pe care nu o instalează nimeni și pe care o actualizezi din vinovăție. Costă ore în fiecare lună, face portofoliul să pară mai aglomerat decât este și nu te învață nimic.

Pune o dată de revizuire când publici. Dacă la acea dată recomandările sunt zero, nimeni nu a deschis un issue și nici tu nu mai folosești unealta, arhiveaz-o cu o notă în README sau șterge-o. Ștergerea elimină obligația și semnalul fals. Un studio cu două unelte folosite este într-o poziție mai bună decât unul cu șase pe care nimeni nu le-a atins, iar portofoliul convinge mai mult când nu este umplut de formă.

Poziția noastră, pentru protocol: cele două unelte de mai sus au câteva luni și nicio stea. Nu pretindem că un depozit ne-a adus un client, pentru că până acum nu s-a întâmplat. Ce putem susține este mecanismul, iar descrierea cinstită a pariului este un cost lunar mic împotriva unei rentabilități care se acumulează și care încă nu a sosit. Dacă recomandările rămân la zero la data de revizuire, articolul acesta rămâne mărturia unui lucru încercat, ceea ce este și el util.

Dacă lucrezi la ceva care merită publicat

Danube Labs este un studio de software, AI și automatizare condus de fondator, în București. Dacă ai o problemă pe care ai rezolvat-o deja manual de două ori, poate merita transformată într-o unealtă. Vezi software personalizat pentru cum arată lucrul, uită-te la portofoliu pentru uneltele publicate până acum sau programează o discuție introductivă gratuită.