Kuinka aloittaa avoimen lähdekoodin projekti

Nimeni on Dima ja olen Ruby-kehittäjä. Tänään haluan jakaa kokemukseni avoimen lähdekoodin ratkaisun luomisesta. Puhun siitä, mihin vaiheisiin projektin tulisi ryhtyä, kuinka valita oikea toiminto ensimmäiselle julkaisulle ja mitä virheitä tapasin henkilökohtaisesti luodessani avoimen lähdekoodin projektia.

Puoli vuotta sitten sain ajatuksen, että olisi hyvä luoda avoimen lähdekoodin projekti. Haastattelun testitehtävien sijaan riittää, että lähetän linkin arkistoon. Mahdollisuus auttaa kollegoita ratkaisemaan heidän jokapäiväiset ongelmansa inspiroivat minua.

Olen aina pidä helmistä hallintopaneelien luomisessa. Mahdollisen ylimääräisen liikkeen on määriteltävä luokka uudelleen, ja muutoskenttiä varten on tehtävä muutoksia tiedostoihin. Kun olen ajatellut ja keskustellut kollegoiden kanssa, päätin luoda uuden kirjaston, joka olisi joustava eikä vaatisi kojelautoja tai määritystiedostoja.

Määritä tavoitteet

Jokainen avoimen lähdekoodin projekti ratkaisee tietyn ongelman. Keskustele kollegoiden kanssa, chatit, foorumit ja jaa ideasi. Se auttaa sinua ensimmäisissä vaiheissa ymmärtämään tärkeitä asioita, kuten jo olemassa olevia ratkaisuja, ja kuulemaan kritiikkiä. Keskustele ihmisten kanssa, joilla on jo avoimen lähdekoodin projekteja. He voivat antaa sinulle erittäin arvokkaita neuvoja, joten älä pelkää kysyä ja tehdä aloite.

Yksi tärkeä neuvoja, jotka sain tuossa vaiheessa, on kiinnittää huomiota ensisijaisesti projektin dokumentointiin. Sinulla voi olla erittäin hyvä projekti, mutta kukaan ei vie aikaa ymmärtääkseen, miten se toimii.

Tärkein tekijä, jota ilman jatkovaiheet ovat mahdottomia, on motivaatio. Projektin idean pitäisi innostaa sinua ensisijaisesti. Useimmiten ihmiset totuvat työkaluihin, joilla he työskentelevät, ja putoavat mukavuusalueelle, joten ulkoiset mielipiteet voivat olla epäselviä.

Suunnittelu

Tietyn tehtävänhallinnan valinta on maun asia. Sillä tulisi olla selkeä kuva projektisi tehtävistä ja vaiheista.

Jaa tehtävät alitehtäviin. Ihannetapauksessa, jos yksi tehtävä kestää enintään 3–4 tuntia, on tärkeää nauttia pienten tehtävien toteuttamisesta. Tämä auttaa välttämään palamista ja motivaation menetystä.

Käytän keskeistä seurantalaitetta. Suurin etu on ilmainen versio avoimen lähdekoodin projekteille, joissa voit lajitella tehtäviä tyypin (ominaisuus, vika, urakka, julkaisu) mukaan ja ryhmitellä ne julkaisuiksi ja määritetyiksi määräajoiksi.

Dokumentointi

Jokaisen avoimen lähdekoodin projektin tulisi sisältää nämä asiat:

  • LUE
  • Avoimen lähdekoodin lisenssi
  • Myötävaikuttavat ohjeet
  • Muutosloki

README-tiedosto selittää paitsi projektin käytön myös projektin tarkoituksen. Jos et tiedä kuinka kirjoittaa README-tiedosto oikein, voit tarkastella muita tunnettuja avoimen lähdekoodin projekteja tai käyttää mallia.

Lisenssi takaa, että muut voivat käyttää, kopioida ja muokata projektin lähdekoodia. Sinun on lisättävä tämä tiedosto jokaiseen arkistoon avoimen lähdekoodin projektisi kanssa. MIT ja Apache 2.0 GPLv3 ovat suosituimpia lisenssejä avoimen lähdekoodin projekteille. Jos et ole varma, mitä valita, voit käyttää tätä kätevää palvelua.

CONTRIBUTING-tiedosto auttaa muita kehittäjiä osallistumaan projektiin. Projektin ensimmäisissä vaiheissa ei ole tarpeen kiinnittää erityistä huomiota tähän tiedostoon. Voit käyttää jo valmistettua mallia toisesta projektista.

Changelog sisältää tuetun, kronologisesti järjestetyn luettelon merkittävistä muutoksista kullekin versiolle. Kuten CONTRIBUTING-tiedostossa, en suosittele kiinnittämään siihen erityistä huomiota varhaisessa vaiheessa.

Versiointi

Käyttäjille ja avustajille tärkeiden muutosten seuraamiseksi on semanttinen versio. Versionumero sisältää numeroita ja noudattaa seuraavaa mallia XYZ

  • X iso julkaisu
  • Y-pieni julkaisu
  • Z-korjaustiedoston vapauttaminen

Jatkuva integrointi / jatkuva toimitus

Testien ja rakennuksen automaattiseen suorittamiseen käytän Travis CI: tä. On myös hyvä lisätä merkkejä, jotta ohjatun asennuksen onnistunut kokoonpano, testin kattavuus (Codecov) ja dokumentaatio (tuuman CI) voidaan näyttää.

Jokaisen uuden sitoutumisen tai yhdistämisen jälkeen masterissa minulla on automaattisesti käyttöönotto Herokulle (erittäin kätevä integrointi GitHubiin). Kaikki työkalut ovat täysin ilmaisia ​​avoimen lähdekoodin projektille.

Minun virheeni

Alkuvaiheen analysoimiseksi minulla oli idea, mutta selkeää suunnitelmaa ei ollut. Päätin, että halusin tehdä tämän ilman, että minulla olisi selkeää käsitystä siitä, kuinka paljon aikaa se vie, tai erityistä esitystä toiminnoista, jotka olisivat kirjaston ensimmäisessä versiossa. Minulla oli vain paljon halua ja selkeän suunnitelman puuttuminen.

Luettuani muiden hankkeiden (paitsi avoimen lähdekoodin) historian huomasin, että jotkut suunnitelmat ovat varhaisessa vaiheessa liian optimistisia. He tarvitsevat uudelleenarvioinnin vahvuuksistaan ​​ja kyvyistään. Mutta ei ole helppoa löytää päivittäin aikaa uuden ominaisuuden kirjoittamiseen projektiin. Suurin osa tehtävistä jouduttiin lopulta kitkemään, jättäen MVP: lle tarvittavan vähimmäismäärän.

Tällä hetkellä yksinkertainen-admin-projektini on alfa-versiossa. Muihin suunnitelmiin kuuluu erillisen version luominen kirjastosta Hanamille.