Sådan starter du et Open Source-projekt

Mit navn er Dima og jeg er Ruby-udvikler. I dag vil jeg dele min erfaring med at skabe en open source-løsning. Jeg vil tale om, hvilke skridt projektet skal tage, hvordan man vælger den rigtige funktionalitet til den første udgivelse, og hvilke fejl jeg stod personligt overfor, da jeg oprettede mit open source-projekt.

For et halvt år siden fik jeg ideen om, at det ville være godt at oprette et open source-projekt. I stedet for testopgaver til interviewet ville det være nok for mig at sende et link til arkivet. Udsigten til at hjælpe kolleger med løsningen på deres daglige problemer inspirerede mig.

Jeg har altid ikke lide perler til oprettelse af administrationspaneler. Enhver ekstra bevægelse skal omdefinere klassen, og for ændringsfelter skal du foretage ændringer i filerne. Efter at have tænkt og snakket med kolleger besluttede jeg at oprette et nyt bibliotek, der ville være fleksibelt og ikke kræve dashboards eller konfigurationsfiler.

Bestem målene

Hvert open source-projekt løser et specifikt problem. Tal med kolleger, chats, fora, og del din idé. Det hele hjælper dig på de første skridt til at forstå vigtige ting, som hvilke løsninger der allerede findes, og at høre kritik. Tal med folk, der allerede har open source-projekter. De kan give dig meget værdifuld rådgivning, så vær ikke bange for at spørge og tage initiativet.

En vigtig rådgivning, som jeg fik på det tidspunkt, er først at være opmærksom på dokumentationen af ​​projektet. Du kan have et meget godt projekt, men ingen vil bruge tiden på at forstå, hvordan det fungerer.

Det vigtigste aspekt, uden hvilket yderligere trin er umulige, er motivation. Idéen om projektet skal primært inspirere dig. Ofte vænner folk sig til de værktøjer, de arbejder med, og falder ind i en komfortzone, så eksterne meninger kan være tvetydige.

Planlægning

Valget af en bestemt task manager er et spørgsmål om smag. Det skal have et klart billede af opgaverne og stadierne i dit projekt.

Opdel opgaver i underopgaver. Ideelt set, hvis en opgave ikke tager mere end 3-4 timer, er det vigtigt at nyde implementeringen af ​​små opgaver. Dette hjælper med at undgå udbrændthed og tab af motivation.

Jeg bruger pivotal tracker. Den største fordel er en gratis version til open source-projekter, hvor du kan sortere opgaver efter type (feature, bug, chore, release) og gruppere dem i releases og bestemte deadlines.

Dokumentation

Hvert open source-projekt skal indeholde disse ting:

  • LÆS MERE
  • Open Source licens
  • Medvirkende retningslinjer
  • Changelog

README-filen forklarer ikke kun, hvordan du bruger dit projekt, men også formålet med dit projekt. Hvis du ikke ved, hvordan du korrekt skriver en README-fil, kan du se på andre kendte open source-projekter eller bruge en skabelon.

Licensen garanterer, at andre kan bruge, kopiere og ændre projektets kildekode. Du skal tilføje denne fil til hvert arkiv med dit open source-projekt. MIT og Apache 2.0 GPLv3 er de mest populære licenser til open source-projekter. Hvis du ikke er sikker på, hvad du skal vælge, kan du bruge denne praktiske service.

CONTRIBUTING-filen hjælper andre udviklere med at bidrage til projektet. Ved de første trin i projektet er det ikke nødvendigt at være meget opmærksom på denne fil. Du kan bruge den allerede forberedte skabelon fra et andet projekt.

Changelog indeholder en understøttet, kronologisk ordnet liste over væsentlige ændringer for hver version. Som med filen CONTRIBUTING anbefaler jeg ikke at være særlig opmærksom på dette tidligt.

Versionering

For at spore vigtige ændringer for brugere og bidragydere er der en semantisk version. Versionsnummeret indeholder tal og overholder følgende mønster XYZ

  • X større frigivelse
  • Y mindre frigivelse
  • Z patch frigivelse

Kontinuerlig integration / Kontinuerlig levering

For automatisk at køre tests og bygge bruger jeg Travis CI. Det er også en god ide at tilføje badges for at vise den vellykkede samling af build i guiden, testdækningen (Codecov) og dokumentationen (Inch CI).

Efter hver ny forpligtelse eller fletning i masteren har jeg automatisk en implementering på Heroku (meget praktisk integration med GitHub). Alle værktøjer er helt gratis til et open source-projekt.

Mine fejl

For at analysere den indledende fase havde jeg en idé, men der var ingen klar plan. Jeg besluttede, at jeg ville gøre dette uden at have en klar idé om, hvor lang tid det ville tage eller en specifik repræsentation af de funktioner, der ville være i den første version af biblioteket. Jeg havde bare meget lyst og mangel på en klar plan.

Efter at have læst historien om andre projekter (ikke kun open source) bemærkede jeg også, at nogle planer på et tidligt tidspunkt er for optimistiske. De har brug for en revurdering af deres styrker og evner. Men det er ikke let at finde tid hver dag til at skrive en ny funktion i projektet. De fleste af opgaverne måtte til sidst lukkes ud, hvilket efterlod det nødvendige minimum for MVP.

I øjeblikket er mit simple-admin-projekt i alfa-versionen. Yderligere planer inkluderer oprettelse af en separat version af biblioteket til Hanami.