Sciencelakes

Sådan at køre en vellykket Free Software Project

Karl Fogel

Copyright © 2005, 2006, 2007, 2008, 2009, 2010 Karl Fogel, under en creativecommons Attribution-ShareAlike (3,0) licens.

Dedikation

Denne bog er dedikeret til to kære venner uden hvem det ikke ville have været mulig: Karen Underhill og Jim Blandy.

Hvorfor skrive denne bog?

Til fester, folk ikke længere giver mig en blank stare, når jeg fortæller dem, at jeg skriver fri software. «Åh, ja, open source-lignende Linux?» de siger. Jeg nikker ivrigt i enighed. «Ja, præcis! Det er hvad jeg gør.» Det er rart ikke at være helt fringe længere. I fortiden, var det næste spørgsmål normalt relativt forudsigelige: «Hvordan kan du tjene penge at gøre det?» For at besvare, ville jeg opsummere økonomien i open source: at der er organisationer i hvis interesse det er at have bestemt software eksisterer, men at de ikke behøver at sælge kopier, de ønsker blot at sørge for software er tilgængelig og opretholdes som et redskab i stedet for en vare.

Senest har dog det næste spørgsmål ikke altid drejet sig om penge. De forretningsmæssige argumenter for open source software [1] er ikke længere så mystisk, og mange ikke-programmører allerede forstå-eller i det mindste er ikke overrasket over, at der er folk ansat på det på fuld tid. I stedet det spørgsmål, jeg har hørt oftere og oftere er «Åh, hvordan hænger det sammen?»

Jeg havde ikke et tilfredsstillende svar parat, og jo hårdere jeg prøvede at komme op med en, jo mere jeg indså, hvor komplekst et emne det virkelig er. Kørsel af en gratis software-projekt er ikke ligefrem som at løbe en virksomhed (forestille sig at skulle konstant forhandle karakteren af dit produkt med en gruppe af frivillige, hvoraf de fleste du aldrig har mødt!). Heller Af forskellige grunde er det præcis som at køre en traditionel non-profit organisation, eller en regering. Det har ligheder med alle disse ting, men jeg har langsomt kommet til den konklusion, at fri software er sui generis. Der er mange ting, som det kan være nyttigt at sammenlignes, men ingen med hvilke det kan ligestilles med. Selv den antagelse, at fri software-projekter kan «køre» er en strækning. En gratis software-projekt kan startes, og det kan være påvirket af de berørte parter, ofte ganske kraftigt. Men dets aktiver kan ikke gøres til ejendom af en enkelt ejer, og så længe der er mennesker et eller andet sted-overalt-interesseret i at fortsætte det, kan det ikke ensidigt lukket ned. Alle har uendelig magt, alle har ingen magt. Det gør for en interessant dynamik.

Det er derfor, jeg ønskede at skrive denne bog. Gratis software projekter har udviklet en distinkt kultur, en etos, hvor frihed til at gøre softwaren gøre noget man ønsker, er en central tese, og alligevel er resultatet af denne frihed er ikke en spredning af individer hver gang deres egen separate måde med koden , men entusiastisk samarbejde. Faktisk kompetence på samarbejde i sig selv er en af de mest værdsatte færdigheder i fri software. For at håndtere disse projekter er at engagere sig i en slags hypertrophied samarbejde, hvor ens evne til ikke kun at arbejde med andre, men at komme op med nye måder at arbejde sammen kan resultere i konkrete fordele for softwaren. Denne bog forsøger at beskrive de teknikker, hvormed dette kan gøres. Det er på ingen måde komplet, men det er mindst en begyndelse.

God fri software er et værdigt mål i sig selv, og jeg håber, at læserne, der kommer på udkig efter måder at opnå det vil være tilfreds med hvad de finder her. Men ud over det håber jeg også at formidle noget af den store fornøjelse at være haft at arbejde med et motiveret team af open source-udviklere, og fra at interagere med brugerne i den vidunderligt direkte måde at open source tilskynder. Deltagelse i et vellykket fri software projekt er sjovt, og i sidste ende det er det holder hele systemet i gang.

Hvem bør læse denne bog?

Denne bog er beregnet til softwareudviklere og ledere som overvejer at starte et open source projekt, eller som har startet en og spørger sig selv, hvad de skal gøre nu. Det bør også være en hjælp for folk, der bare ønsker at deltage i et open source projekt, men har aldrig gjort det før.

Læseren behøver ikke at være en programmør, men bør kende de grundlæggende software engineering begreber som kildekode, compilere, og patches.

Tidligere erfaring med open source-software, som enten en bruger eller en udvikler, er ikke nødvendig. De, der har arbejdet i fri software-projekter før vil sandsynligvis finde det mindste nogle dele af bogen en smule indlysende, og måske ønsker at springe disse afsnit. Fordi der er sådan en potentielt bred vifte af publikum erfaring, jeg har gjort en indsats for at mærke sektioner klart, og at sige, når noget kan springes over af dem allerede bekendt med materialet.

Kilder

Meget af råvaren til denne bog kom fra fem års arbejde med Subversion projektet (http://subversion.tigris.org/). Subversion er et open source version control system, skrevet fra bunden, og skal erstatte CVS som de facto version control system af valg i open source-fællesskabet. Projektet blev startet af min arbejdsgiver, CollabNet (http://www.collab.net/), i begyndelsen af 2000, og gudskelov CollabNet forstod lige fra starten, hvordan du kører det som et rigtig stærkt, distribueret indsats. Vi fik en masse frivillige developer buy-in tidligt, i dag er der 50-nogle udviklere på projektet, hvoraf kun nogle få er CollabNet medarbejdere.

Subversion er på mange måder et klassisk eksempel på et open source-projekt, og jeg endte med at trække på det hårdere end jeg oprindeligt forventet. Dette var til dels et spørgsmål om bekvemmelighed: når jeg havde brug et eksempel på et bestemt fænomen, kunne jeg normalt kalder en op fra Subversion ret off toppen af mit hoved. Men det var også et spørgsmål om kontrol. Selv om jeg er involveret i andre fri software-projekter i forskellig grad, og tale med venner og bekendte, der er involveret i mange flere, man hurtigt indser, når du skriver til print, at alle påstande skal være fact-tjekket. Jeg ønskede ikke at komme med udtalelser om begivenheder i andre projekter baseret udelukkende på, hvad jeg kunne læse i deres offentlige postlistearkiver. Hvis nogen skulle forsøge at med Subversion, jeg vidste, ville hun have ret omkring halvdelen af tiden og forkert den anden halvdel. Så når tegning inspiration eller eksempler fra et projekt, som jeg ikke har direkte erfaring, jeg prøvede først at tale med en informant der nogen, jeg kunne stole at forklare, hvad der egentlig foregår.

Subversion har været mit job for de sidste 5 år, men jeg har været involveret i gratis software til 12. Andre projekter, der påvirkede denne bog, omfatter:

• GNU Emacs tekst editor projekt på Free Software Foundation, som jeg opretholder et par små pakker.
• Concurrent Versions System (CVS), som jeg har arbejdet på intenst i 1994-1995 med Jim Blandy, men har været involveret med kun sporadisk siden.
• Indsamlingen af open source-projekter kendt som Apache Software Foundation, især Apache Portable Runtime (ÅOP) og Apache HTTP Server.
• OpenOffice.org, Berkeley Database fra Sleepycat, og MySQL Database, jeg har ikke været involveret i disse projekter, personligt, men har observeret dem, og i nogle tilfælde, snakkede med folk der.
• GNU Debugger (GDB) (også).
• Debian-projektet (ligeså).

Dette er ikke en komplet liste, selvfølgelig. Som de fleste open source programmører, holder jeg løs faner på mange forskellige projekter, bare for at få en fornemmelse af den generelle tilstand af tingene. Jeg vil ikke nævne dem alle her, men de nævnes i teksten, hvor det er relevant.

Tak

Denne bog tog fire gange så lang tid at skrive, end jeg troede det ville, og en stor del af den tid følte snarere som et flygel ophængt over mit hoved, hvor jeg gik. Uden hjælp fra mange mennesker, ville jeg ikke have været i stand til at fuldføre det, mens der opholder sane.

Andy Oram, min redaktør på O’Reilly, var en forfatter drøm. Bortset fra at kende det område, intimt (han foreslog mange af de emner), har han den sjældne gave at vide, hvad man ville sige og hjælpe en finde den rigtige måde at sige det. Det har været en ære at arbejde sammen med ham. Tak også til Chuck Toporek til styring dette forslag til Andy højre væk.

Brian Fitzpatrick revideret næsten alt materialet, som jeg skrev det, som ikke kun gjort bogen bedre, men holdt mig at skrive, da jeg ønskede at være overalt i verden, men foran computeren. Ben Collins-Sussman og Mike Pilato også tjekket op på fremskridt, og var altid glade for at diskutere, undertiden på længde-uanset emne, jeg prøvede at dække den pågældende uge. De har også bemærkede, da jeg bremset, og forsigtigt naget når det er nødvendigt. Tak, gutter.

Biella Coleman skrev sin afhandling på samme tid jeg skrev denne bog. Hun ved, hvad det betyder at sætte sig ned og skrive hver dag, og gav et inspirerende eksempel såvel som en sympatisk øre. Hun har også en fascinerende anthropologist’s-øje lyset af den fri software-bevægelsen, der giver både ideer og referencer, som jeg var i stand anvendelse i bogen. Alex Golub-anden antropolog med en fod i den frie software verden, og også afslutte sin afhandling på samme tid var usædvanligt støttende tidligt, som hjalp en hel del.

Micah Anderson eller anden måde aldrig syntes for undertrykt af hans eget skriftligt gig, som var inspirerende i en syg, misundelse-frembringende slags måde, men han var altid klar med venskab, samtale, og (ved mindst én lejlighed) teknisk support. Tak, Micah!

Jon Trowbridge og Sander Striker gav både opmuntring og konkret hjælp, deres brede erfaring i fri software, materiale jeg kunne ikke har fået nogen anden måde.

Takket være Greg Stein ikke kun for venskab og godt timet opmuntring, men for at vise Subversion-projektet, hvor vigtigt regelmæssig kode anmeldelse er i opbygningen af et programmeringssprog samfund. Tak også til Brian Behlendorf, der taktfuldt trommede ind i vores hoveder betydningen af at have drøftelser offentligt, og jeg håber, at princip afspejles i hele denne bog.

Takket være Benjamin «Mako» Hill og Seth Schoen, for forskellige samtaler om fri software og dens politik, at Zack Urlocker og Louis Suarez-Potts til at tage tid ud af deres travle hverdag der skal interviewes, til Shane på den Slashcode liste for at tillade hans stilling, der skal citeres, og at Haggen Så for hans enormt hjælpsomme sammenligning af konserverede hosting sites.

Takket være Alla Dekhtyar, Polina, og Sonya for deres utrættelige og patient opmuntring. Jeg er meget glad for, at jeg ikke længere vil have at afslutte (eller rettere, prøve uden held at afslutte) vores aftener tidligt at gå hjem og arbejde på «The Book».

Tak til Jack Repenning for venskab, samtale, og en stædig afvisning af at nogensinde acceptere en let forkert analyse, når en hårdere rigtige er tilgængelig. Jeg håber, at nogle af hans lange erfaring med både softwareudvikling og software-branchen smittede af på denne bog.

CollabNet var usædvanlig generøse i at tillade mig en fleksibel tidsplan for at skrive, og ikke klage, når det gik på langt længere end oprindeligt planlagt. Jeg kender ikke alle de snørklede af, hvordan ledelsen ankommer til sådanne beslutninger, men jeg formoder Sandhya Klute, og senere Mahesh Murthy, havde noget at gøre med det-min tak til dem begge.

Hele Subversion udviklingsteam har været en inspiration for de seneste fem år, og meget af det er i denne bog, jeg lærte af at arbejde med dem. Jeg vil ikke takke dem alle ved navn her, fordi der er for mange, men jeg beder enhver læser, der løber ind i en Subversion committer til straks at købe det committer at drikke efter eget valg-jeg helt sikkert planer om at.

Mange gange har jeg ranted til Rachel Scollon om status for bogen, hun var altid villig til at lytte, og på en måde lykkedes at gøre problemerne synes mindre end før vi snakkede. Det hjalp en masse-tak.

Tak (igen) til Noel Taylor, der må da have undret jeg ønskede at skrive en anden given bog, hvor meget jeg klagede sidste gang, men hvis venskab og ledelse af Golosa hjalp med at holde musik og godt kammeratskab i mit liv, selv i de travleste tidspunkter . Tak også til Matthew Dean og Dorothea Samtleben, venner og langmodighed musikalske partnere, som var meget forstående, da mine undskyldninger for ikke at praktisere stablet op. Megan Jennings var konstant støttende, og virkelig interesserede i emnet, selvom det var uvant for hende en stor tonic for en usikker forfatter. Tak, kammerat!

Jeg havde fire kyndige og flittige anmeldere til denne bog: Yoav Shapira, Andrew Stellman, Davanum Srinivas, og Ben Hyde. Hvis jeg havde været i stand til at indarbejde alle deres fremragende forslag, ville dette være en bedre bog. Som det var, tidsbegrænsninger tvang mig til at vælge og vrage, men de forbedringer stadig var betydelig. Eventuelle fejl, der forbliver er helt min egen.

Mine forældre, Frances og Henry, var vidunderligt støttende som altid, og da denne bog er mindre teknisk end den foregående, jeg håber, de vil finde det lidt mere læsbar.

Endelig vil jeg gerne takke dedicatees, Karen Underhill og Jim Blandy. Karens venskab og forståelse har betydet alt for mig, ikke kun under skrivning af denne bog, men i de sidste syv år. Jeg ville simpelthen ikke er færdig uden hendes hjælp. Ligeledes for Jim, en sand ven og en hacker hacker, som først lærte mig om gratis software, så meget som en fugl kan lære en flyvemaskine om at flyve.

Disclaimer

De tanker og synspunkter i denne bog, er mine egne. De behøver ikke nødvendigvis repræsentere CollabNet eller af Subversion-projektet.

[1] Udtrykkene «open source» og «fri» er det væsentlige synonymt i denne sammenhæng, og de er diskuteret mere i afsnittet «» Free «Versus» Open Source «» i Kapitel 1, Introduktion.

Kapitel 1.. Indledning

De fleste fri software-projekter mislykkes.

Vi er tilbøjelige til ikke at høre ret meget om de fejl. Kun vellykkede projekter tiltrækker opmærksomhed, og der er så mange gratis software-projekter i alt [2], at selv om kun en lille procentdel lykkes, er resultatet stadig en masse af synlige projekter. Vi ved heller ikke høre om de fejl, fordi fejl ikke er en begivenhed. Der er ingen enkelt øjeblik, når et projekt ophører med at være levedygtig, folk bare slags afdrift væk og stoppe med at arbejde på det. Der kan være et tidspunkt, hvor en endelig foretages ændringer til projektet, men dem, der gjorde det normalt ikke vidste dengang, at det var den sidste. Der er ikke engang en klar definition af, hvornår et projekt er udløbet. Er det, når det ikke har været aktivt arbejdet på i seks måneder? Når dens brugerbase stopper voksende, uden at have overskredet udvikleren base? Hvad hvis udviklerne af et projekt opgive det, fordi de indså de var overlapning med arbejdet i en anden-og hvad nu hvis de slutter, at andet projekt, og udvid derefter det til at omfatte en stor del af deres tidligere indsats? Gjorde det første projekt ende, eller bare skifte hjem?

På grund af sådanne kompleksiteter, er det umuligt at sætte et præcist tal på fejlrate. Men anekdotiske beviser fra mere end et årti i open source, nogle casting rundt på SourceForge.net, og lidt googling alle peger på den samme konklusion: satsen er meget høj, sandsynligvis i størrelsesordenen 90-95%. Antallet klatrer højere, hvis du medtager efterlevende men dysfunktionelle projekter: dem, der producerer køre kode, men som ikke er behagelige steder at være, eller ikke gør fremskridt så hurtigt eller så pålideligt som de kunne.

Denne bog handler om at undgå fiasko. Den undersøger ikke blot hvordan man gør tingene rigtigt, men hvordan du gør dem forkert, så du kan genkende og korrigere problemer tidligt. Mit håb er, at efter at have læst det, vil du have et repertoire af teknikker ikke bare for at undgå almindelige faldgruber ved open source udvikling, men også for behandlingen af vækst og vedligeholdelse af et vellykket projekt. Succes er ikke et nulsumsspil, og denne bog er ikke om at vinde eller få foran konkurrenterne. Faktisk er en vigtig del af at køre et open source projekt, der arbejder problemfrit med andre, beslægtede projekter. I det lange løb, bidrager hver vellykket projekt til velvære af den samlede, globale krop af fri software.

Det ville være fristende at sige, at fri software-projekter mislykkes for de samme mulige grunde proprietære software-projekter gør. Bestemt, gratis software ikke har monopol på urealistiske krav, vage specifikationer, dårlig forvaltning, utilstrækkelige design faser, eller nogen af de andre Hobgoblins allerede velkendte for software-industrien. Der er en enorm krop af at skrive om disse emner, og jeg vil forsøge ikke at gentage det i denne bog. I stedet vil jeg forsøge at beskrive de problemer, som er særegne for fri software. Når et gratis software-projekt går på grund, er det ofte fordi udviklerne (eller ledere) ikke værdsætter de unikke problemer med open source software udvikling, selv om de kunne have været helt forberedt til de bedre kendte vanskeligheder lukkede source-udvikling .

En af de mest almindelige fejl er urealistiske forventninger om fordelene ved open source selv. En åben licens garanterer ikke, at horder af aktive udviklere pludselig vil frivilligt deres tid til dit projekt, heller ikke open-sourcing en urolig projekt automatisk helbrede sine dårligdomme. Faktisk tværtimod: åbning af et projekt kan tilføje helt nye sæt af kompleksitet, og koster mere på kort sigt end blot at holde det in-house. Åbning betyder arrangere koden til at være forståelig for helt fremmede, oprettelse af en udvikling websted og e-mail lister, og ofte skrive dokumentation for første gang. Alt dette er en masse arbejde. Og selvfølgelig, hvis alle interesserede udviklere dukker op, er der den ekstra byrde at besvare deres spørgsmål i et stykke tid før at se nogen fordel af deres tilstedeværelse. Som udvikler Jamie Zawinski sagt om de urolige tidlige dage af Mozilla-projektet:

Open source virker, men det er absolut ikke et universalmiddel. Hvis der er en skræmmende fortælling her, er det at du ikke kan tage et døende projekt, drys den med den magiske nisse støv af «open source», og har alt magisk arbejde ud. Software er hård. De spørgsmål er ikke så simpelt.

(Fra http://www.jwz.org/gruntle/nomo.html)

En beslægtet fejltagelse er at skimping på præsentation og emballering, regne, at de altid kan ske senere, når projektet er godt på vej. Præsentation og emballage omfatter en bred vifte af opgaver, der alle kredser omkring temaet reducere adgangsbarriere. Realiseringen af projektet indbyder til de uindviede betyder skrivning bruger og udvikler dokumentation, oprettelse af et projekt hjemmeside, der er informativ for nyankomne, automatisere så meget af softwarens kompilering og installation som muligt, desværre osv. Mange programmører behandle dette arbejde som værende af sekundær betydning til selve koden. Der er et par grunde til dette. For det første kan det føles som busywork, fordi dens fordele er mest synlige for dem, mindst bekendt med projektet, og vice versa. Efter alt, har de mennesker, der udvikler koden ikke virkelig har brug for emballagen. De ved allerede, hvordan du installerer, administrere og bruge softwaren, fordi de skrev det. For det andet, de færdigheder der kræves for at gøre præsentation og emballering godt ofte er helt forskellige fra dem, der kræves for at skrive kode. Folk har en tendens til at fokusere på, hvad de er gode til, selv om det måske tjene projektet bedre at bruge lidt tid på noget, der passer dem mindre. Kapitel 2, Introduktion diskuterer præsentation og emballering i detaljer, og forklarer, hvorfor det er afgørende, at de prioriteres højt fra starten af projektet.

Dernæst kommer fejlslutning at ringe eller ingen projektledelse er påkrævet i open source, eller omvendt, at de samme forvaltningspraksis anvendt til in-house udvikling vil arbejde lige så godt på et open source-projekt. Management i et open source projekt er ikke altid meget synlige, men i de vellykkede projekter, er det normalt sker bag kulisserne i en eller anden form. En lille tankeeksperiment tilstrækkeligt at vise hvorfor. En open source-projekt består af en tilfældig samling af programmører-allerede en notorisk selvstændigt tænkende kategori-der har sandsynligvis aldrig mødt hinanden, og som hver kan have forskellige personlige mål med at arbejde på projektet. Det tankeeksperiment er blot at forestille sig, hvad der ville ske med en sådan gruppe uden ledelse. Spærring mirakler, ville det kollapse eller glide fra hinanden meget hurtigt. Tingene vil ikke bare køre selv, så meget som vi kunne ønske os anderledes. Men forvaltningen, selvom det kan være ganske aktiv, er ofte uformelle, subtile og low-key. Det eneste, holde en udvikling gruppe sammen, er deres fælles tro på, at de kan gøre mere i koncert end individuelt. Således er målet af ledelsen er mest for at sikre, at de fortsætter med at tro dette, har ved at fastsætte standarder for kommunikation, ved at sikre brugbare udviklere ikke få marginaliseret på grund af personlige idiosyncracies, og generelt ved at gøre projektet et sted udviklere ønsker at holde kommer tilbage til. Specifikke teknikker til at gøre dette diskuteres i resten af denne bog.

Endelig er der en generel kategori af problemer, der kan kaldes «svigt i kulturel sejlads.» For ti år siden, selv fem, ville det have været for tidligt at tale om en global kultur med fri software, men ikke længere. En genkendelig kultur har langsomt dukket op, og mens det er bestemt ikke monolitisk-det er mindst lige så tilbøjelige til intern uenighed og fraktionalisme som enhver geografisk bundet kultur-det har en grundlæggende ensartet kerne. Mest succesfulde open source-projekter udviser nogle eller alle af de særlige kendetegn ved denne kerne. De belønner visse typer af adfærd, og straffe andre, de skaber en atmosfære, der fremmer uplanlagte deltagelse, undertiden på bekostning af central koordinering, de har begreberne uhøflighed og høflighed, som kan afvige væsentligt fra de fremherskende andetsteds. Vigtigst af alt har mangeårige deltagere generelt internaliseret disse standarder, så de deler et groft konsensus om forventet adfærd. Mislykkede projekter normalt afviger på væsentlige punkter fra denne kerne, om end utilsigtet, og ofte ikke har en konsensus om, hvad der udgør en rimelig standard opførsel. Det betyder, at når der opstår problemer, kan situationen hurtigt forværres, da deltagerne mangler en allerede etableret bestand af kulturelle reflekser at falde tilbage på for at løse forskelle.

Denne bog er en praktisk guide, ikke et antropologisk studie eller en historie. Men en praktisk kendskab til baggrunden for nutidens gratis software kultur er et væsentligt fundament for enhver praktisk rådgivning. En person, der forstår kulturen kan rejse langt og bredt i open source-verdenen, støder mange lokale variationer i skik og dialekt, men stadig være i stand til at deltage komfortabelt og effektivt overalt. I modsætning hertil vil en person, der ikke forstår kulturen finde processen med at organisere eller deltage i et projekt vanskelig og fuld af overraskelser. Da antallet af mennesker, der udvikler gratis software stadig vokser med stormskridt, der er mange mennesker i denne sidstnævnte kategori-dette er i høj grad en kultur af nye indvandrere, og vil fortsat være det i nogen tid. Hvis du tror, du kan være en af dem, i næste afsnit giver baggrund for diskussioner, du vil støde på senere, både i denne bog og på internettet. (På den anden side, hvis du har arbejdet med open source i et stykke tid, kan du allerede ved en masse af sin historie, så er du velkommen til at springe næste afsnit.)

Historie

Software deling har eksisteret så længe som selve softwaren. I de tidlige dage af computere, følte producenter, konkurrencemæssige fordele skulle havde hovedsagelig i hardware innovation, og derfor ikke betale meget opmærksomhed til software som en forretning aktiv. Mange af de kunder, for disse tidlige maskiner var forskere eller teknikere, der var i stand til at ændre og udvide den software leveres med maskinen selv. Kunder undertiden distribueret deres patches tilbage ikke blot til producenten, men til andre ejere af lignende maskiner. Producenterne ofte tolereret og endda opmuntret dette: i deres øjne, forbedringer af softwaren, uanset kilden, netop har gjort maskinen mere attraktiv for andre potentielle kunder.

Selv om denne tidlige periode lignede nutidens gratis software kultur på mange måder, det adskilte sig i to afgørende henseender. Først var der endnu lidt standardisering af hardware-det var en tid med blomstrende innovation i computer design, men mangfoldigheden af databehandlingsarkitekturer betød, at alt var i strid med alt andet. Således ville software skrevet til en maskine normalt ikke på en anden. Programmører tendens til at erhverve ekspertise i et bestemt arkitektur eller familie af arkitekturer (hvorimod de i dag ville være mere tilbøjelige til at erhverve ekspertise i et programmeringssprog eller familie af sprog, tillid til, at deres ekspertise vil kunne overføres til, hvad computing hardware, de tilfældigvis finde sig selv arbejde med). Fordi en persons ekspertise tendens til at være specifikke for en slags computer, deres ophobning af ekspertise havde den virkning, at den pågældende computer mere attraktivt for dem og deres kolleger. Det var derfor i producentens interesse for maskin-specifik kode og viden til at spredes så bredt som muligt.

For det andet var der ingen Internet. Selv om der var færre juridiske begrænsninger på deling end i dag, var der flere tekniske dem: hvordan man får data fra sted til sted, var ubekvem og besværlig, relativt set. Der var nogle små, lokale netværk, god til deling af oplysninger mellem medarbejdere på samme forskningslaboratorium eller virksomhed. Men der var barrierer at overvinde, hvis man ønskede at dele med alle, uanset hvor de var. Disse barrierer blev overvundet i mange tilfælde. Sommetider forskellige grupper fik kontakt med hinanden uafhængigt af hinanden, sende diske eller bånd gennem jord mail, og nogle gange producenterne selv fungerede som central clearing huse til patches. Det hjalp også, at mange af de tidlige edb-udviklere arbejdede på universiteter, hvor udgivelse ens viden var forventet. Men de fysiske realiteter datatransmission betød der var altid en impedans til deling, en impedans proportional med afstanden (reelle eller organisatoriske), at softwaren skulle rejse. Udbredt, friktionsløs deling, som vi kender det i dag, var det ikke muligt.

The Rise of Proprietary Software og Free Software

Som industrien modnet, flere indbyrdes forbundne ændringer forekom samtidigt. Den vilde mangfoldighed af hardware designs efterhånden gav plads til et par klare vindere-vindere gennem overlegen teknologi, overlegen markedsføring, eller en kombination af de to. Samtidig, ikke helt tilfældigt, og udvikling af såkaldte «højt niveau» programmeringssprog betød, at man kunne skrive et program én gang ét sprog, og har det automatisk oversat («kompileret») til at køre på forskellige typer af computere. Følgerne af denne blev ikke tabt på hardwareproducenter: en kunde kunne nu foretage en større software engineering indsats uden nødvendigvis at låse sig ind i en bestemt computer arkitektur. Når dette blev kombineret med den gradvise indsnævring af performance forskelle mellem forskellige computere, som de mindre effektive design blev luget ud, kunne en producent, der behandlede sin hardware som sit eneste aktiv se frem til en fremtid med faldende avancer. Rå computerkraft var ved at blive ombyttelige godt, mens software var ved at blive det differentiator. Sælger software, eller i det mindste behandle det som en integreret del af hardware salg, begyndte at ligne en god strategi.

Det betød, at producenterne måtte starte håndhæve ophavsretten til deres kode mere strengt. Hvis brugerne simpelthen fortsatte med at dele og ændre koden frit indbyrdes, kan de uafhængigt reimplement nogle af de forbedringer, der nu sælges som «merværdi» af leverandøren. Værre kunne delt kode komme i hænderne på konkurrenterne. Det ironiske er, at alt dette skete omkring det tidspunkt, hvor internettet var at komme i gang. Lige når virkelig uhindret software deling blev endelig bliver teknisk muligt, ændringer i computerbranchen gjort det økonomisk uønsket, i det mindste fra det synspunkt af en enkelt virksomhed. Leverandørerne fastspændt ned, enten nægter brugere adgang til den kode, der kørte deres maskiner, eller insistere på ikke-disclosure aftaler, der gjorde effektiv deling umulig.

Bevidst modstand

Som verden af ubegrænset kode swapping langsomt falmet væk, krystalliseret en modreaktion i hovedet på mindst én programmør. Richard Stallman arbejdede i kunstig intelligens Lab på Massachusetts Institute of Technology i 1970′erne og begyndelsen af 80′erne, under hvad der viste sig at være en guldalder og en gylden placering til rutenummer. AI Lab havde en stærk «hacker etik», [3] og folk var ikke kun tilskyndes, men forventes at dele, hvad forbedringer, de gjorde til systemet. Da Stallman skrev senere:

Vi ikke kalde vores software «gratis software», fordi dette udtryk endnu ikke eksisterede, men det er, hvad det var. Når folk fra et andet universitet eller et selskab ønskede at port og bruge et program, vi gerne lade dem. Hvis du så en person ved hjælp af en uvant og interessant program, kan du altid bede om at se kildekoden, så du kunne læse den, ændre den, eller kannibalisere dele af det at lave et nyt program.

(Fra http://www.gnu.org/gnu/thegnuproject.html)

Denne paradisisk samfund kollapsede omkring Stallman kort efter 1980, da de ændringer, der var sket i resten af branchen omsider fanget op med AI Lab. En start firma hyret væk mange af Lab, programmører til at arbejde på et operativsystem svarer til, hvad de havde arbejdet på i Lab, men nu under en eksklusiv licens. Samtidig overtog AI Lab nyt udstyr, der fulgte med et proprietært operativsystem.

Stallman så større mønster i, hvad der foregik:

De moderne computere i den æra, såsom VAX eller 68.020, havde deres egne styresystemer, men ingen af dem var fri software: du havde til at underskrive en fortrolighedsaftale selv at få en eksekverbar kopi.

Det betød, at det første skridt i at bruge en computer var at love ikke at hjælpe din nabo. En samarbejdende samfund var forbudt. Reglen lavet af ejerne af leverandørejet software var, «Hvis du deler med din nabo, du er en pirat. Hvis du ønsker ændringer, beder os at gøre dem.»

Ved nogle ejendommelighed personlighed, besluttede han at modstå tendensen. I stedet for at fortsætte med at arbejde på den nu-decimerede AI Lab, eller tage et job at skrive kode på en af de nye selskaber, hvor resultaterne af hans arbejde ville blive holdt låst inde i en boks, han trådte ud af Lab og startede GNU-projektet og Free Software Foundation (FSF). Målet med GNU [4] var at udvikle en helt fri og åben computer operativsystem og krop af applikationssoftware, hvor brugerne aldrig ville blive forhindret i at hacking eller dele deres modifikationer. Han var i det væsentlige ud for at genskabe, hvad der var blevet ødelagt under AI Lab, men på et globalt plan, og uden de sårbarheder, der havde gjort AI Lab kultur modtagelige for nedbrydning.

Ud over at arbejde på det nye operativsystem, udtænkt Stallman en copyright licens, hvis vilkår garanteret, at hans kode ville være konstant fri. GNU General Public License (GPL) er en klog stykke juridisk judo: den siger, at den kode kan kopieres og ændres uden begrænsninger, og at begge kopier og afledte værker (dvs., modificerede versioner) skal fordeles under samme licens som den oprindelige, uden yderligere restriktioner. I realiteten bruger det ophavsretten at opnå en effekt modsat den traditionelle ophavsret: i stedet for at begrænse softwarens distribution, det forhindrer nogen, selv forfatteren fra at begrænse den. For Stallman var det bedre end blot at sætte sin kode ind i det offentlige rum. Hvis det var i det offentlige rum, kunne nogen særlig kopi af det inkorporeres i et proprietært program (som det også er kendt for at ske med kode under permissive ophavsretslicenser). Mens en sådan inkorporering ikke på nogen måde ville formindske den oprindelige kode fortsatte tilgængelighed, ville det have betydet, at Stallman indsats kunne gavne fjenden-proprietær software. Den GPL kan opfattes som en form for protektionisme for fri software, fordi det forhindrer ikke-fri software drage fuld fordel af GPLed kode. GPL og dens forhold til andre gratis softwarelicenser er diskuteret i detaljer i kapitel 9, licenser, Copyrights og patenter.

Med hjælp fra mange programmører, delte nogle af dem Stallman ideologi og hvoraf nogle blot ønskede at se en masse gratis kode til rådighed, GNU-projektet begyndte at frigive gratis erstatninger for mange af de mest kritiske komponenter i et operativsystem. På grund af den nu-udbredte standardisering i computer hardware og software, var det muligt at bruge GNU udskiftninger på ellers ikke-fri systemer, og mange mennesker gjorde. GNU teksteditor (Emacs) og C compiler (GCC) var særligt vellykkede, at få store og loyale followings ikke af ideologiske årsager, men simpelthen på deres tekniske meritter. Omkring 1990 havde GNU fremstillede de fleste af et frit styresystem, bortset fra kernel-delen, at maskinens faktisk starter op, og det er ansvaret for at forvalte hukommelse, disk og andre systemressourcer.

Desværre havde GNU-projektet har valgt en kerne design, der viste sig at være sværere at gennemføre end forventet. Den efterfølgende forsinkelse forhindrede Free Software Foundation fra at den første version af et helt frit styresystem. Den sidste stykke blev sat på plads i stedet af Linus Torvalds, en finsk datalogi studerende, der med hjælp fra frivillige over hele verden, havde afsluttet en gratis kerne ved hjælp af en mere konservativ design. Han kaldte det Linux, og når det blev kombineret med de eksisterende GNU-programmer, var resultatet et helt frit styresystem. For første gang kunne du starter din computer og udføre arbejde uden brug af leverandørejet software. [5]

En stor del af softwaren på dette nye operativsystem ikke blev produceret af GNU-projektet. Faktisk var GNU ikke engang den eneste gruppe der arbejder på at producere et frit styresystem (for eksempel, var den kode, der til sidst blev NetBSD og FreeBSD allerede under udvikling på dette tidspunkt). Betydningen af Free Software Foundation var ikke kun i den kode, de skrev, men i deres politiske retorik. Ved at tale om fri software som en årsag i stedet for en bekvemmelighed, de gjorde det svært for programmører ikke at have en politisk bevidsthed om det. Selv de, der var uenige med FSF måtte engagere problemet, hvis kun at afstikke en anden holdning. FSF effektivitet som propagandister lå i at binde deres kode til en besked, ved hjælp af GPL og andre tekster. Som deres kode stor udbredelse, at budskabet spredes så godt.

Utilsigtet modstand

Der var mange andre ting i den spirende gratis software scene, dog, og få var så explictly ideologisk som Stallman GNU Project. En af de vigtigste var Berkeley Software Distribution (BSD), en gradvis re-implementering af Unix-operativsystemet, som indtil slutningen af 1970 har havde været et løst proprietær forskningsprojekt på AT & T-by programmører ved University of California i Berkeley . BSD-gruppen foretog ikke nogen åbenlys politiske erklæringer om behovet for programmører at slutte sig sammen og dele med hinanden, men de praktiserede ideen med flair og entusiasme, ved at koordinere en massiv distribueret udviklingsindsats i hvilken Unix-kommandolinjefunktioner og kode biblioteker, og i sidste ende operativsystemets kerne selv, blev omskrevet fra bunden for det meste af frivillige. Den BSD-projektet blev et mønstereksempel på ikke-ideologisk fri software udvikling, og også tjente som en uddannelse jorden for mange udviklere, der ville gå på at forblive aktive i open source-verdenen.

En anden smeltedigel af kooperativ udvikling var X Window System, et gratis, netværk-transparent grafisk computing miljø, der er udviklet på MIT i midten-1980 er i partnerskab med hardwareleverandører, der havde en fælles interesse i at kunne tilbyde deres kunder et vinduesystemet. Langt fra modstående proprietær software, X licensen bevidst har ladet proprietære udvidelser på toppen af den frie kerne-hvert medlem af konsortiet ønskede chance for at forbedre standard X distribution, og derved opnå en konkurrencemæssig fordel i forhold til de øvrige medlemmer. X Windows [6] selv var fri software, men primært som en måde at skabe lige konkurrencevilkår mellem konkurrerende forretningsmæssige interesser, ikke ud af et ønske om at afslutte dominans leverandørejet software. Endnu et eksempel, der går forud for GNU-projektet med et par år, var TeX, Donald Knuth er gratis, forlagsvirksomhed-kvalitet opsætning system. Han frigivet det under en licens, der tillod nogen at ændre og distribuere koden, men ikke at kalde resultatet «TeX» medmindre det passerede en meget streng sæt kompatibilitetstest (dette er et eksempel på den «trademark-beskytte» klasse af fri licenser, diskuteres mere i kapitel 9, licenser, Copyrights og patenter). Knuth var ikke at tage et standpunkt i den ene eller den anden på spørgsmålet om fri-versus-proprietær software, han bare havde brug for et bedre typesetting system for at fuldføre sin virkelige mål-en bog om edb-programmering-og ikke så nogen grund til ikke at frigive hans system til verden når du er færdig.

Uden opregner hver projekt og hver licens, er det sikkert at sige, at ved slutningen af 1980, var der en masse gratis software til rådighed under en bred vifte af licenser. Mangfoldigheden af licenser afspejlede en tilsvarende mangfoldighed af motiver. Selv nogle af de programmører, der har valgt GNU GPL var langt mindre ideologisk drevet end GNU projektet. Selv om de nød at arbejde på fri software, har mange udviklere ikke overveje leverandørejet software et socialt onde. Der var mennesker, der følte en moralsk impuls for at befri verden af «software hamstring» (Stallmans betegnelse for ikke-fri software), men andre blev motiveret mere af teknisk ophidselse, eller ved fornøjelsen af at arbejde sammen med ligesindede samarbejdspartnere, eller endog ved en simpel menneskelig ønske om ære. Alligevel ved og store disse forskellige motivationer ikke interagerer på en destruktiv måde. Dette skyldes til dels software, i modsætning til andre kreative former som prosa eller billedkunst, skal passere semi-objektive prøver for at blive betragtet som en succes: den skal køre og være rimeligt fri for bugs. Dette giver alle deltagere i et projekt en slags automatisk ubestridt, en årsag og en ramme for et samarbejde uden at bekymre sig for meget om kvalifikationer ud over den tekniske.

Udviklere havde en anden grund til at holde sammen så godt: det viste sig, at den frie software verden var at producere nogle meget høj kvalitet kode. I nogle tilfælde var det påviseligt teknisk overlegent den nærmeste ikke-fri alternativ, i andre tilfælde var det mindste være sammenlignelige, og selvfølgelig er det altid koste mindre. Mens kun få mennesker kunne have været motiveret til at køre gratis software på strengt filosofiske grunde, mange mennesker var glade for at køre det, fordi det gjorde et bedre job. Og af dem, der brugte det, var nogle procent altid villige til at donere deres tid og evner til at vedligeholde og forbedre softwaren.

Denne tendens til at producere god kode var bestemt ikke er universel, men det skete med stigende hyppighed i fri software-projekter rundt om i verden. Virksomheder, der afhang tungt på software efterhånden begyndte at tage varsel. Mange af dem opdagede, at de allerede var ved hjælp af gratis software i dag-til-dag operationer, og simpelthen ikke havde vidst det (den øverste ledelse er ikke altid klar over alt det it-afdelingen gør). Selskaber begyndte at tage en mere aktiv og offentlig rolle i fri software-projekter, der bidrager tid og udstyr, og nogle gange endda direkte at finansiere udviklingen af frie programmer. Sådanne investeringer kan i de bedste scenarier, tilbagebetale sig selv mange gange. Sponsoren kun betaler et lille antal ekspert programmører at hellige sig projektet på fuld tid, men høster fordelene af alles bidrag, herunder arbejde fra ubetalte frivillige og fra programmører, der betales af andre selskaber.

«Free» Versus «Open Source»

Da erhvervslivet gav mere og mere opmærksomme på fri software blev programmører står over for nye spørgsmål af præsentationen. Den ene var ordet «gratis» i sig selv. På første hører udtrykket «fri software» mange mennesker fejlagtigt tror, det betyder bare «nul-cost software.» Det er sandt, at al fri software er nul omkostninger, [7], men ikke alle nul-cost software er gratis. For eksempel, under slaget af de browsere i 1990′erne både Netscape og Microsoft forærede deres konkurrerende webbrowsere uden beregning, i en kamp for at vinde markedsandele. Hverken browser var frie i «fri software» sense. Du kunne ikke få kildekoden, og selv hvis du kunne, men du havde ikke ret til at ændre eller videredistribuere den. [8] Det eneste, du kunne gøre, var at downloade en eksekverbar og køre den. De browsere var ikke mere fri end præproducerede software købt i en butik, de bare havde en lavere pris.

Denne forvirring over ordet «gratis» skyldes udelukkende en uheldig tvetydighed i det engelske sprog. De fleste andre tungemål skelne lave priser fra frihed (sondringen mellem gratis og libre er umiddelbart klart for taler romanske sprog, for eksempel). Men engelsk position som de facto bro sprog af internettet betyder, at et problem med engelsk er til en vis grad et problem for alle. Den misforståelse omkring ordet «gratis» var så udbredt, at fri software programmører efterhånden udviklet en standard formel som svar: «Det er gratis som i frihed-tænke ytringsfriheden, ikke gratis øl.» Alligevel skulle forklare det igen og igen er trættende. Mange programmører følte med en vis berettigelse, at det tvetydige ord «gratis» blev hæmmer offentlighedens forståelse af denne software.

Men problemet gik dybere end det. Ordet «gratis» udført med det en uomgængelig moralsk bibetydning: hvis friheden var et mål i sig selv, det ikke ligegyldigt, om fri software også sket for at være bedre, eller mere rentabelt for visse virksomheder under visse omstændigheder. Det var blot behagelige bivirkninger af et motiv, der var på bunden, hverken teknisk eller merkantil, men moralsk. Endvidere «fri som i frihed» position tvang en himmelråbende inkonsekvens på virksomheder, der ønskede at støtte bestemte gratis programmer i et aspekt af deres forretning, men fortsat markedsføre leverandørejet software i andre.

Disse dilemmaer kom til et samfund, der allerede var klar til en identitetskrise. De programmører der faktisk skrive fri software har aldrig været en mening om det overordnede mål, om nogen, af den fri software-bevægelsen. Selv at sige, at udtalelser, løber fra den ene yderlighed til den anden ville være misvisende, eftersom det ville fejlagtigt indebære et lineært område, hvor der er i stedet en flerdimensional spredning. Dog kan to hovedkategorier af tro skelnes mellem, hvis vi er villige til at ignorere finesser for øjeblikket. En gruppe tager Stallman mener, at friheden til at dele og ændre er det vigtigste, og at der derfor, hvis du holder op med at tale om frihed, du har udeladt det centrale spørgsmål. Andre mener, at selve softwaren er det vigtigste argument i sin favør, og er ubehageligt med forkynde proprietær software selv dårligt. Nogle, men ikke alle, gratis software programmører tror, at forfatteren (eller arbejdsgiver, der er tale om lønnet arbejde) bør have ret til at kontrollere vilkårene for distribution, og at der ikke moralsk dom behøver være knyttet til valget af bestemte vilkår.

I lang tid har disse forskelle ikke skal undersøges nøje eller formuleret, men fri software er spirende succes i erhvervslivet gjort spørgsmålet uundgåelig. I 1998 blev udtrykket open source skabt som et alternativ til «gratis», af en koalition af programmører, der med tiden blev The Open Source Initiative (OSI). [9] OSI følte ikke blot, at «fri software» var potentielt forvirrende, men at ordet «gratis» var blot et symptom på et generelt problem: at bevægelsen havde brug for en marketing program til at pitche det til virksomhedernes verden, og at tale om moral og sociale fordele ved deling ville aldrig flyve i virksomhedernes bestyrelseslokaler. Med deres egne ord:

Open Source Initiative er et marketing program for gratis software. Det er en plads til «fri software» på solide pragmatiske grunde snarere end ideologisk karbad-hamrende. Den vindende stof har ikke ændret sig, den tabende attitude og symbolik har. …

Sagen, der skal gøres for de fleste techies handler ikke om begrebet open source, men navnet. Hvorfor ikke kalde det, som vi traditionelt har, gratis software?

En direkte årsag er, at udtrykket «fri software» er let misforstås på måder, der fører til konflikt. …

Men den egentlige årsag til ommærkning er et markedsførings-en. Vi forsøger at pitche vores koncept til erhvervslivet nu. Vi har et vindende produkt, men vores positionering i fortiden, har været forfærdelige. Udtrykket «fri software» er blevet misforstået af forretningsfolk, der forveksles ønsket om at dele med anti-kommercialisme, eller værre, tyveri.

Mainstream virksomhedernes administrerende direktører og CTOs vil aldrig købe «fri software». Men hvis vi tager meget samme tradition, de samme mennesker og de samme fri-softwarelicenser og ændre etiketten til «open source»? det, vil de købe.

Nogle hackere finde det svært at tro, men det er fordi de er techies der tænker i konkrete, væsentlige vilkår og ikke forstår, hvor vigtigt billede, er, når du sælger noget.

I markedsføringen, er udseendet virkelighed. Det indtryk, at vi er villige til at klatre ned fra barrikaderne og arbejde med virksomhedernes verden tæller lige så meget som virkeligheden i vores adfærd, vores overbevisninger og vores software.

(Fra http://www.opensource.org/ Eller rettere, tidligere fra dette websted -. OSI har tilsyneladende taget ned siderne siden da, selv om de stadig kan ses på http://web.archive.org/web/20021204155057/ http://www.opensource.org/advocacy/faq.php og

Hovederne på mange isfjelde af kontroverser er synlige i denne tekst. Det refererer til «vores overbevisning», men smart undgår uddyber præcis, hvad disse domme er. For nogle kan det være den overbevisning, at koden er udviklet i henhold til en åben proces vil være bedre kode, for andre kan det være den overbevisning, at alle oplysninger skal deles. Der er brugen af ordet «tyveri» til at henvise (formentlig) til ulovlig kopiering, en sædvane, som mange objekt, med den begrundelse, at det ikke er tyveri, hvis den oprindelige besidderen har stadig elementet bagefter. Der er den forjættende fingerpeg om, at den fri software-bevægelsen kan være fejlagtigt anklaget for anti-kommercialisme, men det efterlader omhyggeligt ureflekteret spørgsmålet om, hvorvidt en sådan beskyldning ville have nogen basis i virkeligheden.

Ingen er at sige, at OSI hjemmeside er inkonsekvent eller vildledende. Det er ikke. Det er snarere et eksempel på, hvad de OSI påstande havde været forsvundet fra den fri software-bevægelsen: «. Levedygtig i erhvervslivet» god markedsføring, hvor «god» betyder Open Source Initiative gav en masse mennesker præcis, hvad de havde ledt efter-et ordforråd til at tale om fri software som en udvikling metode og forretningsstrategi, i stedet for som et moralsk korstog.

Udseendet af Open Source Initiative ændret landskabet af fri software. Det formaliseret en dikotomi, som længe havde været unavngivne, og dermed tvunget bevægelsen til at erkende, at det havde interne politik såvel som eksternt. Virkningen dag er, at begge parter har skullet finde fælles fodslag, da de fleste projekter omfatter programmører fra begge lejre, samt deltagere, der ikke passer nogen klar kategori. Det betyder ikke, folk taler aldrig om moralske motivationer-bortfalder i den traditionelle «hacker-etikken» kaldes ud, for eksempel. Men det er sjældent, at en gratis software / open source udvikler til åbent spørgsmålstegn ved den grundlæggende motivation andre i et projekt. Bidraget trumps indskyderen. Hvis nogen skriver god kode, behøver du ikke spørge dem, om de gør det af moralske grunde, eller fordi deres arbejdsgiver betalte dem til, eller fordi de er ved at bygge op deres CV, eller hvad. Du vurdere bidraget af tekniske grunde, og reagere på et teknisk grundlag. Selv eksplicit politiske organisationer som Debian-projektet, hvis mål er at tilbyde en 100% gratis (dvs. «fri som i frihed») computing miljø, er temmelig afslappet om integration med ikke-fri kode og samarbejde med programmører, der ikke deler nøjagtig de samme mål.

Situationen i dag

Når du kører et gratis software-projekt, vil du ikke brug for at tale om sådanne tungtvejende filosofiske spørgsmål på daglig basis. Programmører vil ikke insistere på, at alle andre i projektet enige med deres synspunkter om alle ting (dem, der insisterer på dette hurtigt finde sig selv ude af stand til at arbejde i ethvert projekt). Men du behøver at være opmærksom på, at spørgsmålet om «gratis» versus «open source» eksisterer, dels for at undgå at sige ting, der kan være skadelige for nogle af deltagerne, og dels fordi forståelse udvikleres motivation er den bedste måde, i nogle forstand, er den eneste måde, at styre et projekt.

Gratis software er en kultur af valg. At operere med succes i det, er du nødt til at forstå, hvorfor folk vælger at være i det i første omgang. Tvangsforanstaltninger teknikker virker ikke. Hvis folk er utilfredse i et projekt, vil de bare vandre ud til en anden. Gratis software er bemærkelsesværdigt selv blandt frivillige fællesskaber for sin lethed af investeringen. De fleste af de involverede mennesker har faktisk aldrig mødt de andre deltagere ansigt til ansigt, og blot donere stumper af tid, når de har lyst til det. De normale ledninger, som mennesker obligation med hinanden og danner varige grupper indsnævret ned til en lille kanal: det skrevne ord, foretaget via elektroniske ledninger. På grund af dette, kan det tage lang tid for en sammenhængende og dedikeret gruppe til at danne. Omvendt er det ganske let for et projekt at miste en potentiel frivillig i de første fem minutter af bekendtskab. Hvis et projekt ikke gøre et godt første indtryk, nytilkomne sjældent give det en chance.

Forgængelighed, eller snarere den potentielle forgængelighed, af relationer er måske den mest skræmmende opgave for et nyt projekt. Hvad vil overbevise alle disse mennesker til at holde sammen længe nok til at producere noget nyttigt? Svaret på dette spørgsmål er komplekst nok til at besætte resten af denne bog, men hvis det skulle blive udtrykt i én sætning, ville det være dette:

Folk skal føle, at deres tilknytning til et projekt, og indflydelse på det, er direkte proportional med deres bidrag.

Ingen klasse af udviklere, eller potentielle udviklere, bør nogensinde føle diskonteres eller diskrimineret for ikke-tekniske årsager. Det er klart, projekter med virksomhedernes sponsorering og / eller funktionærer udviklere skal være særlig forsigtig på dette område, som kapitel 5, Money diskuterer i detaljer. Selvfølgelig betyder det ikke, at hvis der ikke er virksomhedernes sponsorering så har du intet at bekymre sig om. Penge er blot en af mange faktorer, der kan påvirke et projekts succes. Der er også spørgsmål om, hvad sprog at vælge, hvilken licens, hvad udviklingsproces, præcis hvad slags infrastruktur til at etablere, hvordan at offentliggøre projektets start effektivt, og meget mere. Start et projekt ud på den højre fod er emnet for næste kapitel.

[2] SourceForge.net, en populær hosting site, havde 79.225 projekter registreret som fra midten af april 2004. Dette er ikke i nærheden af det samlede antal fri software-projekter på internettet, naturligvis, det er bare det nummer, der valgte at bruge SourceForge.

[3] Stallman bruger ordet «hacker» i betydningen «person, der elsker at programmere og nyder at være klog om det,» ikke det relativt nye betydning af «en person, der bryder ind i computere.»

[4] Det står for «GNU er ikke Unix» og «GNU» i denne udvidelse står for … det samme.

[5] Teknisk set Linux var ikke den første. En gratis styresystem til IBM-kompatible computere, kaldet 386BSD, var kommet ud kort før Linux. Men det var meget sværere at få 386BSD op at køre. Linux foretaget en sådan splash ikke kun fordi det var gratis, men fordi det faktisk havde en stor chance for at starte computeren, når du har installeret det.

[6] De foretrækker at blive kaldt «X Window System», men i praksis som regel folk kalder det «X Windows», fordi tre ord er bare alt for besværligt.

[7] Man kan opkræve et gebyr for at give kopier af gratis software, men da man ikke kan stoppe modtagerne at tilbyde det uden beregning bagefter, er prisen faktisk kørt til nul med det samme.

[8] Kildekoden til Netscape Navigator blev til sidst løsladt under en open source licens, i 1998, og blev grundlaget for den Mozilla webbrowser. Se http://www.mozilla.org/.

[9] OSI web hjem er http://www.opensource.org/.

Kapitel 2. Kom godt i gang

Den klassiske model for, hvordan fri software-projekter kommer i gang blev leveret af Eric Raymond, i en nu berømt papir på open source-processer titlen Katedralen og basaren. Han skrev:

Al god gerning af software starter ved at ridse en udviklers personlige kløe.

(Fra http://www.catb.org/~esr/skrifter/katedral-basar/)

Bemærk, at Raymond ikke var at sige, at open source-projekter sker kun, når nogle enkelte får en klør. Snarere blev han siger at god software resultater, når programmøren har en personlig interesse i, at problemet løst, relevansen af dette til fri software var, at en personlig kløe tilfældigvis være den hyppigste motivation for at starte en gratis software-projekt.

Det er stadig, hvordan de fleste fri software-projekter er i gang, men i mindre grad nu end i 1997, da Raymond skrev disse ord. I dag har vi fænomenet organisationer, inklusive for-profit selskaber-start store, centralt styrede open source-projekter fra bunden. Den enlige programmør, banging ud noget kode til at løse et lokalt problem, og derefter realisere resultatet har bredere anvendelighed, er stadig kilde til megen nye gratis software, men er ikke den eneste historie.

Raymond pointe er stadig indsigtsfulde, dog. Den afgørende betingelse er, at producenterne af softwaren har en direkte interesse i dens succes, fordi de bruger det selv. Hvis softwaren ikke gør, hvad det er meningen at gøre, vil den person eller organisation, der producerer det føler utilfredshed i deres daglige arbejde. For eksempel kan den OpenAdapter projektet (http://www.openadapter.org/), som blev startet af investeringsbanken Dresdner Kleinwort Wasserstein som et open source-ramme for integration af forskellige økonomiske informationssystemer, næppe siges at ridse en individuel programmør personlige klør. It ridser en institutionel kløe. Men det klør følger direkte af erfaringerne fra institutionen og dens partnere, og derfor, hvis projektet undlader at lindre dem, vil de vide. Dette arrangement giver en god software, fordi tilbagekoblingssløjfen flyder i den rigtige retning. Programmet er ikke skrevet for at blive solgt til en anden, så de kan løse deres problem. Det bliver skrevet for at løse sin egen problem, og derefter delt med alle, meget som om problemet var en sygdom, og softwaren var medicinen, hvis fordeling er beregnet til helt at udrydde epidemien.

 

Dette kapitel handler om hvordan man kan indføre en ny gratis software-projekt til verden, men mange af dets anbefalinger vil lyde bekendt for en sundheds organisation distribuerer medicin. Målene er meget ens: du ønsker at gøre det klart, hvad medicinen gør, får det i hænderne på de rigtige mennesker, og sørg for, at dem, der modtager den ved, hvordan man bruger det. Men med software, du også ønsker at lokke nogle af modtagerne til at deltage i igangværende forskningsindsats for at forbedre medicinen.

Gratis software distribution er en dobbelt opgave. Den software skal erhverve brugere, og for at tilegne udviklere. Disse to behov er ikke nødvendigvis i konflikt, men de gør tilføje nogle kompleksitet til et projekts indledende præsentation. Nogle oplysninger er nyttige for både publikum, nogle er kun nyttig til den ene eller den anden. Begge former for oplysninger bør tilslutte sig princippet om skalerede præsentation, det er, at graden af detaljer præsenteres på hvert trin skal svare direkte til mængden af tid og kræfter lagt i af læseren. Større indsats skal altid være lig mere belønning. Når de to ikke korrelerer stramt, kan folk hurtigt miste troen og stoppe investere indsats.

Konsekvensen af dette er, at optrædener sagen. Programmers, især ofte ikke kan lide at tro det. Deres kærlighed til indhold frem for formalia er næsten et punkt af faglig stolthed. Det er ikke tilfældigt, at så mange programmører udviser en antipati for marketing og PR-arbejde, eller at professionelle grafiske designere er ofte forfærdede over, hvad programmører komme med på egen hånd.

Det er en skam, fordi der er situationer, hvor form er stof, og projekt præsentation er en af dem. For eksempel er det allerførste en besøgende lærer om et projekt, hvad dets hjemmeside ser ud. Denne information absorberes før nogen af det faktiske indhold på hjemmesiden er fattet-før noget af teksten er blevet læst eller links klikket på. Dog uretfærdigt det end måtte være, kan folk ikke stoppe sig selv fra at danne en umiddelbar første indtryk. Webstedets udseende signalerer, om pleje blev taget i at organisere projektets præsentation. Mennesker har ekstremt følsom antenner til detektering af investeringen af pleje. De fleste af os kan fortælle i et blik, om en web site blev kastet sammen hurtigt eller fik alvorlige overvejelser. Dette er det første stykke af oplysninger, dit projekt lægger ud, og det indtryk, det skaber vil bære over til resten af projektet ved association.

Mens en stor del af dette kapitel taler om indholdet dit projekt bør starte ud med, skal du huske, at dens udseende og stof også. Fordi projektets hjemmeside har at arbejde for to forskellige typer af besøgende-brugere og udviklere-særlig opmærksomhed bør rettes mod klarhed og rettethed. Selv om dette ikke er stedet for en generel afhandling om web design, ét princip er vigtigt nok til at fortjene omtale, især når sitet tjener flere (hvis overlappende) publikum: folk skal have en idé hvor et link går, inden du klikker på det. For eksempel bør det være indlysende at se på links til brugerdokumentation at de fører til brugerdokumentation, og ikke til, at sige, udvikler dokumentation. Løb en projekt handler dels om at levere information, men det handler også om at levere komfort. Den blotte tilstedeværelse af visse standard tilbud, i forventede steder, beroliger brugere og udviklere, der beslutter, om de ønsker at blive involveret. Den siger, at dette projekt har sin handling sammen, har foregrebet spørgsmålene folk vil stille, og har gjort en indsats for at besvare dem på en måde, der kræver minimal anstrengelse på den del af spørgeren. Ved at give off denne aura af beredskab, sender projektet ud en besked: «Din tid vil ikke være spildt, hvis du bliver involveret,» hvilket er præcis, hvad folk har brug for at høre.

Men først, Look Around

Før du starter et open source projekt, er der en vigtig advarsel:

Altid kigge rundt for at se, om der er et eksisterende projekt, der gør hvad du ønsker. Chancerne er rigtig god, at det problem, du ønsker løst nu, en anden ville løst før dig. Hvis de gjorde løse det, og udgav deres kode under en fri licens, så er der ingen grund til at opfinde den dybe tallerken i dag. Der er undtagelser, selvfølgelig: Hvis du ønsker at starte et projekt som en uddannelsesmæssig erfaring, vil præ-eksisterende kode ikke hjælpe, eller måske det projekt du har i tankerne er så specialiseret, at du ved, at der er nul chance nogen anden har gjort den. Men generelt er der ingen mening ikke kigger, og payoff kan være enorme. Hvis de sædvanlige søgemaskiner på internettet ikke møder op noget, kan du prøve at søge på http://freecode.com/ (et open source-projekt nyhedsside, om hvilken mere vil blive sagt senere), på http://www.sourceforge. netto/, og i free Software Foundation bibliotek af gratis software på http://directory.fsf.org/.

Selv hvis du ikke kan finde præcis, hvad du ledte efter, kan du finde noget så tæt, at det giver mere mening at deltage, at projektet og tilføje funktionalitet end at starte fra bunden selv.

Begyndende fra, hvad du Have

Du har kigget rundt, fandt, at intet derude virkelig passer til dine behov, og besluttede at starte et nyt projekt.

Hvad nu?

Den sværeste del om at lancere et gratis software-projekt er at omdanne en privat vision til et andet offentligt. Du eller din organisation kan udmærket ved hvad du vil, men udtrykker dette mål forståeligt til verden er en hel del arbejde. Det er imidlertid vigtigt, at du tager dig tid til at gøre det. Du og de andre stiftere skal beslutte, hvad projektet egentlig handler om, det vil sige, beslutte sine begrænsninger, hvad det vil ikke gøre det så godt, hvad det vil-og skrive en mission statement. Denne del er normalt ikke alt for hårdt, selvom det nogle gange kan afsløre uudtalte forudsætninger og endda uenighed om karakteren af projektet, hvilket er fint: bedre til at løse dem nu end senere. Det næste skridt er at pakke op af projektet for det offentlige forbrug, og det er, dybest set, ren slid.

Hvad gør det så besværligt, er, at den hovedsageligt består af at organisere og dokumentere tingene alle allerede kender-»Alle», det vil sige, hvem der har været involveret i projektet hidtil. Således for de mennesker at gøre arbejdet, er der ingen umiddelbar fordel. De behøver ikke en README-fil med en oversigt over projektet, eller et design dokument eller brugermanual. De behøver ikke en omhyggeligt arrangeret kode træ svarer til de uformelle, men udbredt standarder for software source distributioner. Uanset hvordan kildekoden er indrettet, er fint for dem, fordi de allerede er vant til det alligevel, og hvis koden kører på alle, de ved, hvordan man bruger det. Det behøver ikke engang noget, for dem, hvis de grundlæggende arkitektoniske forudsætninger for projektet forbliver udokumenteret, de er allerede bekendt med det også.

Nyankomne, på den anden side, har brug for disse ting. Heldigvis har de ikke brug for dem alle på én gang. Det er ikke nødvendigt for dig at give alle mulige ressource, før du tager et projekt publikum. I en perfekt verden, måske ville alle nye open source-projekt starter ud livet med en grundig design dokument, en komplet brugsanvisning (med særlige markeringer til funktioner planlagt, men endnu ikke gennemført), smukt og portably pakket kode, som kan køre på enhver computerplatform, og så videre. I virkeligheden ville tage sig af alle disse løse ender være uoverkommeligt tidskrævende, og alligevel, det er arbejde, at man med rimelighed kan håbe frivillige vil hjælpe med, når projektet er i gang.

Hvad er nødvendigt, er imidlertid, at nok investering sættes i præsentationen, som nybegyndere kan komme forbi den indledende hindring af det manglende kendskab. Tænk på det som det første skridt i en bootstrapping proces, for at bringe projektet til en slags minimal aktivering energi. Jeg har hørt denne tærskel kaldes hacktivation energi: den mængde energi, en nybegynder skal sætte ind, før hun begynder at få noget tilbage. Jo lavere et projekts hacktivation energi, jo bedre. Din første opgave er at bringe hacktivation energi ned til et niveau, der tilskynder folk til at involvere sig.

Hver af de følgende underafsnit beskriver et vigtigt aspekt starte et nyt projekt. De præsenteres nogenlunde i den rækkefølge, at en ny besøgende vil støde dem, men naturligvis i hvilken rækkefølge du faktisk gennemføre dem kan være anderledes. Du kan behandle dem som en checkliste. Når man starter et projekt, bare gå ned på listen og sørg for at du har hvert element er dækket, eller i det mindste at du er fortrolig med de potentielle konsekvenser, hvis du har forladt en ud.

Vælg et godt navn

Sæt dig selv i skoene af en person, der lige hørt om dit projekt, måske ved at have snuble over det mens du søger efter software til at løse et problem. Den første ting, de vil støde er projektets navn.

Et godt navn vil ikke automatisk gøre dit projekt lykkes, og et dårligt navn vil ikke doom det-godt, en virkelig dårlig navn sandsynligvis kunne gøre det, men vi starter fra den antagelse, at ingen her aktivt forsøger at gøre deres projekt mislykkes. Dog kan et dårligt navn bremse vedtagelsen af projektet, enten fordi folk ikke tager det alvorligt, eller fordi de simpelthen har svært ved at huske det.

Et godt navn:

• Giver en idé hvad projektet gør, eller i hvert fald fortælles i en indlysende måde, sådan at hvis man kender navnet og ved, hvad projektet gør, vil navnet komme hurtigt til at tænke derefter.
• Er let at huske. Her er der ingen vej udenom det faktum, at engelsk er blevet standardsproget af internettet: «let at huske» betyder «nemme for nogen, der kan læse engelsk at huske.» Navne, der er ordspil afhængige modersmål udtale, for eksempel, vil være uigennemsigtig for de mange ikke-engelsktalende læsere derude. Hvis ordspil er særligt overbevisende og mindeværdig, kan det stadig være det værd, bare huske på, at mange mennesker ser navnet ikke vil høre det i deres hoved vejen en indfødt ville.
• Er det ikke det samme som et andet projekt navn, og ikke krænker på nogen varemærker. Dette er blot gode manerer, samt god juridisk forstand. Du ønsker ikke at skabe identitet forvirring. Det er svært nok at holde styr på alt det, der er tilgængelig på nettet allerede, uden forskellige ting med samme navn.
• De ressourcer, der er nævnt tidligere i afsnittet «Men først, Look Around» er nyttige i at opdage, om et andet projekt allerede har det navn, du tænker på. Gratis varemærke søgninger er tilgængelige på http://www.nameprotect.org/ og http://www.uspto.gov/.
• Hvis det er muligt, er tilgængelig som et domænenavn i. Com,. Netto, og. Org top-level domæner. Du bør vælge en, formentlig org, at annoncere som officielt hjem site for projektet. De to andre skal sende der og er simpelthen at forhindre tredjemand i at skabe identitet forvirring omkring projektets navn. Selv hvis du har til hensigt at være vært for projektet på et andet site (se afsnittet «Dåse Hosting»), kan du stadig registrere projekt-specifikke domæner og videresender dem til hosting site. Det hjælper brugerne meget at have en simpel URL at huske.

Har en klar mission Statement

Når de har fundet projektets hjemmeside, den næste ting folk vil kigge efter, er en hurtig beskrivelse, en mission statement, så de kan beslutte (inden 30 sekunder), uanset om de er interesserede i at lære mere. Det skal kunne ses tydeligt placeret på forsiden, helst lige under projektets navn.

Den mission statement skal være konkret, begrænsning, og frem for alt kort. Her er et eksempel på en god en, fra http://www.openoffice.org/:

Hvis du vil oprette, som et fællesskab, det førende internationale kontorpakke, som vil køre på alle større platforme og give adgang til al funktionalitet og data gennem åben-komponent baseret API’er og et XML-baseret filformat.

På bare et par ord, de har ramt alle de høje punkter, hovedsagelig ved at trække på læserens forudgående kendskab. Ved at sige «som et fællesskab», signalerer de, at ingen selskabsskat vil dominere udviklingen, «international» betyder, at softwaren vil give folk mulighed for at arbejde på flere sprog og lokaliteter, «alle større platforme» betyder det vil være bærbar til Unix, Macintosh , og Windows. Resten signalerer, at åbne grænseflader og letforståelige filformater er en vigtig del af målet. De kommer ikke lige ud og sige, at de forsøger at være et gratis alternativ til Microsoft Office, men de fleste mennesker kan formentlig læse mellem linjerne. Selv om denne mission statement ser bred ved første øjekast, det er faktisk helt omskrevet: ordene «kontorpakke» betyder noget meget konkret til dem bekendt med sådan software. Igen er læserens formodede forhåndsviden (i dette tilfælde sandsynligvis fra MS Office), der anvendes til at holde mission statement kortfattet.

Karakteren af et mission statement afhænger dels af, hvem der skriver det, ikke bare på den software, det beskriver. For eksempel giver det mening for OpenOffice.org at bruge ordene «som et fællesskab», fordi projektet blev startet, og er stadig i vid udstrækning sponsoreret af Sun Microsystems. Ved at inkludere disse ord angiver søn sin følsomhed over for bekymringer, at det måske vil forsøge at dominere udviklingsprocessen. Med denne slags ting, går blot demonstrerer bevidsthed om potentialet for et problem en lang vej mod at undgå problemet helt. På den anden side, formentlig projekter, der ikke sponsoreres af et enkelt selskab behøver ikke sådan sprog, da der jo er udvikling af lokalsamfundet normen, så der normalt ville være nogen grund til at opføre det som en del af missionen.

Angiver, at projektet er gratis

De, der forbliver interesseret efter at have læst mission statement vil næste ønsker at se flere detaljer, måske nogle bruger eller udvikler dokumentation, og i sidste ende gerne vil hente noget. Men før noget af det, vil de nødt til at være sikker på, at det er open source.

Forsiden skal gøre det utvetydigt klart, at projektet er open source. Dette kan synes indlysende, men du ville blive overrasket over, hvor mange projekter glemmer at gøre det. Jeg har set fri software-projekt web sites, hvor forsiden ikke blot ikke sige hvilken bestemt gratis licens softwaren blev distribueret under, men ikke har hævdet, ligefrem, at softwaren var gratis på alle. Undertiden den afgørende bit af oplysninger blev forvist til siden Downloads, eller udviklerne side, eller et andet sted, der kræves endnu en museklik at komme til. I ekstreme tilfælde blev licensen ikke givet nogen steder på hjemmesiden på alle-den eneste måde at finde det var for at downloade softwaren og kig ind.

Du må ikke begå denne fejl. En sådan undladelse kan miste mange potentielle udviklere og brugere. State oppe foran, lige under mission statement., At projektet er «fri software» eller «open source software», og give den nøjagtige licens En hurtig guide til at vælge en licens er givet i afsnittet «Valg af en Licens og anvende det» senere i dette kapitel, og licensordninger spørgsmål drøftes i detaljer i kapitel 9, licenser, Copyrights og patenter.

På dette tidspunkt har vores hypotetiske besøgende bestemt, sandsynligvis i et minut eller mindre, at hun er interesseret i udgifterne, siger, mindst fem minutter mere efterforsker projekt. De næste afsnit beskriver, hvad hun skulle støde på, at fem minutter.

Funktioner og krav Liste

Der bør være en kort liste over de funktioner softwaren understøtter (hvis noget ikke er afsluttet endnu, kan du stadig angive det, men sætte «planlagt» eller «in progress» ud for det), og den form for it-miljøet kræves for at køre softwaren. Tænk på de funktioner / krav liste som hvad du ville give til en person beder om en hurtig oversigt over softwaren. Det er ofte blot en logisk udvidelse af mission statement. For eksempel kan den mission statement sige:

Hvis du vil oprette en fuld-tekst indexer og søgemaskine med en rig API til brug af programmører i at yde søgetjenester til store samlinger af tekstfiler.

De funktioner og krav liste ville give de oplysninger, afklaring af mission statement anvendelsesområde:

Features:

• Søgninger almindelig tekst, HTML og XML
• Ord eller en sætning søgning
• (Planlagte) Fuzzy matching
• (Planlagt) Trinvis opdatering af indekser
• (Planlagte) Indeksering af fjerntliggende websteder

Krav:

• Python 2,2 eller højere
• Nok diskplads til at holde indeksene (ca. 2x original data størrelse)

Med disse oplysninger, kan læserne hurtigt få en fornemmelse af, om denne software har noget håb om at arbejde for dem, og de kan overveje at få inddraget som udviklere også.

Udvikling status

Folk altid ønsker at vide, hvordan et projekt gør. For nye projekter, de ønsker at vide kløften mellem projektets løfte og aktuelle virkelighed. For modne projekter, de ønsker at vide, hvor aktivt det er vedligeholdt, hvor ofte det lægger ud nye udgivelser, hvordan reagerer det sandsynligvis være at fejlrapporter osv.

For at besvare disse spørgsmål, bør du give en udvikling status side med angivelse af projektets kortsigtede mål og behov (for eksempel kunne det være på udkig efter udviklere med en bestemt slags ekspertise). Den side kan også give en historie af tidligere udgivelser, med funktionen lister, så kan de besøgende få en idé om, hvordan projektet definerer «fremskridt», og hvor hurtigt det gør fremskridt i henhold til denne definition.

Vær ikke bange for at kigge uforberedte, og ikke give efter for fristelsen til at hype udviklingen status. Alle ved, at software udvikler i etaper, og der er ingen skam i at sige «Dette er alpha software med kendte fejl Det kører, og arbejder i det mindste noget af tiden, men bruge på egen risiko.». En sådan sprog vil ikke skræmme væk den slags udviklere, du har brug for på det tidspunkt. Som for brugerne, er en af de værste ting et projekt kan gøre tiltrække brugere, før softwaren er klar til dem. Et ry for ustabilitet eller bugginess er meget svært at ryste, når erhvervet. Conservativism betaler sig i det lange løb, det er altid bedre for software til at være mere stabil end brugeren forventede end mindre, og behagelige overraskelser producere den bedste form for mund-til-mund.

Alpha og Beta

Udtrykket alpha betyder normalt en første udgivelse, som brugerne kan få rigtigt arbejde gjort, og som har alle den tilsigtede funktionalitet, men som også har vidst fejl. Hovedformålet med alpha-software er at generere feedback, så udviklerne ved, hvad de skal arbejde på. Den næste fase, beta, betyder den software, har fået alle de alvorlige fastsat bugs, men er endnu ikke blevet testet nok til at certificere til udgivelse. Formålet med beta software er enten at blive den officielle udgivelse, forudsat ingen bugs er fundet, eller give detaljeret feedback til udviklerne, så de kan nå den officielle frigivelse hurtigt. Forskellen mellem alfa og beta er i høj grad et spørgsmål om dom.

Downloads

Den software skal kunne downloades i kildekode i standardformater. Når et projekt er først komme i gang, binære (eksekverbar) pakker er ikke nødvendigt, medmindre softwaren har sådanne komplicerede build krav eller afhængigheder, der blot får det til at køre ville være en masse arbejde for de fleste mennesker. (Men hvis det er tilfældet, er projektet vil have en hård tid tiltrække udviklere alligevel!)

Fordelingen mekanisme bør være så praktisk, standard og lave omkostninger som muligt. Hvis du prøvede at udrydde en sygdom, ville du ikke distribuere medicinen på en sådan måde, at det kræver en ikke-standard sprøjte størrelse at administrere. Ligeledes bør software i overensstemmelse med standard build og lægningsmetoder, jo mere den afviger fra standarderne, vil de flere potentielle brugere og udviklere give op og gå væk forvirret.

Det lyder indlysende, men mange projekter ikke gider at standardisere deres installationsprocedurerne indtil meget sent i spillet, fortæller sig selv, de kan gøre det når som helst: «Vi vil sortere alle de ting ud, når koden er tættere på at være klar. » Hvad de ikke indser er, at ved at udskyde det kedelige arbejde for efterbehandling byggeværktøjerne og installation procedurer, er de rent faktisk gør koden tager længere tid at blive klar-fordi de afskrækker udviklere, som måske ellers ville have bidraget til koden. Mest snigende, de ikke ved, at de mister alle disse udviklere, fordi processen er en ophobning af ikke-begivenheder: en person besøger en hjemmeside, downloader software, forsøger at bygge det, mislykkes, giver op og går væk. Hvem vil nogensinde vide det skete, bortset fra personen selv? Ingen arbejder på projektet vil indse, at nogens interesse og god vilje have været tavst spildt.

Kedeligt arbejde med en høj payoff bør altid ske tidligt, og en betydelig sænkning projektets adgangsbarriere gennem god emballage bringer en meget høj payoff.

Når du slipper en downloades pakke, er det vigtigt, at du giver et entydigt versionsnummer til frigivelsen, så folk kan sammenligne to vilkårlige udgivelser og vide som afløser den anden. En detaljeret diskussion af version nummerering kan findes i afsnittet «Release Nummerering», og nærmere oplysninger om standardisering build og installationsprocedurer er dækket i afsnittet «Emballage», både i kapitel 7, Packaging, slipper, og Daily Development.

Version Control og Bug Tracker Access

Downloading kildepakker er fint for dem, der blot ønsker at installere og bruge softwaren, men det er ikke nok for dem, der ønsker at fejlsøge eller tilføje nye funktioner. Nightly source snapshots kan hjælpe, men de er stadig ikke finkornet nok til en blomstrende udvikling samfund. Mennesker har brug for real-time adgang til de nyeste kilder, og den måde at give dem det er at bruge en version kontrolsystem. Tilstedeværelsen af anonymt tilgængelig version kontrollerede kilder er et tegn-til både brugere og udviklere, at dette projekt gør en indsats for at give folk, hvad de behøver for at deltage. Hvis du ikke kan tilbyde versionskontrol med det samme, og derefter sætte et skilt op at sige du har til hensigt at sætte den op snart. Versionsstyring infrastruktur drøftet i detaljer i afsnittet «Version Control» i kapitel 3, teknisk infrastruktur.

Det samme gælder for projektets bug tracker. Betydningen af en bug tracking system ligger ikke kun i deres værdi for udviklere, men i hvad det betyder for projektets observatører. For mange mennesker, er en tilgængelig fejldatabase en af de stærkeste tegn på, at et projekt skal tages alvorligt. Desuden, jo højere antallet af fejl i databasen, jo bedre projektet ser ud. Det kan synes ulogisk, men husk, at antallet af registrerede fejl virkelig afhænger af tre ting: det absolutte antal af bugs til stede i softwaren, er antallet af brugere, der anvender software, og bekvemmelighed, som disse brugere kan registrere nye fejl. Af disse tre faktorer, er de sidste to mere betydningsfuld end den første. Enhver software af tilstrækkelig størrelse og kompleksitet har en i det væsentlige vilkårligt antal bugs venter på at blive opdaget. Det virkelige spørgsmål er, hvor godt vil projektet gøre på registrering og prioritere disse fejl? Et projekt med et stort og velholdt bug database (hvilket betyder bugs er blevet besvaret hurtigt, duplikerede bugs er forenet, etc.) fremsætter derfor et bedre indtryk end et projekt med ingen bug database eller en næsten tom database.

Selvfølgelig, hvis dit projekt kun lige er begyndt så fejldatabase vil indeholde meget få fejl, og der er ikke meget du kan gøre ved det. Men hvis status side understreger projektets ungdom, og hvis folk kigger på det fejldatabase kan se, at de fleste ansøgninger har fundet sted for nylig, kan de ekstrapolere fra, at projektet stadig har en sund sats på spåner, og de vil ikke blive unødigt bange af den lave absolutte antal registrerede fejl.

Bemærk, at bug trackers ofte bruges til at spore ikke blot software bugs, men ekstraudstyr anmodninger, dokumentation ændringer, indtil opgaver og meget mere. Detaljerne ved at drive en bug tracker er dækket i afsnittet «Bug Tracker» i kapitel 3, teknisk infrastruktur, så jeg vil ikke gå ind i dem her. Det vigtige ting fra en præsentation synspunkt er bare at have en bug tracker, og sørge for, at faktum er synlig fra forsiden af projektet.

Kommunikationskanaler

Besøgende normalt ønsker at vide, hvordan at nå de mennesker, der deltager i projektet. Giv adresserne på postlister, chat rooms, og IRC-kanaler, og alle andre fora, hvor andre involverede med softwaren kan nås. Gør det klart, at du og de andre forfattere i projektet er tilmeldt disse postlister, så folk se, at der er en måde at give feedback, der vil nå udviklerne. Din tilstedeværelse på listerne betyder ikke en forpligtelsesperioden at besvare alle spørgsmål eller gennemføre alle funktion anmodninger. I det lange løb vil de fleste brugere formentlig aldrig slutte sig til de fora alligevel, men de vil blive trøstet at vide, at de kunne, hvis de nogensinde brug for.

I de tidlige stadier af et projekt, er der ingen grund til at have separate bruger-og udviklings fora. Det er meget bedre at have alle involveret med softwaren taler sammen, i en «rum». Blandt tidlige adopters, er sondringen mellem bygherren og bruger ofte fuzzy, i det omfang det kan skelnes, er forholdet mellem udviklere at brugerne normalt meget højere i de tidlige dage af projektet end senere. Selvom du ikke kan antage, at hver early adopter er en programmør, der ønsker at hacke på softwaren, kan du antage, at de er mindst interesseret i følgende udviklingssamtaler og i at få en fornemmelse af projektets retning.

Da dette kapitel er kun om at få et projekt i gang, er det nok blot at sige, at disse meddelelser fora er nødt til at eksistere. Senere, i afsnittet «Håndtering Vækst» i kapitel 6, Communications, vil vi undersøge, hvor og hvordan man opsætter disse fora, de måder, hvorpå de kan have behov for mådehold eller anden ledelse, og hvordan du adskille brugerfora fra developer forums , når den tid kommer, uden at oprette en uoverstigelig kløft.

Udvikler Retningslinjer

Hvis nogen overvejer at bidrage til projektet, vil hun søge udvikler retningslinjer. Udvikler retningslinjer er ikke så meget teknisk som social: de forklare, hvordan udviklerne interagerer med hinanden og med brugerne, og i sidste ende hvordan tingene bliver gjort.

Dette emne er beskrevet i detaljer i afsnittet «skrive det hele ned» i kapitel 4, sociale og politiske infrastruktur, men de grundlæggende elementer i developer retningslinjer er:

• henvisninger til fora for interaktion med andre udviklere
• instruktioner om, hvordan at rapportere fejl og indsende patches
• en indikation af, hvordan udviklingen sker som regel-er projektet en velvillig diktatur, et demokrati, eller noget andet

Ingen nedsættende betydning er beregnet med «diktatur», ved den måde. Det er helt okay at køre et tyranni, hvor en bestemt udvikler har vetoret over alle ændringer. Mange vellykkede projekter på denne måde. Det vigtige er, at projektet kommer lige ud og sige det. En tyranni foregiver at være et demokrati vil slå folk ud, et tyranni, der siger det er et tyranni vil gøre fint, så længe tyrannen er kompetente og pålidelige.

Se http://subversion.apache.org/docs/community-guide/ for et eksempel på særligt grundige udvikler retningslinjer eller http://www.openoffice.org/dev_docs/guidelines.html til bredere retningslinjer, der fokuserer mere på ledelse og ånden i deltagelse og mindre på tekniske spørgsmål.

Den separate spørgsmål om at tilvejebringe en programmør introduktion til softwaren er diskuteret i afsnittet «Developer dokumentation» senere i dette kapitel.

Dokumentation

Dokumentation er essentielt. Der skal være noget for folk at læse, selvom det er rudimentær og ufuldstændig. Dette falder helt og holdent ind i «slid» kategorien nævnt tidligere, og er ofte det første område, hvor et nyt open source projekt falder ned. Kommer op med en mission statement og feature liste, vælge en licens, der sammenfatter udviklingen status-disse er alle relativt små opgaver, der definitivt kan afsluttede og skal normalt ikke blive returneret til engang gjort. Dokumentation, på den anden side, er aldrig rigtig færdig, hvilket kan være en af grundene folk nogle gange forsinke start det overhovedet.

Det mest lumske er, at dokumentation anvendelighed til dem skriftligt det er det modsatte af dens nytteværdi for dem, der vil læse det. Den vigtigste dokumentation for de første brugere er det grundlæggende: hvordan du hurtigt oprette softwaren, en oversigt over, hvordan det virker, måske nogle guider til at gøre almindelige opgaver. Men disse er netop de ting, de forfattere af dokumentation kender alt for godt så godt, at det kan være svært for dem at se tingene fra læserens synspunkt, og at møjsommeligt stave, hvilke forholdsregler (til forfattere) synes så indlysende som at være uværdig for omtale.

Der er ingen magisk løsning på dette problem. Nogen behøver blot at sætte sig ned og skrive de ting, og derefter køre den ved typiske nye brugere til at teste dens kvalitet. Brug en enkel, nem at redigere format såsom HTML, almindelig tekst, Texinfo, eller nogle variant af XML-noget, der er praktisk for lette, hurtige forbedringer på stående fod. Dette er ikke kun at fjerne enhver overhead, kan hindre de oprindelige forfattere fra at foretage gradvise forbedringer, men også for dem, der deltage i projektet senere og ønsker at arbejde på dokumentationen.

En måde at sikre grundlæggende indledende dokumentation bliver gjort, er at begrænse dens omfang på forhånd. På den måde skriver den i det mindste ikke vil føle sig som en åben opgave. En god tommelfingerregel er, at den skal opfylde følgende minimale kriterier:

• Fortæl læseren tydeligt hvor meget teknisk ekspertise, de er forventes at have.
• Beskriv klart og grundigt, hvordan du opsætter softwaren, og et eller andet sted nær begyndelsen af dokumentationen, at brugeren fortælle, hvordan du kører en slags diagnostisk test eller simpel kommando til at bekræfte, at de har sat tingene op korrekt. Startup dokumentation er på nogle måder vigtigere end det faktiske forbrug dokumentation. Jo mere indsats nogen har investeret i at installere og komme i gang med den software, jo mere vedholdende hun vil være i at finde ud avanceret funktionalitet, der ikke er veldokumenteret. Når folk opgiver, at de opgive tidligt, og derfor er det de tidligste stadier, såsom montering, der har brug for mest støtte.
• Giv en tutorial-stil eksempel på, hvordan man gør en fælles opgave. Det er klart, ville mange eksempler på mange opgaver blive endnu bedre, men hvis tid er begrænset, så vælg en opgave og gå igennem det grundigt. Når nogen ser, at softwaren kan bruges til én ting, vil de begynde at udforske, hvad ellers kan gøre på egen hånd-og hvis du er heldig, begynde at fylde i dokumentationen selv. Hvilket bringer os til næste punkt …
• Mærk de områder, hvor dokumentationen er kendt for at være ufuldstændig. Ved at vise læserne, at du er bevidst om sine mangler, tilslutter du dig selv med deres synspunkt. Din empati forsikrer dem om, at de ikke står over for en kamp for at overbevise projektet, hvad der er vigtigt. Disse etiketter behøver ikke repræsentere løfter om at udfylde de huller af nogen bestemt dato, det er lige så legitimt at behandle dem som åbne anmodninger om frivillig hjælp.

Det sidste punkt er af betydning i bredere forstand, faktisk, og kan anvendes på hele projektet, ikke bare dokumentationen. En nøjagtig bogføring af kendte mangler er normen i open source-verdenen. Du behøver ikke at overdrive projektets mangler, bare identificere dem omhyggeligt og lidenskabsløst når sammenhængen kræver det (uanset om dokumentationen i fejlsporingsdatabase, eller på en mailingliste diskussion). Ingen vil behandle dette som defaitisme på den del af projektet, eller som en forpligtelse til at løse problemerne inden en bestemt dato, medmindre projektet giver tilsagn eksplicit. Da alle, der bruger softwaren vil opdage manglerne for sig selv, det er meget bedre for dem at være psykisk forberedt-så projektet vil se ud som om den har en solid viden om, hvordan det gør.

Fastholdelse af en FAQ

En FAQ («Frequently Asked Questions» dokument) kan være en af de bedste investeringer et projekt gør med hensyn til pædagogisk payoff. Ofte stillede spørgsmål er meget tunet til de spørgsmål brugere og udviklere faktisk spørge-i modsætning til de spørgsmål, du måtte have forventet dem til at spørge-og derfor en velholdt FAQ tendens til at give dem, der hører det præcis, hvad de leder efter. FAQ er ofte det første sted brugerne ser, når de støder på et problem, der ofte selv frem til den officielle manual, og det er sandsynligvis det dokument i projektet størst sandsynlighed for at være knyttet til fra andre websteder.

Desværre kan du ikke gøre FAQ ved starten af projektet. Gode FAQs er ikke skrevet, dyrkes de. De er per definition reaktive dokumenter, udvikler med tiden som reaktion på menneskers dag-til-dag brugen af softwaren. Da det er umuligt at rette foregribe de spørgsmål, folk vil bede, er det umuligt at sætte sig ned og skrive en nyttig FAQ fra bunden.

Derfor skal du ikke spilde din tid på at forsøge at. Du kan dog finde det nyttigt at oprette en overvejende blank FAQ skabelon, så der vil være et oplagt sted for folk at bidrage med spørgsmål og svar efter at projektet er i gang. På dette stadium er det vigtigste egenskab ikke fuldstændighed, men bekvemmelighed: Hvis FAQ er nemt at tilføje til, vil folk tilføje til det. (Korrekt FAQ vedligeholdelse er en ikke-triviel og spændende problem, og er diskuteret mere i afsnittet «FAQ Manager» i kapitel 8, adm. Volunteers.)

Tilgængeligheden af dokumentation

Dokumentation skal være tilgængelig fra to steder: online (direkte fra hjemmesiden), og i den downloades distribution af softwaren (se afsnittet «Emballage» i kapitel 7, Packaging, slipper, og Daily Development). Det skal være online, i Eksempelprocent form, fordi folk ofte læse dokumentationen før du henter software for første gang, som en måde at hjælpe dem med at beslutte om du vil hente overhovedet. Men det bør også ledsage i softwaren, på princippet om, at downloade skal levere (dvs. gøre lokalt tilgængeligt) alt, hvad man skal bruge pakken.

For online dokumentation, så sørg for, at der er et link, der bringer op hele dokumentationen i én HTML-side (sætte en note som «monolitisk» eller «all-in-one» eller «single large side» ud for linket, så folk ved, at det kan tage et stykke tid at indlæse). Dette er nyttigt, fordi folk ofte ønsker at søge efter et bestemt ord eller en sætning på tværs af hele dokumentationen. Generelt, de allerede ved, hvad de leder efter, de kan bare ikke huske, hvad sektion er det i. For sådanne mennesker, intet er mere frustrerende end at støde en HTML-side for indholdsfortegnelsen, så en anden side til indførelse, så en anden side for installationsvejledning mv Når siderne er brudt op sådan, deres browsers søgefunktionen er ubrugelig. Den separate-sidetypografi er nyttig for dem, der allerede ved, hvad sektion de har brug for, eller som ønsker at læse hele dokumentationen fra forrest til bagest i rækkefølge. Men det er ikke den mest almindelige måde dokumentation tilgås. Langt oftere er nogen, der er dybest set fortrolig med den software, der kommer tilbage for at søge efter et bestemt ord eller en sætning. At undlade at forsyne dem med en enkelt søgbart dokument ville kun gøre deres liv sværere.

Udvikler dokumentation

Udvikler dokumentation er skrevet for at hjælpe programmører forstå koden, så de kan reparere og udvide det. Det er noget anderledes end de udvikleren retningslinjer omtalt tidligere, som er mere socialt end teknisk. Udvikler retningslinjer fortæller programmører, hvordan man får sammen med hinanden, udvikler dokumentation fortæller dem, hvordan at komme sammen med selve koden. De to er ofte pakket sammen i ét dokument for nemheds (som med http://subversion.apache.org/docs/community-guide/ eksemplet tidligere), men de behøver ikke at være.

Selvom udvikleren dokumentation kan være meget nyttigt, er der ingen grund til at forsinke en frigivelse at gøre det. Så længe de oprindelige forfattere er tilgængelige (og vil) til at besvare spørgsmål om den kode, der er nok til at begynde med. Faktisk er nødt til at besvare de samme spørgsmål igen og igen en fælles motivation for at skrive dokumentation. Men selv før det er skrevet, vil bestemt bidragydere stadig formår at finde vej rundt i koden. Den kraft, der driver folk til at bruge tid på at lære en kodebase er, at koden gør noget nyttigt for dem. Hvis folk har tillid til, at de vil tage sig tid til at finde ud af ting, og hvis de ikke har den tro, vil ingen mængde af udviklerdokumentation få eller beholde dem.

Så hvis du har tid til at skrive dokumentation for kun én målgruppe, skrive det for brugerne. Alle brugerdokumentation er i realiteten, udvikler dokumentation samt; enhver programmør, der kommer til at arbejde på et stykke software skal være fortrolige med, hvordan man bruger det. Senere, når du ser programmører stiller de samme spørgsmål igen og igen, tager sig tid til at skrive nogle særskilte dokumenter bare for dem.

Nogle projekter bruger wikis til deres oprindelige dokumentation, eller endda som deres primære dokumentation. Det er min erfaring, wikien dette virkelig fungerer kun, hvis aktivt redigeret af nogle få mennesker, som er enige om, hvordan dokumentationen skal organiseres, og hvad slags «stemme» det bør have. Se afsnittet «Wikis» i kapitel 3, teknisk infrastruktur til mere.

Eksempel på output og Screenshots

Når projektet involverer en grafisk brugergrænseflade, eller hvis den producerer grafiske eller på anden måde karakteristisk output, sætte nogle prøver op på projektets hjemmeside. I tilfælde af grænsefladen, betyder dette skærmbilleder, til output, kan det være skærmbilleder eller kun filer. Begge appellerer til menneskers behov for øjeblikkelig tilfredsstillelse: en enkelt screenshot kan være mere overbevisende end afsnit beskrivende tekst og mailingliste snak, fordi et screenshot er inarguable bevis på, at softwaren virker. Det kan være fejlbehæftet, kan det være svært at installere, kan det ufuldstændigt dokumenteret, men det screenshot er stadig bevis for, at hvis man lægger nok arbejde, kan man få det til at køre.

Screenshots

Da screenshots kan være skræmmende, indtil du rent faktisk har lavet et par stykker, her er grundlæggende vejledning i at lave dem. Brug af Gimp (http://www.gimp.org/), åben Fil-> Acquire-> Screenshot, skal du vælge enkelt vindue eller hele skærmen, og klik derefter på OK. Nu er din næste museklik vil fange vinduet eller skærmbilledet klikkes på som et billede i Gimp. Beskær og ændre størrelsen på billedet som det er nødvendigt, ved at følge instruktionerne på http://www.gimp.org/tutorials/Lite_Quickies/ # afgrøde.

Der er mange andre ting, du kan sætte på projektets hjemmeside, hvis du har tid, eller hvis en eller anden grund, de er særligt velegnede: en nyhedsside, et projekt historie side, en beslægtet links side, en site-søgning feature, et donationer link, osv. Ingen af disse er nødvendigheder ved opstart, men holde dem i tankerne for fremtiden.

Dåse hosting

Der er et par steder, der giver gratis hosting og infrastruktur til open source-projekter: en web-området, versionsstyring, en bug tracker, en download-området, chatfora, regelmæssige sikkerhedskopier osv. Detaljerne varierer fra sted til sted, men det samme basale tjenester tilbydes på dem alle. Ved at bruge et af disse websteder, får du en masse gratis, hvad du giver op, naturligvis, er finkornet kontrol over brugerens oplevelse. Den hosting-tjeneste afgør, hvad software stedet kører, og kan kontrollere eller i det mindste påvirke udseendet og fornemmelsen af projektets websider.

Se afsnittet «Dåse Hosting» i kapitel 3, teknisk infrastruktur for en mere detaljeret diskussion af fordele og ulemper ved dåse hosting, og en liste over steder, der tilbyder det.

Valg af en Licens og anvende det

Dette afsnit er beregnet til at være en meget hurtig, meget grov guide til at vælge en licens. Læs kapitel 9, licenser, Copyrights og patenter til at forstå de detaljerede juridiske konsekvenser af de forskellige licenser, og hvordan den licens, du vælger, kan påvirke folks evne til at blande din software med anden fri software.

Der er rigtig mange gratis softwarelicenser at vælge imellem. De fleste af dem behøver vi ikke overveje her, da de blev skrevet for at tilfredsstille de særlige juridiske behov af nogle selskab eller person, og ville ikke være passende for dit projekt. Vi vil begrænse os til kun de mest almindeligt anvendte licenser i de fleste tilfælde, vil du ønsker at vælge en af dem.

De «gøre noget» Licenser

Hvis du er fortrolig med dit projekt kode potentielt bruges i proprietære programmer, derefter bruge en MIT / X-stil licens. Det er den enkleste af flere minimale licenser, der gør lidt mere end hævde nominel ophavsret (uden faktisk at begrænse kopiering), og angiver, at koden kommer med nogen garanti. Se afsnittet kaldet «The MIT / X Window System License» for yderligere oplysninger.

Den GPL

Hvis du ikke ønsker din kode, der skal bruges i proprietære programmer, skal du bruge GNU General Public License (http://www.gnu.org/licenses/gpl.html). GPL er nok den mest anerkendte fri software licens i verden i dag. Dette er i sig selv en stor fordel, da mange potentielle brugere og bidragydere allerede vil være bekendt med det, og vil derfor ikke nødt til at bruge ekstra tid til at læse og forstå din licens. Se afsnittet kaldet «The GNU General Public License» i kapitel 9, licenser, Copyrights og patenter for detaljer.

Hvis brugerne interagerer med din kode primært via et netværk, det vil sige, at softwaren er normalt en del af en hosted service-så overveje at bruge GNU Affero GPL stedet. Se GNU Affero GPL: En version af GNU GPL for server-side kode i kapitel 9, licenser, Copyrights og patenter for mere.

Sådan ansøger en Licens til din software

Når du har valgt en licens, skal du anvende det til softwaren.

Den første ting at gøre, er angive licensen tydeligt på projektets forside. Du behøver ikke at inkludere selve teksten af licensen der, bare give sit navn og gøre det linke til den fulde licens tekst på en anden side. Det fortæller offentligheden, hvad licens du har til hensigt at softwaren til at blive frigivet under-men det er ikke helt nok til lovlige formål. Den anden fase er, at selve softwaren bør omfatte licensen.

Standarden måde at gøre dette på er at sætte fuld licens tekst i en fil kaldet KOPIERING (eller licens) inkluderet med kildekoden, og derefter sætte en kort varsel i en kommentar i toppen af hver kilde fil navngivning copyright dato, holder, og licens, og sige hvor man kan finde den fulde ordlyd af licensen.

Der er mange variationer af dette mønster, så vil vi se på bare ét eksempel her. GNU GPL siger at sætte en meddelelse som denne i toppen af hver kilde fil:

Copyright (C) <year> <navn på author>

Dette program er fri software: du kan redistribuere det og / eller modificere
det under betingelserne i GNU General Public License som publiceret af
Free Software Foundation, enten version 3 af licensen, eller
(Efter eget valg) enhver senere version.

Dette program er distribueret i håb om at det vil være nyttigt,
men UDEN NOGEN GARANTI, endda uden den underforståede garanti
SALGBARHED eller EGNETHED TIL ET BESTEMT FORMÅL. Se
GNU General Public License for flere detaljer.

Du bør have modtaget en kopi af GNU General Public License
sammen med dette program. Hvis ikke, se <http://www.gnu.org/licenses/>

Det siger ikke udtrykkeligt, at den kopi af den licens, du har modtaget sammen med programmet er i filen COPYING eller licens, men det er, hvor det er normalt sat. (Du kan ændre ovennævnte varsel at fastslå, at direkte.) Denne skabelon giver også en fysisk adresse, hvorfra man kan anmode om en kopi af licensen. En anden almindelig metode er at give et link til en webside, der indeholder licensen.

Kontakt en advokat (eller bruge din dømmekraft, hvis du ikke har råd til en advokat) og pege på hvor du føler den mest permanent kopi af licensen, overholdes, det kan simpelthen være et sted på din projektets hjemmeside. I almindelighed, er den meddelelse du lægger i hver kildefilen ikke at se ud nøjagtig som den ovenfor, så længe den starter med det samme varsel indehaveren af ophavsretten og dato, hedder navnet på licens, og gør det klart, hvor du kan se den fuldstændige licens.

Indstilling af Tone

Indtil videre har vi dækket engangs-opgaver, du gør i løbet af projektets setup: plukke en licens, arrangere den første websted, osv. Men de vigtigste aspekter af at starte et nyt projekt er dynamiske. Valg af en mailingliste adresse er nemt, sikring af, at listens samtaler forbliver on-topic og produktiv er en helt anden sag. Hvis projektet bliver åbnet op efter mange års lukket, in-house udvikling, vil dets udviklingsprocesser ændre sig, og du bliver nødt til at forberede de eksisterende udviklere for ændringen.

De første skridt er det sværeste, fordi fortilfælde og forventninger til fremtidig adfærd endnu ikke er fastsat. Stabilitet i et projekt kommer ikke fra formelle politikker, men fra en delt, hard-to-pin-down kollektiv visdom, der udvikler sig over tid. Der er ofte skriftlige regler så godt, men de har tendens til at være væsentligt en destillation af det immaterielle, stadigt skiftende aftaler, der virkelig styrer projektet. De skriftlige politikker definerer ikke projektets kultur så meget som beskrive det, og selv da kun ca.

Der er et par grunde til, at tingene fungerer på denne måde. Vækst og stor omsætning er ikke så skadeligt for ophobning af sociale normer, som man kunne tro. Så længe ændringer ikke sker for hurtigt, er der tid til nyankomne at lære, hvordan tingene skal gøres, og efter at de lærer, vil de bidrage til at styrke disse måder selv. Overvej, hvordan børnesange overlever århundreder. Der er børn i dag synger nogenlunde samme rim som børn gjorde hundreder af år siden, selv om der ikke er børn i live nu, der var i live da. Yngre børn hører sangene sunget af ældre, og når de bliver ældre, de til gengæld vil synge dem foran andre yngre. Børnene er ikke engagere sig i en bevidst program for overførsel, selvfølgelig, men grunden sangene overleve er ikke desto mindre, at de sendes regelmæssigt og gentagne gange. Tidsskalaen for fri software-projekter kan ikke måles i århundreder (vi ikke kender endnu), men dynamikken i transmission er meget det samme. Omsætningen er hurtigere, dog, og skal opvejes af en mere aktiv og bevidst transmission indsats.

Denne indsats er hjulpet af det faktum, at folk generelt dukke op forventer og leder efter sociale normer. Det er bare, hvordan mennesker er bygget. Under enhver gruppe forenet af en fælles bestræbelse, søge mennesker der melder instinktivt for adfærd, der vil markere dem som en del af gruppen. Målet om at få fortilfælde tidligt er at gøre disse «in-gruppen» adfærd være dem, der er nyttige for projektet, for først er etableret, vil de være stort set selvforstærkende.

Følgende er nogle eksempler på specifikke ting, du kan gøre for at sætte gode fortilfælde. De er ikke ment som en udtømmende liste, lige som illustrationer af idéen om, at fastsættelsen af en fælles stemning tidligt hjælper et projekt voldsomt. Fysisk kan alle udviklere til at arbejde alene i et rum for sig selv, men du kan gøre meget for at få dem til at føle, at de er alle arbejder sammen i samme rum. Jo mere de føler på denne måde, jo mere tid de får lyst til at bruge på projektet. Jeg valgte disse særlige eksempler, fordi de kom op i Subversion-projektet (http://subversion.tigris.org/), som jeg deltog i, og observeret fra begyndelsen. Men de er ikke enestående for Subversion, situationer som disse vil komme op i de fleste open source-projekter, og skal ses som muligheder for at starte ting ud på højre fod.

Undgå private diskussioner

Selv efter du har taget projektets offentligheden, vil du og de andre grundlæggere ofte finde jer, der ønsker at bosætte vanskelige spørgsmål af private kommunikation blandt en inderkreds. Dette gælder især i de tidlige dage af projektet, når der er så mange vigtige beslutninger at gøre, og normalt få frivillige kvalificerede til at lave dem. Alle de oplagte ulemper ved offentlige liste diskussioner vil væven håndgribeligt foran dig: forsinkelsen ligger i e-mail-samtaler, det er nødvendigt at give tilstrækkelig tid til konsensus form, besværet med naive frivillige, der tror, de forstår alle de spørgsmål, men faktisk ikke (hvert projekt har disse; sommetider de er næste års stjerne bidragydere, sommetider de forblive naive evigt), den person, der ikke kan forstå, hvorfor du kun ønsker at løse problemet X når det er naturligvis en delmængde af større problem Y, og så videre. Fristelsen til at træffe beslutninger bag lukkede døre, og præsentere dem som fait accompli, eller i det mindste som de faste anbefalingerne for et forenet og indflydelsesrig stemme blok, vil være stor faktisk.

Gør det ikke.

Som langsomme og besværlige som offentlige diskussioner kan være, de er næsten altid at foretrække i det lange løb. Træffe vigtige beslutninger i private er som sprøjtning bidragyder frastødende på dit projekt. Ingen seriøs volontør vil holde sig omkring for længe i et miljø, hvor en hemmelig råd gør alle de store beslutninger. Derudover vil offentlig diskussion har gavnlige bivirkninger, der vil vare ud over, hvad flygtig teknisk spørgsmål var omtvistet:

• Diskussionen vil hjælpe uddanne nye udviklere. Du ved aldrig, hvor mange øjne ser samtalen, selv om de fleste mennesker ikke deltage, kan mange blive sporing lydløst, gleaning oplysninger om softwaren.
• Drøftelserne vil træne dig i kunsten at forklare tekniske spørgsmål til folk, som ikke er så fortrolige med den software, som du er. Dette er en færdighed, der kræver øvelse, og du kan ikke få denne praksis ved at tale med folk, der allerede ved, hvad du ved.
• Diskussionen og dens konklusioner vil være tilgængelige i offentlige arkiver for evigt efter, så fremtidige drøftelser for at undgå genopleve de samme trin. Se afsnittet «Conspicuous Brug af Archives» i kapitel 6, Communications.

Endelig er der den mulighed, at en person på listen, kan yde et reelt bidrag til samtalen, ved at komme op med en idé du aldrig forventet. Det er svært at sige, hvor sandsynligt det er, det bare afhænger af kompleksiteten af koden og krævet grad af specialisering. Men hvis anekdotiske beviser kan tillades, vil jeg vove at det er mere sandsynligt end én intuitivt ville forvente. I Subversion-projektet, troede vi (stifterne) vi står over for en dyb og kompleks sæt af problemer, som vi havde tænkt over hårdt i flere måneder, og vi ærligt tvivl om, at nogen på den nyoprettede postliste ville kunne gøre en reel bidrag til diskussionen. Så vi tog den dovne rute og begyndte batting nogle tekniske ideer frem og tilbage i private e-mails, indtil en observatør af projektet [10] fanget færten af, hvad der foregik og bad for diskussionen skal flyttes til den offentlige liste. Rolling vore øjne en smule, vi gjorde-og blev bedøvet med antallet af indsigtsfulde kommentarer og forslag, der hurtigt førte. I mange tilfælde mennesker tilbød ideer, som aldrig havde fundet sted til os. Det viste sig at der var nogle meget kloge mennesker på denne liste, de lige havde ventet på den rigtige madding. Det er sandt, at de efterfølgende drøftelser tog længere end de ville have, hvis vi havde holdt samtalen private, men de var så meget mere produktiv, at det var værd at den ekstra tid.

Uden at synke ned i hånd-vinke generaliseringer som «gruppen er altid klogere end den enkelte» (vi har alle mødt nok grupper til at vide bedre), må det erkendes, at der er visse aktiviteter på hvilke grupper Excel. Massive peer review er en af dem, generere et stort antal ideer hurtigt er en anden. Kvaliteten af de ideer afhænger af kvaliteten af den tænkning, der gik ind i dem, selvfølgelig, men du vil ikke vide, hvad slags tænkere er derude, indtil du stimulerer dem med et udfordrende problem.

Der er naturligvis nogle diskussioner, der skal havde privat, i denne bog vil vi se eksempler på dem. Men det ledende princip bør altid være: Hvis der ikke er nogen grund til at være private, bør det være offentlige.

At gøre dette ske kræver handling. Det er ikke nok alene at sikre, at alle dine egne indlæg går til den offentlige liste. Du skal også skubbe andre folks unødigt private samtaler til listen også. Hvis nogen forsøger at starte en privat diskussion, og der er ingen grund til at være privat, så det påhviler dig at åbne den relevante meta-diskussion med det samme. Må ikke engang kommentere på det oprindelige emne, indtil du enten har held styret samtalen til et offentligt sted, eller konstateres, at privatlivets fred virkelig var nødvendigt. Hvis du gør det konsekvent, vil folk fange på temmelig hurtigt og begynde at bruge de offentlige fora som standard.

Nip Uhøflighed i opløbet

Helt fra starten af dit projekt offentlige eksistens, bør du opretholde en nul-tolerance politik overfor uhøflig eller fornærmende adfærd i sine fora. Nul-tolerance betyder ikke teknisk håndhævelse per se. Du behøver ikke at fjerne folk fra mailing liste, når de flamme anden abonnent, eller tage væk deres engagement adgang, fordi de gjorde nedsættende bemærkninger. (I teorien kan du i sidste ende nødt til at ty til sådanne aktioner, men kun efter at alle andre muligheder er slået fejl, der per definition ikke er tilfældet i starten af projektet.) Nul-tolerance betyder blot aldrig at lade dårlig opførsel glide af ubemærket. For eksempel, når nogen lægger en teknisk kommentar blandet sammen med en ad hominem angreb på en anden udvikler i projektet er det bydende nødvendigt, at dit svar adresse ad hominem angreb først, da et separat spørgsmål til sig selv, og først bagefter gå videre til det tekniske indhold.

Det er desværre meget let, og alt for typisk, for konstruktive drøftelser for at forfalde til destruktive flamme krige. Folk vil sige ting i e-mail, at de aldrig ville sige ansigt til ansigt. De diskussionsemner kun forstærke denne effekt: i tekniske spørgsmål, ofte folk føler, at der er en enkelt rigtige svar på de fleste spørgsmål, og at uenighed med dette svar kun kan forklares med uvidenhed eller dumhed. Det er en kort afstand fra at kalde nogen tekniske forslag dumt at ringe til personen selv dum. Faktisk er det ofte svært at fortælle hvor teknisk debat blade off og karakter angreb begynder, hvilket er en af grundene til drastiske reaktioner eller straffe er ikke en god idé. I stedet, når du tror, du ser det ske, lave et indlæg, der understreger vigtigheden af at holde diskussionen venlig, uden at beskylde nogen for at være bevidst giftige. Sådanne «Nice Police» poster har dog en uheldig tendens til at lyde som en børnehave lærer belærer en klasse på god opførsel:

Først, lad os venligst skære ned på de (potentielt) ad hominem comments «. Naiv og uvidende om de grundlæggende principper for IT-sikkerhed» For eksempel kalder J design for sikkerheden lag Det kan være sandt, eller det kan ikke, men i begge tilfælde er det ikke muligt at få diskussionen. J gjorde sit forslag i god tro. Hvis den har mangler, pege dem ud, og vi ordner dem eller få et nyt design. Jeg er sikker på M betød ingen personlig fornærmelse J, men den frasering var uheldigt, og vi forsøger at holde tingene konstruktiv her omkring.

Nu til forslaget. Jeg tror, M havde ret i at sige, at …

Som opstyltet som sådan responser lyd, de har en mærkbar effekt. Hvis du konsekvent kalde dårlig opførsel, men ikke kræver en undskyldning eller bekræftelse fra den fejlende part, så du forlader folk fri til at køle ned og vise deres bedre side ved at opføre mere rigtig pænt, næste gang-og de vil. En af hemmelighederne ved at gøre dette med succes er at aldrig gøre det meta-diskussion hovedemnet. Det bør altid være en sidebemærkning, en kort indledning til den vigtigste del af dit svar. Påpeg i forbifarten, at «vi ikke gør tingene på den måde rundt her,» men derefter gå videre til det reelle indhold, så du giver folk noget on-topic til at reagere på. Hvis nogen protester, at de ikke fortjener din irettesættelse, nægter simpelthen at blive trukket ind i en diskussion om det. Enten reagerer ikke (hvis du tror, de er bare at lade off damp og ikke kræver et svar), eller sige undskyld hvis du overreagerede, og at det er svært at opdage nuancer i e-mail, og derefter vende tilbage til den vigtigste emne. Aldrig nogensinde insistere på en kvittering, offentlig eller privat, fra nogen, at de opførte sig upassende. Hvis de vælger af egen fri vilje for at skrive en undskyldning, det er fantastisk, men kræver, at de gør det kun vil medføre vrede.

Det overordnede mål er at gøre god etikette ses som en af «in-gruppen» adfærd. Dette hjælper projektet, fordi udviklerne kan køres væk (selv fra projekter, de kan lide og ønsker at støtte) ved flamme krige. Du må ikke engang ved, at de blev drevet bort, nogen kunne lure på mailinglisten, se, at det tager en tyk hud til at deltage i projektet, og beslutte mod at blive involveret på alle. Holde fora venlige er en langsigtet overlevelse strategi, og det er nemmere at gøre, når projektet er stadig lille. Når det er en del af kulturen, vil du ikke behøver at være den eneste person fremme den. Det vil blive opretholdt af alle.

Øv Conspicuous Code Review

En af de bedste måder at fremme en produktiv udvikling samfund er at få folk kigger på hinandens kode. Nogle tekniske infrastruktur er nødvendig for at gøre det effektivt-navnlig skal forpligte emails være tændt, se afsnittet «Commit emails» for yderligere oplysninger. Virkningen af e-mail ved er, at hver gang nogen begår en ændring til kildekoden, en e-mail går ud viser logmeddelelse og diffs for ændringen (se diff, i afsnittet «Version Control Vocabulary»). Kode anmeldelse er praksis at gennemgå begå e-mails som de kommer ind, søger bugs og mulige forbedringer. [11]

Kode gennemgang tjener flere formål samtidig. Det er det mest oplagte eksempel på peer review i open source-verdenen, og direkte bidrager til at vedligeholde software kvalitet. Enhver bug, der om et stykke software fik der ved at blive begået, og ikke påvist, og derfor desto mere øjne uret begår, jo færre fejl vil skibet. Men kode review tjener også en indirekte formål: det bekræfter over for folk, at det, de gør spørgsmål, fordi man naturligvis ikke ville tage tid til at gennemgå en commit, medmindre en plejet om dens virkning. Folk gør deres bedste arbejde, når de ved, at andre vil tage sig tid til at evaluere den.

Anmeldelser skal være offentlige. Selv om lejligheder, hvor jeg har siddet i det samme fysiske rum med udviklere, og en af os har gjort en commit, vi passe på ikke at gøre den fornyede verbalt i Værelset, men at sende den til udviklingen postliste stedet. Alle har fordel af at se den fornyede ske. Folk følger kommentar og undertiden finde fejl i det, og selv når de ikke gør det, er det stadig minder dem om, at revision er en forventet, regelmæssig aktivitet, ligesom opvask eller slå græs.

I Subversion-projektet, gjorde vi ikke i første omgang lave en regelmæssig praksis af kode gennemgang. Der var ingen garanti for, at alle tilsagn ville blive revideret, selvom man til tider kan se ud over en ændring, hvis man var særligt interesseret i det område af koden. Bugs gled i det virkelig kunne og burde have været fanget. En udvikler ved navn Greg Stein, der kendte værdien af kode gennemgang fra tidligere arbejde, besluttede, at han skulle til at sætte et eksempel ved at gennemgå hver linje af hver enkelt forpligtelse, der gik ind i koden repository. Hver commit gjort nogen blev hurtigt efterfulgt af en e-mail til udvikleren liste fra Greg, dissekering af commit, analysere eventuelle problemer, og lejlighedsvis at rose en smart stykke kode. Straks blev han fange bugs og ikke-optimale kodning praksis der ellers ville have smuttede forbi uden nogensinde at blive bemærket. Spidst, han aldrig klagede over at være den eneste person, der gennemgår hver commit, selvom det tog en hel del af sin tid, men han gjorde lovpriser kode review, når han havde chancen. Pretty snart, andre mennesker, inklusive mig selv, begyndte at gennemgå forpligter regelmæssigt også. Hvad var vores motivation? Det var ikke, at Greg bevidst havde skamme os ind i det. Men han havde bevist, at gennemgå kode var en værdifuld måde at tilbringe tid, og at man kunne bidrage lige så meget til projektet ved at gennemgå andres ændringer som ved at skrive ny kode. Når han viste, at det blev forventet adfærd, til det punkt, hvor enhver commit, der ikke får nogle reaktion ville få committer at bekymre sig, og selv bede på listen, hvorvidt nogen havde haft en chance for at gennemgå det endnu. Senere, Greg fik et job, der ikke lader ham så meget tid til Subversion, og måtte stoppe med at gøre regelmæssige gennemgange. Men inden da, var den vane så indgroet for resten af os, at det lader til, at det havde stået på i umindelige tider.

Begynde at gøre anmeldelser fra allerførste commit. Den slags problemer, der er lettest at fange ved at gennemgå diffs er sikkerhedshuller, hukommelseslækager, utilstrækkelige kommentarer eller API dokumentation, off-by-one fejl, opkaldsgrupper / opkaldte disciplin uoverensstemmelser, og andre problemer, der kræver et minimum af omgivende kontekst til at spotte . Imidlertid har endnu større målestok spørgsmål såsom manglende abstrakte gentagne mønstre til en enkelt placering bliver spottable efter en gjort anmeldelser regelmæssigt, fordi erindringen om tidligere diffs informerer gennemgang af de nuværende diffs.

Må ikke bekymre dig, at du ikke kan finde noget at kommentere, eller at du ikke ved nok om alle områder af koden. Der vil normalt være noget at sige om næsten alle commit, selv når du ikke kan finde noget at spørgsmål, kan du finde noget at rose. Det vigtigste er at gøre det klart for alle committer at det, de gør, er set og forstået. Selvfølgelig betyder kode review ikke fritager programmørerne af ansvaret for at gennemgå og afprøve deres ændringer før begå, ingen bør afhænge af kode review for at fange ting, han burde have fanget på egen hånd.

Når du åbner et tidligere Lukket Project, være følsom over for størrelsen af den Change

Hvis du åbner et eksisterende projekt, en der allerede har aktive udviklere er vant til at arbejde i et lukket-source miljø, så sørg for at alle forstår, at en stor forandring kommer-og sørg for, at du forstår, hvordan det kommer til at føle fra deres synspunkt.

Prøv at forestille dig, hvordan situationen ser ud for dem: tidligere blev al kode og design beslutninger lavet med en gruppe af andre programmører, der kendte softwaren mere eller mindre lige så godt, som alle har modtaget det samme pres fra den samme ledelse, og som alle kender hinandens styrker og svagheder. Nu du spørger dem om at udsætte deres kode til kontrol af tilfældige fremmede, der vil danne domme kun er baseret på den kode, uden bevidsthed om, hvad business pres kan have tvunget nogle beslutninger. Disse fremmede vil stille masser af spørgsmål, spørgsmål, at bump de eksisterende udviklere til at indse, at den dokumentation, de knoklet så hårdt over er stadig utilstrækkelig (dette er uundgåeligt). Til top det alle off, de nyankomne er ukendte, ansigtsløse enheder. Hvis en af dine udviklere allerede føler sig usikker på sine evner, forestille sig, hvordan det vil blive forværret, når nytilkomne påpege fejl i koden han skrev, og værre, så gør det foran hans kolleger. Medmindre du har et team af perfekte kodere, det er uundgåeligt, i virkeligheden, vil det sandsynligvis ske for dem alle i første omgang. Det er ikke fordi de er dårlige programmører, det er bare, at enhver program over en vis størrelse har fejl, og peer review vil stedet nogle af disse fejl (se afsnittet «Praksis Conspicuous Code Review» tidligere i dette kapitel). Samtidig vil de nyankomne selv ikke være genstand for megen peer review i starten, da de ikke kan bidrage med kode, indtil de er mere fortrolige med projektet. Til dine udviklere, kan det føles som om al kritik er indgående, aldrig udgående. Der er således fare for en belejring mentalitet tager fat blandt de gamle hænder.

Den bedste måde at undgå dette er at advare alle om, hvad der kommer, forklare det, så fortæl dem, at den oprindelige ubehag er helt normalt, og berolige dem, at det kommer til at få det bedre. Nogle af disse advarsler bør finde sted privat, før projektet åbnes. Men du kan også finde det nyttigt at minde folk om de offentlige lister, at dette er en ny måde for udvikling af projektet, og at det vil tage nogen tid at tilpasse sig. Den allerbedste ting du kan gøre, er et godt eksempel. Hvis du ikke kan se dine udviklere besvarer nok newbie spørgsmål, så bare at fortælle dem om at besvare flere kommer ikke til at hjælpe. De kan ikke have en god fornemmelse af, hvad berettiger et svar, og hvad der ikke gør endnu, eller det kan være, at de ikke har en fornemmelse af, hvordan at prioritere kodning arbejde mod den nye byrde af eksterne kommunikation. Den måde at få dem til at deltage, er at deltage selv. Vær på de offentlige postlister, og sørg for at besvare nogle spørgsmål der. Når du ikke har ekspertisen til at stille med et spørgsmål, så synligt indleverer den til en udvikler, der gør-og se at sørge for at han følger op med et svar, eller i det mindste et svar. Det vil naturligvis være fristende for de mangeårige udviklere til at forfalde til private diskussioner, da det er hvad de er vant til. Sørg for at du er tilmeldt de interne postlister, hvor dette kan ske, så du kan bede om, at sådanne drøftelser blive flyttet til de offentlige lister med det samme.

Der er andre, mere langsigtede problemer med at åbne op tidligere lukkede projekter. Kapitel 5, Money udforsker teknikker til at blande lønnede og ulønnede udviklere med succes, og kapitel 9, licenser, copyrights og patenter diskuterer nødvendigheden af juridiske omhu, når der åbnes op en privat kodebase, der kan indeholde skriftlig software eller «ejet» af andre parter.

Annoncerer

Når projektet er præsentabel-ikke perfekt, bare præsentabel-du klar til at annoncere det til verden. Dette er faktisk en meget enkel proces: Gå til http://freecode.com/ klikke på Send i den øverste navigationslinje, og udfylde en formular annoncere dit nye projekt. Freecode (kendt som Freshmeat.net indtil det blev omdøbt i okt 2011) er det sted alles ure til nye projekter annonceringer. Du behøver kun at fange et par øjne der for nyheder om dit projekt til at sprede fra mund til mund.

Hvis du kender til postlister eller nyhedsgrupper, hvor en annoncering af dit projekt vil være on-topic og af interesse, så send der, men vær omhyggelig med at gøre præcis én post pr forum, og at dirigere folk til dit projekts egne fora for opfølgning op diskussion (ved at sætte Svar til header). Stillingerne skal være korte og få ret til det punkt:

Til: discuss@lists.example.org
Emne: [ANN] Scanley fuldtekst indekseringen projekt
Svar til: dev@scanley.org

Dette er en engangs-stilling at annoncere oprettelsen af Scanley
projekt, et open source fuldtekst indexer og søgemaskine med en
rige API, til brug for programmører i at yde søgetjenester for
store samlinger af tekstfiler. Scanley nu kører kode, er
under aktiv udvikling, og er på udkig efter både udviklere og
testere.

Hjemmeside: http://www.scanley.org/

features:
- Søger almindelig tekst, HTML og XML
- Word eller en sætning søgning
- (Planlagte) Fuzzy matching
- (Planlagte) Trinvis opdatering af indekser
- (Planlagte) Indeksering af fjerntliggende websteder

krav:
- Python 2,2 eller højere
- Nok diskplads til at holde indeksene (ca. 2x
oprindelige data størrelse)

For mere information, kan du komme til scanley.org.

Tak,
-J. Random

Der er en løbende debat i den frie software verden om, hvorvidt det er nødvendigt at begynde med at køre kode, eller om et projekt kan drage fordel af at blive åbnet selv under design / diskussion fase. Jeg plejede at tænke starter med at køre kode var den vigtigste faktor, at det var, hvad der adskilte vellykkede projekter fra legetøj, og at alvorlige udviklere kun ville blive tiltrukket af software, der gjorde noget konkret allerede.

Dette viste sig ikke at være tilfældet. I Subversion-projektet, startede vi med et design dokument, en kerne af interesserede og gode forbindelser udviklere, en masse fanfare, og ingen rindende kode overhovedet. Til min fuldstændig overraskelse overtog projektet aktive deltagere lige fra begyndelsen, og med den tid, vi havde noget kørende, var der en hel del frivillige udviklere allerede dybt involveret. Subversion er ikke det eneste eksempel, Mozilla-projektet blev også lanceret uden at køre kode, og er nu en succesfuld og populær webbrowser.

I lyset af sådanne beviser, har jeg til at bakke væk fra den påstand, at køre kode er absolut nødvendig for at lancere et projekt. Løb kode er stadig det bedste fundament for succes og en god tommelfingerregel ville være at vente, indtil du har det, før annoncere dit projekt. Imidlertid kan der være situationer, hvor annoncere tidligere giver mening. Jeg tror, at i det mindste en veludviklet design dokument, ellers en slags kode ramme er nødvendig, selvfølgelig kan ændres baseret på den offentlige feedback, men der må være noget konkret, noget mere håndgribeligt end bare gode intentioner , for folk at synke deres tænder ind.

Når du annoncere, skal du ikke forvente en horde af frivillige til at deltage i projektet med det samme bagefter. Normalt er resultatet af at annoncere, er, at du får et par afslappet henvendelser, nogle flere mennesker deltage i dine adresselister, og bortset fra at alt fortsætter temmelig meget som før. Men over tid, vil du bemærke en gradvis stigning i deltagelsen fra både nye kode bidragydere og brugere. Meddelelse er blot plantning af en frø. Det kan tage lang tid for nyheden at sprede sig. Hvis projektet konsekvent belønner dem, der får involveret, vil nyheden spredes, selv om, fordi folk ønsker at dele, når de har fundet noget godt. Hvis alt går vel, vil dynamikken i eksponentielle kommunikationsnet langsomt omdanne projektet til et sammensat samfund, hvor man ikke nødvendigvis kender alles navn og kan ikke længere følge hver enkelt samtale. De næste kapitler om at arbejde i dette miljø.
[10] Vi har ikke fået til afsnittet om kreditering endnu, men bare for at praktisere, hvad jeg vil senere prædike: observatørens navn var Brian Behlendorf, og det var ham, der påpegede den generelle betydning af at holde alle diskussioner offentligt tilgængelige, medmindre der var et specifikt behov for privatliv.

[11] Dette er, hvordan kode review er normalt gøres i open source-projekter, i hvert fald. I mere centraliserede projekter, «code anmeldelse» kan også betyde flere mennesker, der sidder ned sammen og gå over udskrifter af kildekode, på udkig efter specifikke problemer og mønstre.

Kapitel 3. Teknisk Infrastruktur

Gratis software projekter bygger på teknologier, der understøtter selektiv fangst og integration af information. Jo mere dygtig du er til at bruge disse teknologier, og ved at overtale andre til at bruge dem, jo mere vellykket dit projekt være. Det bliver kun mere sandt, som projektet vokser. God information management er, hvad forhindrer open source projekter i at kollapse under vægten af Brooks ‘lov [12], hvori det hedder, at tilsætning af arbejdskraft til en sen software-projekt gør det senere. Fred Brooks observeret, at kompleksiteten af et projekt stiger med kvadratet på antallet af deltagere. Når kun få personer er involveret, kan alle nemt snakke med alle andre, men når hundredvis af mennesker er involveret, er det ikke længere muligt for hver person at forblive konstant opmærksomme på, hvad alle andre gør. Hvis god gratis software projektledelse handler om at gøre alle føle, at de alle er arbejder sammen i samme rum, det oplagte spørgsmål er: Hvad sker der, når alle i et overfyldt værelse forsøger at tale på én gang?

Dette problem er ikke nyt. I ikke-metaforiske overfyldte lokaler, er løsningen parlamentarisk procedure: formelle retningslinjer for, hvordan man har real-time diskussioner i store grupper, hvordan man kan sørge vigtige dissents ikke går tabt i oversvømmelser af «me-too» kommentarer, hvordan man kan danne underudvalg , hvordan man kan genkende, når beslutningerne træffes, osv. En vigtig del af den parlamentariske procedure er at angive hvordan gruppen hænger sammen med dets information management system. Nogle bemærkninger er lavet «for the record», andre er ikke. Pladen er underlagt direkte manipulation, og skal forstås som værende ikke en bogstavelig afskrift af, hvad der skete, men en repræsentation af hvad gruppen er indstillet på at give fandt sted. Pladen er ikke monolitisk, men antager forskellige former til forskellige formål. Det består af referatet af individuelle møder, den komplette samling af alle referater af alle møder, sammendrag, dagsordener og deres anmærkninger, betænkninger, rapporter fra korrespondenter ikke er til stede, lister af action poster mv

Fordi internettet ikke er virkelig et værelse, behøver vi ikke at bekymre dig om at gentage de dele af parlamentarisk procedure, der holder nogle mennesker stille, mens andre taler. Men når det kommer til information management teknikker, veldrevet open source-projekter er parlamentarisk procedure på steroider. Da næsten al kommunikation i open source-projekter sker skriftligt, har udarbejde systemer udviklet sig til routing og mærkning data korrekt, for at minimere gentagelser for at undgå falske forskelle, for gemme og hente data, til at korrigere dårlige eller forældede oplysninger, og for at knytte uensartede bits af information med hinanden som nye forbindelser observeres. Aktive deltagere i open source-projekter internalisere mange af disse teknikker, og vil ofte udføre komplekse manuelle opgaver at sikre, at oplysningerne er ført korrekt. Men hele bestræbelse afhænger i sidste ende sofistikeret software support. Så meget som muligt, bør kommunikationsmedierne selv gøre routing, mærkning og registrering, og de bør gøre oplysningerne tilgængelige for mennesker i den mest bekvemme måde. I praksis selvfølgelig vil mennesker stadig nødt til at gribe ind på mange punkter i processen, og det er vigtigt, at softwaren gør sådanne interventioner praktisk også. Men generelt, hvis de mennesker sørge for at etiketten og ruteinformationer præcist på sin første indrejse i systemet, så softwaren skal konfigureres til at gøre så meget brug af denne metadata som muligt.

Rådene i dette kapitel er intenst praktisk, baseret på erfaringerne med specifik software og brugsmønstre. Men pointen er ikke blot at undervise i en bestemt samling af teknikker. Det er også at vise, ved hjælp af mange små eksempler, den generelle holdning, der bedst fremmer god information management i dit projekt. Denne holdning vil indebære en kombination af tekniske færdigheder og folk færdigheder. De tekniske færdigheder er afgørende, fordi information management software altid kræver konfiguration, plus en vis mængde løbende vedligeholdelse og tweaking som nye behov opstår (se f.eks diskussionen om, hvordan man håndterer projekt vækst i afsnittet «Pre-Filtrering af Bug Tracker «senere i dette kapitel). De mennesker færdigheder er nødvendige, fordi det menneskelige samfund kræver også vedligeholdelse: det er ikke altid umiddelbart indlysende, hvordan man bruger disse værktøjer til fuldt udbytte, og i nogle tilfælde projekter har modstridende konventioner (f.eks diskussionen om fastsættelse Svar til overskrifter på udgående se mail listerne, i afsnittet «Postlister»). Alle involverede i projektet vil skulle fremmes, på de rigtige tidspunkter og i de rigtige måder, at gøre deres del for at holde projektets information godt organiseret. Jo mere involverede bidragyder, jo mere kompleks og specialiseret de teknikker, hun kan forventes at lære.

Information management har ingen cut-and-tørret løsning. Der er for mange variabler. Du kan endelig få alt konfigureret bare den måde du ønsker det, og har de fleste af fællesskabet deltager, men så projekt vækst vil gøre nogle af de former for praksis unscalable. Eller projekt væksten kan stabilisere, og udvikleren og brugerne falde til i en komfortabel forhold til den tekniske infrastruktur, men så nogen vil komme og opfinde en helt ny information management service, og meget snart nytilkomne vil spørge, hvorfor dit projekt ikke bruge det for eksempel, sker det nu til en masse fri software-projekter, der eksisterede før opfindelsen af wiki (se http://en.wikipedia.org/wiki/Wiki). Mange spørgsmål er spørgsmål af dom, der indebærer kompromiser mellem den bekvemmelighed af dem producerer information og bekvemmeligheden ved dem, der forbruger det, eller mellem den tid, der kræves for at konfigurere information management software og den fordel, han bringer til projektet.

Pas på fristelsen til at over-automatisere, det er, at automatisere ting, der virkelig kræver menneskelig opmærksomhed. Teknisk infrastruktur er vigtig, men hvad gør et gratis software-projekt arbejde er pleje-og intelligent udtryk for denne pleje-af de involverede mennesker. Den tekniske infrastruktur er hovedsagelig om at give mennesker bekvemme måder at gøre det.

Hvad et projekt, skal

De fleste open source-projekter tilbyde mindst et minimum, standard sæt af værktøjer til administration af oplysninger:

webstedet
Primært en centraliseret, ensrettet ledning af information fra projektet ud til offentligheden. Webstedet kan også tjene som en administrativ grænseflade til andre projektværktøjer.

postlister
Normalt de mest aktive kommunikation forum i projektet, og «medium rekord.»

versionsstyring
Giver udviklere mulighed for at styre kodeændringer bekvemt, herunder vende tilbage og «forandring portering». Aktiverer alle til at se, hvad der sker med koden.

bug tracking
Giver udviklere mulighed for at holde styr på, hvad de arbejder med, koordinere med hinanden og planlægge udgivelser. Aktiverer alle til at forespørge status for fejl og registrere oplysninger (f.eks reproduktion opskrifter) om bestemte fejl. Kan bruges til sporing ikke kun bugs, men også opgaver, udgivelser, nye funktioner osv.

Real-time chat
Et sted for hurtige, lette diskussioner og spørgsmål / svar udvekslinger. Ikke altid arkiveres helt.

Hvert værktøj i dette sæt behandler et udtalt behov, men deres funktioner er også indbyrdes forbundet, og de værktøjer skal bringes til at fungere sammen. Nedenfor vil vi undersøge, hvordan de kan gøre det, og endnu vigtigere, hvordan man får folk til at bruge dem. Webstedet er ikke diskuteret indtil udgangen, da det virker mere som lim til de øvrige komponenter end som et redskab i sig selv.

Du kan være i stand til at undgå en masse af de hovedpine af at vælge og konfigurere disse værktøjer ved hjælp af en dåse hosting site: en server, der tilbyder færdigpakkede, templatized web områder med alle de ledsagende nødvendige værktøjer til at køre en gratis software-projekt. Se afsnittet kaldet «dåse Hosting» senere i dette kapitel for en diskussion af fordele og ulemper ved dåse hosting.

Postlister

Postlister er brød og smør af projektets kommunikation. Hvis en bruger er udsat for ethvert forum udover de websider, er det mest sandsynligt, at være en af projektets postlister. Men før de oplever den postliste selv, vil de opleve postliste grænseflade det vil sige, den mekanisme, hvorved de tiltræder («abonnere på») på listen. Dette bringer os til regel # 1 af postlister:

Forsøg ikke at administrere postlister i hånden-get liste management software.

Det vil være fristende at sætte denne off. Opsætning postliste management software kan virke som overkill i første omgang. Håndtering af små, lave lister over trafikproblemer i hånden vil virke forførende let: du bare oprette et abonnement adresse, frem til dig, og når nogen mails det, du tilføje (eller fjerne) deres e-mail-adresse i noget tekst-fil, der indeholder alle de adresser på listen. Hvad kunne være enklere?

Tricket er, at god postliste management-hvilket er, hvad folk er kommet til at forvente, er ikke let på alle. Det handler ikke kun om abonnement og afmelding brugere, når de anmoder om. Det handler også om at moderere at forhindre spam, der tilbyder den postliste i fordøje versus besked-by-besked form, giver standard liste og projektoplysninger ved hjælp af auto-responders, og forskellige andre ting. Et menneske overvågning af et abonnement adresse kan kun levere et minimum af funktionalitet, og selv da ikke så stabilt og hurtigt som software kunne.

Moderne liste management software normalt tilbyder mindst følgende funktioner:

Både email-og web-baserede abonnement
Når en bruger abonnerer på en liste, bør hun straks få en automatisk velkomst besked i svaret, at fortælle hende, hvad hun har abonneret på, hvordan man omgås videre med postliste software, og (vigtigst), hvordan man afmelder. Denne automatiske svar kan tilpasses til at indeholde projekt-specifikke oplysninger, naturligvis, såsom projektets hjemmeside, FAQ placering mv

Abonnement i enten fordøje tilstand eller besked-by-besked tilstand
I digest tilstand modtager abonnenten en e-mail om dagen, som indeholder alle listen for den pågældende dag. For folk, der følger en liste løst, uden at deltage, er digest tilstand ofte at foretrække, fordi det giver dem at scanne alle de emner på en gang og undgå at blive distraheret af e-mails, der kommer ind på tilfældige tidspunkter.

Moderation funktioner
Til «moderat» er at kontrollere stillinger til at sikre de er a) ikke spam, og b) om emnet, før de går ud til hele listen. Moderation nødvendigvis indebærer mennesker, men software kan gøre meget for at gøre det lettere. Der er mere sagt om moderation senere.

Administrativ grænseflade
Blandt andet muliggør dette en administrator til at gå ind og fjerne forældede adresser nemt. Dette kan blive presserende, når en modtageradresse begynder at sende automatisk «Jeg er ikke længere på denne adresse» svarer tilbage til listen som svar på hver liste post. (Nogle postliste software kan endda opdage dette i sig selv, og afmelde den person automatisk.)

Header manipulation
Mange mennesker har sofistikeret filtrering og besvarelse bestemmelser fastsat i deres mail læsere. Postliste software kan tilføje og manipulere visse standard headers for disse mennesker at drage fordel af (flere detaljer nedenfor).

Arkivering
Alle indlæg til de styrede lister bliver gemt og gøres tilgængelige på nettet, alternativt nogle postliste software tilbyder specielle grænseflader til at tilslutte et eksternt arkivering værktøj såsom mhonarc (http://www.mhonarc.org/). Som afsnittet «Conspicuous Brug af Archives» i kapitel 6, Communications diskuterer, arkivering er afgørende.

Pointen med alt dette er blot at understrege, at postliste management er et komplekst problem, der er blevet givet en masse tanker, og for det meste er blevet løst. Du behøver bestemt ikke at blive en ekspert i det. Men du skal være opmærksom på, at der er altid plads til at lære mere, og denne liste ledelsen vil optage din opmærksomhed fra tid til anden i løbet af at køre et gratis software-projekt. Nedenfor vil vi undersøge nogle af de mest almindelige postliste konfigurationsproblemer.

Spam Prevention

Mellem når denne sætning er skrevet, og når det er offentliggjort, vil Internettet i hele spam problemet formentlig fordoblet i sværhedsgrad-eller i det mindste vil føle på den måde. Der var en tid for ikke så længe siden, da man kunne køre en postliste uden at tage nogen spam-foranstaltninger til forebyggelse på alle. Den lejlighedsvise omstrejfende indlæg vil stadig dukke op, men sjældent nok kun at være et lavt niveau irritation. Denne æra er væk for evigt. I dag vil en postliste, der tager ingen spam forebyggende foranstaltninger hurtigt nedsænkes i junk e-mails, til punktet af unusability. Spam forebyggelse er obligatorisk.

Vi opdeler spam forebyggelse i to kategorier, nemlig at forhindre spam indlæg fra vises på dine mailinglister, og forhindrer, at din adresseliste fra at være en kilde til nye e-mail-adresser til spammere ‘mejetærskere. Førstnævnte er mere vigtigt, så undersøger vi det først.

Filtrering indlæg

Der er tre grundlæggende teknikker til forebyggelse spam stillinger, og de fleste postliste software tilbyder alle tre. De er bedst brugt i tandem:

Kun automatisk tilladelse indlæg fra liste abonnenter.

1. Dette er effektivt for så vidt som det går, og involverer også meget lidt administrativt overhead, da det er som regel bare et spørgsmål om at ændre en indstilling i postliste software konfiguration. Men bemærke, at stillinger, som ikke automatisk er godkendt ikke skal simpelthen kasseres. I stedet bør de sendes videre til mådehold, af to grunde. Først, du ønsker at tillade ikke-abonnenter til at sende. En person med et spørgsmål eller et forslag bør ikke være nødvendigt at abonnere på en mailingliste blot at foretage et enkelt indlæg der. For det andet kan endda abonnenter undertiden sende fra en anden adresse end den, ved hvilken de er tilmeldt. E-mail adresser er ikke en pålidelig metode til at identificere folk, og ikke bør behandles som sådan.
2. Filter stillinger ved spam-filtrering software. Hvis postliste software gør det muligt (de fleste gør), kan du få stillinger, filtreret af spam-filtrering software. Automatisk spam-filtrering er ikke perfekt, og vil aldrig blive, da der er en uendelig våbenkapløb mellem spammere og filter forfattere. Men det kan i høj grad reducere mængden af spam, der kommer igennem til moderation køen, og da længere at køen er jo mere tid mennesker skal bruge undersøge det, enhver mængde af automatiserede filtrering er gavnligt. Der er ikke plads her for detaljerede instruktioner om opsætning spamfiltre. Du bliver nødt til at konsultere din postliste software dokumentation for, at (se afsnittet «Software» senere i dette kapitel). Liste software ofte kommer med nogle indbyggede spam forebyggelse funktioner, men du måske ønsker at tilføje nogle tredjepart filtre. Jeg har haft gode erfaringer med disse to: SpamAssassin (http://spamassassin.apache.org/) og SpamProbe (http://spamprobe.sourceforge.net/). Dette er ikke en kommentar til de mange andre open source spamfiltre derude, hvoraf nogle er tilsyneladende også ganske godt. Jeg sker bare at have brugt de to mig og været tilfreds med dem.
3. Moderation. For mails, der ikke automatisk er tilladt i kraft af at være fra en liste abonnent, og som gør det gennem spam filtreringssoftware, om nogen, den sidste fase er mådehold: posten sendes til en speciel adresse, hvor et menneske undersøger det og bekræfter eller forkaster det. Bekræftelse af en stilling tager en af to former: du kan acceptere posten bare denne ene gang, eller du kan fortælle listen software til at give denne og alle fremtidige indlæg fra samme afsender. Du næsten altid ønsker at gøre det sidstnævnte, for at reducere den fremtidige moderation byrde. Nærmere oplysninger om, hvordan du bekræfte variere fra system til system, men det er som regel et spørgsmål om at besvare en særlig adresse med kommandoen «acceptere» (der betyder acceptere bare denne ene stilling) eller «tillader» (tillader dette og fremtidige stillinger). Afvisning er normalt gøres ved blot at ignorere moderation mail. Hvis listen softwaren aldrig modtager bekræftelse på, at noget er en gyldig post, så vil det ikke videregive denne post på til listen, så blot at opgive moderation mail opnår den ønskede effekt. Nogle gange skal du også mulighed for at reagere med et «afvise» eller «deny» kommando, til automatisk at afvise fremtidige mails fra samme afsender, uden selv at køre dem gennem mådehold. Der er sjældent noget tidspunkt at gøre dette, da moderation handler mest om spam forebyggelse, og spammere tendens til ikke at sende fra samme adresse to gange alligevel.

Vær sikker på at bruge mådehold kun for at filtrere spam og klart off-topic beskeder, såsom når en person utilsigtet stillinger til den forkerte postliste. Afdæmpningen system vil normalt give dig en måde at svare direkte til afsenderen, men ikke bruger denne metode til at besvare spørgsmål, der virkelig hører hjemme på mailinglisten sig selv, selvom du kender svaret fra toppen af dit hoved. At gøre dette ville fratage projektets fællesskab af et præcist billede af, hvad slags spørgsmål folk stiller, og fratage dem en chance for at besvare spørgsmål selv og / eller se svar fra andre. Postliste moderation er strengt om at holde listen fri for junk og off-topic e-mails, intet mere.

Adresse gemmer sig i arkiverne

For at forhindre, at dine postlister fra at være en kilde til adresser for spammere, en almindelig teknik er for arkiverne at skjule folks email-adresser, for eksempel ved at erstatte

jrandom@somedomain.com

med

jrandom_AT_somedomain.com

eller

jrandomNOSPAM@somedomain.com

eller en tilsvarende indlysende (til et menneske) kodning. Da spam adresse høstmaskiner arbejder ofte ved at kravle gennem websider, inklusive din postliste online arkiv-og leder efter sekvenser, der indeholder «@», der koder adresserne er en måde at gøre folks e-mail-adresser usynlig eller nytteløst at spammere. Det gør intet for at forhindre spam i at blive sendt til postlisten selv, selvfølgelig, men det gør undgå at øge mængden af spam sendt direkte til listen brugernes personlige adresser.

Address skjule kan være kontroversielle. Nogle mennesker kan lide det en masse, og vil blive overrasket, hvis dine arkiver ikke gør det automatisk. Andre mennesker synes, det er for meget af en ulempe (fordi mennesker også nødt til at oversætte de adresser tilbage, før du bruger dem). Sommetider folk hævde, at det er ineffektivt, fordi en mejetærsker i teorien kunne kompensere for konsekvent kodning mønster. Bemærk dog, at der er empiriske beviser for, at adressen gemmer sig er effektiv, se http://www.cdt.org/speech/spam/030319spamreport.shtml.

Ideelt set ville listen management software overlade valget op til den enkelte abonnent, enten gennem en særlig ja / nej header eller en indstilling i denne abonnentens liste kontoindstillinger. Men jeg kender ikke til nogen software, som tilbyder per-abonnent eller per post valg i sagen, så for nu listen lederen skal træffe en beslutning for alle (under forudsætning af arkiveringssystemet tilbyder funktionen på alle, som ikke altid er tilfældet). Jeg læner mig meget mildt mod drejning adresse gemmer sig på. Nogle mennesker er meget omhyggelig med at undgå at lægge deres e-mail-adresser på websider eller andre steder en spam mejetærsker kunne se det, og de ville blive skuffet over at have alt det omhu smidt væk af en mailingliste arkiv, i mellemtiden, ulejligheden adresse skjule pålægger arkivbrugere er meget lille, da det er trivielt at omdanne en skjult adresse tilbage til en gyldig, hvis du har brug for at nå den person. Men husk på, at i sidste ende, er det stadig et våbenkapløb: med den tid, du læser dette, kan mejetærskere godt have udviklet sig til det punkt, hvor de kan genkende de mest almindelige former for skjul, og vi bliver nødt til at tænke på noget andet.

Identifikation og Header Management

Liste abonnenter ofte ønsker at sætte mails fra listen ind i en projekt-specifik mappe, adskilt fra deres øvrige post. Deres mail læsning software kan gøre dette automatisk ved at undersøge mailens brevhoveder. Overskrifterne er felterne øverst i mailen, der angiver afsender, modtager, emne, dato, og forskellige andre ting om meddelelsen. Visse overskrifter er velkendte og faktisk er obligatoriske:

From: ...
To: ...
Subject: ...
Date: ...

Andre er valgfri, men stadig helt standard. For eksempel er emails ikke strengt nødvendigt at have

Svar til: sender@email.address.here
header, men de fleste gør, fordi det giver modtagerne en idiotsikker måde at nå forfatteren (det er især nyttig, når forfatteren var nødt til at sende fra en anden adresse end den, som svar skal rettes).

Nogle e-mails læsning software giver en nem-at-bruge interface til arkivering mails baseret på mønstre i overskriften Emne. Det får folk til at anmode om, at postliste tilføje en automatisk præfiks til alle fag, så de kan indstille deres læsere til at kigge efter, at præfiks og automatisk fil de mails i den rigtige mappe. Ideen er, at den oprindelige forfatter ville skrive:

Om: Gør de 2,5 udgivelse.
men den post vil dukke op på listen ser sådan ud:

Emne: [discuss@lists.example.org] Realiseringen af de 2,5 udgivelse.
Selv om de fleste liste management software giver mulighed for at gøre dette, jeg stærkt anbefale mod at dreje indstillingen på. Det problem det løser nemt kan løses i langt mindre påtrængende måder, og omkostningerne ved spise plads i feltet Emne er alt for højt. Erfarne postliste brugere typisk scanne Emner af dagens indbakken mail at beslutte, hvad at læse og / eller reagere på. Forudstille listens navn til emnet kan skubbe højre side af Emne væk fra skærmen, hvilket gør det usynlige. Dette skjuler oplysninger, som folk afhængige af for at beslutte, hvilke mails til at åbne, og dermed reducere den overordnede funktionalitet af mailinglisten for alle.

I stedet for at munging overskriften Emne, lær dine brugere til at drage fordel af de andre standard overskrifter, startende med at header, som bør sige postlisten navn:

Til: <discuss@lists.example.org>
Enhver e-mail-læser, der kan filtrere på Emne skal kunne filtrere på at lige så nemt.

Der er et par andre valgfri-men-standard headers forventes for postlister. Filtrering på disse er endnu mere pålidelig end at bruge «Til» eller «cc» overskrifter, da disse overskrifter er føjet til hver stilling skabes ved postliste management software selv, kan nogle brugere tælle om deres tilstedeværelse:

list-help: <mailto:discuss-help@lists.example.org>
liste-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org>
liste-post: <mailto:discuss@lists.example.org>
Sendt til: postliste discuss@lists.example.org
Mailing-List: kontakt discuss-help@lists.example.org, køre ved ezmlm

For det meste er de selvforklarende. Se http://www.nisto.com/listspec/list-manager-intro.html for mere forklaring, eller hvis du har brug for virkelig detaljeret, formel specifikation se http://www.faqs.org/rfcs/rfc2369. html.

Bemærk, hvordan disse overskrifter indebærer, at hvis du har en postliste med navnet «liste», så har du også administrative adresser «liste-help» og «liste-unsubscribe» til rådighed. Ud over disse, er det normalt at have «liste-subscribe», for sammenføjning, og «liste-ejer», for at nå listens administratorer. Afhængigt af listen management software, du bruger, disse og / eller forskellige andre administrative adresser kan oprettes, dokumentationen vil have detaljer. Normalt en fuldstændig forklaring på alle disse særlige adresser er sendt til hver ny bruger som del af en automatiseret «velkomst mail» på abonnementet. Du selv vil sandsynligvis få en kopi af denne velkomst mail. Hvis du ikke gør, så spørg en anden om en kopi, så du ved, hvad dine brugere ser, når de slutter sig til listen. Hold kopi handy, så du kan besvare spørgsmål om mailing liste funktioner, eller endnu bedre, sætte det på en webside eller andet sted. På den måde når folk mister deres egen kopi af instruktionerne og send at spørge «Hvordan kan jeg afmelde denne liste?», Kan du bare aflevere dem webadressen.

Nogle postliste software tilbyder en mulighed for at tilføje afmelding instrukser til bunden af hvert indlæg. Hvis denne indstilling er tilgængelig, tænde den. Det forårsager kun et par ekstra linjer pr besked, i en harmløs placering, og det kan spare dig for en masse tid, ved at skære ned på antallet af mennesker, der mail du-eller værre, mail listen!-Spørger, hvordan man afmelder .

Den Store Svar til debat

Tidligere i afsnittet «Undgå Private diskussioner», jeg understregede vigtigheden af at sikre drøftelser ophold i offentlige fora, og talte om, hvordan aktive foranstaltninger er undertiden nødvendig for at forhindre samtaler efterfølgende ud i private e-mail tråde, desuden dette kapitel er alt om opsætning projekt kommunikation software til at gøre så meget af arbejdet for dig som muligt. Derfor, hvis postliste management software tilbyder en måde til automatisk at få diskussioner at blive på listen, skulle man tro, drejning, at funktionen på ville være det oplagte valg.

Tja, ikke helt. Der er sådan en funktion, men det har nogle ret alvorlige ulemper. Spørgsmålet om, hvorvidt eller ikke at bruge det er en af de hotteste debatter i postliste management-ganske vist ikke en kontrovers, der er tilbøjelige til at gøre aftenen nyheder i din by, men det kan blusse op fra tid til anden i fri software-projekter. Nedenfor vil jeg beskrive funktionen, giver de store argumenter på begge sider, og gøre den bedste anbefaling jeg kan.

Den funktion selv er meget enkel: postliste software kan, hvis du ønsker det, automatisk indstille Svar til header på hver post til omdirigere svar til postliste. Det vil sige, uanset hvad den oprindelige afsender lægger Reply-til header (eller selv hvis de ikke inkludere en på alle), på det tidspunkt listen abonnenterne se stillingen, vil overskriften indeholder listen adresse:

Svar til: discuss@lists.example.org
På sit ansigt, synes dette som en god ting. Fordi stort set alle mail software til læsning er opmærksom på Svar til header, når nogen reagerer på et indlæg nu, vil deres svar blive automatisk rettet til hele listen, ikke bare til afsenderen af den meddelelse, der reagerede på. Selvfølgelig kan responder stadig manuelt ændre, hvor budskabet går, men det vigtigste er, at som standard svar er rettet til listen. Det er et perfekt eksempel på brug af teknologi til at fremme samarbejde.

Desværre er der nogle ulemper. Den første er kendt som den kan ikke finde min vej hjem problem: nogle gange den oprindelige afsender vil sætte deres «rigtige» email-adresse i feltet Svar til området, fordi for en eller anden grund de sender e-mail fra en anden adresse end den, hvor de modtager det. Folk, der altid læse og sende fra samme sted har ikke dette problem, og kan blive overrasket over, at det overhovedet eksisterer. Men for dem, der har usædvanlige email konfigurationer, eller som ikke kan styre, hvordan Fra adressen på deres mails udseende (måske fordi de sender fra arbejde og ikke har nogen indflydelse på it-afdeling), ved hjælp af Svar til kan være den eneste måde, de nødt til at sikre, at svarene nå dem. Når en sådan person indlæg til en mailingliste, at han ikke abonnerer på, hans indstilling Svar til bliver afgørende information. Hvis listen software overskriver det, kan han aldrig se svarene på sin post.

Den anden ulempe har at gøre med forventningerne, og efter min mening er den mest magtfulde argument imod Svar til munging. De fleste erfarne mail-brugere er vant til to grundlæggende metoder til at svare: svar-til-alle og svar-til-forfatter. Alle moderne mail læsning software har separate taster for disse to aktioner. Brugerne ved, at sende svar til alle (der er, herunder listen), bør de vælge svar-til-alle, og at svare privat til forfatteren, hvis man vælger svar-til-forfatter. Selvom du ønsker at tilskynde folk til at svare til listen, når det er muligt, der er sikkert omstændigheder, hvor en privat svar er den responder prærogativ for eksempel, kan de ønsker at sige noget fortroligt til forfatteren af den oprindelige meddelelse, noget der ville være uhensigtsmæssigt på den offentlige liste.

Overvej nu, hvad der sker, når listen har tilsidesat den oprindelige afsenders Svar til. Den responder rammer svaret-til-forfatter nøgle, forventer at sende en privat besked tilbage til den oprindelige forfatter. Fordi det er den forventede adfærd, kan han ikke gider at se nøje på modtageradressen i den nye meddelelse. Han komponerer sin private, fortrolige besked, en som måske siger pinlige ting om en person på listen, og rammer den sendetasten. Uventet et par minutter senere hans budskab vises på mailinglisten! Sandt nok, i teorien skulle han have set nøje på modtagerfeltet, og burde ikke have antaget noget om Svar til header. Men forfattere næsten altid sat Svar til til deres egen personlige adresse (eller rettere, deres mail-software sætter det for dem), og mange longtime e-mail brugere er kommet til at forvente, at. I virkeligheden, når en person bevidst sætter Svar til til en anden adresse, såsom listen han normalt gør et punkt for at nævne dette i brødteksten, så vil folk ikke blive overrasket over, hvad der sker, når de svare.

På grund af de mulige alvorlige konsekvenser af denne uventede opførsel, er min egen præference for at konfigurere liste management software til aldrig røre Svar til header. Dette er et eksempel på, bruge teknologi til at opmuntre til samarbejde har, forekommer det mig, potentielt farlige bivirkninger. Men der er også nogle vægtige argumenter på den anden side af denne debat. Uanset hvordan du vælger, vil du lejlighedsvis få folk udstationering til din liste spørger, hvorfor du ikke valgte den anden vej. Da dette ikke er noget, du nogensinde vil som den vigtigste diskussionsemne på din liste, kan det være godt at have en dåse svar parat, af den slags, der er mere tilbøjelige til at stoppe diskussionen end at fremme den. Sørg for at du ikke insistere på, at din beslutning, alt efter hvad det er, er naturligvis det eneste rigtige og fornuftige (selvom du tror det er tilfældet). I stedet påpege, at dette er en meget gammel debat, der er gode argumenter på begge sider, er intet andet valg vil tilfredsstille alle brugere, og derfor skal du lige har lavet den bedste beslutning, du kunne. Høfligt bede om, at emnet ikke tages op til fornyet, medmindre nogen har noget helt nyt at sige, derefter bo ud af tråden og håber det dør en naturlig død.

Nogen kan foreslå en afstemning for at vælge den ene eller den anden. Du kan gøre det, hvis du vil, men jeg personligt ikke føler, at tælle hoveder er en tilfredsstillende løsning i dette tilfælde. Straffen for en person, der er overrasket over den opførsel er så enorm (utilsigtet at sende en privat mail til en offentlig liste), og besvær for alle andre er temmelig lille (lejlighedsvis at skulle minde nogen til at reagere på hele listen i stedet for blot at dig), at det ikke er klart, at flertallet, selvom de er de fleste, bør være i stand til at sætte mindretal ved en sådan risiko.

Jeg har ikke taget alle aspekter af dette problem her, kun dem, der syntes af allerstørste betydning. For en fuld diskussion, se disse to kanoniske dokumenter, som er dem folk altid cite, når de har denne debat:

• Lad Svar til alene, af Chip Rosenthal http://www.unicom.com/pw/reply-to-harmful.html
• Sæt Reply-to til listen, ved Simon Hill http://www.metasystema.net/essays/reply-to.mhtml

Trods den milde præference angivet ovenfor, mener jeg ikke der er en «rigtige» svar på dette spørgsmål, og heldigvis deltage i mange lister, der er fastsat Svar til. Den vigtigste ting du kan gøre, er at sætte sig på den ene eller den anden tidligt, og prøv ikke at blive viklet ind i debatter om det efter at.

To fantasier

En dag, vil nogen få den lyse idé at gennemføre et svar-til-liste nøgle i en mail-læser. Det ville bruge nogle af de brugerdefinerede liste headers tidligere nævnt at finde ud af adressen på postlisten, og derefter tage fat på besvarelsen direkte til listen kun, forlader slukning af andre modtageradresser, da de fleste nok er tilmeldt til listen alligevel. Til sidst vil andre mail-læsere afhente funktion, og hele denne debat vil gå væk. (Faktisk betyder Mutt mail læseren tilbyde denne funktion. [13])

En endnu bedre løsning ville være, Svar til munging at være en per-abonnent præference. De, der ønsker, at listen for at indstille Svar til munged (enten på andres indlæg eller på deres egne stillinger) kunne anmode om det, og dem, der ikke ville bede om Svar til at blive ladt alene. Men jeg kender ikke til nogen liste management software, der tilbyder dette på en per-abonnent basis. For nu synes vi at stå med en global indstilling. [14]

Arkivering

De tekniske detaljer i forbindelse med oprettelse postliste arkivering er specifikke for den software, der kører på listen, og er uden for rammerne af denne bog. Når du vælger eller konfigurere et arkiveringssystem, overveje disse kvaliteter:

Spørg opdatering
Folk vil ofte ønsker at henvise til en arkiveret indlæg under den sidste time eller to. Hvis det er muligt, bør den Archiver arkiv hver post øjeblikkeligt, så der på det tidspunkt et indlæg vises på postlisten, det er allerede til stede i arkiverne. Hvis denne indstilling ikke er tilgængelig, så i det mindste forsøge at sætte Archiver at opdatere sig selv hver time eller så. (Som standard køre nogle archivers deres opdatering behandler en gang per nat, men i praksis, der er alt for meget lag tid for en aktiv postliste.)

Referentiel stabilitet
Når en meddelelse er arkiveret på en bestemt URL, bør det forblive tilgængelige på det nøjagtig samme webadresse for evigt, eller så tæt på for evigt som muligt. Selv hvis arkiverne er genopbygget, gendannes fra backup, eller på anden måde fastgjort, skal eventuelle webadresser, der allerede er gjort offentligt tilgængelige forblive den samme. Stabile referencer gør det muligt for internetbrugere søgemaskiner at indeksere arkiverne, hvilket er en stor velsignelse for brugere, der søger efter svar. Stabile referencer er også vigtigt, fordi mail listerne og tråde ofte er en sammenhæng fra bug tracker (se afsnittet «Bug Tracker» senere i dette kapitel) eller fra andre projektdokumenter.

Ideelt set ville postliste software omfatter en besked arkiv URL, eller i det mindste besked-specifikke del af URL’en, i en header, når det fordeler beskeden til modtagerne. På den måde folk, der har en kopi af meddelelsen vil være i stand til at kende sit arkiv placering uden rent faktisk at besøge arkiverne, hvilket ville være nyttigt, fordi enhver handling, der involverer en webbrowser er automatisk tidskrævende. Hvorvidt postliste software faktisk tilbyder denne funktion, ved jeg ikke, desværre, dem jeg har brugt ikke. Men det er noget at kigge efter (eller, hvis du skriver postliste software, er det en funktion til at overveje at indføre, please).

Backups
Det burde være rimeligt indlysende, hvordan du sikkerhedskopierer arkiver, og genoprettelse opskrift bør ikke være for svært. Med andre ord, ikke behandle din Archiver som en sort boks. Du (eller nogen i dit projekt) bør vide, hvor det er opbevaring af beskeder, og hvordan man kan regenerere de aktuelle arkiv sider fra meddelelsen butik, hvis det nogensinde skulle blive nødvendigt. Disse arkiver er dyrebare data-et projekt, der mister dem mister en god del af sin kollektive hukommelse.

Trådunderstøttelse
Det bør være muligt at gå fra en enkelt meddelelse til tråden (gruppe relaterede meddelelser), som den oprindelige meddelelse er en del af. Hver tråd skal have sin egen webadresse også, adskilt fra webadresserne på de enkelte meddelelser i tråden.

Søgbarhed
En Archiver, der ikke understøtter søge-på ligene af beskeder, samt forfattere og emner, er tæt på ubrugelig. Bemærk, at nogle archivers understøtte søgning ved blot at landbruget arbejde ud til en ekstern søgemaskine som Google. Det er acceptabelt, men direkte søgning support er som regel mere finjusteret, fordi det giver søgepersonens at præcisere, at kampen skal vises i en emnelinje versus kroppen, for eksempel.

Ovenstående er blot en teknisk tjekliste til at hjælpe dig med at evaluere og oprette et arkiveringssystem. At få folk til rent faktisk at bruge arkiveringssystemet til projektets fordel diskuteres i senere kapitler, især afsnittet «Conspicuous brug af Arkiv».

Software

Her er nogle open source-værktøjer til at gøre liste forvaltning og arkivering. Hvis det websted, hvor du er vært dit projekt allerede har en standardopsætning, så kan du ikke nogensinde nødt til at træffe beslutning om et værktøj overhovedet. Men hvis du skal installere en selv, disse er nogle muligheder. Dem jeg har faktisk anvendes, er Mailman, Ezmlm, mhonarc, og Hypermail, men det betyder ikke, de andre er ikke god for (og selvfølgelig er der sikkert andre værktøjer derude, at jeg bare ikke tilfældigvis finde , så du skal ikke tage dette som en komplet liste).

Postliste management software:

• Mailman — http://www.list.org/ (Har en indbygget arkiveringssystem, Pipermail, og har kroge til at tilslutte eksterne archivers Mailman har været standard i lang tid, og dens administration interfaces, især for spam moderation og abonnement mådehold, viser deres alder og kan være frustrerende at brug for dem vant til mere moderne grænseflader.)
• GroupServer — http://www.groupserver.org/ (Har indbygget Archiver og integreret web-baseret interface. GroupServer er noget sværere at etablere end Mailman, og som i begyndelsen af 2012 krævede en meget bestemt sæt af forudsætninger, men når du har det kører det tilbyder brugerne en bedre oplevelse.)
• Sympa — http://www.sympa.org/ (Udviklet og vedligeholdt af et konsortium af franske universiteter, og designet til at håndtere både meget store lister (> 700.000 medlemmer) og et stort antal af lister kan arbejde med en bred vifte af afhængigheder. For eksempel, kan du køre det med sendmail, postfix , qmail eller exim som det underliggende budskab transfer agent. Indbygget web-baserede arkivering.)
• SmartList — http://www.procmail.org/ (Beregnet til brug med Procmail mail system.)
• Ecartis — http://www.ecartis.org/
• ListProc — http://listproc.sourceforge.net/
• Ezmlm — http://cr.yp.to/ezmlm.html (Designet til at arbejde med Qmail postomdeling system.)
• Dada — http://mojo.skazat.com/ (På trods af webstedets bizarre forsøg på at skjule den kendsgerning, er dette gratis software, udgivet under GNU General Public License. Den har også en indbygget arkiveringssystem.)

Postliste arkivering software:

• Mhonarc — http://www.mhonarc.org/
• Hypermail — http://www.hypermail.org/
• Lurker — http://sourceforge.net/projects/lurker/
• Procmail — http://www.procmail.org/ (Companion software til SmartList, dette er en generel mail system, der kan tilsyneladende være udformet som en Archiver.)

Version Control

En version kontrolsystem (eller revision styresystem) er en kombination af teknologier og metoder til at spore og styre ændringer i et projekts filer, især kildekode, dokumentation og websider. Hvis du aldrig har brugt version kontrol før, den første ting du skal gøre er at gå finde nogen, der har, og få dem til at deltage i dit projekt. Disse dage, vil alle forventer mindst dit projekt kildekode til at være under versionskontrol, og sandsynligvis ikke vil tage projektet alvorligt, hvis den ikke bruger version kontrol med mindst minimal kompetence.

Grunden version kontrol er så universel, er, at det hjælper med stort set alle aspekter af at køre et projekt: inter-developer kommunikation, release management, bug management, code stabilitet og eksperimentelle udviklingsindsats og tildeling og godkendelse af ændringer ved bestemte udviklere. Den version styresystem giver en central koordinerende kraft blandt alle disse områder. Kernen i versionsstyring er Change Management: identifikation af hver diskret ændring, der foretages til projektets filer, kommentering enhver ændring med metadata ligesom ændringen dato og forfatter, og derefter afspilning af disse kendsgerninger til hvem spørger, uanset i hvilken måde de spørger. Det er en kommunikations-mekanisme, hvor en ændring er den grundlæggende enhed af oplysninger.

Dette afsnit omfatter ikke diskutere alle aspekter af bruger en version styresystem. Det er så altomfattende, at det skal behandles topisk i hele bogen. Her vil vi koncentrere os om at vælge og oprette en version control system på en måde, der vil fremme kooperativ udvikling nede ad vejen.

Version Control Ordforråd

Denne bog kan ikke lære dig, hvordan du bruger version kontrol, hvis du aldrig har brugt det før, men det ville være umuligt at diskutere emnet uden et par nøglebegreber. Disse vilkår er nyttige uafhængigt af nogen særlig version control system: de er de grundlæggende navneord og verber af netværksbaserede samarbejde, og vil blive anvendt generisk i resten af denne bog. Selv om der var ingen version kontrolsystemer i verden, vil problemet med forandringsledelse tilbage, og disse ord giver os et sprog til at tale om dette problem koncist.

«Version» Versus «Revision»

Ordet versionen er undertiden bruges som et synonym for «revision», men jeg vil ikke bruge det på den måde i denne bog, fordi det er for nemt forveksles med «version» i den forstand af en version af et stykke software, der er , frigivelse eller udgave nummer, som i «Version 1,0″. Men da udtrykket «version control» er allerede standard, vil jeg fortsætte med at bruge det som et synonym for «revision kontrol» og «change control».

forpligte
For at gøre en ændring af projektet, mere formelt, at gemme en ændring i den version kontrol database på en sådan måde, at det kan indarbejdes i fremtidige versioner af projektet. «Commit» kan anvendes som et verbum eller et substantiv. Som et navneord, er det væsentlige synonymt med «forandring». For eksempel: «Jeg har lige begået en rettelse til servernedbrud bug folk har rapporteret om Mac OS X. Jay, kunne du venligst gennemgå begå og kontrollere, at jeg ikke misbruger måleren der?»

log besked
Lidt kommentar knyttet til hver commit, der beskriver karakteren og formålet med commit. Logmeddelelser er blandt de vigtigste dokumenter i ethvert projekt: de er broen mellem det meget teknisk sprog af individuelle kodeændringer og mere bruger-orienterede sprog af funktioner, fejlrettelser, og projektets fremdrift. Senere i dette afsnit, vil vi se på måder at distribuere logmeddelelser til de relevante målgrupper; også, afsnittet «Kodificering Tradition» i kapitel 6, Communications diskuterer måder at tilskynde bidragydere til skrive præcise og brugbare logmeddelelser.

opdatere
Bede om, at andres ændringer (begår) inkorporeres i din lokale kopi af projektet, det er, at bringe din kopi «up-to-date». Dette er en meget almindelig operation, de fleste udviklere opdatere deres kode flere gange om dagen, så de ved, de kører nogenlunde det samme de andre udviklere kører, og så hvis de ser en fejl, kan de være temmelig sikker på det er ikke fastsat allerede. For eksempel: «. Hey, jeg bemærkede indeksering koden altid droppe den sidste byte Er det en ny fejl?» «Ja, men det var fastsat i sidste uge-prøve at opdatere, skal det gå væk.»

repository
En database, hvori ændringer er lagret. Nogle versionskontrolsystemer er samlet: der er en enkelt, master repository, som gemmer alle ændringer i projektet. Andre er decentraliseret hver udvikler har sin egen repository, og ændringer kan byttes frem og tilbage mellem repositories vilkårligt. Den version kontrol system holder styr på afhængigheder mellem ændringer, og når det er tid til at lave en udgivelse, der er et særligt sæt af ændringer godkendt til løsladelse. Spørgsmålet om, hvorvidt centralt eller decentralt er bedre er en af de varige hellige krige softwareudvikling, forsøge ikke at falde i fælden med at skændes om det på dit projekt lister.

checkout
Processen med at få en kopi af projektet fra et arkiv. En kassen giver normalt et mappetræ kaldes en «fungerende kopi» (se nedenfor), hvorfra ændringer kan begås tilbage til den oprindelige repository. I nogle decentrale versionskontrolsystemer, er hver arbejdsdag kopiere sig selv et depot, og ændringer kan skubbes ud til (eller trækkes ind i) enhver arkiv, der er villige til at acceptere dem.

arbejdskopi
En udvikler private mappetræ der indeholder projektets kildekodefiler, og muligvis dens websider eller andre dokumenter. En arbejdsgruppe kopi indeholder også en lille smule af metadata forvaltes af version control system, fortæller fungerende kopi hvilken repository det kommer fra, hvad «revisioner» (se nedenfor) af filerne er til stede, osv. Generelt hver udvikler har sin egen arbejdskopi, hvor han gør og tester ændringer, og hvorfra han begår.

revision, ændring, ændrings-
En «revision» er normalt en specifik inkarnation af en bestemt fil eller mappe. For eksempel dette, hvis projektet starter ud med revision 6 i filen F, og derefter nogen begår en ændring F, producerer revision 7 i F. Nogle systemer bruger også «revision», «forandring» eller «ændrings» at henvise til et sæt ændringer begået sammen som én begrebsmæssig enhed.

Disse vilkår lejlighedsvis har forskellige tekniske betydninger i forskellige versionskontrolsystemer, men den generelle idé er altid det samme: de giver en måde at tale netop om nøjagtige tidspunkter i historien for en fil eller et sæt filer (sige, umiddelbart før og efter en fejl er rettet). For eksempel: «Åh ja, hun fast, at i revision 10″ eller «Hun er fastsat, at der i revision 10 i foo.c.»

Når man taler om en fil eller samling af filer uden at angive en bestemt revision, er det almindeligt antaget, at man betyder den seneste revision (r) til rådighed.

diff
En tekstlige en ændring. En diff viser, hvilke linjer blev ændret, og hvordan, samt et par linjer af omgivende kontekst på hver side. En udvikler, der er allerede er bekendt med noget kode kan normalt læse en diff mod denne kode og forstå, hvad ændringen gjorde, og endda spot bugs.

tag
En etiket for en bestemt samling af filer på bestemte revisioner. Tags er normalt bruges til at bevare interessante snapshots af projektet. For eksempel er et tag som regel lavet for hver enkelt offentlig udgivelse, så man kan få, direkte fra version control system, den nøjagtige sæt af filer / revisioner omfatter denne frigivelse. Fælles mærkenavne er ting som Release_1_0, Delivery_00456 osv.

gren
En kopi af projektet, under versionskontrol men isolerede, således at ændringer af filialen ikke påvirker resten af projektet, og vice versa, undtagen når ændringerne er bevidst «fusionerede» fra den ene side til den anden (se nedenfor ). Filialer er også kendt som «linjer af udvikling». Selv når et projekt har ingen eksplicitte grene, er udviklingen stadig anses for at ske på den «vigtigste gren», også kendt som «main line» eller «trunk».

Grene har en måde at isolere forskellige udviklingslinier fra hinanden. For eksempel kan en gren anvendes til eksperimentel udvikling, som ville være for destabiliserende for hovedstammen. Eller omvendt, kan en filial bruges som et sted for at stabilisere en ny udgivelse. Under release processen, vil regelmæssig udvikling fortsætter uafbrudt i de vigtigste gren af depotet, i mellemtiden, om løsladelse gren, ingen ændringer tillades bortset fra dem, der er godkendt af frigivelsen ledere. På den måde gør en frigivelse behøver ikke forstyrre igangværende udviklingsarbejde. Se afsnittet «Brug filialer for at undgå flaskehalse» senere i dette kapitel for en mere detaljeret diskussion af forgrening.

fusionere (alias port)
Hvis du vil flytte et skift fra en gren til en anden. Dette omfatter sammenlægning fra hovedstammen til en anden gren, eller vice versa. I virkeligheden er de de mest almindelige typer af fusionerer, det er sjældent at overføre en ændring mellem to ikke-hovedgrene. Se afsnittet «Singularity af information» for flere oplysninger om denne form for sammenlægning.

«Sammenflet» har en anden, beslægtet betydning: Det er, hvad version control system gør, når det ser, at to personer har ændret den samme fil, men i ikke-overlappende måder. Da de to ændringer ikke forstyrrer hinanden, når den ene af de folk opdaterer deres kopi af filen (som allerede indeholder deres egne ændringer), vil den andens ændringer automatisk blive fusioneret i. Det er meget almindeligt, især på projekter, hvor flere mennesker er hacking på den samme kode. Når to forskellige ændringer gør overlap, er resultatet en «konflikt», se nedenfor.

konflikt
Hvad sker der, når to mennesker forsøger at lave forskellige ændringer til det samme sted i koden. Alle versionskontrolsystemer registrerer automatisk konflikter, og underrette mindst én af de mennesker, der er involveret, at deres ændringer er i konflikt med en andens. Det er så op til, at menneskets at løse konflikten, og at kommunikere, at beslutning til version control system.

lås
En måde at erklære en eksklusiv hensigt at ændre en bestemt fil eller mappe. For eksempel, «Jeg kan ikke begå eventuelle ændringer af websiderne lige nu. Det ser ud til Alfred har dem alle låst, mens han løser deres baggrundsbilleder.» Ikke alle versionskontrolsystemer tilbyder endda mulighed for at låse, og af dem, der gør, alt ikke kræve låsefunktion, der skal bruges. Dette skyldes parallel, samtidig udvikling er normen, og låse folk ud af filer er (normalt) i modsætning til dette ideal.

Version kontrolsystemer, der kræver låsning at gøre forpligter siges at bruge lock-modify-unlock model. Dem, der ikke siges at anvende copy-modificere-merge model. En fremragende dybdegående forklaring og sammenligning af de to modeller kan findes på http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html. I almindelighed er det kopi-modify-merge model bedre for open source-udvikling, og alle versionskontrolsystemer diskuteret i denne bog støtte, at model.

Valg af en version Control System

Mens dette skrives, er de to mest populære version kontrolsystemer i den gratis software verden Concurrent Versions System (CVS, http://www.cvshome.org/) og Subversion (SVN, http://subversion.tigris.org/ ).

CVS har eksisteret i lang tid. De fleste erfarne udviklere er allerede bekendt med det, det gør mere eller mindre, hvad du har brug for, og da det har været populært i lang tid, vil du sandsynligvis ikke ender i nogen lange diskussioner om, hvorvidt det var det rigtige valg. CVS har nogle ulemper, dog. Den giver ikke en nem måde at referere til multi-filændringer, det giver dig ikke ret til at omdøbe eller kopiere filer under versionskontrol (så hvis du har brug for at reorganisere din kode træ efter start af projektet, kan det være en reel smerte), og det har dårlig fusionerende støtte; det ikke håndtere store filer eller binære filer meget godt, og nogle operationer er langsom, når et stort antal filer er involveret.

Ingen af CVS har skønhedsfejl er dødelig, og det er stadig meget populært. I de senere år senere Subversion har vinder frem, især i nyere projekter. [15]. Hvis du starter et nyt projekt, jeg anbefale Subversion.

På den anden side, da jeg er involveret i Subversion projekt måske min objektivitet rimelighed drages i tvivl. Og i de sidste par år er en række nye open source-version kontrolsystemer er dukket op. Bilag A, gratis version Control Systems viser alle dem, jeg kender, i hård rækkefølge af popularitet. Da listen gør det klart, kunne træffes beslutning om en version styresystem nemt blive en livslang forskningsprojekt. Muligvis vil du blive skånet den beslutning, fordi det vil blive gjort for dig af din hosting site. Men hvis du skal vælge, rådføre sig med dine andre udviklere, så spørg rundt for at se, hvad folk har erfaring med, og vælg derefter en og køre med det. Enhver stabil, klar til produktion version control system vil gøre, og du behøver ikke at bekymre dig for meget om at gøre en drastisk forkert beslutning. Hvis du simpelthen ikke kan gøre op dit sind, så gå med Subversion. Det er forholdsvis let at lære, og vil sandsynligvis fortsat være en standard for mindst et par år.

Brug af Version Control System

Anbefalingerne i dette afsnit er ikke rettet mod en bestemt version control system, og bør være enkel at gennemføre i nogen af dem. Rådfør dig specifikt system dokumentation for yderligere oplysninger.

Version alt

Hold ikke kun dit projekt kildekode under versionskontrol, men også dets hjemmeside, dokumentation, FAQ, design noter, og alt andet, folk måske ønsker at redigere. Hold dem lige ved siden af kildekoden, i samme repository træ. Enhver oplysning værd at skrive ned er værd versionering det vil sige, enhver oplysning, der kunne ændre. Ting, der ikke ændrer skal arkiveres, ikke versioneres. For eksempel, en e-mail, når udstationeret, ikke ændres, derfor ville versionering det ikke mening (medmindre det bliver en del af nogle større, dynamisk dokument).

Årsagen versionsstyring alt sammen på ét sted er vigtigt, er, så folk kun behøver at lære en mekanisme til at sende ændringerne. Ofte en bidragyder vil starte ud ved at gøre redigeringer de websider eller dokumentation, og flytte til små kode bidrag senere, f.eks. Når projektet bruger det samme system for alle slags indlæg, folk kun behøver at lære reb gang. Versionering alt sammen betyder også, at nye funktioner kan begås sammen med deres dokumentation opdateringer, at forgrening koden forgrene dokumentationen også, etc.

Opbevar ikke genererede filer under versionskontrol. De er ikke rigtig redigerbare data, eftersom de er fremstillet af programmering fra andre filer. For eksempel oprette nogle build-systemer konfigurere baseret på skabelonen configure.in. At foretage en ændring til configure, ville man redigere configure.in og derefter regenerere, og dermed kun skabelonen configure.in er en «redigerbar fil.» Bare version skabeloner-Hvis du version er resultatet filerne så godt, vil folk uundgåeligt glemmer at regenerere, når de begår en ændring i en skabelon, og de resulterende uoverensstemmelser vil forårsage nogen ende af forvirring. [16]

Reglen om, at alle redigerbare data skal opbevares under versionskontrol har en uheldig undtagelse: bug tracker. Bug databaser holde masser af redigerbare data, men af tekniske årsager kan generelt ikke gemme disse data i de vigtigste version control system. (Nogle trackers har primitive versionering funktioner i deres egen, men er uafhængige af projektets hovedarkivet.)

Browsability

Projektets opbevaringssted skal være gennemses på internettet. Dette betyder ikke kun evnen til at se de seneste revisioner af projektets filer, men at gå tilbage i tiden og se på tidligere revisioner, se forskellene mellem revisioner, læse log beskeder til udvalgte ændringer mv

Browsability er vigtigt, fordi det er en let portal til projektdata. Er lageret ikke kan ses via en webbrowser, så en person ønsker at inspicere en bestemt fil (sige, for at se om en bestemt bugfix havde gjort det i koden) skal først installere version control klient software lokalt, som kunne vise deres simpel forespørgsel fra en to-minutters opgave i en halv time eller længere opgave.

Browsability indebærer også kanoniske webadresser til visning specifikke revisioner af filer, og til visning af seneste revision på et givet tidspunkt. Dette kan være meget nyttigt i tekniske drøftelser, eller når pege folk til dokumentation. For eksempel, «, For bug retningslinjer for forvaltning, se community-guide/index.html filen i din arbejdskopi» i stedet for at sige, man kan sige «For bug retningslinjer for forvaltning, se http://subversion.apache.org/docs/ community-guide /, «at give en webadresse, der peger altid til den seneste revision af den community-guides/index.html fil. Webadressen er bedre, fordi det er helt entydig, og undgår spørgsmålet om, hvorvidt modtageren har en up-to-date arbejder kopi.

Nogle versionsstyring systemer kommer med indbygget repository-browsing mekanismer, mens andre er afhængige af tredjeparts værktøjer til at gøre det. Tre sådanne værktøjer er ViewVC (http://viewvc.org/), CVSWeb (http://www.freebsd.org/projects/cvsweb.html), og WebSVN (http://websvn.tigris.org/). De første værker med både CVS og Subversion, den anden med CVS kun, og den tredje med Subversion kun.

Forpligt emails

Hver commit til lageret skal generere en e-mail der viser hvem der foretog ændringen, da de gjorde det, hvilke filer og mapper ændret, og hvordan de ændres. E-mailen skal gå til en særlig postliste helliget til at begå e-mails, adskilt fra de postlister som mennesker post. Udviklere og andre interesserede bør tilskyndes til at abonnere på begår listen, da det er den mest effektive måde at følge med i hvad der sker i projektet på kodeniveau. Bortset fra de åbenlyse tekniske fordele ved peer review (se afsnittet «Praksis Conspicuous Code Review»), begå emails medvirke til at skabe en følelse af fællesskab, fordi de etablerer et fælles miljø, hvor folk kan reagere på begivenheder (begår), at de kender er synlige for andre.

De nærmere af etablering begå emails vil variere afhængigt af din version control system, men normalt er der et script eller andet emballeret facilitet til at gøre det. Hvis du har problemer med at finde det, så prøv at finde dokumentation på kroge, især en post-commit hook, også kaldet loginfo krog i CVS. Post-begå kroge er en generel metode til at lancere automatiserede opgaver som svar på begår. Krogen er udløst af en individuel commit, fødes alle oplysninger om denne commit, og er derefter frit kan bruge disse oplysninger til at gøre noget-for eksempel, at sende en e-mail.

Med færdigpakkede begå e-mail systemer, kan du ønsker at ændre nogle af standardindstillingerne adfærd:

Nogle begå afsendere omfatter ikke de faktiske diffs i e-mailen, men i stedet give en URL for at se ændringen på internettet ved hjælp lageret browsing system. Mens det er godt at angive webadressen, så ændringen kan blive henvist til senere, er det også meget vigtigt, at commit email omfatter diffs selv. Læsning email er allerede en del af folks rutine, så hvis indholdet af ændringen er synlig lige der i commit e-mail, vil udviklere gennemgå begå på stedet, uden at forlade deres post læser. Hvis de er nødt til at klikke på en URL til at gennemgå ændringen, vil de fleste ikke gøre det, fordi det kræver en ny handling i stedet for en fortsættelse af, hvad de allerede gør. Desuden, hvis korrekturlæseren ønsker at spørge noget om ændringen, er det langt lettere at ramme svar-med-tekst og blot anmærke citerede diff end det er at besøge en webside, og møjsommeligt cut-and-paste dele af diff fra web browser til e-mail-klient.

(Selvfølgelig, hvis diff er enorme, som når en stor mængde ny kode er blevet tilføjet til lageret, så giver det mening at udelade diff og tilbyder kun URL’en. Fleste begå afsendere kan gøre denne form for begrænsning automatisk . Hvis din ikke kan, så er det stadig bedre at omfatte diffs, og leve med lejlighedsvis enorme e-mail, end at forlade diffs slukket helt. Praktisk gennemgang og kommentering er en hjørnesten i kooperativ udvikling, alt for vigtigt til at undvære.)

De begå emails bør sætte deres svar til header til den regelmæssige udvikling liste, ikke commit e-mail liste. Det vil sige, når nogen gennemgår en commit og skriver et svar, bør deres svar automatisk blive rettet mod den menneskelige udvikling listen, hvor tekniske problemer normalt diskuteret. Der er et par grunde til. Først, du ønsker at holde alle tekniske diskussion om én liste, fordi det er, hvor folk forventer, at det vil ske, og fordi den måde er der kun én arkiv for at søge. For det andet kan der være interesserede parter ikke abonnerer på den commit e-mail liste. For det tredje commit e-mail liste annoncerer sig selv som en tjeneste for at se begår, ikke for at se begår og lejlighedsvis tekniske drøftelser. De, der abonnerer på den commit e-mail liste ikke tilmelde dig noget, men begå emails, sende dem andet materiale via denne liste ville krænke en implicit kontrakt. Fjerde folk skriver ofte programmer, der læser den commit e-mail liste og bearbejde resultaterne (til visning på en webside, for eksempel). Disse programmer er forberedt på at håndtere konsekvent-formaterede begå e-mails, men ikke er i uoverensstemmelse menneske-skriftlige mails.

Bemærk, at dette råd til at indstille Svar til ikke i strid med anbefalingerne i afsnittet kaldet «The Great Svar til debatten» tidligere i dette kapitel. Det er altid okay for afsenderen af en besked for at indstille Svar til. I dette tilfælde er afsenderen den version styresystem selv, og det sætter Svar til for at indikere, at et passende sted for svar er udviklingen mailingliste, ikke commit liste.

CIA: En standardiseret Change Publication Mechanism

Begå mails er ikke den eneste måde at udbrede forandringer nyheder. Du kan også installere CIA (http://cia.vc/), en real-time begå statistik nyhedslæser og distributør. Den mest populære brug af CIA, er at sende begå meddelelser til IRC-kanaler, så folk er logget ind disse kanaler ser begår sker i realtid. Selv om noget mindre teknisk nytte end begå e-mails, da observatørerne måske eller måske ikke være omkring, når en commit meddelelse popper op i IRC, er denne teknik af stor samfundsmæssig nytte. Folk får følelsen af at være en del af noget levende og aktiv, og føler, at de kan se fremskridt, der er gjort lige foran deres øjne. Og fordi de meddelelser vises i et fælles rum, folk i chatten ofte reagere i realtid, gennemgår begå og kommentere den på stedet.

Den måde CIA værker er, at du påberåbe sig sin anmelderen program fra din post-commit hook. Anmelderen formaterer commit oplysninger i en XML-meddelelse, som den sender til en central server (typisk cia.vi). Denne server derefter distribuerer commit oplysninger til andre fora.

CIA kan også konfigureres til at sende ud RSS-feeds. Se dokumentationen på http://cia.vc/ for yderligere oplysninger.

Hvis du vil se et eksempel på CIA i aktion, skal du pege din IRC klient på irc.freenode.net, kanal # begår, som viser aktivitet på tværs af alle de projekter, CIA ser.

Brug grene til at undgå flaskehalse

Ikke-ekspert versionshåndteringssystemer brugere er nogle gange lidt bange for forgrening og fletning. Dette er formentlig en bivirkning af CVS popularitet: CVS grænseflade til forgrening og fletning er lidt ulogisk, så mange mennesker har lært at undgå disse operationer helt.

Hvis du er blandt de mennesker, løse lige nu at erobre enhver frygt du måtte have, og tage sig tid til at lære at gøre forgrening og sammenlægning. De er ikke vanskelige operationer, når man vænner sig til dem, og de bliver stadig vigtigere som et projekt erhverver flere udviklere.

Filialer er værdifulde, fordi de vender en knap ressource-arbejde rum i projektets code-til en rigelig én. Normalt alle udviklere arbejder sammen i samme sandkasse, konstruere samme slot. Når nogen ønsker at tilføje en ny vindebro, men kan ikke overbevise alle andre, at det ville være en forbedring, forgrening gør det muligt for hende at gå til en isoleret hjørne og prøve det. Hvis indsatsen lykkes, kan hun invitere de andre udviklere til at undersøge resultatet. Hvis alle enige om, at resultatet er godt, kan de fortælle den version kontrolsystem til at flytte («merge») vindebroen fra filialen slot over til den vigtigste slot.

Det er nemt at se, hvordan denne evne hjælper kollaborativ udvikling. Folk har brug for frihed til at prøve nye ting uden at føle sig som de støder sammen med andres arbejde. Lige så vigtigt er, at der er tidspunkter, hvor kode for at blive isoleret fra den sædvanlige udvikling kundeafgangen, for at få en bug fast eller en release stabiliseret (se afsnittet «Stabiliserende en Release» og afsnittet «vedligeholder flere release Lines» i Kapitel 7, Packaging, slipper, og Daily Udvikling) uden at bekymre sig om sporing et bevægeligt mål.

Brug grene rundhåndet og opmuntre andre til at bruge dem. Men også sørge for, at en given filial er kun aktiv for præcis så længe som nødvendigt. Hver aktiv filial er en lille dræn på fællesskabets opmærksomhed. Selv dem, der ikke arbejder i en filial stadig opretholde en perifer bevidsthed om, hvad der foregår i den. En sådan bevidsthed er ønskelig, selvfølgelig, og begår emails skal sendes ud for gren begår lige som for alle andre commit. Men filialer bør ikke være en mekanisme til at opdele udviklingen samfund. Med få undtagelser skulle det endelige mål for de fleste grene være at fusionere deres ændringer tilbage i hovedledningen og forsvinde.

Singularitet af oplysninger

Sammenfletning har en vigtig konsekvens: aldrig begå den samme ændring to gange. Det vil sige, hvis en given ændring indtaste den version kontrolsystem præcis én gang. Revisionen (eller et sæt af revisioner), hvor ændringen trådte er dens unikke identifikator fra da af. Hvis det skal anvendes til filialer andre end den, som det indgik, så det bør slås sammen fra sin oprindelige indgang til de andre destinationer, i modsætning til at begå en tekstuelt identisk ændring, som ville have den samme virkning i koden , men ville gøre nøjagtig bogføring og release management umulig.

De praktiske virkninger af dette råd er forskellige fra version control system til et andet. I nogle systemer er fusionerer særlige begivenheder, grundlæggende forskellige fra begår, og bære deres egen metadata med dem. I andre medlemsstater er resultatet af fusionerer begået på samme måde andre ændringer er engagerede, så det primære middel til at skelne en «fusionere begå» fra en «ny ændring commit» er i log-besked. I en sammenfletning log budskab, må du ikke gentage logmeddelelse af den oprindelige ændring. I stedet bare viser, at dette er en sammenfletning, og giv den identificerende revision af den oprindelige ændring, med højst en enkelt sætning resumé af sin virkning. Hvis nogen ønsker at se den fulde logmeddelelsen, bør hun kontakte den oprindelige revision.

Grunden er det vigtigt at undgå at gentage log budskab er, at logmeddelelser undertiden er redigeret efter de er blevet begået. Hvis en ændring log budskab blev gentaget ved hver sammenfletning destinationen, og selv om nogen redigeret den oprindelige meddelelse, ville hun stadig lade alle gentagelser ukorrigeret-som kun ville skabe forvirring ned af vejen.

Det samme princip gælder for at vende tilbage en forandring. Hvis en ændring trækkes tilbage fra koden, så logmeddelelse føres tilbage bør kun, at en specifik ændring (er) er ved at blive vendt, ikke beskrive den faktiske kode ændring, der skyldes reversion, idet semantik for ændring kan være afledt ved at læse den oprindelige logmeddelelsen og forandring. Selvfølgelig bør det reversion log budskab også oplyse årsagen til, at ændringen bliver vendt, men det bør ikke overlappe noget fra den oprindelige ændring log besked. Hvis det er muligt, skal du gå tilbage og redigere det oprindelige changes logmeddelelse at påpege, at det blev vendt.

Alt det ovenstående betyder, at du skal bruge en konsekvent syntaks for at henvise til revisioner. Dette er nyttigt, ikke kun i logmeddelelser, men i e-mails, bug tracker, og andre steder. Hvis du bruger CVS, vil jeg foreslå «sti / til / fil / in / projekt / træ: REV», hvor REV er en CVS revision nummer som «1,76″. Hvis du bruger Subversion, standarden syntaks for revision 1729 er «r1729″ (filstier er ikke nødvendig, fordi Subversion anvender globale revisionsnumre). I andre systemer, er der normalt en standard syntaks til ekspression af ændrings-navn. Uanset den rette syntaks er for dit system, tilskynde folk til at bruge det, når der henvises til ændringer. Konsekvent udtryk for forandring navne gør projekt bogholderi meget lettere (som vi vil se i kapitel 6, kommunikation og kapitel 7, Packaging, slipper, og Daily Development), og da en stor del af bogholderiet vil ske ved frivillige, det skal være så let som muligt.

Se også afsnittet «udgivelser og daglige udvikling» i kapitel 7, Packaging, slipper, og Daily Development.

Tilladelse

De fleste versionsstyring systemer tilbyder en funktion, hvor visse mennesker kan tillades eller bortfalde fra at begå i bestemte delområder af lageret. Efter princippet om, at når udleveret en hammer, folk begynde at kigge rundt til negle, mange projekter bruger denne funktion med løssluppenhed, omhyggeligt hvorved folk adgang til netop de områder, hvor de er blevet godkendt til at begå, og sørge for at de ikke kan begå andre steder . (Se afsnittet «committere» i kapitel 8, adm. Volunteers for, hvordan projekter beslutte, hvem der kan begå hvor.)

Der er sandsynligvis lidt skade sket ved at udøve en sådan stram styring, men en mere afslappet politik er også fint. Nogle projekter blot bruge en ære system: når en person får commit adgang, selv for et delområde af lageret, hvad de rent faktisk modtager, er en adgangskode, der giver dem mulighed for at begå overalt i projektet. De er bare bedt om at holde deres begår i deres område. Husk, at der ikke er nogen reel risiko her: i et aktivt projekt, forpligter alle er revideret alligevel. Hvis nogen begår hvor de er ikke meningen, at, andre vil bemærke det og sige noget. Hvis en ændring skal fortrydes, det er simpelt nok-alt er under versionskontrol alligevel, så bare vende tilbage.

Der er flere fordele ved at den afslappede fremgangsmåde. Først som udviklere ekspandere til andre områder (som de normalt vil, hvis de bo med projektet), er der ingen administrative omkostninger at give dem bredere privilegier. Når beslutningen er foretaget, kan den person, der bare begynde at begå i det nye område med det samme.

For det andet kan ekspansion ske på en mere finkornet måde. Generelt vil en committer i område X, der ønsker at udvide til område Y begynde at sende patches mod Y og beder til gennemgang. Hvis en person, der allerede har begå adgang til område Y ser sådan et plaster og godkender det, kan de bare fortælle indsenderen at begå ændringen direkte (med angivelse af anmelder / godkender ‘s navn i logmeddelelse, naturligvis). På den måde vil begå komme fra den person, der rent faktisk skrev ændringen, hvilket er at foretrække både ud fra en information management synspunkt og ud fra et godskrivning synspunkt.

Sidst, og måske vigtigst, ved hjælp af ære system tilskynder en atmosfære af tillid og gensidig respekt. Give nogen begå adgang til et underdomæne er en erklæring om deres tekniske beredskab-den siger: «. Vi ser du har ekspertise til at foretage begår i et bestemt domæne, så go for it» Men at pålægge strenge godkendelsesprocedurer kontrol siger: «Ikke alene er vi påstår en grænse for din ekspertise, vi er også lidt mistænksom om dine hensigter.» Det er ikke den slags udsagn, som du ønsker at gøre, hvis du kan undgå det. At bringe nogen ind i projektet som en committer er en mulighed for at indlede dem i en cirkel af gensidig tillid. En god måde at gøre det på er at give dem mere magt, end de er formodes at bruge, så informere dem om, at det er op til dem at holde sig inden for de fastsatte grænser.

Det Subversion projektet har opereret på ære systemet vej for mere end fire år, med 33 fulde og 43 partielle committere som dette skrives. Den eneste forskel at systemet faktisk håndhæver er mellem committere og ikke-committere, yderligere underinddelinger vedligeholdes udelukkende af mennesker. Men vi har aldrig haft et problem med nogen bevidst begår uden for deres domæne. En eller to gange at der har været en uskyldig misforståelse om omfanget af en persons begå privilegier, men det har altid blevet løst hurtigt og venligt.

Det er klart, i situationer, hvor selvjustits er upraktisk, skal du stole på hårde tilladelse kontrol. Men sådanne situationer er sjældne. Selv når der er millioner af linjer kode og hundredvis eller tusindvis af udviklere, en forpligte sig til en given kode modul bør stadig undersøges af dem, der arbejder på dette modul, og de kan genkende, hvis nogen begået der, som ikke skulle. Hvis regelmæssig commit revision ikke sker, så projektet har større problemer at slås med end godkendelsesordningen alligevel.

Sammenfattende må ikke bruge for meget tid at pille med den version kontrol godkendelsessystem, medmindre du har en særlig grund til. Det vil normalt ikke bringe meget håndgribelig fordel, og der er fordele ved at forlade sig på de menneskelige kontrol i stedet.

Intet af dette bør forstås således, at de restriktioner, selv er uden betydning, selvfølgelig. Det ville være dårligt for et projekt, der skal tilskynde folk til at begå i områder, hvor de ikke er kvalificeret. Endvidere i mange projekter, har fuld (ubegrænset) commit adgang til en særlig status: det indebærer stemmeret på projekt-dækkende spørgsmål. Denne politiske aspekt af commit adgang diskuteres mere i afsnittet «Hvem Stemmer?» I kapitel 4, sociale og politiske infrastruktur.

Bug Tracker

Bug tracking er et bredt emne, forskellige aspekter af det diskuteres i hele denne bog. Her vil jeg prøve at koncentrere hovedsagelig på opsætning og tekniske overvejelser, men for at komme til dem, vi er nødt til at starte med et politisk spørgsmål: præcis, hvad slags oplysninger skal opbevares i en bug tracker?

Udtrykket bug tracker er vildledende. Bug tracking systemer er også ofte bruges til at spore nye funktion anmodninger, engangs-opgaver, uopfordret patches-virkelig noget, der har tydelig begyndelse og slutning stater, med valgfri overgang hedder i mellem, og der tilfalder information i hele dens levetid. Af denne grund er bug trackers også kaldet udstede trackers, defekt trackers, artefakt trackers, anmode trackers, problemer billet-systemer osv. Se tillæg B, Free Bug Trackers til en liste over software.

I denne bog, vil jeg fortsætte med at bruge «bug tracker» for den software, der gør det muligt at spore, fordi det er hvad de fleste mennesker kalder det, men vil bruge spørgsmål til at henvise til et enkelt element i bug tracker database. Dette giver os mulighed for at skelne mellem den adfærd eller dårlig opførsel at brugeren stødt (dvs. den bug selv), og trackeren rekord af fejlen opdagelse, diagnose, og i sidste ende løses. Husk, at selv om de fleste spørgsmål er om faktiske fejl, kan spørgsmål bruges til at spore andre typer opgaver også.

Den klassiske spørgsmål livscyklus ser sådan ud:

Nogen filer spørgsmålet. De giver en sammenfatning, en indledende beskrivelse (herunder en reproduktion opskrift, hvis det er relevant, se afsnittet kaldet «Behandl Hver bruger som en potentiel Frivillige» i kapitel 8, adm. Frivillige til, hvordan man fremme gode fejlrapporter), og uanset andre oplysninger tracker beder om. Den person, som indgiver problemet kan være totalt ukendte for projekt-fejlrapporter og Funktionsanmodninger er så tilbøjelige til at komme fra brugeren samfund som fra udviklerne.

Når indleveret, problemet er i det, der kaldes en åben tilstand. Fordi der ikke er blevet taget endnu nogle trackers også mærke det som ubekræftet og unstarted / eller. Det er ikke tildelt nogen, eller i nogle systemer, er det tildelt en falsk bruger til at repræsentere manglen på reelle stævnemøde. På dette punkt er det i en bedrift område: Spørgsmålet er blevet registreret, men endnu ikke integreret i projektet bevidsthed.

Andre læser spørgsmålet, tilføje kommentarer til det, og måske spørge den oprindelige filer for afklaring på visse punkter.

Fejlen bliver gengivet. Det kan være det vigtigste øjeblik i dets livscyklus. Selvom fejlen ikke er faktisk fastsat endnu, det faktum at nogen udover den oprindelige filer var i stand til at gøre det ske beviser, at det er ægte, og ikke mindre vigtigt, bekræfter over for den oprindelige filer, at de har bidraget til projektet ved at rapportere en reel fejl.

Fejlen bliver diagnosticeret: dens årsag er identificeret, og hvis det er muligt, den indsats, der kræves for at løse det skønnes. Sørg for, at disse ting bliver optaget i spørgsmålet, hvis den person, der diagnosticeres fejlen pludselig er nødt til at træde væk fra projektet i et stykke tid (som ofte kan ske med frivillige udviklere), bør en anden kunne samle op, hvor hun slap .

I denne fase, eller undertiden den foregående, en udvikler kan «tage ejerskab» af spørgsmålet og tildele den til sig selv (afsnittet «Der skal klart skelnes mellem undersøgelse og opgave» i kapitel 8, adm. Frivillige undersøger tildelingsprocessen mere detaljeret ). Spørgsmålet prioritet kan også indstilles på dette stadium. For eksempel, hvis det er så alvorligt, at det bør forsinke den næste udgivelse denne omstændighed skal identificeres tidligt, og trackeren skal have en måde at bemærke det.

Spørgsmålet bliver planlagt til opløsning. Planlægning er ikke nødvendigvis ensbetydende navngive en dato for, hvornår det vil blive rettet. Nogle gange er det bare betyder at afgøre, hvilken fremtidig frigivelse (ikke nødvendigvis den næste) fejlen bør fastsættes ved, eller beslutte, at det ikke behøver blokere nogen særlig udgivelse. Planlægning kan også undværes, hvis fejlen er hurtig at lave.

Fejlen bliver rettet (eller opgaven fuldført, eller plasteret, eller hvad). Ændringen eller sæt af ændringer, der fastsatte det bør registreres i en kommentar i spørgsmålet, hvorefter sagen er lukket og / eller markeret som løst.

Der er nogle almindelige varianter af denne livscyklus. Undertiden et problem lukkes meget snart efter at være blevet indgivet, fordi det viser sig ikke at være en fejl på alle, men snarere en misforståelse hos brugeren. Som et projekt får flere brugere, flere og flere sådanne ugyldige spørgsmål vil komme ind, og udviklere vil lukke dem med de stadigt kort for hovedet svar. Prøv at sikre sig mod sidstnævnte tendens. Det gør ingen noget godt, som den enkelte bruger i hvert enkelt tilfælde er ikke ansvarlig for alle de tidligere ugyldige spørgsmål den statistiske tendens ses kun fra udviklernes synspunkt, ikke brugerens. (I afsnittet kaldet «Pre-Filtrering af Bug Tracker» senere i dette kapitel, vil vi se på teknikker til at reducere antallet af ugyldige spørgsmål.) Også, hvis forskellige brugere oplever den samme misforståelse igen og igen, kan det betyde dette aspekt af software skal redesignet. Denne form for mønster er nemmest at lægge mærke til, når der er et problem Manager overvåger fejldatabase, se afsnittet «Issue Manager» i kapitel 8, Managing Volunteers.

En anden almindelig livscyklus variation er, at emnet skal lukkes som en dublet snart efter Trin 1. En kopi er, når nogen filer et problem, der allerede er kendt af projektet. Dubletter er ikke begrænset til åbne spørgsmål: det er muligt for en fejl at komme tilbage efter at have været fast (dette er kendt som en regression), i hvilket tilfælde den foretrukne kursus er normalt at genåbne den oprindelige emission og lukke eventuelle nye rapporter som dubletter af den oprindelige. Fejlsporingssystemet skal holde styr på dette forhold bidirektionelt, således at reproduktion oplysninger i dubletterne er til rådighed for den oprindelige emission og vice versa.

En tredje variation er for udviklerne at lukke spørgsmålet, tænker de har rettet det, kun at have den originale reporter afvise rettelsen og åbne den igen. Dette er normalt, fordi udviklerne simpelthen ikke har adgang til miljøet er nødvendige for at genskabe fejlen, eller fordi de ikke teste rettelsen ved hjælp af nøjagtig samme reproduktion opskrift som reporter.

Bortset fra disse forskelle, kan der være andre små detaljer af livscyklussen, som variere efter tracking software. Men den grundlæggende form er den samme, og mens livscyklus selv ikke er specifik for open source software, det har konsekvenser for, hvordan open source-projekter anvender deres bug trackers.

Som trin 1 indebærer, trackeren er lige så meget et offentligt ansigt af projektet, da postlister eller websider. Enhver kan indgive et problem, kan man se på et problem, og alle kan gennemse listen over aktuelt åbne spørgsmål. Det følger heraf, at du aldrig vide, hvor mange mennesker der venter på at se fremskridt på en given problemstilling. Mens størrelsen og dygtighed af udviklingen samfund begrænser den hastighed, hvormed spørgsmål kan løses, skal projektet i det mindste forsøge at anerkende hvert nummer det øjeblik ser det ud til. Selv om problemet dvæler et stykke tid, en reaktion tilskynder reporter til at blive involveret, fordi hun føler, at et menneske har registreret, hvad hun har gjort (husk at indgive et problem omfatter normalt en større indsats end fx udstationering en e-mail). Desuden, når et problem er set af en udvikler, det kommer ind i projektets bevidsthed, i den forstand, at bygherren kan være på udkig efter andre forekomster af problemet, kan tale om det med andre udviklere, osv.

Behovet for rettidige reaktioner indebærer to ting:

• Trackeren skal være tilsluttet en postliste, således at alle ændringer til et spørgsmål, herunder dens oprindelige ansøgning, får en mail til at gå ud at beskrive, hvad der skete. Denne mailingliste er sædvanligvis forskellig fra den almindelige udvikling liste, da ikke alle udviklere vil måske modtage automatiserede bug mails, men (ligesom med begå mails) Reply-til header skal indstilles til udviklingen postliste.
• Formularen til arkivering spørgsmål bør fange reporter-mail-adresse, så hun kan kontaktes for yderligere oplysninger. (Det bør imidlertid ikke kræve reporter-mail-adresse, som nogle mennesker foretrækker at rapportere problemer anonymt. Se afsnittet «Anonymitet og involvering» senere i dette kapitel for mere om betydningen af anonymitet.)

Interaktion med postlister

Sørg for, bug tracker ikke bliver til et diskussionsforum. Selv om det er vigtigt at opretholde en menneskelig tilstedeværelse i bug tracker, er det ikke fundamentalt egnet til real-time diskussion. Tænk på det snarere som et arkiveringssystem, en måde at organisere fakta og henvisninger til andre diskussioner, primært dem, der finder sted på postlister.

Der er to grunde til at foretage denne skelnen. For det første er bug trackeren er mere besværligt at bruge end de postlister (eller end real-time chat fora, for den sags skyld). Det er ikke fordi bug trackers har dårlig brugergrænseflade design, det er bare, at deres grænseflader er designet til at opfange og præsentere diskrete tilstande, ikke fritflydende diskussioner. For det andet, ikke alle, der bør inddrages i drøftelserne af en given problemstilling er nødvendigvis ser bug tracker. En del af god issue management (se afsnittet «Del styringsopgaver samt teknisk Tasks» i kapitel 8, adm. volontører) er at sørge for hvert emne bliver bragt til de rigtige folks opmærksomhed, i stedet for at alle udviklere til at overvåge alle spørgsmål. I afsnittet der hedder «ingen samtaler i Bug Tracker» i kapitel 6, Kommunikation, vil vi se på måder at sikre folk ikke ved et uheld vandlås diskussioner af passende fora og ind i bug tracker.

Nogle bug trackers kan overvåge postlister og automatisk logge alle e-mails, der er omkring et kendt problem. Typisk de gør dette ved at anerkende nummers identifikationsnummer i emnelinjen af mailen, som en del af en særlig streng, udviklere lærer at inkludere disse strenge i deres mails for at tiltrække den tracker varsel. Den bug tracker kan enten gemme hele e-mail, eller (endnu bedre) bare optage et link til posten i den almindelige postliste arkiv. Uanset hvad, dette er en meget nyttig funktion, hvis din tracker har det, skal du sørge både for at tænde den og minde folk til at drage fordel af det.

Pre-Filtrering af Bug Tracker

De fleste udstede databaser til sidst lider af samme problem: et knusende belastning af dobbelte eller ugyldige spørgsmål indgivet af velmenende, men uerfarne eller dårligt informeret brugere. Det første skridt i bekæmpelsen af denne tendens er normalt at sætte en iøjnefaldende meddelelse på forsiden af fejlen tracker, forklarer, hvordan du fortælle, hvis en fejl er virkelig en bug, hvordan man kan søge at se om den allerede er blevet indgivet, og endelig, hvordan til effektivt at rapportere det, hvis man stadig synes det er en ny fejl.

Dette vil reducere støjniveauet i et stykke tid, men da antallet af brugere stiger, vil problemet i sidste ende komme tilbage. Ingen enkelte bruger kan kritiseres for det. Hver enkelt er bare forsøger at bidrage til projektet trivsel, og selv om deres første fejlrapport er ikke nyttigt, du stadig ønsker at opmuntre dem til at blive involveret og fil bedre forhold i fremtiden. I mellemtiden, om projektet skal holde spørgsmålet databasen som fri for junk som muligt.

De to ting, der vil gøre mest for at undgå dette problem er: at sørge for der er folk, der ser den bug tracker, der har nok viden til at lukke spørgsmål som ugyldige eller duplikerer det øjeblik, de kommer ind, og kræver (eller stærkt opmuntrende) brugere til at bekræfte deres bugs med andre mennesker før arkivere dem i trackeren.

Den første teknik synes at anvendes universelt. Selv projekter med stort problem databaser (sige, Debian bug tracker på http://bugs.debian.org/, som indeholdt 315.929 spørgsmål som dette skrives) stadig arrangere ting, så nogen ser hvert nummer, der kommer i. Det kan være en anden person afhængigt af kategorien af spørgsmålet. For eksempel er Debian-projektet en samling af software-pakker, så Debian automatisk dirigerer hvert nummer til de relevante pakkevidligeholdere. Selvfølgelig kan brugerne undertiden misidentify et nummers kategori, med det resultat, at spørgsmålet er sendt til den forkerte person i første omgang, som derefter kan nødt til at omdirigere den. Men det vigtigste er, at byrden stadig er delt, uanset om brugeren gætter rigtigt eller forkert, når der fremsendes, er spørgsmålet watching stadig fordelt mere eller mindre ligeligt blandt udviklerne, så hvert spørgsmål er i stand til at modtage en rettidig reaktion.

Den anden teknik er mindre udbredt, sandsynligvis fordi det er sværere at automatisere. Grundtanken er, at hver ny emne bliver «buddied» ind i databasen. Når en bruger tror han har fundet et problem, bliver han bedt om at beskrive det på en af de postlister, eller i en IRC-kanal, og få en bekræftelse fra nogen, at det faktisk er en fejl. Bringe i det andet par øjne tidligt kan forhindre en masse falske rapporter. Sommetider den anden part er i stand til at identificere, at adfærden ikke er en fejl, eller er fastsat i de seneste udgivelser. Eller hun kan være bekendt med symptomer fra en tidligere udgave, og kan forhindre en kopi arkivering ved at pege brugeren til den ældre spørgsmål. Ofte er det nok bare at spørge brugeren «Har du søge i bug tracker for at se om den allerede er blevet rapporteret?» Mange mennesker simpelthen ikke tænke på det, men er glade for at gøre søgningen, når de kender nogen, der venter dem til.

Det kammerat system kan virkelig holde problemet databasen ren, men det har nogle ulemper også. Mange mennesker vil indgive solo alligevel, enten gennem ikke at se eller gennem bort, vejledningen for at finde en makker til nye spørgsmål. Derfor er det stadig nødvendigt for frivillige til at se problemet databasen. Hertil kommer, fordi de fleste nye indberettere ikke forstår, hvor svært det opgave med at fastholde spørgsmålet databasen, det er ikke fair at irettesætte dem for hårdt for at ignorere retningslinjerne. Således frivillige skal være på vagt, og alligevel udvise tilbageholdenhed i, hvordan de hoppe unbuddied spørgsmål tilbage til deres reportere. Målet er at uddanne hver reporter til at bruge buddying system i fremtiden, så der er en stadigt voksende pulje af mennesker, der forstår problemet-filtrering system. Om at se et unbuddied emne, er de ideelle trin:

Umiddelbart reagere på problemet, høfligt takke brugeren til arkivering, men peger dem til de buddying retningslinjer (som bør naturligvis være tydeligt lagt ud på hjemmesiden).

Hvis problemet er klart gyldige og ikke en kopi, godkende det alligevel, og starte det ned den normale livscyklus. Efter alt, er journalisten nu blevet informeret om buddying, så der er ingen grund til at spilde det hidtidige arbejde ved at lukke en gyldig emne.

Ellers, hvis problemet ikke er klart gyldig, skal den lukkes, men bede reporter at genåbne det, hvis de får en bekræftelse fra en kammerat. Når de gør det, bør de sætte en henvisning til bekræftelse tråd (f.eks en URL ind i postlistearkiver).

Husk, at selv om dette system vil forbedre signal / støj-forholdet i spørgsmålet database over tid, vil det aldrig helt stoppe misfilings. Den eneste måde at forhindre misfilings helt at lukke bug tracker til alle, men udviklerne-en kur, der er næsten altid værre end sygdommen. Det er bedre at acceptere, at rense ud ugyldige spørgsmål altid vil være en del af projektets rutinemæssig vedligeholdelse, og at forsøge at få så mange som muligt til at hjælpe.

Se også afsnittet «Issue Manager» i kapitel 8, Managing Volunteers.

IRC/real-time chat Systems

Mange projekter tilbyder real-time chat rooms med Internet Relay Chat (IRC), fora, hvor brugere og udviklere kan stille hinanden spørgsmål og få øjeblikkelige reaktioner. Mens du kan køre en IRC-server fra din egen hjemmeside, er det generelt ikke værd at besværet. I stedet, hvad alle andre gør: køre dine IRC-kanaler på Freenode (http://freenode.net/). Freenode giver dig den kontrol, du har brug for at administrere dit projekts IRC-kanaler [17], mens skåne dig den ikke-ubetydelig besvær at opretholde en IRC-server selv.

Den første ting at gøre, er at vælge en kanal navn. Det mest oplagte valg er navnet på dit projekt, hvis det er til rådighed på Freenode, så brug det. Hvis ikke, så prøv at vælge noget så tæt på dit projekts navn, og så nem at huske, som muligt. Annoncer kanalens ledig fra dit projekt hjemmeside, så en besøgende med et hurtigt spørgsmål vil se det med det samme. For eksempel vises dette i en fremtrædende placeret øverst på Subversion hjemmeside:

Hvis du bruger Subversion, anbefaler vi, at du tilmelder dig users@subversion.tigris.org mailingliste, og læs Subversion Book og FAQ. Du kan også stille spørgsmål om IRC på irc.freenode.net kanalen # svn.

Nogle projekter har flere kanaler, én pr underemne. F.eks. En kanal til installationsproblemer, en anden for brug spørgsmål, en anden for udvikling chat osv. (afsnittet «Håndtering Vækst» i kapitel 6, Communications diskuterer og hvordan man opdele i flere kanaler) Når dit projekt er ung, skal der kun være én kanal, hvor alle taler sammen. Senere, da de bruger-til-udvikler forholdet tiltager, kan separate kanaler blive nødvendig.

Hvordan vil folk kende alle de tilgængelige kanaler, endsige hvilken kanal til at tale i? Og når de taler, hvordan vil de vide, hvad de lokale konventioner?

Svaret er at fortælle dem ved at indstille den kanal emne. [18] kanal emne er en kort besked hver bruger ser, når de først ind i kanalen. Det giver hurtig vejledning til nyankomne, og henvisninger til yderligere oplysninger. For eksempel:

Du taler på # svn

Emne for # svn er Forum for Subversion spørgsmål fra brugerne, se også
http://subversion.tigris.org/. | | Udvikling diskussion sker i
# Svn-dev. | | Vær venlig ikke at indsætte lange udskrifter her, i stedet bruge
en Pastebin site som http://pastebin.ca/. | | NEWS: Subversion 1.1.0
frigives, se http://svn110.notlong.com/ for detaljer.
Det er lakoniske, men det fortæller nyankomne hvad de har brug for at vide. Det siger præcis, hvad kanalen er for, giver projektets hjemmeside (hvis nogen vandrer ind i kanalen uden først at have været til projektets hjemmeside), nævner en beslægtet kanal, og giver nogle retningslinjer om indsættelse.

Indsæt Sites

En IRC-kanal er et fælles rum: alle kan se, hvad alle andre siger. Normalt er det en god ting, da det tillader folk at hoppe ind i en samtale, når de tror, de har noget at bidrage med, og gør det muligt for tilskuerne at lære ved at se. Men det bliver problematisk, når en person har til at give en stor mængde information på en gang, såsom en debugging session afskrift, fordi indsætte alt for mange linjer af output ind i kanalen vil forstyrre andre samtaler.

Løsningen er at bruge en af Pastebin eller pastebot sites. Når der anmodes om en stor mængde data fra en person, skal du bede dem om ikke at indsætte den i kanalen, men i stedet for at gå til (for eksempel) http://pastebin.ca/, indsætte deres data i formularen der, og fortæl den resulterende ny webadresse til IRC kanal. Alle kan derefter besøge webadressen og få vist dataene.

Der er en række gratis pasta sites til rådighed nu, for mange for en udtømmende liste, men her er nogle af dem, jeg har set brugt: http://www.nomorepasting.com/, http://pastebin.ca/ , http://nopaste.php.cd/ http://rafb.net/paste/ http://sourcepost.sytes.net/, http://extraball.sunsite.dk/notepad.php, og http:/ / www.pastebin.com/.

Bots

Mange teknisk orienterede IRC-kanaler har et ikke-humant element, en såkaldt bot, som er i stand til at lagre og regurgitating information som reaktion på bestemte kommandoer. Typisk bot rettet ligesom ethvert andet medlem af kanalen, der er, er kommandoerne leveret af «at tale til» bot. For eksempel:

<kfogel> ayita: Lær diff-cmd = http://subversion.tigris.org/faq.html # diff-cmd
<ayita> Tak!
Det fortalte den bot (der er logget ind i kanalen som ayita) til at huske en bestemt webadresse som svaret på spørgsmålet «diff-cmd». Nu kan vi tage fat ayita, beder bot til at fortælle en anden bruger om diff-cmd:

<kfogel> ayita: fortæl jrandom om diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html # diff-cmd
Det samme kan opnås via et bekvemt blot:

<kfogel>! et jrandom diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html # diff-cmd
Den nøjagtige kommando sæt og adfærd adskiller sig fra bot til bot. Ovenstående eksempel er med ayita (http://hix.nu/svn-public/alexis/trunk/), som der er normalt et tilfælde kører i # svn på freenode. Andre robotter omfatter Dancer (http://dancer.sourceforge.net/) og Supybot (http://supybot.com/). Bemærk, at ingen særlige server privilegier er påkrævet for at køre en bot. En bot er et klient program, alle kan indstille én op og dirigere den til at lytte til en bestemt server / kanal.

Hvis din kanal tendens til at få de samme spørgsmål igen og igen, jeg stærkt anbefale at oprette en bot. Kun en lille procentdel af kanal-brugere vil opnå den nødvendige ekspertise til at manipulere bot, men disse brugere vil besvare en uforholdsmæssig stor procentdel af spørgsmål, fordi bot giver dem mulighed for at reagere så meget mere effektivt.

Arkivering IRC

Selv om det er muligt at arkivere alt hvad der sker i en IRC-kanal, er det ikke nødvendigvis forventet. IRC samtaler kan være nominelt offentlige, men mange mennesker tænker på dem som uformelle, semi-private samtaler. Brugere kan være skødesløs med grammatik, og udtrykker ofte udtalelser (for eksempel om anden software eller andre programmører), at de ikke ønsker bevaret for evigt i et online-arkiv.

Selvfølgelig vil der undertiden være uddrag, der bør bevares, og det er fint. De fleste IRC-klienter kan logge en samtale til en fil på brugerens anmodning, eller hvis dette ikke, kan man altid bare klippe og indsætte samtalen fra IRC til en mere permanent forum (oftest bug tracker). Men vilkårlige skovhugst kan gøre nogle brugere urolig. Hvis du gør arkiv alt, sørg for at angive så tydeligt i kanalen emne, og give en webadresse til arkivet.

RSS-feeds

RSS (Really Simple Syndication) er en mekanisme til at fordele meta-data-rige nyhedsresuméer til «abonnenter», det vil sige personer, der har tilkendegivet interesse i at modtage disse resuméer. En given RSS kilde er normalt kaldes et feed, og brugerens abonnement grænseflade kaldes en feed-læser eller foder nyhedslæser. RSS Bandit og den eponyme Feedreader er to open source RSS-læsere, f.eks.

Der er ikke plads her til en detaljeret teknisk forklaring af RSS [19], men du skal være opmærksom på to ting. For det første er foderet software til læsning valgt af abonnenten og er den samme for alle de feeds, der abonnent skærme — faktisk er det den største salgsargument af RSS: at abonnenten vælger et interface til brug for alle deres feeds, så hver foder kan koncentrere bare om at levere indhold. For det andet, RSS er nu allestedsnærværende, så meget, at de fleste mennesker, der bruger det ikke engang ved, de bruger det. Til den store verden, ser RSS som en lille knap på en webside, med en etiket at sige «Abonner på dette websted» eller «News feed». Du klikker på knappen, og fra da af din feed-læser (som meget vel kan være en applet indlejret i dit hjem side) automatisk opdateringer, når der er nyheder fra hjemmesiden.

Det betyder, at dit open source projekt sandsynligvis bør tilbyde en RSS-feed (bemærk, at mange af de konserverede hosting sites — se afsnittet «Dåse Hosting» — tilbyde det lige ud af æsken). Vær forsigtig med ikke at skrive så mange nyheder hver dag, at abonnenter ikke kan skille fårene fra bukkene. Hvis der er for mange nyheder begivenheder, vil folk bare ignorere foder eller endda ophæve abonnementet i ophidselse. Ideelt ville et projekt tilbyde separate feeds, en for store annonceringer, en anden følgende (sige) begivenheder i issue tracker, en anden for hver postliste, osv. I praksis er det svært at gøre godt: det kan resultere i grænsefladen forvirring både for besøgende til projektets hjemmeside og for administratorerne. Men på et minimum, skal projektet tilbyder en RSS-feed på forsiden, for at sende store annonceringer, såsom udgivelser og sikkerhedsadvarsler. [20]

Wikis

En wiki er et websted, der tillader enhver besøgende at redigere eller udvide dens indhold; udtrykket «wiki» (fra en hawaiiansk ord, der betyder «hurtig» eller «super-hurtig») er også brugt til at henvise til den software, som muliggør en sådan redigering . Wikis blev opfundet i 1995, men deres popularitet er virkelig begyndt at tage fart siden 2000 eller 2001, forstærket dels af den succes, Wikipedia (http://www.wikipedia.org/), en wiki-baseret free-indhold encyklopædi. Tænk på en wiki som falder et sted mellem IRC og websider: wikis ikke sker i realtid, så folk får en chance for at tænke og polere deres bidrag, men de er også meget nemt at tilføje til, involverer mindre grænseflade overhead end redigering af en regelmæssig webside.

Wikis er endnu ikke standard udstyr til open source-projekter, men de vil sandsynligvis være snart. Da de er forholdsvis ny teknologi, og folk er stadig eksperimenterer med forskellige måder at bruge dem, vil jeg bare tilbyde et par ord om forsigtighed her-på nuværende tidspunkt, er det lettere at analysere misbrug af wikis end at analysere deres succeser.

Hvis du beslutter dig for at køre en wiki, sætte en stor indsats i at have en klar side organisation og tiltalende visuelle layout, så de besøgende (dvs. potentielle redaktører) vil instinktivt vide, hvordan man passer ind i deres bidrag. Lige så vigtigt, sende disse standarder på wikien selv, så folk har et sted at gå til vejledning. Alt for ofte, wiki-administratorer bliver ofre for den fantasi, at fordi horder af besøgende enkeltvis tilføjer indhold af høj kvalitet til webstedet, skal summen af alle disse bidrag derfor også være af høj kvalitet. Det er ikke, hvordan web sites arbejde. Hver enkelt side eller afsnit kan være god, når de betragtes i sig selv, men det vil ikke være godt, hvis indlejret i en uorganiseret eller forvirrende hele. Alt for ofte, wikis lider af:

Mangel på navigations principper. Et velorganiseret hjemmeside gør, at gæsterne føle, at de ved, hvor de er til enhver tid. For eksempel, hvis siderne er godt designet kan folk intuitivt se forskel mellem en «indholdsfortegnelse» region og et «indhold» region. Bidragydere til en wiki vil respektere sådanne forskelle også, men kun hvis forskellene er til stede til at begynde med.

Gentagelse af oplysninger. Wikis ofte ender med forskellige sider siger lignende ting, fordi de enkelte bidragydere ikke mærke til gentagelser. Dette kan være dels en konsekvens af den manglende navigations principper nævnt ovenfor, idet folk ikke kan finde den kopieret indhold, hvis det ikke er der, hvor de forventer, at det at være.

Inkonsekvent målgruppe. Til en vis grad dette problem er uundgåeligt, når der er så mange forfattere, men det kan mindskes, hvis der er skrevet retningslinjer om, hvordan man skaber nyt indhold. Det hjælper også at aggressivt redigere nye bidrag i starten, som et eksempel, så de standarder begynder at synke i.

Den fælles løsning på alle disse problemer er den samme: have redaktionelle standarder, og demonstrere dem ikke kun ved at lægge dem, men ved at redigere sider til at overholde dem. Generelt vil wikis forstærke eventuelle svagheder i deres oprindelige materiale, da bidragydere efterligne, hvad mønstre, de ser foran dem. Må ikke netop oprettet wikien og håber alt falder på plads. Du skal også prime det med velskrevet indhold, så folk har en skabelon at følge.

Den lysende eksempel på en veldrevet wiki er Wikipedia, selvom det kan være dels fordi indholdet (encyklopædi poster) er naturligvis velegnet til wiki-format. Men hvis du undersøger Wikipedia nøje, vil du se, at dens administratorer lagde en meget grundig fundament for samarbejdet. Der er omfattende dokumentation for, hvordan man skriver nye poster, hvordan man kan opretholde en passende synsvinkel, hvad slags redigeringer at gøre, hvad redigeringer for at undgå en konfliktløsning proces for den anfægtede redigeringer (omfatter flere stadier, herunder eventuel voldgift), og så videre. De har også tilladelse kontrol, således at hvis en side er målet for gentagne upassende redigeringer, kan de låse den ned, indtil problemet er løst. Med andre ord, de ikke bare smide nogle skabeloner på en hjemmeside og håbe på det bedste. Wikipedia fungerer, fordi dens grundlæggere tænkte grundigt over, hvordan man får tusindvis af fremmede at skræddersy deres skriftligt til en fælles vision. Selvom du måske ikke brug for den samme grad af parathed til at køre en wiki til et gratis software-projekt, ånden er værd at efterligne.

For mere information om wikis kan ses http://en.wikipedia.org/wiki/Wiki. Også den første wiki stadig i live og godt, og indeholder en masse diskussion om at køre wikis: se http://www.c2.com/cgi/wiki?WelcomeVisitors, http://www.c2.com/cgi/wiki ? WhyWikiWorks, og http://www.c2.com/cgi/wiki?WhyWikiWorksNot for forskellige synspunkter.

Web Site

Der er ikke meget at sige om opsætning af projektets hjemmeside fra et teknisk synspunkt: at oprette en web-server og skrive websider er ret simple opgaver, og de fleste af de vigtige ting at sige om layout og arrangement var omfattet af foregående kapitel. Webstedet hovedfunktion er at fremlægge en klar og indbydende overblik over projektet, og at binde sammen de andre værktøjer (version control system, bug tracker, osv.). Hvis du ikke har den nødvendige ekspertise til at etablere en web-server selv, er det normalt ikke svært at finde nogen, der gør, og er villige til at hjælpe. Ikke desto mindre, for at spare tid og kræfter, folk ofte foretrækker at bruge en af de konserverede hosting sites.

Dåse Hosting

Der er to primære fordele ved at bruge en dåse site. Den første er server kapacitet og båndbredde: deres servere er velnæret kasser sidder på rigtig fede rør. Uanset hvor godt dit projekt bliver, er du ikke kommer til at løbe tør for diskplads eller oversvømme netværksforbindelsen. Den anden fordel er enkelhed. De har allerede valgt en bug tracker, en version kontrolsystem, en mailingliste manager, en Archiver, og alt andet du har brug for at køre et websted. De har konfigureret de værktøjer, og tager sig af sikkerhedskopier for alle de data, der lagres i værktøjerne. Du behøver ikke at gøre mange beslutninger. Alt du skal gøre er at udfylde en formular, skal du trykke på en knap, og pludselig har du et projekt hjemmeside.

Disse er temmelig betydelige fordele. Ulempen er naturligvis, er, at du skal acceptere deres valg og konfigurationer, selv om noget andet ville være bedre for dit projekt. Normalt dåse sites kan justeres inden for visse snævre parametre, men du vil aldrig få det finkornet kontrol ville du have, hvis du opretter webstedet selv og havde fuld administrativ adgang til serveren.

Et perfekt eksempel på dette er håndteringen af genererede filer. Visse projekt websider kan genereres filer, for eksempel, er der systemer til at holde FAQ data i et let-til-redigere mester format, hvorfra HTML, PDF og andre præsentationsformater kan genereres. Som forklaret i afsnittet «Version alt» tidligere i dette kapitel, ville du ikke ønsker at versionen de genererede formater, kun master-fil. Men når dit websted er hostet på en andens server, kan det være umuligt at oprette en brugerdefineret krog at regenerere online HTML-version af FAQ, når master file ændres. Den eneste løsning er at version, de genererede formater også, så at de dukker op på webstedet.

Der kan være større konsekvenser så godt. Du må ikke have så meget kontrol over præsentationen, som du kunne ønske. Nogle af de dåse hosting sites giver dig mulighed for at tilpasse dine websider, men sidens standard layout som regel ender viser gennem i forskellige akavede måder. For eksempel har nogle projekter, der er vært for sig på SourceForge helt tilpasset hjemmesider, men alligevel pege udviklere til deres «SourceForge side» for mere information. Den SourceForge side er hvad der ville være projektets hjemmeside, havde projektet ikke brugt en brugerdefineret hjemmeside. Den SourceForge side har links til bug tracker, CVS repository, downloads, osv. Desværre en SourceForge side indeholder også en stor del af uvedkommende støj. Den øverste er en bannerreklame, ofte en animeret billede. I venstre side er en lodret arrangement af links i ringe relevans for nogen interesseret i projektet. Den højre side er ofte en anden reklame. Kun midten af siden er helliget lige projekt-specifikt materiale, og selv der er arrangeret i en forvirrende måde, der ofte gør de besøgende i tvivl om hvad man skal klikke på næste.

Bag hver enkelt aspekt af SourceForge design, er der ingen tvivl en god grund-god fra SourceForge synspunkt, såsom reklamer. Men fra et individuelt projekt synspunkt, kan det resultere i en mindre-end-ideal webside. Jeg mener ikke at plukke på SourceForge, for lignende bekymringer gælder for mange af de konserverede hosting sites. Pointen er, at der er en afvejning. Du får nødhjælp fra de tekniske byrder ved at drive et projekt site, men kun på bekostning af at acceptere en andens måde at drive det.

Kun du kan beslutte, om dåse hosting er bedst til dit projekt. Hvis du vælger en dåse websted, skal du lade åben mulighed for at skifte til dine egne servere senere, ved hjælp af en brugerdefineret domænenavn for projektets «hjemadresse». Du kan videresende webadressen til den dåse site, eller har et fuldt tilpasset startsiden på den offentlige URL og hånd-brugere off til dåse site for avanceret funktionalitet. Bare sørg for at arrangere ting, sådan at hvis du senere beslutter at bruge en anden hosting løsning, er projektets adresse ikke behøver at ændre sig.

Valg af en dåse hosting site

Der er nu (som i begyndelsen af 2011) en etableret tre store af gratis dåse hosting sites. Alle tre tilbyder gratis-of-charge hosting for projekter, der frigives under open source licenser. De giver versionsstyring, bug tracking, og wikis (nogle tilbyder også andre funktioner, såsom binære downloads):

GitHub Version kontrol er Git kun-men hvis du bruger Git alligevel, det er nok det rette sted for dit projekt. GitHub er blevet centrum i universet for Git-projekter, og har integreret alle deres tjenester med Git. GitHub tilbyder også et komplet API til at interagere programmeringsmæssigt med deres service. Den giver ikke postlister, men de er til rådighed så mange andre steder, at det ikke skulle noget meget.

Google Code Hosting tilbud Subversion og Mercurial versionskontrolsystemer (ingen Git, i hvert fald ikke endnu), wikis, en downloads område, og en temmelig nice bug tracker. Det leveres også med API’er: de versionskontrolsystemer er naturligvis deres egen API, det issue tracker har sin egen API, wiki indhold tilbydes direkte i den version kontrolsystem og er derfor redigeres af scripts, og den downloads området byder scriptede uploads, med andre ord. en API Postlister er tilvejebragt via Google Groups (så igen, kunne det samme erklæring være fremstillet af ethvert hosting site).

SourceForge Dette er den ældste, og ved nogle foranstaltninger stadig den største af de gratis hosting sites. Det indeholder alle de funktioner, de andre gør, og dens interface er meget anvendeligt, men nogle mennesker finder reklame blokke på projekt sider at være distraherende. Det synes at være den eneste af de tre store, der tilbyder alle de store versionskontrolsystemer (Git, Subversion, Mercurial, og CVS) lige nu. SourceForge tilbyder også sine egne postlister, selvom du kan naturligvis bruge nogle andre postliste service.

Nogle få organisationer, for eksempel Apache Software Foundation, tilbyder også gratis hosting til open source-projekter, der passer godt med deres missioner og deres samfund af eksisterende projekter.

Hvis du er i tvivl om, hvor at være vært, jeg stærkt anbefale bare med en af de tre store. Hvis du vil have endnu mere vejledning: brug GitHub hvis dit projekt bruger Git for versionskontrol, ellers bruge Google Code Hosting. SourceForge er også helt acceptabelt, men på dette tidspunkt ikke har nogen signifikant fordel i forhold til de andre, og reklamen kan være irriterende.

Mange mennesker har observeret, at gratis projekt hosting sites selv ofte ikke gøre al den software, der kører stedet avialble under en fri software-licens (nogle, der gør, er Launchpad, Gitorious og GNU Savannah). Min fornemmelse er, at mens det ville være ideelt at have adgang til al den kode, der kører stedet, det afgørende er at have en måde eksportere dine data, og at være i stand til at interagere med dine data på en automatiseret måde. Et sådant sted kan aldrig virkelig låse dig i, og vil endda være strækbart til en vis grad gennem programmatiske interface. Mens der er en vis værdi i at have al den kode, der kører en hosting site tilgængelig under open source vilkår i praksis krav faktisk at indsætte denne kode i et produktionsmiljø er uoverkommelige for de fleste brugere. Disse websteder har brug for flere servere, tilpassede netværk og fuldtidsansatte stabe til at holde dem kørende, blot at have koden ville ikke være tilstrækkelig til at kopiere eller «gaffel» tjenesten alligevel. Det vigtigste er blot at sørge for dine data ikke kommer i klemme.

Wikipedia har en grundig sammenligning af hosting faciliteter, det er det første sted at søge efter up-to-date, omfattende information om open source-projekt hosting muligheder. Haggen Så gjorde også en grundig evaluering af forskellige dåse hosting sites, som en del af forskning for hans ph.d. afhandling, Opførelse af en Evaluation Model for Free / Open Source projekt Hosting (FOSPHost) sites. Selv om det blev gjort i 2005, han synes at have opdateret det så sent som i 2007, og hans kriterier sandsynligvis fortsat vil være gyldige i lang tid. Hans resultater er på http://www.ibiblio.org/fosphost/, og se især meget læsbar sammenligning diagram på http://www.ibiblio.org/fosphost/exhost.htm.

Anonymitet og engagement

Et problem, der ikke er strengt begrænset til de konserverede sites, men er oftest findes der, er misbrug af brugerens login funktionalitet. Funktionaliteten selv er enkel nok: Webstedet giver hver besøgende til at registrere sig med brugernavn og adgangskode. Fra da af det holder en profil for den pågældende bruger, og projektets administratorer kan tildele brugeren bestemte tilladelser, for eksempel retten til at forpligte sig til lageret.

Dette kan være yderst nyttigt, og det er faktisk en af de vigtigste fordele ved dåse hosting. Problemet er, at nogle gange bruger login ender med at blive nødvendig for opgaver, der burde være tilladt ikke-registrerede besøgende, især evnen til at indgive spørgsmål i bug tracker, og at kommentere på eksisterende emner. Ved at kræve en logget ind brugernavn til sådanne aktioner, rejser projektet inddragelse bar for hvad der bør være hurtig og bekvem opgaver. Selvfølgelig ønsker man være i stand til at kontakte en person, der har indtastet data i issue tracker, men som har et felt, hvor hun kan trænge ind i hende e-mail-adresse (hvis hun ønsker at) er tilstrækkelig. Hvis en ny bruger ser en fejl og ønsker at rapportere det, vil hun kun blive irriteret over at skulle udfylde en kontooprettelse formular, før hun kan komme ind i bug i trackeren. Hun kan simpelthen beslutter ikke at indsende fejlen overhovedet.

Fordelene ved brugerstyring generelt opvejer ulemperne. Men hvis du kan vælge, hvilke handlinger kan udføres anonymt, så sørg for ikke blot, at alle skrivebeskyttede sagsanlæg til ikke-logget ind besøgende, men også nogle dataindtastning aktioner, især i bug tracker, og hvis du har dem , wiki sider.
[12] Fra sin bog The Mythical Man Month, 1975. Se http://en.wikipedia.org/wiki/The_Mythical_Man-Month og http://en.wikipedia.org/wiki/Brooks_Law.

[13] Kort efter denne bog udkom, skrev Michael Bernstein mig til at sige: «Der er andre email-klienter, der gennemfører et svar-til-liste funktion udover Mutt For eksempel har Evolution denne funktion som en genvejstast, men ikke en knap. (Ctrl + L). »

[14] Da jeg skrev, at jeg har lært, at der er mindst en liste management system, der tilbyder denne funktion: Siesta. Se også denne artikel om det: http://www.perl.com/pub/a/2004/02/05/siesta.html

[15] Se http://cia.vc/stats/vcs og http://subversion.tigris.org/svn-dav-securityspace-survey.html for tegn på denne vækst.

[16] For en anden mening om spørgsmålet om versionsstyring configure filer, se Alexey Makhotkin s post «configure.in og versionsstyring» på http://versioncontrolblog.com/2007/01/08/configurein-and-version-control/ .

[17] Der er ingen krav eller forventning om, at du donere til Freenode, men hvis du eller dit projekt har råd til det, kan du overveje et bidrag. De er en skattefri velgørenhed i USA, og de udfører en værdifuld tjeneste.

[18] For at indstille en kanal emne, skal du bruge / emne kommando. Alle kommandoer i IRC starter med «/». Se http://www.irchelp.org/ hvis du ikke er bekendt med IRC brug og administration, i særdeleshed er http://www.irchelp.org/irchelp/irctutorial.html en fremragende tutorial.

[19] Se http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html for det.

[20] Kredit, hvor kredit skyldes: dette afsnit var ikke i første offentliggjorte udgave af bogen, men Brian Akers blog «Release Kriterier, open source, tanker om …» mindede mig om nytten af RSS-feeds til open source-projekter.

Kapitel 4. Sociale og politiske infrastruktur

De første spørgsmål folk normalt spørger om fri software er «Hvordan virker det? Hvad holder et projekt kørende? Hvem træffer beslutningerne?» Jeg er altid utilfredse med ligegyldige svar om meritokrati, den samarbejdsånd, kode taler for sig selv, etc. Faktum er, spørgsmålet er ikke let at besvare. Meritokrati, samarbejde og køre kode er alle en del af det, men de gør meget for at forklare, hvordan projekterne rent faktisk kører på en dag-til-dag basis, og siger intet om, hvordan konflikter løses.

Dette kapitel forsøger at vise de strukturelle fundament vellykkede projekter har til fælles. Jeg mener «vellykket» ikke bare i form af teknisk kvalitet, men også operationel sundhed og overlevelsesevne. Operationel sundhed er projektets fortsatte evne til at inkorporere nye kode bidrag og nye udviklere, og at være lydhør over for indkommende fejlrapporter. Overlevelsesevne er projektets evne til at eksistere uafhængigt af enhver individuel deltager eller sponsor-tænk på det som sandsynligheden for, at projektet ville fortsætte, selv om alle de stiftende medlemmer var at gå videre til andre ting. Teknisk succes er ikke svært at opnå, men uden en robust udvikler base og social fundament, kan et projekt være ude af stand til at håndtere den vækst, indledende succes bringer, eller afgang karismatiske personer.

Der er forskellige måder at opnå denne form for succes. Nogle involverer en formel ledelsesstruktur, hvorved debatter løst, er nye udviklere inviteret i (og til tider ud), nye funktioner planlagt, og så videre. Andre indebærer mindre formel struktur, men mere bevidst selvbeherskelse, at producere en atmosfære af fairness, at folk kan stole på som en de facto styreform. Begge veje fører til samme resultat: en følelse af institutionel permanens, støttet af vaner og procedurer, der er godt forstås af alle, der deltager. Disse funktioner er endnu mere vigtigt i selvorganiserende systemer end i centralt styrede dem, fordi det i selvorganiserende systemer, alle er klar over, at et par dårlige æbler kan ødelægge hele tønde, i det mindste for en tid.

Forkability

Den uundværlige ingrediens, der binder udviklerne sammen om et gratis software-projekt, og gør dem villige til at gå på kompromis, når det er nødvendigt, er kodens forkability: evne nogen til at tage en kopi af kildekoden og bruge den til at starte et konkurrerende projekt, kendt som en gaffel. Det paradoksale er, at muligheden for at gaflerne er normalt en meget større kraft i fri software-projekter end egentlige gafler, som er meget sjældne. Fordi en gaffel er dårligt for alle (af grunde gennemgås i detaljer i afsnittet «Forks» i kapitel 8, adm. Frivillige), jo mere alvorlig er truslen om en gaffel bliver, jo mere villige folk er til at gå på kompromis for at undgå det.

Forks, eller snarere mulighederne for gafler, er årsagen er der ingen ægte diktatorer i fri software-projekter. Dette kan synes som en overraskende krav, i betragtning af hvor almindeligt det er at høre nogen kaldes «diktator» eller «tyran» i en given open source-projekt. Men denne form for tyranni er speciel, helt forskellig fra den konventionelle forståelse af ordet. Forestil dig en konge, hvis fag kunne kopiere hele hans kongerige til enhver tid og flytte til kopien at herske som de ønsker. Ville ikke sådan en konge regere meget forskelligt fra, hvis individer var bundet til at bo under hans styre, uanset hvad han gjorde?

Dette er grunden til selv projekter, der ikke formelt er organiseret som demokratier er i praksis demokratier når det kommer til vigtige beslutninger. Replikabilitet indebærer forkability, forkability indebærer konsensus. Det kan godt være, at alle er villige til at bøje sig for en leder (det mest berømte eksempel er Linus Torvalds i Linux-kernen udvikling), men det er fordi de vælger at gøre det, i en helt ikke-kyniske og ikke-skummel måde. Diktatoren har ingen magiske magt over projektet. En vigtig egenskab af alle open source-licenser, er, at de ikke giver den ene part mere magt end nogen anden i beslutningen om, hvordan koden kan ændres eller anvendes. Hvis diktatoren pludseligt skulle begynde at gøre dårlige beslutninger, ville der være rastløshed, efterfulgt sidst ved oprør og en gaffel. Bortset, selvfølgelig, tingene sjældent kommer så langt, fordi diktatoren kompromiser først.

Men bare fordi forkability sætter en øvre grænse for, hvor meget strøm man kan udøve i et projekt betyder ikke at der ikke er væsentlige forskelle i, hvordan projekterne styres. Du ønsker ikke enhver beslutning om at komme ned til den sidste udvej spørgsmål om, hvem der overvejer en gaffel. Det ville få kedelige meget hurtigt, og sap energi væk fra egentlige arbejde. De næste to afsnit undersøge forskellige måder at organisere projekter, således at de fleste beslutninger gå glat. Disse to eksempler er noget idealiseret ekstremer, mange projekter falder et sted langs et kontinuum mellem dem.

Godgørende Diktatorer

Den venligsindet diktator model er præcis, hvad det lyder som: endelig besluttende myndighed ligger hos én person, som i kraft af personlighed og erfaring, forventes at bruge det med omtanke.

Selv om «venligsindet diktator» (eller BD) er standard betegnelse for denne rolle, ville det være bedre at tænke på det som «community-godkendt voldgiftsmand» eller «dommer». Normalt behøver velvillige diktatorer faktisk ikke gøre alle de beslutninger, eller endda de fleste af de beslutninger. Det er usandsynligt, at en person kunne have tilstrækkelig ekspertise til at gøre konsekvent gode beslutninger på tværs af alle områder af projektet, og alligevel, vil kvalitets-udviklere ikke bo rundt, medmindre de har en vis indflydelse på projektets retning. Derfor velgørende diktatorer almindeligvis ikke diktere meget. I stedet lod de tingene arbejde sig ud gennem diskussion og eksperimenter når det er muligt. De deltager i disse drøftelser sig selv, men som regelmæssige udviklere, ofte udskyde til et område vedligeholder der har mere ekspertise. Først når det er klart, at der ikke kan opnås konsensus, og at størstedelen af gruppen ønsker nogen til at guide den beslutning, således at udviklingen kan komme videre, gør de sætter deres fod ned og sige «Dette er den måde, det kommer til at være.» Modvilje mod at træffe beslutninger ved fiat er et træk deles af næsten alle succesfulde velvillige diktatorer, det er en af grundene til at de formår at holde rolle.

Hvem kan være en god venligsindet diktator?

At være en BD kræver en kombination af træk. Det skal først og fremmest, et godt finpudsede følsomhed over for ens egen indflydelse i projektet, hvilket igen bringer selvbeherskelse. I de tidlige stadier af en diskussion, bør man ikke udtrykke meninger og konklusioner med så stor sikkerhed, at andre har lyst til det er meningsløst at dissens. Folk skal være ukodet ideer, selv dumme ideer. Det er uundgåeligt, at BD vil skrive en dum idé fra tid til anden også, selvfølgelig, og dermed den rolle kræver også en evne til at genkende og anerkende, når man har lavet en dårlig beslutning, selv om dette er simpelthen et træk, at enhver god udvikler skal have, især hvis hun bliver med projektet i lang tid. Men forskellen er, at BD har råd til at glide fra tid til anden, uden at bekymre sig om langsigtet skade på hendes troværdighed. Udviklere med mindre anciennitet måske ikke føler sig så sikker, så BD bør sætningen kritikker eller i strid beslutninger med en vis følsomhed for hvor meget vægt hendes ord bære, både teknisk og psykologisk.

BD behøver ikke at have de skarpeste tekniske færdigheder nogen i projektet. Hun skal være dygtige nok til at arbejde på koden selv, og til at forstå og kommentere eventuelle ændringer under overvejelse, men det er alt. BD position er hverken erhverves, eller holdt i kraft af intimidere kodning færdigheder. Hvad er vigtigt, er erfaring og overordnede design sans-ikke nødvendigvis evnen til at producere godt design på anfordring, men evnen til at genkende godt design, uanset kilde.

Det er almindeligt for den venligsindet diktator til at være stifter af projektet, men det er mere en korrelation end en årsag. Den slags kvaliteter, der gør en i stand til at starte et projekt-teknisk kompetence, evne til at overtale andre til at deltage, osv.-er præcis de kvaliteter enhver BD vil være nødvendigt. Og selvfølgelig starte stiftere ud med en slags automatisk anciennitet, som ofte kan være nok til at gøre velgørende diktatur vises stien mindst modstand for alle parter.

Husk, at muligheden for at gaffel går begge veje. En BD kan gaffel et projekt lige så let som alle andre, og nogle har lejlighedsvis gjort det, da de mente, at den retning, de ønskede at tage projektet var forskellig fra, hvor de fleste andre udviklere ønskede at gå. På grund af forkability, er det ligegyldigt, om det venligsindet diktator har root (systemadministratorrettigheder) på projektets vigtigste servere eller ej. Folk taler nogle gange om server kontrol, som om det var den ultimative kilde til magt i et projekt, men i virkeligheden er det irrelevant. Evnen til at tilføje eller fjerne folks begå passwords på en bestemt server påvirker kun den kopi af det projekt, der er bosat på den pågældende server. Langvarig misbrug af denne magt, hvad enten BD eller en anden, ville simpelthen føre til udvikling flytter til en anden server.

Uanset om dit projekt skal have en venligsindet diktator, eller ville køre bedre med nogle mindre centraliseret system, afhænger i høj grad af, hvem der er til rådighed til at udfylde den rolle. Som en generel regel, hvis det er simpelthen indlysende for alle, hvem der skal være den BD så det er den måde at gå. Men hvis ingen kandidat for BD er umiddelbart indlysende, så projektet bør nok bruge en decentral beslutningsproces, som beskrevet i næste afsnit.

Konsensus-baserede demokrati

Når projekterne bliver ældre, har de tendens til at bevæge sig væk fra den velvillige diktatur model og mod mere åbent demokratiske systemer. Dette er ikke nødvendigvis ud af utilfredshed med en bestemt BD. Det er simpelthen, at gruppe-baserede styring er mere «evolutionært stabil», at låne en biologisk metafor. Når en venligsindet diktator trin ned, eller forsøg på at sprede beslutningskraft mere jævnt, det er en mulighed for gruppen at slå sig ned på et nyt, ikke-diktatorisk system-etablere en forfatning, som det var. Gruppen kan ikke benytte denne lejlighed for første gang, eller den anden, men til sidst vil de, når de gør det, at beslutningen er næppe nogen sinde skal vendes. Almindelig sund fornuft forklarer hvorfor: hvis en gruppe af N mennesker var til vest én person med særlig kraft, ville det betyde, at N — 1 mennesker blev hver enige om at nedsætte deres individuelle indflydelse. Folk normalt ikke ønsker at gøre det. Selv hvis de gjorde, ville den resulterende diktatur stadig være betinget: den gruppe salvede BD, klart gruppen kunne afsætte BD. Derfor, når et projekt er flyttet fra ledelse af en karismatisk person til en mere formel, gruppe-baseret system, er det sjældent bevæger sig tilbage.

Nærmere oplysninger om, hvordan disse systemer fungerer varierer meget, men der er to fælles elementer: et, at gruppen arbejder med konsensus det meste af tiden, to, er der en formel afstemning mekanisme til at falde tilbage på, når konsensus ikke kan nås.

Konsensus betyder blot en aftale, som alle er villige til at leve med. Det er ikke en uklar: en gruppe nået til enighed om et givent spørgsmål, når nogen foreslår, at der er opnået enighed, og ingen modsiger påstanden. Den person, som foreslår konsensus bør naturligvis, stat specifikt, hvad konsensus er, og hvilke handlinger der ville blive truffet som følge af det, hvis de ikke er indlysende.

Mest samtale i et projekt er på tekniske emner, såsom den rigtige måde at løse en bestemt fejl, eller ej at tilføje en funktion, hvor strengt at dokumentere interfaces, etc. Konsensus-baserede styring fungerer godt, fordi det passer perfekt med den tekniske Discussion selv. Ved udgangen af en diskussion, er der ofte generel enighed om, hvilke skridt at tage. Nogen vil normalt gøre en afsluttende post, der er både en oversigt over, hvad der er besluttet, og en implicit forslag af konsensus. Dette giver en sidste chance for en anden til at sige «Vent, jeg ikke enig. Vi er nødt til hash ud af det noget mere.»

For små, ukontroversielle beslutninger, er forslaget om konsensus implicit. For eksempel, når en udvikler spontant begår en bugfix den forpligte sig selv er et forslag om konsensus: «. Jeg antager vi alle enige om, at denne fejl skal rettes, og at dette er måden at løse det» Selvfølgelig betyder udvikleren faktisk ikke sige, at, hun bare forpligter fix, og de andre i projektet ikke gider at oplyse deres aftale, fordi tavshed er samtykke. Hvis nogen begår en ændring, der viser sig ikke at have konsensus, resultatet er simpelthen for projektet at diskutere ændringen, som om det ikke allerede var blevet begået. Grunden til dette fungerer, er emnet for næste afsnit.

Version Control betyder, at du kan slappe af

Det forhold, at projektet kildekode holdes under versionskontrol betyder, at de fleste beslutninger kan nemt unmade. Den mest almindelige måde, hvorpå dette sker, er, at nogen begår en ændring fejlagtigt tænker alle ville være tilfredse med det, kun for at blive mødt med indsigelser efter den kendsgerning. Det er typisk for sådanne indvendinger til at starte ud med en obligatorisk undskyldning for at have gået glip af forudgående drøftelse, selv om dette kan udelades, hvis den indsigende finder ingen registrering af en sådan diskussion i postlistearkiver. Uanset hvad, er der ingen grund til at tonen i debatten at være anderledes, efter at ændringen er blevet begået end før. Enhver ændring kan altid nulstilles, i det mindste indtil afhængige ændringer er indført (dvs. ny kode, der ville bryde, hvis den oprindelige forandring pludselig blev fjernet). Den version styresystem giver projektet en måde at fortryde virkningerne af dårligt eller forhastet dom. Dette vil igen, frigør folk til at stole på deres instinkter om, hvor meget feedback er nødvendig, før du laver noget.

Det betyder også, at processen med at etablere konsensus behøver ikke at være meget formelle. De fleste projekter håndtere det ved føler. Mindre ændringer kan gå i uden diskussion eller med minimal diskussion efterfulgt af et par nikker for aftalen. For flere væsentlige ændringer, især dem med potentiale til at destabilisere en masse kode, bør folk vente en dag eller to før forudsat at der er enighed, baggrunden er, at ingen bør blive marginaliseret i en vigtig samtale, blot fordi han ikke kontrollere e-mail ofte nok.

Så når nogen er sikker på at han ved hvad der skal gøres, bør han bare gå videre og gøre det. Dette gælder ikke kun for software-rettelser, men til web site opdateringer, dokumentation ændringer, og alt andet usandsynligt, at være kontroversiel. Normalt vil der kun være nogle få tilfælde, hvor en handling er behov for at fortryde, og disse kan håndteres på en sag til sag-basis. Selvfølgelig skal man ikke opfordre folk til at være stædig. Der er stadig en psykologisk forskel mellem en beslutning, der drøftes, og en, der allerede er trådt i kraft, selv om det er teknisk reversibel. Folk altid føler, at momentum er allieret til handling, og det vil være lidt mere tilbageholdende med at vende tilbage en ændring, end at forhindre det i første omgang. Hvis en udvikler misbruger denne omstændighed ved at begå potentielt kontroversielle ændringer for hurtigt, men folk kan og bør klage, og fastslå, at bygherren til en strengere standard indtil tingene bedre.

Når konsensus ikke kan opnås, Stem

Uundgåeligt, nogle debatter vil bare ikke consense. Når alle andre muligheder for at bryde et dødvande mislykkes, at løsningen er at stemme. Men før en afstemning kan tages, skal der være et klart sæt valg på stemmesedlen. Her, igen, den normale proces med teknisk diskussion blander lykketræf med projektets beslutningsprocedurer. Den slags spørgsmål, der kommer til afstemning indebærer ofte komplekse, mangefacetterede problemer. I ethvert sådant kompleks diskussion, er der som regel en eller to personer at spille rollen som mægler: udstationering periodiske oversigter over de forskellige argumenter og holde styr på, hvor de centrale omstridte punkter (og aftale) løgn. Disse oversigter hjælpe alle måle, hvor store fremskridt der er gjort, og minde alle om hvilke spørgsmål, som skal løses. De samme opgørelser kan tjene som prototyper for en stemmeseddel ark, bør en stemme blive nødvendigt. Hvis de ærlige mæglere har gjort deres arbejde godt, vil de være i stand til troværdig kræve afstemning, når den tid kommer, og gruppen vil være villige til at bruge en stemmeseddel ark baseret på deres resumé af spørgsmålene. De mæglere selv kan være deltagere i debatten, det er ikke nødvendigt for dem at forblive over kampen, så længe de kan forstå og temmelig repræsentere andres synspunkter, og ikke lade deres partiske følelser forhindrer dem i at opsummere status for debatten i en neutral måde.

Det faktiske indhold af stemmesedlen er normalt ikke kontroversiel. Ved den tid sager nå en afstemning, har uenighed sædvanligvis kogt ned til et par vigtige spørgsmål med genkendelige mærker og korte beskrivelser. Lejlighedsvis en udvikler vil protestere mod den form for afstemning selv. Nogle gange er hans bekymring er berettiget, for eksempel, at et vigtigt valg blev slap eller ikke er beskrevet præcist. Men andre gange en udvikler kan blot forsøge at afværge det uundgåelige, måske at vide, at afstemningen formentlig ikke vil gå sin vej. Se afsnittet «Vanskelige Personer» i kapitel 6, Communications til hvordan man kan håndtere denne form for obstruktion.

Husk at angive afstemningssystemet, da der er mange forskellige slags, og folk kan gøre forkerte antagelser om, hvilken procedure der anvendes. Et godt valg i de fleste tilfælde er godkendelsen afstemning, hvor hver vælger kan stemme for så mange af de valg, på stemmesedlen som han kan lide. Godkendelse stemme er enkel at forklare og at tælle, og i modsætning til nogle andre metoder, kun det involverer en valgrunde. Se http://en.wikipedia.org/wiki/Voting_system # List_of_systems for mere information om godkendelse afstemning og andre afstemningssystemer, men prøv at undgå at komme i en lang debat om, hvilke afstemningssystem bruge (fordi, selvfølgelig, vil du derefter finde dig selv i en debat om, hvilke afstemningssystem skal bruges til at afgøre afstemningssystemet!). En af grundene til godkendelse stemme er et godt valg, er, at det er meget svært for nogen at gøre indsigelse mod, det er omtrent lige så retfærdig som et afstemningssystem kan være.

Endelig foretager stemmer i offentligheden. Der er ikke behov for hemmeligholdelse eller anonymitet i en afstemning om anliggender, der er blevet drøftet offentligt alligevel. Lad hver deltager sende sine stemmer til projektet postliste, således at enhver observatør kan stemme overens og kontrollere resultaterne for sig selv, og så alt er registreret i arkiverne.

Hvornår skal stemme

Det sværeste ved at stemme er at bestemme, hvornår de skal gøre det. I almindelighed bør tage en afstemning være meget sjældne en sidste udvej, når alle andre muligheder er slået fejl. Tror ikke på at stemme som en god måde at løse debatter. Det er det ikke. Det ender diskussion, og derved ender kreativ tænkning om problemet. Så længe diskussionen fortsætter, er der mulighed for, at nogen vil komme med en ny løsning alle kan lide. Det sker overraskende ofte: en livlig debat kan producere en ny måde at tænke om problemet, og føre til et forslag, der i sidste ende tilfredsstiller alle. Selv når der ikke nye forslag opstår, er det stadig normalt bedre at finde et kompromis end at holde en afstemning. Efter et kompromis, er alle en lille smule ulykkelig, hvorimod efter en afstemning, nogle mennesker er utilfredse, mens andre er glade. Fra et politisk synspunkt er den tidligere situation foretrække: mindst hver person kan føle han ekstraheret en pris for sin utilfredshed. Han kan være utilfredse, men så er alle andre.

Afstemningen største fordel er, at det endelig afregner et spørgsmål, så alle kan komme videre. Men det afgør det ved en optælling, i stedet for ved rationel dialog, der fører alle til den samme konklusion. De mere erfarne folk er med open source-projekter, jo mindre ivrig jeg finde dem at være at afgøre spørgsmål ved afstemning. I stedet vil de forsøge at udforske hidtil uset grad løsninger, eller gå på kompromis mere alvorligt, end de oprindeligt havde planlagt. Forskellige teknikker er tilgængelige til at forhindre en for tidlig afstemning. Det mest oplagte er simpelthen at sige «Jeg tror ikke, vi er klar til afstemning endnu,» og forklare hvorfor ikke. En anden er at bede om en uformel (ikke-bindende) håndsoprækning. Hvis svaret klart en tendens mod den ene side eller den anden, vil dette gøre nogle mennesker pludselig mere villige til at gå på kompromis, der ikke er behov for en formel afstemning. Men den mest effektive måde er simpelthen at tilbyde en ny løsning, eller en ny synsvinkel på et gammelt forslag, så folk genoptage forbindelserne med de spørgsmål, i stedet for blot at gentage de samme argumenter.

I visse sjældne tilfælde kan alle enige om, at alle de kompromisløsninger er værre end nogen af de ikke-kompromis dem. Når det sker, stemme er mindre forkasteligt, både fordi det er mere sandsynligt at føre til en overlegen løsning, og fordi folk ikke vil være alt for ulykkelig uanset hvordan det viser sig. Selv da bør afstemningen ikke være forhastet. Diskussionen fører op til en afstemning er, hvad uddanner vælgerne, så stoppe denne diskussion tidligt kan sænke kvaliteten af resultatet.

(Bemærk, at dette råd til at være tilbageholdende med at kalde stemmer gælder ikke for ændringen-integration afstemning beskrevet i afsnittet «Stabiliserende en Release» i kapitel 7, Packaging, slipper, og Daily Development. Der stemme er mere af et kommunikations mekanisme, et middel til at registrere sit engagement i forandringsprocessen review-processen, så alle kan se, hvor meget gennemgå en given ændring har modtaget.)

Hvem Stemmer?

At have et valgsystem rejser spørgsmålet om vælgere: hvem får lov til at stemme? Dette har potentiale til at være et følsomt emne, fordi det tvinger projektet til officielt at anerkende nogle mennesker som værende mere involveret, eller som havende bedre dom, end andre.

Den bedste løsning er simpelthen at tage en eksisterende sondring begå adgang og vedhæfte stemmerettigheder privilegier til det. I projekter, der tilbyder både fuld og delvis commit adgang, afhænger spørgsmålet om, hvorvidt delvise committere kan stemme i høj grad af den proces, hvorved delvis commit adgang. Hvis projektet rækker ud liberalt, for eksempel som en måde at bevare mange tredjeparts-bidraget værktøjer i lageret, så bør det gøres klart, at delvis commit adgang er egentlig bare om at begå, ikke at stemme. Den omvendte implikation naturligt holder så godt: da fuld committere vil have stemme privilegier, skal de vælges ikke kun som programmører, men som medlemmer af vælgerne. Hvis nogen viser forstyrrende eller modarbejdende tendenser på postlisten, bør gruppen være meget forsigtige med at gøre ham en committer, selv om personen er teknisk dygtige.

Afstemningssystemet selv bør bruges til at vælge nye committere, både hele og delvise. Men her er et af de sjældne tilfælde, hvor hemmeligholdelse er hensigtsmæssigt. Du kan ikke have stemmer om potentielle committere posteret i en offentlig postliste, fordi ansøgerens følelser (og omdømme) kunne blive såret. I stedet den sædvanlige måde er, at en eksisterende committer indlæg til en privat postliste, der kun består af de øvrige committere, at foreslå, at nogen gives begå adgang. De øvrige committere sige deres mening frit, vel vidende diskussionen er privat. Ofte vil der ikke være nogen uenighed, og derfor ikke stemme nødvendig. Efter at have ventet et par dage for at sikre alle committer har haft en chance for at reagere, der har foreslået mails kandidatlandene og tilbyder ham begå adgang. Hvis der er uenighed, diskussion ensues som for ethvert andet spørgsmål, hvilket kan resultere i en afstemning. Til denne proces at være åben og ærlig, den omstændighed, at diskussionen finder sted på alle bør være hemmelig. Hvis personen er under overvejelse vidste det foregik, og derefter blev aldrig tilbudt commit adgang, kunne han konkludere, at han havde tabt afstemningen, og ville sandsynligvis føle sig såret. Selvfølgelig, hvis nogen eksplicit beder om commit adgang, så er der intet andet valg end at behandle forslaget og eksplicit acceptere eller afvise ham. Hvis det sidste, så skal det gøres så høfligt som muligt, med en klar forklaring: «Vi kunne godt lide din patch, men har ikke set nok af dem endnu,» eller «Vi sætter pris på alle dine patches, men de krævede betydelige justeringer før de kan anvendes, så vi ikke føler sig godt tilpas og giver dig begå adgang endnu. Vi håber, at dette vil ændre sig over tid, selv om. » Husk, hvad kunne du siger komme som et slag, afhængigt af personens grad af tillid. Prøv at se det fra deres synspunkt, som du skriver mail.

Fordi at tilføje en ny committer er mere følgeskader end de fleste andre engangs beslutninger, nogle projekter har særlige krav til afstemningen. For eksempel kan de kræve, at forslaget modtage mindst n positive stemmer og ingen negative stemmer, eller at et absolut flertal stemmer herfor. De præcise parametre er ikke vigtigt, det vigtigste idé er at få gruppen til at være forsigtig med at tilføje nye committere. Lignende eller endnu strengere, særlige krav kan gælde for stemmer for at fjerne en committer, selvom det vil forhåbentlig aldrig blive nødvendigt. Se afsnittet «committere» i kapitel 8, adm. Frivillige til mere på de ikke-stemmeberettigede aspekter af at tilføje og fjerne committere.

Afstemninger Versus Afstemninger

For visse typer af stemmer, kan det være nyttigt at udvide vælgerne. For eksempel, hvis udviklerne kan simpelthen ikke finde ud af, om en given grænseflade valg matcher den måde, folk faktisk bruger softwaren én løsning er at bede til alle abonnenter af projektets postlister at stemme. Disse er virkelig meningsmålinger snarere end synes, men udviklerne kan vælge at behandle resultatet som bindende. Som med enhver meningsmåling, skal du sørge for at gøre det klart for deltagerne, at der er en skrive-in option: hvis nogen tænker på en bedre løsning ikke tilbydes i meningsmåling spørgsmål, kan hendes reaktion vise sig at være det vigtigste resultat af valget .

Vetoer

Nogle projekter giver en særlig slags afstemning kendt som en veto. Et veto er en måde for en udvikler at sætte en stopper for en forhastet eller uovervejede forandring, i det mindste længe nok for alle at diskutere det mere. Tænk på et veto som et sted mellem en meget stærk indvending og en filibuster. Dets nøjagtige betydning varierer fra det ene projekt til det andet. Nogle projekter gør det meget vanskeligt at tilsidesætte et veto, mens andre tillader dem at burde vige for regelmæssig flertal, måske efter en tvungen forsinkelse for yderligere diskussion. Enhver veto bør ledsages af en grundig forklaring, et veto uden en sådan forklaring anses for bortfaldet ved ankomsten.

Med vetoer kommer problemet med veto misbrug. Sommetider udviklere er for ivrige efter at øge indsatsen ved at støbe en veto, når der virkelig alt, hvad der blev kaldt for var mere diskussion. Du kan forhindre veto misbrug ved at være meget tilbageholdende med at bruge vetoretten selv, og ved forsigtigt at kalde det ud, når en anden bruger sin veto for ofte. Hvis det er nødvendigt, kan du også minde den gruppe, der vetoer er bindende for kun så længe gruppe er enig de er-jo, hvis et klart flertal af udviklere vil have X, så X kommer til at ske en eller anden måde. Enten nedlægge veto bygherren vil tilbage ned, eller gruppen vil beslutte at svække betydningen af et veto.

Du kan se folk skrive «-1″ for at udtrykke et veto. Denne anvendelse kommer fra Apache Software Foundation, som har en meget struktureret afstemninger og veto proces, der er beskrevet i http://www.apache.org/foundation/voting.html. Apache standarder har spredt sig til andre projekter, og du vil se deres konventioner, der anvendes i varierende grad i en masse steder i open source-verdenen. Teknisk set betyder «-1″ ikke altid indikerer en formel veto selv efter de Apache standarder, men uformelt det normalt forstås et veto, eller i det mindste en meget stærk indvending.

Ligesom stemmer, kan vetoer tilbagevirkende kraft. Det er ikke okay at gøre indsigelse mod en veto med den begrundelse, at den pågældende ændring allerede er blevet begået, eller foranstaltninger, der træffes (medmindre det er noget uigenkaldeligt, som at sætte en pressemeddelelse). På den anden side, sent en vetoret, der ankommer uger eller måneder er ikke sandsynligt, at blive taget meget alvorligt og bør heller ikke være.

Skrive det hele ned

På et tidspunkt, kan antallet af konventioner og aftaler flyder rundt i dit projekt blive så stor, at du har brug for at optage det et eller andet sted. For at give et sådant dokument legitimitet, gør det klart, at det er baseret på postliste diskussioner og på aftaler, der allerede er i kraft. Som du skriver det, henvise til de relevante tråde i postlistearkiver, og når der er et punkt du ikke er sikker om, så spørg igen. Dokumentet bør ikke indeholde nogen overraskelser: Det er ikke kilden til de aftaler, det er blot en beskrivelse af dem. Selvfølgelig, hvis det er en succes, vil folk begynde at citere det som en kilde til autoritet i sig selv, men det betyder bare afspejler den samlede vilje gruppen præcist.

Dette er det dokument, der hentydes til i afsnittet «Developer Guidelines» i kapitel 2, Introduktion. Naturligvis, når projektet er meget ung, bliver du nødt til at fastsætte retningslinjer uden gavn af et længerevarende projekt historie at trække på. Men som udviklingen samfund modnes, kan du justere sproget for at afspejle den måde, tingene faktisk vise sig.

Forsøg ikke at være udtømmende. Intet dokument kan fange alt folk behøver at vide om at deltage i et projekt. Mange af de konventioner, et projekt udvikler sig altid forblive usagt, aldrig nævnt eksplicit, men følges af alle. Andre ting er simpelthen for oplagt at blive nævnt, og ville kun distrahere fra vigtig, men ikke indlysende materiale. For eksempel er der ingen mening skriftligt retningslinjer som «Vær høflig og respektfuld til andre på postlister, og ikke begynde at flamme krige» eller «Skriv ren, læsbar bug-fri kode.» Selvfølgelig disse ting er ønskelige, men da der er ingen tænkelig univers, hvor de måske ikke er ønskeligt, er de ikke værd at nævne. Hvis folk bliver uhøflige på postlisten, eller skrive buggy kode, er de ikke kommer til at stoppe, bare fordi projektet retningslinjer sagde til. Sådanne situationer skal behandles som de opstår, ikke ved tæppe formaninger at være god. På den anden side, hvis projektet har særlige retningslinjer om, hvordan man skriver god kode, såsom regler om dokumentation hver API i et bestemt format bør derefter disse retningslinjer nedskrives så fuldstændigt som muligt.

En god måde at afgøre, hvad der skal medtages, er at basere dokument om de spørgsmål, som nytilkomne stiller oftest, og på de klager erfarne udviklere gør oftest. Dette betyder ikke nødvendigvis, det skal blive til en FAQ ark-det sandsynligvis behov for en mere sammenhængende narrativ struktur end FAQs kan tilbyde. Men det bør følge den samme virkelighed-baserede princip om at imødegå de problemer, der rent faktisk opstår, snarere end dem du forventer kan opstå.

Hvis projektet er en menneskekærlig diktatur, eller har officerer udstyret med særlige beføjelser (præsident, stol, uanset), så dokumentet er også en god lejlighed til at kodificere arv procedurer. Sommetider kan være så simpelt som at nævne bestemte mennesker som udskiftninger i tilfælde BD pludselig forlader projektet eller anden grund. Generelt, hvis der er en BD, kan det kun BD slippe af sted med at navngive en efterfølger. Hvis der bliver valgt officerer, så nominering og valgproceduren, der blev brugt til at vælge dem i første omgang bør beskrives i dokumentet. Hvis der ikke var nogen procedure oprindeligt, så få enighed om en procedure på postlisterne, før du skriver om det. Folk kan til tider være ømskindet om hierarkiske strukturer, så emnet skal håndteres med følsomhed.

Måske det vigtigste er at gøre det klart, at reglerne kan blive revurderet. Hvis de konventioner, der er beskrevet i dokumentet begynder at hæmme projektet, minde om, at det formodes at være et levende udtryk for koncernens intentioner, ikke en kilde til frustration og blokering. Hvis nogen gør det til en vane af uretmæssigt beder om regler, der skal op til fornyet overvejelse, hver gang de regler kommer i hendes måde, behøver du ikke altid nødt til at debattere det med hende nogle gange tavshed er den bedste taktik. Hvis andre mennesker er enige med klagerne, vil de kime i, og det vil være indlysende, at noget skal ændres. Hvis ingen andre er enig, så vil personen ikke får meget respons, og reglerne vil forblive som de er.

To gode eksempler på projekter retningslinjer er de Subversion EF Guide på http://subversion.apache.org/docs/community-guide/, og Apache Software Foundation styreformer dokumenter, på http://www.apache.org/foundation / hvordan-det-works.html og http://www.apache.org/foundation/voting.html. ASF er virkelig en samling af software-projekter, juridisk organiseret som en almennyttig organisation, så dens dokumenter tendens til at beskrive ledelsesprocedurer mere end udviklings konventioner. De er stadig værd at læse, selv om, fordi de repræsenterer den akkumulerede oplevelse af en masse open source-projekter.

Kapitel 5. Penge

I dette kapitel undersøges, hvordan man sætter finansieringen til en fri software-miljø. Det er ikke kun rettet mod udviklere, der bliver betalt for at arbejde på fri software-projekter, men også på deres ledere, der har brug for at forstå den sociale dynamik i udviklingsmiljøet. I de følgende afsnit, er adressaten («dig») formodes at være enten et lønnet udvikler, eller en, der håndterer den slags udviklere. Rådgivningen vil ofte være de samme for begge, når det ikke er, vil den tiltænkte målgruppe gøres klart fra konteksten.

Corporate finansiering af fri software udvikling er ikke et nyt fænomen. En masse udvikling har altid været uformelt subsidieret. Når en systemadministrator skriver et netværk analyse værktøj til at hjælpe hende gøre hendes job, så indlæg det online og får fejlrettelser og har bidrag fra andre systemadministratorer, hvad der er sket, er, at en uofficiel Konsortiet er blevet dannet. Konsortiets midler kommer fra systemadministratorer lønninger, og dens kontorplads og båndbredde er doneret, omend ubevidst, af de organisationer, de arbejder for. Disse organisationer drage fordel af investeringen, selvfølgelig, selv om de måske ikke er institutionelt klar over det i første omgang.

Forskellen i dag er, at mange af disse bestræbelser er ved at blive formaliseret. Virksomheder er blevet bevidste om fordelene ved open source software, og begyndte at involvere sig mere direkte i sin udvikling. Udviklere har også kommet til at forvente, at virkelig vigtige projekter vil tiltrække mindst donationer, og måske endda langsigtede sponsorer. Mens tilstedeværelsen af penge ikke har ændret grundlæggende dynamik i fri software-udvikling, har det i høj grad ændret skalaen, hvor tingene sker, både med hensyn til antallet af udviklere og tid-per-developer. Det har også haft indvirkning på, hvordan projekterne er organiseret, og hvordan de parter, der er involveret i dem interagere. De spørgsmål er ikke kun om, hvordan pengene bliver brugt, eller hvordan investeringsafkastet måles. De er også om ledelse og proces: hvordan kan de hierarkiske kommandostrukturer selskaber og de semi-decentraliserede frivillige samfund af fri software-projekter arbejde produktivt med hinanden? Vil de blive enige om hvad «produktivt» betyder?

Finansiel opbakning er generelt hilst velkommen af open source-udvikling fællesskaber. Det kan reducere et projekt sårbarhed over for de kræfter Chaos, som feje så mange projekter, før de virkelig komme væk fra jorden, og derfor kan det gøre folk mere villige til at give den software en chance, de føler, de er at investere deres tid i noget, der vil stadig være omkring seks måneder fra nu. Det er trods alt troværdighed smitsom, til et punkt. Når fx IBM støtter et open source projekt, folk temmelig meget antage projektet vil ikke få lov til at mislykkes, og deres deraf følgende vilje til at afsætte indsats for at det kan gøre, at en selvopfyldende profeti.

Men finansieringen bringer også en opfattelse af kontrol. Hvis ikke håndteres forsigtigt, kan penge opdele et projekt i in-gruppen og ud-gruppe udviklere. Hvis de ulønnede frivillige får en fornemmelse af, at design beslutninger eller funktion tilføjelser er simpelthen tilgængelige til den højestbydende, vil de hovedet ud til et projekt, der virker mere som et meritokrati og mindre som ulønnet arbejdskraft til en andens fordel. De kan aldrig klage åbenlyst på postlisterne. I stedet vil der simpelthen være mindre og mindre støj fra eksterne kilder, som de frivillige efterhånden holde op med at blive taget alvorligt. Den brummer af mindre aktivitet vil fortsætte, i form af fejlrapporter og lejlighedsvise små rettelser. Men der vil ikke være nogen store kode bidrag eller udenfor deltagelse i design diskussioner. Folk fornuft, hvad der forventes af dem, og leve op (eller ned) til disse forventninger.

Selvom penge skal bruges med omhu, betyder ikke, det kan ikke købe indflydelse. Kan det helt sikkert. Tricket er, at det ikke kan købe indflydelse direkte. I en simpel kommerciel transaktion, handel du penge til hvad du ønsker. Hvis du har brug for en funktion tilføjet, du underskrive en kontrakt, betale for det, og det bliver gjort. I et open source-projekt, er det ikke så enkelt. Du kan underskrive en kontrakt med nogle udviklere, men de ville være at narre sig selv-og du-hvis de garanteret, at det arbejde, du har betalt for, ville blive accepteret af udviklingen samfund, blot fordi du har betalt for det. Arbejdet kan kun accepteres på sine egne fortjenester, og hvordan det passer ind i samfundets vision for softwaren. Du kan have nogle indflydelse på denne vision, men du vil ikke være den eneste stemme.

Så penge kan ikke købe indflydelse, men det kan købe ting, der fører til at påvirke. Det mest oplagte eksempel er programmører. Hvis gode programmører er ansat, og de hængende længe nok til at få erfaring med software og troværdighed i samfundet, så de kan påvirke projektet på samme måde som ethvert andet medlem. De vil have en afstemning, eller hvis der er mange af dem, vil de have en stemme blok. Hvis de bliver overholdt i projektet, vil de have indflydelse end blot deres stemmer. Der er ikke behov for betalte udviklere til at skjule deres motiver, enten. Efter alle ønsker alle, der ønsker en ændring i den software, det for en grund. Din virksomheds begrundelse er ikke mindre legitim end nogen andens. Det er bare at vægten givet til din virksomheds mål vil blive afgjort af dets repræsentanter status i projektet, ikke af selskabets størrelse, budget eller forretningsplan.

Former for inddragelse

Der er mange forskellige årsager open source-projekter får støtte. Punkterne i denne liste ikke udelukker hinanden, ofte et projekts finansielle opbakning vil medføre flere eller endda alle, disse motivationer:

Byrdefordeling
Separate organisationer med relateret software behov ofte befinder sig duplikere indsats, enten ved redundant skrive lignende kode in-house, eller ved at købe lignende produkter fra leverandører af proprietære programmer. Når de indser, hvad der foregår, organisationerne kan samle deres ressourcer og skabe (eller deltage i) et open source-projekt er skræddersyet til deres behov. Fordelene er indlysende: udgifter til udvikling er delte, men de fordele tilfalder alle. Selv om denne situation synes mest intuitive for nonprofits, kan det gøre strategisk sans selv for for-profit konkurrenter.

Eksempler: http://www.openadapter.org/, http://www.koha.org/

Forøgende tjenester
Når en virksomhed sælger tjenester, der er afhængige af, eller gøres mere attraktiv ved, især open source-programmer, er det naturligvis i dette selskabs interesse at sikre, at disse programmer er aktivt vedligeholdt.

Eksempel: CollabNet støtte af http://subversion.tigris.org/ (disclaimer: det er min dag job, men det er også et perfekt eksempel på denne model).

Støtte hardware salg
Værdien af computere og it-komponenter er direkte relateret til mængden af software til rådighed for dem. Hardwareleverandører-ikke bare hele maskinpistoler leverandører, men også beslutningstagere i perifere enheder og mikrochips, har fundet, at have høj kvalitet gratis software til at køre på deres hardware er vigtigt for kunderne.

Underminering en konkurrent
Sommetider virksomheder støtter en bestemt open source projekt som et middel til at underminere en konkurrents produkt, som måske eller måske ikke være open source selv. Spise væk på en konkurrents markedsandel er normalt ikke den eneste grund til at blive involveret med en open source-projekt, men det kan være en faktor.

Eksempel: http://www.openoffice.org/ (nej, er dette ikke den eneste grund OpenOffice eksisterer, men softwaren i det mindste delvis et svar på Microsoft Office).

Marketing
Under dit firma forbundet med en populær open source program kan simpelthen godt brand management.

Dual-licenser
Dual-licenser er den praksis at tilbyde software under en traditionel proprietær licens til kunder, der ønsker at videresælge det som en del af en proprietær anvendelse af deres egne, og samtidig under en gratis licens til dem, der er villige til at bruge det under open source vilkår (se afsnittet «Dual licensordninger» i kapitel 9, licenser, copyrights og patenter). Hvis open source udvikler-community er aktiv, software får fordelene ved wide-area debugging og udvikling, men selskabet stadig får en royalty strøm til at støtte nogle fuldtidsansatte programmører.

To kendte eksempler er MySQL, skaberne af den databasesoftware af samme navn, og Sleepycat, som tilbyder distributioner og støtte til Berkeley Database. Det er ingen tilfældighed, at de er begge database selskaber. Database-software tendens til at blive integreret i applikationer i stedet markedsføres direkte til brugerne, så det er meget velegnet til dual-licensmodel.

Donationer
Et meget udbredte projekt kan undertiden få betydelige bidrag, fra både enkeltpersoner og organisationer, blot ved at have en online donation knap, eller nogle gange ved at sælge mærkevarer merchandise såsom kaffekrus, T-shirts, musemåtter, osv. En lille advarsel: hvis dit projekt accepterer donationer, planlægge, hvordan pengene skal bruges, før det kommer i, og state planerne på projektets hjemmeside. Diskussioner om, hvordan man afsætte penge tendens til at gå meget mere glat, når den holdes inden der faktiske penge at bruge, og alligevel, hvis der er væsentlige uoverensstemmelser, er det bedre at finde ud af, mens det stadig akademisk.

En bidragyder forretningsmodel er ikke den eneste faktor i hvordan det relaterer til et open source community. Den historiske forhold mellem de to også spørgsmål: Har virksomheden påbegynde projektet, eller er det at tilslutte en eksisterende udviklingsindsats? I begge tilfælde vil finansieringskilde nødt til at tjene troværdighed, men ikke overraskende, at der er en smule mere indtjening, der skal gøres i det sidstnævnte tilfælde. Organisationen skal have klare mål med hensyn til projektet. Er virksomheden forsøger at holde en lederposition, eller blot forsøger at være en stemme i samfundet, til at vejlede, men ikke nødvendigvis regulerer projektets retning? Eller er det bare vil have et par committere rundt, stand til at løse kundernes bugs og få de ændringer i det offentlige fordeling uden dikkedarer?

Husk på disse spørgsmål i tankerne, som du læse retningslinjerne, der følger. De er beregnet til at gælde for enhver form for organisatorisk deltagelse i en fri software-projekt, men hvert projekt er en menneskelig miljø, og derfor er ikke to er nøjagtig ens. Til en vis grad, vil du altid nødt til at spille efter gehør, men efter disse principper vil øge sandsynligheden for tingene dreje ud af den måde, du ønsker.

Leje for Long Term

Hvis du administrerer programmører på et open source-projekt, holde dem der længe nok, at de får både teknisk og politisk ekspertise-et par år, på et minimum. Selvfølgelig, intet projekt, hvad enten åbne eller lukkede source,. Fordele ved at bytte programmører i og ud for ofte Behovet for en nybegynder at lære reb hver gang ville være en afskrækkende i ethvert miljø. Men straffen er endnu stærkere i open source-projekter, fordi udgående udviklere tage med dem ikke blot deres kendskab til koden, men også deres status i samfundet og de menneskelige relationer, de har lavet der.

Troværdigheden en udvikler har akkumuleret kan ikke overføres. Hvis du vil vælge det mest oplagte eksempel, kan en indkommende udvikler ikke arve commit adgang fra en udgående én (se afsnittet «Penge kan ikke købe You Love» senere i dette kapitel), så hvis den nye bygherre ikke allerede har begå adgang, vil han nødt til at indsende patches indtil han gør. Men begå adgang er kun de mest målbare manifestation af tabt indflydelse. En lang tid udvikler også kender alle de gamle argumenter, der er blevet hashet og rehashed på diskussionslister. En ny udvikler, der ikke har nogen erindring om disse samtaler, kan forsøge at hæve de emner igen, hvilket fører til et tab af troværdighed for din organisation, de andre kan undre «Kan de ikke huske noget?» En ny udvikler vil også have nogen politisk fornemmelse for projektets personligheder, og vil ikke være i stand til at påvirke udviklingen retninger så hurtigt eller så glat som en, der har været omkring en lang tid.

Træn nytilkomne gennem et program af superviseret engagement. Den nye udvikler bør være i direkte kontakt med offentligheden udvikling samfund fra den allerførste dag, der starter ud med fejlrettelser og oprydning opgaver, så han kan lære koden base og få et ry i samfundet, men ikke gnist nogen lang og involverede design diskussioner. Alt imens, hvis en eller flere erfarne udviklere til rådighed for afhøring og bør læse alle indlæg den nytilkomne gør til de udviklingsmål lister, selvom de er i tråde, at de erfarne udviklere normalt ikke ville være opmærksom på. Dette vil hjælpe gruppen spot potentielle klipper før den nyankomne strander. Private bag-the-scenes opmuntring og henvisninger kan også hjælpe en masse, især hvis den nytilkomne er ikke vant til massivt parallelle peer review af hans kode.

Når CollabNet hyrer en ny udvikler til at arbejde på Subversion, sætter vi os ned sammen og plukke nogle åbne bugs for den nye person til at skære sine tænder på. Vi vil diskutere de tekniske omrids af de løsninger, og derefter tildele mindst én erfaren udvikler til (offentligt) gennemgå patch, at den nye udvikler vil (også offentligt) post. Vi typisk ikke engang se på plasteret, før den vigtigste udvikling liste ser det, selv om vi kunne, hvis der var nogle grund til. Det vigtige er, at den ny udvikler gå gennem processen med offentlig revision, lære kodebase samtidig bliver vant til at modtage kritik fra komplet fremmede. Men vi forsøger at koordinere timingen så vores egen anmeldelse kommer umiddelbart efter udstationering af plasteret. Herved bliver den første revision af listen ser, er vores, som kan hjælpe slå tonen an for de andres anmeldelser. Det bidrager også til tanken om, at denne nye person er at blive taget alvorligt: hvis andre kan se, at vi sætter i gang for at give detaljerede vurderinger, med grundige forklaringer og referencer til de arkiver, hvor det er relevant, vil de forstå, at en formular af uddannelsen, der foregår, og at det formentlig betyder en langsigtet investering. Dette kan gøre dem mere positivt stemt over for at udvikleren, i det mindste i den grad at tilbringe lidt ekstra tid besvare spørgsmål og gennemgå patches.

Vises som mange, ikke som One

Dine udviklere bør stræbe efter at blive vist i projektets offentlige fora som individuelle deltagere, snarere end som en monolitiske corporate tilstedeværelse. Det er ikke fordi der er nogle negative konnotationer forbundet med monolitiske virksomhedernes tilstedeværelser (godt, måske er der, men det er ikke hvad denne bog handler om). Snarere er det fordi individer er den eneste form for virksomhedens open source-projekter er strukturelt rustet til at beskæftige sig med. En individuel bidragyder kan have diskussioner, indsende patches, erhverve troværdighed, afstemning, og så videre. En virksomhed kan ikke.

Ved at opføre sig på en decentraliseret måde undgår du stimulerende centralisering af opposition. Lad dine udviklere er uenige med hinanden på postlisterne. Motivér dem til at gennemgå hinandens kode så ofte, og så offentligt, som de ville nogen andens. Afskrække dem fra altid at stemme som en blok, for hvis de gør det, kan andre begynder at føle, at lige om generelle principper, bør der være en organiseret indsats for at holde dem i skak.

Der er en forskel mellem faktisk at være decentral og simpelthen at stræbe efter at blive vist på den måde. Under visse omstændigheder kan have dine udviklere opfører sig koncert være ganske nyttigt, og de bør være parat til at koordinere bag kulisserne, når det er nødvendigt. F.eks. Når du foretager et forslag, der har flere mennesker kime ind med aftale tidligt kan hjælpe det sammen, ved at give indtryk af en voksende enighed Andre vil føle, at forslaget har momentum, og at hvis de skulle objekt, vil vedkommende blive stoppe det momentum. Således vil folk kun gøre indsigelse, hvis de har en god grund til at gøre det. Der er intet galt med at skabe enighed som denne, så længe indsigelse er stadig tages alvorligt. De offentlige manifestationer af en privat aftale er ikke mindre oprigtig for at have været koordineret på forhånd, og er ikke skadelige, så længe de ikke er vant til prejudicially snus ud modsatrettede argumenter. Deres formål er alene at hæmme den slags mennesker, der gerne gøre indsigelse bare at holde sig i form, se afsnittet der hedder «jo blødere Topic, jo længere debat» i kapitel 6, kommunikationschef for mere om dem.

Være åben om din motivation

Være så åben om din organisations mål som du kan uden at gå på kompromis med forretningshemmeligheder. Hvis du ønsker, at projektet til at erhverve en bestemt funktion, fordi, siger, dine kunder har været råber på det, bare sige så direkte på postlisterne. Hvis kunderne ønsker at forblive anonym, da det undertiden er tilfældet, så i det mindste spørge dem, om de kan bruges som unavngivne eksempler. Jo mere den offentlige udviklingsbistand samfund kender om hvorfor du ønsker, hvad du ønsker, jo mere komfortabel de vil være med uanset hvad du foreslår.

Dette er i modstrid med instinkt-så let at erhverve, så svært at ryste off-at viden er magt, og at jo flere andre vide om dine mål, jo mere kontrol, de har over dig. Men det instinkt ville være forkert her. Ved offentligt fortaler for funktionen (eller bugfix, eller hvad det er), har du allerede lagt dine kort på bordet. Det eneste spørgsmål er nu, om det vil lykkes for at lede samfundet til at dele dit mål. Hvis du blot angive, at du ønsker det, men kan ikke give konkrete eksempler på, hvorfor, Deres argument er svag, og folk vil begynde at ane en skjult dagsorden. Men hvis du giver bare et par virkelige verden scenarier, der viser, hvorfor den foreslåede funktion er vigtig, som kan have en dramatisk effekt på debatten.

For at se hvorfor dette er tilfældet, overveje alternativet. Alt for ofte, debatter om nye funktioner eller nye retninger er lange og trættende. De argumenter folk avancere ofte reduceres til «jeg personligt ønsker X», eller den altid populære «I mine mange års erfaring som software designer, X er ekstremt vigtigt at brugere / et ubrugelig frill, der vil behage nogen.» Forudsigeligt, fraværet af den virkelige verden brugsdata hverken forkorter eller temperament sådanne debatter, men i stedet giver dem mulighed for at drive længere og længere fra enhver fortøjning i den faktiske brugeroplevelse. Uden nogle modvægt, er det endelige resultat så stor sandsynlighed for ikke at blive bestemt af hvem var den mest veltalende, eller den mest vedholdende, eller den øverste.

Som en organisation med rigelige kundedata til rådighed, har du mulighed for at give netop sådan en modvægt. Du kan være en kanal for information, der ellers ikke har mulighed for at nå udvikling samfund. Det forhold, at oplysningerne understøtter dine ønsker er ikke noget at være flov over. De fleste udviklere ikke individuelt har meget bred erfaring med hvordan den software, de skriver anvendes. Hver udvikleren bruger softwaren i sin egen idiosynkratiske måde, for så vidt angår andre brugsmønstre gå, hun bygger på intuition og gætværk, og inderst inde, hun ved det. Ved at give troværdige oplysninger om et betydeligt antal brugere, er du give offentligheden udvikling samfund noget i stil med ilt. Så længe du præsenterer det rigtigt, vil de bifalder det med begejstring, og det vil drive tingene i den retning, du ønsker at gå.

Nøglen er naturligvis, præsentere er det rigtige. Det vil aldrig gøre for at insistere på, at bare fordi du behandler et stort antal brugere, og fordi de har brug for (eller tror de har brug for) en given funktion, derfor din løsning bør gennemføres. I stedet bør du fokusere dine indledende indlæg om problemet, snarere end på en bestemt løsning. Beskriv i detaljer de oplevelser dine kunder støder, tilbyde så meget analyse som du har til rådighed, og så mange fornuftige løsninger, som du kan tænke på. Når folk begynder at spekulere om effektiviteten af forskellige løsninger, kan du fortsætte med at trække på dine data for at understøtte eller afkræfte, hvad de siger. Du kan have en særlig løsning i tankerne hele tiden, men ikke udskille det ud for særlig opmærksomhed i første omgang. Dette er ikke bedrag, det er simpelthen standard «ærlig mægler» adfærd. Efter alt, er din sande mål at løse problemet, en løsning er blot et middel til dette formål. Hvis den løsning, du foretrækker virkelig er overlegen, vil andre udviklere erkende, at på egen hånd til sidst-og så vil de komme bag det af egen fri vilje, som er meget bedre end du browbeating dem til at gennemføre det. (Der er også den mulighed, at de vil komme i tanke om en bedre løsning.)

Dette er ikke til at sige, at du ikke kan nogensinde kommer ud til fordel for en specifik løsning. Men du skal have tålmodighed til at se den analyse, du allerede har gjort internt gentaget på de offentlige udviklings-postlisterne. Må ikke skrive at sige «Ja, vi har været over alt det her, men det virker ikke af grunde, A, B og C. Når du kommer helt ned til det, er den eneste måde at løse dette er … » Problemet er ikke så meget, at det lyder arrogant som at det giver indtryk af, at du allerede har brugt en ukendt (men, vil folk formoder, stor) mængde af analytiske ressourcer til dette problem, bag lukkede døre. Det gør det synes som om indsatsen har stået på, og måske beslutninger, der træffes, at offentligheden ikke er indviet i, og det er en opskrift på vrede.

Naturligvis, du ved, hvor meget arbejde du har helliget problemet internt, og at viden er, på en måde, en ulempe. Det sætter dine udviklere i en lidt anden mental plads end alle andre på postlisterne, reducerer deres evne til at se tingene fra den synsvinkel af dem, der endnu ikke har tænkt på det problem så meget. Jo tidligere du kan få alle andre tænke over tingene på samme vilkår, som du gør det, vil jo mindre denne distancering effekt være. Denne logik gælder ikke kun for de enkelte tekniske situationer, men det bredere mandat til at gøre dine mål så klart som du kan. Det ukendte er altid mere destabiliserende end den kendte. Hvis folk forstå, hvorfor du ønsker, hvad du ønsker, vil de føle sig trygge ved at tale til dig, selv når de er uenige. Hvis de ikke kan finde ud af hvad der gør dig kryds, vil de antage det værste, i det mindste noget af tiden.

Du vil ikke være i stand til at offentliggøre alt, selvfølgelig, og folk vil ikke forvente, at du. Alle organisationer har hemmeligheder, måske for-profit har flere af dem, men nonprofits har dem også. Hvis du skal ind for en vis kursus, men kan ikke afsløre noget om, hvorfor, så bare tilbyde de bedste argumenter, du kan under dette handicap, og acceptere det faktum, at du måske ikke har så meget indflydelse som du ønsker i diskussionen. Dette er en af de kompromiser, du foretager med henblik på at få en udvikling samfund ikke på din lønningsliste.

Penge kan ikke købe du elsker

Hvis du er en betalt udvikler på et projekt, og indstil derefter retningslinjer tidligt på om hvad pengene kan og ikke kan købe. Dette betyder ikke, du behøver at skrive to gange om dagen til postlisterne gentager din ædle og ubestikkelig karakter. Det betyder blot, at du skal være på udkig efter muligheder for at dæmpe de spændinger, der måtte blive oprettet ved penge. Du behøver ikke at starte ud at antage, at de spændinger er der, du behøver at demonstrere en bevidsthed om, at de har potentiale til at opstå.

Et perfekt eksempel på dette kom op i Subversion projektet. Subversion blev startet i 2000 af CollabNet, som har været projektets primære bidragyder siden sin fremkomst at aflønne flere udviklere (disclaimer: jeg er en af dem). Kort efter projektet startede, har vi hyret en anden udvikler, Mike Pilato, at slutte sig til indsatsen. På det tidspunkt havde kodning allerede begyndt. Selv Subversion var stadig meget i de tidlige stadier, det allerede havde en udvikling samfund med et sæt grundregler.

Mike ankomst rejst et interessant spørgsmål. Subversion allerede haft en politik om, hvordan en ny udvikler får commit adgang. Først han indgiver nogle patches til udviklingen postliste. Efter nok patches er gået for de øvrige committere at se, at den nye bidragyder ved, hvad han laver, nogen foreslår, at han bare begå direkte (dvs. forslag er privat, som beskrevet i afsnittet «committere»). Under forudsætning af committere enige, en af dem mails den nye udvikler og tilbyder ham direkte begå adgang til projektets repository.

CollabNet havde hyret Mike specielt til at arbejde på Subversion. Blandt dem, der allerede er kendte ham, var der ingen tvivl om hans kodning færdigheder eller hans vilje til at arbejde på projektet. Endvidere frivillige udviklere havde et meget godt forhold til de CollabNet medarbejdere, og højst sandsynligt ikke ville have haft noget imod, hvis vi bare havde givet Mike commit adgang den dag han blev ansat. Men vi vidste, at vi ville være at sætte en præcedens. Hvis vi givet Mike commit adgang fiat, ville vi sige, at CollabNet havde ret til at ignorere projektets retningslinjer, simpelthen fordi det var den primære finansieringskilde. Mens skader fra dette ikke nødvendigvis ville være umiddelbart indlysende, ville det efterhånden resultere i ulønnede udviklere føler sig holdt udenfor. Andre mennesker er nødt til at tjene deres tilsagn adgang-CollabNet bare køber det.

Så Mike enige om at starte sin ansættelse hos CollabNet som enhver anden frivillig bygherren, uden commit adgang. Han sendte patches til den offentlig postliste, hvor de kunne være, og var revideret af alle. Vi sagde også på den liste, som vi gjorde tingene på denne måde bevidst, så der kunne være nogen mangler det punkt. Efter et par uger af fast aktivitet af Mike, (jeg kan ikke huske om det var en CollabNet udvikler eller ej) nogen foreslog ham for commit adgang, og han blev accepteret, da vi vidste, at han ville være.

Den slags konsistens får du en troværdighed, at penge aldrig kunne købe. Og troværdighed er en værdifuld valuta at have i de tekniske drøftelser: det er immunisering mod at have sine motiver spørgsmålstegn senere. I varmen i argumentet, vil folk nogle gange lede efter ikke-tekniske måder at vinde kampen. Projektets primære bidragsydere, på grund af sin dybe engagement og indlysende bekymring over de retninger projektet tager, præsenterer en bredere målgruppe end de fleste. Ved at være samvittighedsfulde at overholde alle projektets retningslinjer lige fra starten, gør bidragyder selv samme størrelse som alle andre.

(Se også Danese Coopers blog på http://blogs.sun.com/roller/page/DaneseCooper/20040916 for en lignende historie om commit adgang. Cooper var dengang Sun Microsystems «Open Source Diva»-Jeg tror det var hendes officielle titel -og i blogindlægget, beskriver hun, hvordan Tomcat udvikling samfund fik solen til at holde sine egne udviklere til de samme forplig-adgang standarder som de ikke-Sun udviklere.)

Behovet for finansieringskilderne at spille efter de samme regler som alle andre betyder, at den godgørende diktatur styringsmodel (se afsnittet «velvillige diktatorer» i kapitel 4, sociale og politiske Infrastructure) er lidt sværere at trække ud i nærværelse af finansieringen , især hvis diktatoren arbejder for den primære bidragyder. Da et diktatur har få regler, er det svært for finansieringskilde at bevise, at det er overholder EU-standarder, selv når det er. Det er bestemt ikke umuligt, det kræver blot en projektleder, der er i stand til at se tingene fra synspunkt af de eksterne udviklere, samt at der i Funder, og handle derefter. Selv da er det nok en god idé at have et forslag til ikke-diktatorisk styring sidder i baglommen, klar til at blive bragt ud øjeblikket er der tegn på udbredt utilfredshed i samfundet.

Kontraherende

Kontraheret arbejde skal håndteres forsigtigt i fri software-projekter. Ideelt set, du vil have en entreprenør arbejde for at blive accepteret af fællesskabet og foldet ind i offentlig distribution. I teorien ville det ikke ligegyldigt hvem entreprenøren er, så længe hans arbejde er godt og opfylder projektets retningslinjer. Teori og praksis kan undertiden matche, også: en komplet fremmed, der dukker op med en god patch vil generelt være i stand til at få det ind i softwaren. Problemet er, at det er meget svært at producere en god patch til en ikke-triviel forøgelse eller ny funktion, mens virkelig er en komplet fremmed, skal man først drøfte det med resten af projektet. Varigheden af denne diskussion ikke præcist kan forudsiges. Hvis entreprenøren er timelønnet, kan du ende med at betale mere, end du forventede, hvis han er betalt et fast beløb, kan han ende med at gøre mere arbejde, end han har råd til.

Der er to måder omkring dette. Den foretrukne måde er at lave et kvalificeret gæt om længden af den debat, som er baseret på tidligere erfaringer, tilføje i nogle polstring til fejl, og basere den kontrakt på det. Det hjælper også til at opdele problemet i lige så mange små, uafhængige bidder som muligt, for at øge forudsigeligheden af hvert stykke. Den anden måde er at kontrahere udelukkende for levering af et plaster, og behandle patch accept i det offentlige projekt som en særskilt sag. Så bliver det meget nemmere at skrive kontrakten, men du sidder fast med byrden af at opretholde en privat patch til, så længe du afhænger af softwaren, eller i det mindste så længe det tager dig at få det plaster eller tilsvarende funktionalitet i hovedspor. Selvfølgelig, selv med den foretrukne måde kan selve kontrakten ikke kræve, at plasteret blive accepteret i koden, for det ville indebære at sælge noget, der ikke er til salg. (Hvad hvis resten af projektet uventet beslutter ikke at støtte funktionen?) Kan imidlertid kontrakten kræve en bona fide indsats for at få ændringen accepteret af samfundet, og at det forpligter til lageret, hvis samfundet er enig med det . For eksempel, hvis projektet har skrevet standarder for kodeændringer kan kontrakten henvise disse standarder og præcisere, at arbejdet skal opfylde dem. I praksis ofte virker det den måde alle forhåbninger.

Den bedste taktik for vellykket ordregivende er at leje en af projektets udviklere-fortrinsvis en committer-som entreprenøren. Dette kan virke som en form for indkøbsadfærd indflydelse, og, ja, det er. Men det er ikke så korrupt, som det måske ser ud. En udvikler indflydelse i projektet skyldes primært kvaliteten af hans kode og til hans interaktion med andre udviklere. Det faktum, at han har en kontrakt for at få visse ting gjort, ikke hæve sin status på nogen måde, og ikke sænke det enten, selvom det kan gøre folk undersøge ham mere omhyggeligt. De fleste udviklere ville ikke risikere deres langsigtede position i projektet ved at bakke en uhensigtsmæssig eller almindeligt uglesete ny funktion. Faktisk bør en del af hvad du får, eller får, når du lejer en sådan entreprenør er råd om, hvad slags ændringer vil blive accepteret af fællesskabet. Du får også en lille forskydning i projektets prioriteter. Fordi prioritering er bare et spørgsmål om, hvem der har tid til at arbejde på hvad, hvornår du betaler for nogen tid, du få deres arbejde til at gå op i prioritetskøen en smule. Dette er et godt forstået kendsgerning blandt erfarne open source-udviklere, og i det mindste nogle af dem vil lægge vægt på entreprenørens arbejde, blot fordi det ser ud som det kommer til at få gjort, så de ønsker at hjælpe det bliver gjort rigtigt. Måske vil de ikke skrive noget af koden, men de vil stadig diskutere udformningen og gennemgå koden, som begge kan være meget nyttig. Af alle disse grunde er entreprenøren bedst trukket fra rækken af dem, der allerede er involveret i projektet.

Dette umiddelbart rejser to spørgsmål: Bør kontrakter nogensinde være privat? Og når de ikke er, bør du bekymre dig om at skabe spændinger i samfundet ved, at du har indgået kontrakt med nogle udviklere og ikke andre?

Det er bedst at være åben om kontrakter, når du kan. Ellers kan entreprenørens adfærd synes mærkeligt at andre i samfundet, måske er han pludselig gav uforklarligt høj prioritet til features han aldrig vist interesse i fortiden. Når folk spørger ham, hvorfor han vil have dem nu, hvordan kan han svare overbevisende, hvis han ikke kan tale om det faktum, at han er blevet ansat til at skrive dem?

Samtidig bør hverken du eller entreprenøren handle, som om andre skal behandle din arrangement som en big deal. Alt for ofte har jeg set entreprenører vals på en udvikling liste med den holdning, at deres stillinger bør tages mere alvorligt, blot fordi de bliver betalt. Den slags holdninger signaler til resten af projektet, at entreprenøren angår den omstændighed af kontrakten, i modsætning til den kode, der følger af kontrakten, for at være det vigtigste. Men fra de andre udviklere synspunkt, kun er koderne spørgsmål. På alle tidspunkter, bør fokus holdes på tekniske spørgsmål, ikke på oplysninger om, hvem der betaler hvem. For eksempel håndtag en af udviklerne i Subversion samfund ordregivende i en særlig yndefuld måde. Mens diskutere hans kodeændringer i IRC, vil han nævne som en sidebemærkning (ofte i en privat bemærkning, en IRC PRIVMSG, at en af de andre committere), at han bliver betalt for hans arbejde med denne særlige fejl eller funktion. Men han også konsekvent giver indtryk af, at han gerne vil arbejde på, at forandring alligevel, og at han er glad for penge gør det muligt for ham at gøre det. Han kan eller ikke kan afsløre hans kundens identitet, men i hvert fald, at han ikke dvæle ved kontrakten. Hans bemærkninger om det er bare en pryd for en ellers teknisk diskussion om, hvordan man får noget gjort.

Dette eksempel viser en anden grund til hvorfor det er godt at være åben omkring kontrakter. Der kan være flere organisationer sponsorerer kontrakter på et givet open source-projekt, og hvis hvert ved, hvad de andre prøver at gøre, kan de være i stand til at samle deres ressourcer. I ovenstående tilfælde er projektet største bidragyder (CollabNet) ikke involveret på nogen måde med disse akkorder, men vel vidende, at en anden person sponsorerer visse fejlrettelser tillader CollabNet at omdirigere sine ressourcer til andre bugs, hvilket resulterer i øget effektivitet for projektet som helhed.

Vil andre udviklere harmes, at nogle bliver betalt for at arbejde på projektet? Generelt nej, især når dem, der er betalt er etableret, godt respekterede medlemmer af samfundet alligevel. Ingen forventer, at lønarbejde skal fordeles ligeligt mellem alle de committere. Folk forstår vigtigheden af langsigtede relationer: de usikkerheder, der er involveret i ordregivende er sådan, at når du finder en, du kan arbejde pålideligt med, ville du være tilbageholdende med at skifte til en anden person bare af hensyn til upartiskhed. Tænk på det på denne måde: den første gang du leje, vil der ikke være nogen klager, fordi klart du skulle vælge en person, det er ikke din skyld, du kan ikke ansætte alle. Senere, når du lejer den samme person en anden gang, det er bare almindelig sund fornuft: du allerede kender ham, sidste gang var en succes, så hvorfor tage unødige risici? Således er det helt naturligt at have en eller to go-to mennesker i samfundet, i stedet for at sprede arbejdet omkring jævnt.

Anmeldelse og godkendelse af ændringer

Samfundet er stadig vigtigt for succes i lønarbejde. Deres engagement i design og evalueringsprocessen for store ændringer kan ikke være en eftertanke. Det må betragtes som en del af arbejdet, og fuldt omfavnet af entreprenøren. Må ikke tænke på fællesskabet kontrol som en hindring, der skal overvindes, tænk på det som en gratis design bord og QA afdeling. Det er en fordel at være aggressivt, ikke kun udholdt.

Case study: CVS password-godkendelsesprotokol

I 1995 var jeg den ene halvdel af et partnerskab, der ydede støtte og forbedringer til CVS (den Concurrent Versions System, se http://www.cvshome.org/). Min partner Jim og jeg var uformelt, de vedligeholdere af CVS ved dette punkt. Men vi havde aldrig tænkt grundigt over, hvordan vi skulle forholde sig til det eksisterende, for det meste frivillige CVS udvikling samfund. Vi har lige antages, at de ville sende i pletter, og vi vil anvende dem, og det var temmelig meget, hvordan det fungerede.

Dengang kunne netværksbaserede CVS kun ske via en ekstern login program som rsh. Brug den samme adgangskode til CVS adgang hertil som for login adgang var en indlysende sikkerhedsrisiko, og mange organisationer var afskrækket af det. En stor investeringsbank hyret os til at tilføje en ny mekanisme til ægthedsbekræftelse, så de kunne sikkert bruge sammenkobles CVS med deres fjernkontorer.

Jim og jeg tog kontrakten og satte sig til at designe det nye godkendelsessystem. Hvad vi kom op med var temmelig enkel (USA havde eksportkontrol kryptografisk kode på det tidspunkt, så kunden forstået, at vi ikke kunne gennemføre stærk autentificering), men da vi ikke blev oplevet i at designe sådanne protokoller, vi stadig lavet et par gaffes der ville have været indlysende for en ekspert. Disse fejl ville let være blevet fanget havde vi taget tid til at skrive et forslag og køre det af de andre udviklere til gennemgang. Men vi har aldrig gjorde det, fordi det ikke falde os ind at tænke på udviklingen listen som en ressource, der skal bruges. Vi vidste, at folk var sandsynligvis kommer til at acceptere, hvad vi begået, og-fordi vi ikke vidste, hvad vi ikke vidste, vi ikke gider at gøre arbejdet på en synlig måde, f.eks udstationering patches ofte, hvilket gør små , let fordøjeligt forpligter sig til en særlig gren, osv. Den resulterende godkendelsesprotokol var ikke meget godt, og selvfølgelig, det engang blev etableret, var det vanskeligt at forbedre på grund af kompatibilitetsproblemer bekymringer.

Roden til problemet var ikke manglende erfaring, og vi kunne nemt have lært, hvad vi har brug for at vide. Problemet var vores holdning til den frivillige udvikling samfund. Vi betragtet accept af ændringer som en hurdle at springe, snarere end som en proces, hvor kvaliteten af de ændringer, kan forbedres. Da vi var overbeviste om, at næsten alt, hvad vi gjorde ville blive accepteret (som det var), vi gjort lidt for at få andre involveret.

Det er klart, når du vælger en entreprenør, du vil have nogen med de rette tekniske færdigheder og erfaringer til jobbet. Men det er også vigtigt at vælge en person med en track record af konstruktivt samspil med de øvrige udviklere i samfundet. På den måde du får mere end blot en enkelt person, du får en agent, der vil være i stand til at trække på et netværk af ekspertise til at sikre, at arbejdet udføres i et robust og vedligeholdelsesvenlig måde.

Finansiering Non-Programmering Aktiviteter

Programmering er kun en del af det arbejde, der foregår i et open source-projekt. Fra synspunkt af projektets frivillige, er det den mest synlige og glamourøse del. Det betyder desværre, at andre aktiviteter, såsom dokumentation, formelle test osv., nogle gange kan blive forsømt, i hvert fald sammenlignet med mængden af opmærksomhed, de ofte modtager i leverandørejet software. Corporate organisationer er undertiden i stand til at kompensere for dette, ved at afsætte en del af deres interne softwareudvikling infrastruktur til open source-projekter.

Nøglen til at gøre dette med succes, er at oversætte mellem virksomhedens interne processer og de offentlige udvikling samfund. En sådan oversættelse er ikke ubesværet: ofte to er ikke en tæt match, og forskellene kan kun slås bro via menneskelig indgriben. For eksempel kan virksomheden bruge en anden bug tracker end den offentligt projekt. Selv hvis de bruger den samme tracking software, vil de data, der lagres i det meget anderledes, fordi bug-tracking behov for en virksomhed, er meget forskellige fra dem i en fri software-fællesskabet. Et stykke af oplysninger, der starter i et tracker kan være nødvendigt at være afspejlet i den anden, med fortrolige fjernede partier eller i den anden retning, tilføjet.

De afsnit, der følger handler om, hvordan man opbygger og vedligeholder sådanne broer. Slutresultatet bør være, at open source-projektet kører mere jævnt, samfundet anerkender virksomhedens investering af ressourcer, og alligevel ikke føler, at virksomheden uhensigtsmæssigt styrer tingene mod sine egne mål.

Quality Assurance (dvs. Professional Testing)

I leverandørejet software udvikling, er det normalt at have hold af mennesker dedikeret udelukkende til kvalitetssikring: bug jagt, ydeevne og skalerbarhed testning, interface og dokumentation kontrol osv. Som regel er disse aktiviteter ikke skal opfattes som energisk af volontøren fællesskabet på et gratis software-projekt. Det er dels fordi det er svært at få frivillige arbejdskraft til upåagtede arbejde som testing, dels fordi folk har en tendens til at antage, at have et stort brugergruppen giver projektet en god test dækning, og i tilfælde af ydeevne og skalerbarhed testning, dels fordi frivillige ofte ikke har adgang til de nødvendige hardwareressourcer alligevel.

Den antagelse, at have mange brugere svarer til at have mange testere er ikke helt grundløse. Bestemt der er lidt punkt tildele testere for grundlæggende funktionalitet i fælles miljøer: bugs vil der hurtigt blive fundet af brugere i det naturlige forløb af tingene. Men fordi brugerne bare forsøger at få arbejde, har de ikke bevidst satte sig for at udforske ukendte kant sager i programmets funktionalitet, og er tilbøjelige til at forlade visse typer af fejl fundet belæg. Endvidere, når de opdager en fejl med en let løsning, de ofte tavst implementere løsningen uden generer at rapportere fejlen. Mest snigende kan brugsmønstre for dine kunder (de mennesker, der driver din interesse i softwaren) adskiller sig statistisk signifikante måder fra de brugsmønstre for den gennemsnitlige bruger In The Street.

En professionel test team kan afdække den slags fejl, og kan gøre det så nemt med gratis software som med leverandørejet software. Udfordringen er at formidle test teamets resultater tilbage til den offentlige i en brugbar form. In-house test afdelinger har som regel deres egen måde at rapportere testresultater, der involverer selskabsspecifikke jargon, eller specialiseret viden om bestemte kunder og deres datasæt. Sådanne rapporter ville være upassende for offentlig bug tracker, både på grund af deres form og på grund af fortrolighedshensyn. Selv hvis din virksomheds interne bug tracking software var den samme, som anvendes af det offentlige projekt, kan ledelsen nødt til at gøre selskabsspecifikke kommentarer og ændringer af metadata til de emner (for eksempel at rejse et spørgsmål interne prioritet, eller planlægge sin beslutning om en bestemt kunde). Normalt sådanne noter er fortrolige, sommetider de er ikke engang vist til kunden. Men selv når de ikke er fortrolige, de er uden betydning for den offentligt projekt, og derfor offentligheden bør ikke blive distraheret med dem.

Men kernen fejlrapporten selv er vigtigt for offentligheden. Faktisk er en fejlrapport fra din testafdeling på nogle måder mere værdifulde end én modtaget fra brugere på fri fod, da testafdeling sonder for ting, som andre brugere ikke vil. Da du er usandsynligt at få den pågældende fejlrapport fra enhver anden kilde, du helt sikkert ønsker at bevare den og gøre den tilgængelig for offentligheden projekt.

For at gøre dette, kan enten den QA afdeling Filproblemer direkte i den offentlige issue tracker, hvis de har det godt med det, eller en mellemmand (normalt en af udviklerne) kan «oversætte» testafdelings interne rapporter til nye spørgsmål i offentlig tracker. Oversættelse betyder blot beskriver fejlen på en måde, der gør nogen henvisning til kunde-specifikke oplysninger (reproduktion opskrift kan bruge kundedata, forudsat at kunden godkender det, naturligvis).

Det er lidt foretrække, at de QA afdeling arkivering problemer i den offentlige tracker direkte. Det giver befolkningen en mere direkte vurdering af din virksomheds engagement i projektet: nyttige fejlrapporter tilføje til din organisations troværdighed, ligesom enhver form for teknisk bidrag ville. Det giver også udviklere en direkte kommunikationslinje til test team. For eksempel, hvis den interne QA holdet overvåger offentlige issue tracker kan en udvikler begå en rettelse til en skalerbarhed bug (som bygherren måske ikke har ressourcer til at teste sig selv), og derefter tilføje en note til spørgsmålet beder QA hold at se, om rettelsen haft den ønskede effekt. Forvent en smule modstand fra nogle af de udviklere, programmører har en tendens til at betragte QA som i bedste fald et nødvendigt onde. QA team kan nemt løse dette ved at finde væsentlige fejl og arkivering forståelige rapporter, og på den anden side, hvis deres rapporter ikke er mindst lige så god som dem, der kommer fra den almindelige bruger community så der er ingen mening at have dem interagere direkte med udviklingen team.

Uanset hvad, når et offentligt anliggende findes, den oprindelige indre spørgsmål bør simpelthen henvisning til den offentlige udstedelse af det faglige indhold. Ledelse og betalte udviklere kan fortsætte med at anmærke det interne problem med firma-specifikke kommentarer som nødvendigt, men bruge den offentlige problem for oplysninger, der skal være tilgængelige for alle.

Du bør gå ind i denne proces forventer ekstra overhead. Opretholdelse af to spørgsmål for én fejl er naturligvis mere arbejde end at opretholde et spørgsmål. Fordelen er, at mange flere kodere vil se rapporten og være i stand til at bidrage til en løsning.

Juridisk rådgivning og beskyttelse

Selskaber, for-profit eller non-profit, er næsten de eneste enheder, der nogensinde opmærksomme på komplicerede juridiske problemstillinger i fri software. Individuelle udviklere ofte forstå nuancerne i forskellige open source-licenser, men de generelt ikke har tid eller ressourcer til at følge ophavsret, varemærke, og patentlovgivning i detaljer. Hvis din virksomhed har en juridisk afdeling, kan det hjælpe et projekt ved behandlingen af ophavsretten status af koden, og hjælpe udviklere forstå mulige patent og varemærke spørgsmål. De nøjagtige former denne hjælp kunne tage diskuteres i kapitel 9, licenser, Copyrights og patenter. Det vigtigste er at sørge for, at kommunikationen mellem den juridiske afdeling og udviklingen samfund, hvis de tilfældigvis overhovedet ske med en gensidig forståelse af de meget forskellige universer parterne kommer fra. Den lejlighed, taler disse to grupper forbi hinanden, hver side under forudsætning af domæne-specifik viden, som den anden ikke har. En god strategi er at have et forbindelseskontor (som regel en udvikler, ellers en advokat med teknisk ekspertise) står i midten og oversætter, så længe det er nødvendigt.

Dokumentation og Usability

Dokumentation og usability er begge berømte svage punkter i open source-projekter, selvom jeg tror, i det mindste i tilfælde af dokumentation, at forskellen mellem fri og proprietær software ofte er overdrevet. Ikke desto mindre er det empirisk sandt, at meget open source software mangler førsteklasses dokumentation og usability forskning.

Hvis din organisation ønsker at hjælpe med at udfylde disse huller til et projekt, sandsynligvis den bedste, det kan gøre, er hyre folk, der ikke regelmæssigt udviklere på projektet, men som vil være i stand til at interagere produktivt med udviklerne. Ikke leje regelmæssige udviklere er godt af to grunde: Den ene, den måde du ikke tager udviklingen tid væk fra projektet, to, dem nærmest til softwaren er som regel de forkerte mennesker til at skrive dokumentation eller undersøge anvendeligheden alligevel, fordi de har problemer se software fra en outsider synspunkt.

Det vil dog stadig være nødvendigt for den, der virker på disse problemer til at kommunikere med udviklere. Find mennesker, der er teknisk nok til at tale til den kodende hold, men ikke så ekspert i softwaren, at de ikke kan føle med almindelige brugere længere.

En mellemstor niveau bruger er nok den rette person til at skrive en god dokumentation. Faktisk, efter den første udgave af denne bog udkom fik jeg følgende e-mail fra en open source udvikler ved navn Dirk Reiners:

En kommentar om Money :: Dokumentation og Usability: når vi havde nogle
penge at bruge og besluttede, at en nybegynder tutorial var den mest
kritisk stykke som vi behøvede vi hyret en mellemlang niveau bruger for at skrive det.
Han var gået gennem induktion til systemet nylig nok til
huske de problemer, men han havde fået forbi dem, så han vidste, hvordan man
beskrive dem. Det tillod ham at skrive noget, der behøves kun
mindre rettelser af de centrale udviklere til de ting, som han ikke havde fået
ret, men stadig dækker de «indlysende» ting devs ville have savnet.

Hans sag var endnu bedre, som det havde været hans opgave at introducere en flok
andre mennesker (studerende) til systemet, så han kombinerede oplevelsen af
mange mennesker, der er noget, der var bare en heldig forekomst og er
sandsynligvis svært at få i de fleste tilfælde.

Forudsat Hosting/Båndbredde

For et projekt, der ikke er ved hjælp af en af de gratis dåse hosting sites (se afsnittet «Dåse Hosting» i kapitel 3, teknisk infrastruktur), hvilket giver en server og netværksforbindelse-og vigtigst af alt, systemadministration help-kan være en stor hjælp . Selv om dette er din organisation har for projektet, kan det være en moderat effektiv måde at opnå en god public relations karma, selvom det ikke vil bringe nogen indflydelse på ledelsen af projektet.

Du kan sandsynligvis forvente et banner annonce eller en bekræftelse på projektets hjemmeside, takke din virksomhed for at levere hosting. Hvis du opsætter hosting, så projektets web-adresse er under din virksomheds domænenavn, så vil du få nogle ekstra forening lige gennem URL’en. Dette vil medføre, de fleste brugere til at tænke på den software som havende noget at gøre med din virksomhed, selvom du ikke bidrager til udvikling på alle. Problemet er, at udviklerne er klar over dette associative tendens også, og kan ikke være meget komfortabel med at have projektet i dit domæne, medmindre du bidrage med flere ressourcer end bare båndbredde. Efter alt, er der en masse steder at være vært i disse dage. Samfundet kan i sidste ende føle, at den implicitte fejlallokering af kredit ikke er værd at bekvemmelighed anlagt af hosting, og tage projektet andetsteds. Så hvis du ønsker at give hosting, så gør det, men enten plan for at få endnu mere involveret snart, eller være velunderrettet om, hvor meget engagement du påstår.

Marketing

Selv om de fleste open source-udviklere sandsynligvis ville hader at indrømme det, markedsføring virker. En god marketing kampagne kan skabe buzz omkring en open source produkt, selv til det punkt, hvor nøgtern kodere finde sig selv at have vagt positive tanker om den software til grunde, de ikke helt kan sætte fingeren på. Det er ikke min plads her at dissekere armene-race dynamikken i markedsføring generelt. Enhver selskab er involveret i fri software vil med tiden finde sig selv overvejer, hvordan at markedsføre sig selv, software, eller deres forhold til softwaren. Nedenstående råd handler om hvordan man kan undgå almindelige faldgruber i en sådan indsats, se også afsnittet «Offentlighed» i kapitel 6, Communications.

Husk, at du bliver overvåget

Af hensyn til at holde de frivillige udviklere på din side, er det meget vigtigt ikke at sige noget, der ikke beviseligt sandt. Revision alle hævder omhyggeligt før de stiller dem, og give offentligheden mulighed for at kontrollere dine påstande på egen hånd. Uafhængig faktum kontrol er en vigtig del af open source, og det gælder for mere end blot koden.

Naturligvis ville ingen råde virksomhederne til at foretage uverificerbare krav alligevel. Men med open source aktiviteter, der er en usædvanlig stor mængde af mennesker med ekspertise til at kontrollere krav-folk, der også forventes at have høj båndbredde til internettet og de rette sociale kontakter til at offentliggøre deres resultater i en skadelig måde, bør de vælge til. Når Global MegaCorps Chemical Industries forurener et vandløb, der er kontrollerbare, men kun af uddannede forskere, hvem kan så blive tilbagevist af Global MegaCorps forskere, der forlader den offentlige kradse deres hoveder og spekulerer på, hvad at tænke. På den anden side, er din adfærd i open source-verdenen ikke kun synlige og optaget, det er også nemt for mange mennesker at kontrollere det selvstændigt, kommer til deres egne konklusioner, og sprede disse konklusioner fra mund til mund. Disse kommunikationsnet er allerede på plads, de er essensen af, hvordan open source fungerer, og de kan bruges til at overføre nogen form for information. Gendrivelse er normalt vanskeligt, hvis ikke umuligt, især når, hvad folk siger, er sandt.

For eksempel er det i orden at henvise til din organisation som havende «grundlagt projekt X», hvis du virkelig gjorde. Men du behøver ikke henvise til dig selv som «skaberne af X», hvis det meste af koden er skrevet af udenforstående. Omvendt påstår ikke at have en dybt involveret frivillige udviklere hvis nogen kan se på din repository og se, at der er få eller ingen kodeændringer kommer fra uden for organisationen.

Ikke så længe siden, så jeg en erklæring fra en meget kendt computer firma, angiver, at de udskilte en vigtig softwarepakke under en open source licens. Når den indledende Meddelelsen kom ud, tog jeg et kig på deres nu-offentlige version kontrol repository og så, at den indeholdt kun tre revisioner. Med andre ord, havde de gjort et første import af kildekoden, men næppe noget der var sket siden da. Det i sig selv ikke var bekymrende-they’d netop gjorde meddelelse, trods alt. Der var ingen grund til at forvente en masse udvikling aktivitet med det samme.

Nogen tid senere, de lavede en anden meddelelse. Her er, hvad det sagde, med navn og release nummer erstattet af pseudonymer:

Vi er glade for at meddele, at følgende grundig afprøvning af Singer Fællesskabet, Singer 5 til Linux og Windows er nu klar til brug i produktion.

Nysgerrig efter at vide, hvad fællesskabet havde afdækket i «grundig afprøvning,» Jeg gik tilbage til lageret for at se på sin nylige ændringer historie. Projektet var stadig på revision 3. Tilsyneladende havde de ikke fundet en eneste fejl værd fastsættelse før udgivelsen! Tænker, at resultaterne af fællesskabet test skal være blevet optaget andetsteds, jeg næste undersøgte bug tracker. Der var præcis seks åbne spørgsmål, hvoraf fire havde været åbne i flere måneder allerede.

Det er helt utroligt, selvfølgelig. Når testere pund på et stort og komplekst stykke software i længere tid, vil de finde fejl. Selv om rettelser til disse fejl ikke gør det i den kommende udgivelse, ville man stadig forvente et versionskontrolsystem aktivitet som følge af testprocessen, eller i det mindste nogle nye spørgsmål. Men efter alt at dømme, var der ikke skete noget mellem annonceringen af open source-licens, og den første open source-udgivelse.

Pointen er ikke, at selskabet lå omkring fællesskabet test. Jeg har ingen idé, hvis de var eller ikke. Men de var ligeglade med, hvor meget det så ud som de blev liggende. Da hverken den version kontrol lageret eller issue tracker gav udtryk for, at den påståede strenge test var sket, bør virksomheden enten ikke har gjort kravet i første omgang, eller har givet en klar forbindelse til nogle håndgribelige resultat af denne test («Vi fundet 278 fejl, klik her for detaljer «). Sidstnævnte ville have givet nogen til at få styr på omfanget af Fællesskabets aktivitet meget hurtigt. Som det var, det tog mig kun et par minutter at fastslå, at uanset hvad dette samfund test var, havde det ikke efterladt sig spor i nogen af de sædvanlige steder. Det er ikke en stor indsats, og jeg er sikker på jeg ikke er den eneste, der tog den ulejlighed.

Gennemsigtighed og verificerbarhed er også en vigtig del af præcis kreditering, selvfølgelig. Se afsnittet «Credit» i kapitel 8, adm. Frivillige for mere om dette.

Må ikke Bash Konkurrerende open source-produkter

Afstå fra at give negative udtalelser om konkurrerende open source software. Det er helt okay at give negative fakta, det vil sige, let confirmable påstande af den slags ofte ses i god sammenligning diagrammer. Men negative karakteriseringer af en mindre streng karakter er bedst undgås, af to grunde. Først, de er tilbøjelige til at starte krige, der forringer produktiv diskussion. For det andet, og endnu vigtigere, kan nogle af frivillige udviklere i projektet vise sig at arbejde på konkurrerende projekt så godt. Det er mere sandsynligt end det i første omgang kan virke: projekterne er allerede i det samme domæne (det er derfor, de er i konkurrence), og udviklere med ekspertise i dette domæne kan yde bidrag, uanset hvor deres ekspertise er gældende. Selv når der ikke er nogen direkte udvikler overlap, er det sandsynligt, at udviklerne på dit projekt er mindst bekendt med udviklere på relaterede projekter. Deres evne til at opretholde konstruktive personlige bånd kan hindres af overdrevent negative marketing budskaber.

Bashing konkurrerende lukket source produkter synes at være mere bredt accepteret i open source-verdenen, især når disse produkter er lavet af Microsoft. Personligt beklager jeg denne tendens (selvom igen, der er ikke noget galt med enkle faktuelle sammenligninger), ikke blot fordi det er uhøfligt, men også fordi det er farligt for et projekt at begynde at tro sine egne hype og dermed ignorere de måder, hvorpå konkurrencen kan faktisk være overlegen. Generelt se ud for den virkning, at markedsføringen udsagn kan have på din egen udvikling samfund. Folk kan være så ophidset over at blive bakket op af markedsføring dollars at de mister objektivitet om deres software sande styrker og svagheder. Det er normalt, og endda forventet for et selskabs udviklere til at udvise en vis distance i retning af marketing udsagn, selv i offentlige fora. Det er klart, bør de ikke komme ud og modsige markedsføring besked direkte (medmindre det er faktisk forkert, selvom man håber, at slags ting ville have været fanget tidligere). Men de kan gøre grin med det fra tid til anden, som en måde at bringe resten af udviklingsfællesskabet ned på jorden igen.

Kapitel 6. Kommunikation

Evnen til at skrive klart er måske den vigtigste færdighed, man kan have i et open source miljø. I det lange løb er det vigtigere end programmering talent. En stor programmør med elendig kommunikationsevner kan få kun én ting gjort på et tidspunkt, og selv da kan have problemer med at overbevise andre om at være opmærksomme. Men en elendig programmør med gode kommunikationsevner kan koordinere og overtale mange mennesker til at gøre mange forskellige ting, og derved have en betydelig effekt på et projekt retning og momentum.

Der synes ikke at være meget korrelation, i begge retninger, mellem evnen til at skrive god kode og evnen til at kommunikere med sine medmennesker. Der er en vis sammenhæng mellem programmering godt og beskriver tekniske spørgsmål godt, men beskriver tekniske problemer er kun en lille del af kommunikationen i et projekt. Langt vigtigere er evnen til at leve sig ind i ens publikum, at se ens egne indlæg og kommentarer som andre ser dem, og at få andre til at se deres egne stillinger med lignende objektivitet. Lige så vigtigt er at bemærke, når et givent medie eller kommunikation metode ikke længere fungerer godt, måske fordi det ikke skala som antallet af brugere stiger, og tage sig tid til at gøre noget ved det.

Alt dette er indlysende i teorien-hvad gør det svært i praksis er, at gratis software udviklingsmiljøer er forvirrende forskelligartede både i publikum og i kommunikation mekanismer. Skulle en given tanke udtrykkes i et indlæg på postlisten, som en anmærkning i bug tracker, eller som en kommentar i koden? Ved besvarelse af et spørgsmål i et offentligt forum, hvor meget kan viden man antager på den del af læseren, idet «læseren» er ikke kun den, der stillede spørgsmålet i første omgang, men alle dem, som kan se dit svar ? Hvordan kan udviklerne ophold i konstruktiv kontakt med brugerne, uden at blive oversvømmet af anmodninger om funktioner, falske fejlrapporter og generel snak? Hvordan kan du vide, hvornår et medium har nået grænserne for sin kapacitet, og hvad vil du gøre ved det?

Løsninger på disse problemer er normalt delvis, fordi en bestemt løsning i sidste ende gøres forældet efter projekt vækst eller ændringer i projektets struktur. De er også ofte ad hoc, fordi de er improviserede svar på dynamiske situationer. Alle deltagere skal være opmærksom på, hvornår og hvordan kommunikationen kan blive kørt ned, og inddrages i løsninger. Hjælpe folk gøre dette er en stor del af forvaltningen af et open source projekt. De afsnit, der følger diskutere både hvordan man kan foretage din egen kommunikation, og hvordan man kan gøre vedligeholdelse af kommunikationssystemer mekanismer til en prioritet for alle i projektet. [21]

Du er hvad du skriver

Overvej dette: det eneste man ved om dig på internettet kommer fra, hvad du skriver, eller hvad andre skriver om dig. Du kan være strålende, indsigtsfulde og karismatisk i person-men hvis dine e-mails er vidtløftige og ustruktureret, vil folk antager det er den virkelige dig. Eller måske du virkelig er vidtløftige og ustruktureret i person, men ingen behøver nogensinde vide det, hvis dine indlæg er klare og informative.

Afsætter nogle pleje til din skriftligt vil betale sig enormt. Lang tid fri software hacker Jim Blandy fortæller følgende historie:

Tilbage i 1993 blev jeg arbejdede for Free Software Foundation, og vi var beta-test version 19 af GNU Emacs. Vi ville gøre en betaversion hver uge eller deromkring, og folk ville prøve det og send os fejlrapporter. Der var denne ene fyr, som ingen af os havde mødt personligt, men som gjorde store arbejde: hans fejlrapporter var altid klar og førte os direkte til problemet, og da han gav en ordne sig selv, var det næsten altid ret. Han var fortræffelig.

Nu, før FSF kan bruge kode skrevet af en anden, vi har dem gøre nogle juridiske papirarbejde til at overdrage deres ophavsret interesse for at kode til FSF. Bare tage kode fra komplet fremmede og slippe det i er en opskrift på lovlig katastrofe.

Så jeg mailede fyren formularer og sagde: «Her er noget papirarbejde, vi har brug for, her er hvad det betyder, du underskriver denne ene, har din arbejdsgiver tegn på, at én, og så kan vi begynde at lægge i dine rettelser. Tak meget.»

Han sendte mig en besked tilbage at sige: «Jeg har ikke en arbejdsgiver.»

Så jeg sagde: «Okay, det er fint, bare have dit universitet underskrive den og sende den tilbage.»

Efter en smule, skrev han mig tilbage igen, og sagde: «Tja, faktisk … Jeg er tretten år gammel, og jeg bor sammen med mine forældre.»

Fordi det barn ikke skrive som en tretten-årig, ingen vidste det er, hvad han var. Følgende er nogle måder at gøre din skriftligt giver et godt indtryk også.

Struktur og formatering

Må ikke falde i den fælde at skrive alt, som om det var en mobiltelefon tekstmeddelelse. Skriv i hele sætninger, kapitalisere det første ord i hver sætning, og bruge afsnitsskift hvor det er nødvendigt. Dette er meget vigtigt i e-mails og andre sammensat skrifter. I IRC eller lignende kortvarige fora, er det generelt okay at udelade kapitalisering, skal du bruge komprimerede former for almindelige udtryk, osv. Bare ikke bære disse vaner over i mere formelle, persistente fora. E-mails, dokumentation, fejlrapporter, og andre stykker af skrivning, som er beregnet til at have en permanent liv skal skrives ved brug af standard grammatik og stavning, og har en sammenhængende narrativ struktur. Det er ikke fordi der er noget i sig selv godt om efter vilkårlige regler, men snarere, at disse regler ikke er vilkårlige: de udviklede sig til deres nuværende former, fordi de gør teksten mere læsbar, og du bør holde sig til dem af den grund. Læsbarhed er ønskelig, ikke kun fordi det betyder flere mennesker vil forstå, hvad du skriver, men fordi det gør dig til at ligne den slags person, der tager sig tid til at kommunikere klart: det er, nogen er værd at være opmærksom på.

For e-mail i særdeleshed har oplevet open source-udviklere afgjort på visse konventioner:

Send almindelig tekst mails kun, ikke HTML, RTF, eller andre formater, som kan være uigennemsigtig til tekst-only mail læsere. Formater dine linjer at være omkring 72 kolonner lang. Må ikke overstige 80 kolonner, som er blevet de facto standard terminal bredde (dvs. nogle mennesker kan bruge bredere terminaler, men ingen bruger en smallere en). Ved at gøre dine linjer lidt mindre end 80 kolonner, forlader du plads til et par niveauer af citere tegn, der skal tilføjes i andres svar uden at tvinge en pakkecentrets af din tekst.

Brug rigtige linjeskift. Nogle afsendere gøre en slags falsk linjeombrydning, hvor når du skriver en e-mail, viser displayet linjeskift, der faktisk ikke der. Når posten går ud, kan det ikke have linjeskift du troede, det havde, og det vil ombryde akavet på nogle folks skærme. Hvis din mailer kan bruge falske linjeskift, kigge efter en indstilling, du kan nappe for at gøre det vise de sande linjeskift, mens du skriver.

Når herunder skærm output, kodedele eller anden forudformateret tekst, offset det klart, således at selv en dovent øje kan sagtens se grænserne mellem din prosa og det materiale, du citere. (Jeg havde aldrig forventet at skrive dette råd, da jeg startede denne bog, men på en række open source postlister sidst, jeg har set folk blander tekster fra forskellige kilder uden at gøre det klart, hvem der er hvem. Effekten er meget frustrerende. Det gør deres stillinger betydeligt sværere at forstå, og helt ærligt gør disse mennesker ser en lille smule uorganiserede.)

Når citerer en andens mail, skal du indsætte dine svar, hvor de er mest hensigtsmæssigt, på flere forskellige steder, hvis det er nødvendigt, og skære de dele af deres post, du ikke bruger. Hvis du skriver en hurtig kommentar, der gælder for hele deres post, det er okay at top-post (det vil sige at sætte dit svar over den citerede tekst fra deres mail), ellers bør du citere den relevante del af den oprindelige tekst først, efterfulgt af dit svar.

Konstruér emnelinjen af nye mails omhyggeligt. Det er den vigtigste linie i din mail, fordi det giver hver anden person i projektet at afgøre, om eller ikke at læse mere. Moderne mail software til læsning arrangerer grupper af relaterede beskeder i tråde, som kan defineres ikke kun af et fælles emne, men af forskellige andre overskrifter (som undertiden ikke vises). Det følger heraf, at hvis en tråd begynder at drive til et nyt emne, kan-og du bør-juster emnelinjen i overensstemmelse hermed ved besvarelse. Tråden integritet vil blive bevaret, på grund af de andre overskrifter, men det nye emne vil hjælpe folk kigger på en oversigt over tråden ved, at emnet er drevet. Ligeledes, hvis du virkelig ønsker at starte et nyt emne, så gør det ved at poste en ny mail, ikke ved at besvare en eksisterende post og ændre emnet. Ellers ville din mail stadig samles i den samme tråd som hvad du besvarer, og dermed narre folk til at tro, det handler om noget, det er ikke. Igen vil straffen ikke blot være spild af deres tid, men den lille bule i din troværdighed som en flydende i brug kommunikationsværktøjer.

Indhold

Well-formaterede mails tiltrække læsere, men indholdet holder dem. Ingen sæt faste regler kan garantere en god indhold, selvfølgelig, men der er nogle principper, der gør det mere sandsynligt.

Gør tingene let for dine læsere. Der er et væld af information flyder rundt i en aktiv open source-projekt, og læserne kan ikke forventes at være bekendt med det meste af det, ja, kan de ikke altid kan forventes at vide, hvordan man bliver bekendt med. Hvor det er muligt, bør dine indlæg give oplysninger i form mest bekvemt for læserne. Hvis du nødt til at tilbringe en ekstra to minutter til at grave op webadressen til en bestemt tråd i postlistearkiver, for at redde dine læsere for besværet med at gøre det, det er det værd. Hvis du er nødt til at tilbringe en ekstra 5 eller 10 minutter opsummerer hidtil af en kompleks tråd, for at give folk kontekst, som at forstå dit indlæg, så gør det. Tænk på det på denne måde: jo mere succesfuld et projekt, jo højere læser-til-writer-forhold i et givet forum. Hvis alle indlæg du laver, bliver set af n mennesker, så som n stiger, stiger den var umagen værd expending ekstra indsats for at redde dem folk tid med det. Og som folk ser dig pålægge denne standard på dig selv, vil de arbejde for at matche det i deres egen kommunikation. Resultatet er, ideelt set en stigning i den globale effektivitet af projektet: når der er et valg mellem n mennesker gør en indsats og én person at gøre det, at projektet foretrækker sidstnævnte.

Må ikke deltage i overdrivelse. Overdriver i online stillinger er en klassisk våbenkapløb. For eksempel kan en person, der rapporterer en fejl bekymre at udviklerne ikke vil betale nok opmærksomhed, så han vil beskrive det som en svær, showstopper problem, som forhindrer ham (og alle hans venner / kolleger / kusiner) fra at bruge softwaren produktivt , når det er faktisk kun en mild irritation. Men overdrivelse er ikke begrænset til brugere-programmører ofte gøre det samme i løbet af tekniske debatter, især når uenigheden er over en smagssag snarere end korrekthed:

«Gør det på den måde ville gøre koden helt ulæselige. Det ville være en vedligeholdelse mareridt, sammenlignet med J. Random forslag …»

Den samme følelse faktisk bliver stærkere, når formuleret mindre skarpt:

«Det virker, men det er mindre end ideel i forhold til læsbarhed og vedligeholdelsesevne, tror jeg. J. Random forslag undgås sådanne problemer, fordi det …»

Du vil ikke være i stand til at slippe af overdrivelse fuldstændigt, og generelt er det ikke nødvendigt at gøre det. Sammenlignet med andre former for fejlkommunikation, er overdrivelse ikke globalt skadelige-det gør ondt hovedsagelig gerningsmanden. Modtagerne kan kompensere, det er bare at afsenderen mister lidt mere troværdighed hver gang. Derfor af hensyn til din egen indflydelse i projektet, så prøv at fejle på siden af mådehold. På den måde når du behøver at gøre et stærkt punkt, vil folk tage dig alvorligt.

Rediger to gange. For enhver besked længere end en mellemstor afsnit, genlæse den fra top til bund før du sender den, men når du tror det er gjort første gang. Det er velkendt råd til alle, der har taget en sammensætning klasse, men det er især vigtigt i online-diskussionen. Fordi processen med online sammensætning har tendens til at være meget diskontinuerlig (i forbindelse med at skrive en besked, kan du nødt til at gå tilbage og tjekke andre mails, besøge visse websider, skal du køre en kommando for at fange sin debugging output, osv.), er det specielt let at miste din sans for fortællende sted. Meddelelser, der blev komponeret diskontinuert og ikke kontrolleret, før de sendes ofte genkendes som sådan, til stor ærgrelse (eller så man kunne håbe) af deres forfattere. Tag dig tid til at gennemgå, hvad du sender. Jo mere dine indlæg holde sammen strukturelt, jo mere vil de blive læst.

Tone

Efter at have skrevet tusindvis af beskeder, vil du sikkert finde din stil tenderende mod lakoniske. Dette synes at være normen i de fleste tekniske fora, og der er intet galt med det per se. En vis grad af terseness der ville være uacceptabelt i normale sociale interaktioner er simpelthen standard for fri software hackere. Her er et svar jeg engang trak på en mailingliste om nogle gratis content management software, citeret i sin helhed:

Kan du overhovedet uddybe lidt mere om, hvad problemerne
De løb ind i, etc?

Også:

Hvilken version af Slash bruger du? Jeg kunne ikke sige fra din
oprindelige meddelelse.

Præcis hvordan har du bygge apache / mod_perl kilde?

Har du prøve Apache 2,0 patch, der blev lagt ud omkring på
slashcode.com?

Shane

Nu, er lakoniske! Ingen hilsen, ingen sign-off andet end hans navn, og selve meddelelsen er bare en række spørgsmål formuleret som kompakt som muligt. Hans ene deklarativ sætning var en implicit kritik af min oprindelige meddelelse. Og dog, jeg var glad for at se Shane s mail, og ikke tage hans terseness som et tegn på noget som helst andet end at han er en travl person. Den omstændighed, at han var stille spørgsmål, i stedet for at ignorere min post, betød, at han var villig til at bruge lidt tid på mit problem.

Vil alle læsere reagerer positivt på denne stil? Ikke nødvendigvis, det afhænger af personen og konteksten. For eksempel, hvis nogen bare har sendt erkender, at hun har lavet en fejl (måske hun skrev en bug), og du ved fra tidligere erfaringer, at denne person er tilbøjelig til at være en smule usikker, så mens du stadig kan skrive en kompakt svar bør du sørg for at surdej det med en slags kvittering for hendes følelser. Hovedparten af dit svar ville måske være en kort, engineer’s-eye analyse af situationen, så kortfattede som du ønsker. Men i slutningen, underskrive med noget tyder på, at din terseness ikke skal opfattes som kulde. For eksempel, hvis du lige har givet bunker af råd om, præcis hvordan den person bør rette fejlen og derefter underskrive med «Held og lykke, <dit navn her>» for at angive, at du ønsker dem alt godt og er ikke gal. En strategisk placeret smilende ansigt eller anden emoticlue kan ofte være nok til at berolige en samtalepartner, også.

Det kan virke mærkeligt at fokusere så meget på deltagerens følelser som på overfladen af hvad de siger, men at sætte det unuanceret, følelser påvirker produktiviteten. Følelser er vigtige for andre grunde også, men selv at begrænse os til rent utilitaristiske grunde, kan vi konstatere, at ulykkelige mennesker skriver værre software, og mindre af det. Grund af det begrænsede karakter af de fleste elektroniske medier, dog vil der ofte være nogen åbenlys anelse om, hvordan en person føler. Du bliver nødt til at træffe et kvalificeret gæt baseret på a) hvordan de fleste mennesker ville føle i den situation, og b) hvad du kender denne bestemt person fra tidligere interaktioner. Nogle mennesker foretrækker en mere hands-off holdning, og blot beskæftige sig med alle til pålydende værdi, ideen er, at hvis en deltager ikke sige direkte, at hun føler en særlig måde, så man har noget at behandle hende, som om hun gør. Jeg køber ikke denne fremgangsmåde, for et par grunde. Én, folk ikke opfører sig på den måde i det virkelige liv, så hvorfor skulle de online? To, da de fleste interaktioner finder sted i offentlige fora, folk har tendens til at være endnu mere tilbageholdende i at udtrykke følelser, end de kunne være privat. For at være mere præcis, er de ofte villige til at udtrykke følelser rettet mod andre, såsom taknemmelighed eller harme, men ikke følelser rettet indad, såsom usikkerhed eller stolthed. Men de fleste mennesker arbejder bedre, når de ved, at andre er opmærksomme på deres sindstilstand. Ved at være opmærksom på de små spor, kan du normalt gætte rigtigt det meste af tiden, og motivere folk til at blive involveret i en større grad end de ellers ville.

Jeg mener ikke, selvfølgelig, at din rolle er at være en gruppe terapeut, konstant hjælpe alle til at komme i kontakt med deres følelser. Men ved at være meget opmærksom på de langsigtede mønstre i folks adfærd, vil du begynde at få en fornemmelse af dem som individer, selvom du aldrig møde dem ansigt til ansigt. Og ved at være følsomme over for tonen i dit eget skriftligt, kan du få en overraskende mængde af indflydelse på, hvordan andre føler, at den ultimative fordel af projektet.

I erkendelse Uhøflighed

Et af de vigtigste kendetegn ved open source-kulturen er dens særprægede forestillinger om, hvad gør og ikke udgør uhøflighed. Mens de konventioner beskrevet nedenfor ikke er unikke til fri software udvikling, og heller ikke til software i almindelighed, de ville være bekendt at alle, der arbejder inden for matematik, de hårde videnskaber, eller ingeniørdiscipliner-fri software, med sine porøse grænser og konstant tilstrømning af nye , er et miljø, hvor disse konventioner er især sandsynligt vil blive udsat mennesker kender til dem.

Lad os starte med de ting, der ikke uhøflige:

Teknisk kritik, selv når direkte og unpadded, er ikke uhøflige. Faktisk kan det være en form for smiger: kritikeren siger, underforstået, at målet er værd at tage alvorligt, og er værd at bruge lidt tid på. Det vil sige, jo mere levedygtige det ville have været blot at ignorere en persons post, jo mere af en kompliment bliver det at tage sig tid til at kritisere den (medmindre den kritik ned i en annonce hominem angreb eller en anden form for indlysende uhøflighed, selvfølgelig ).

Blunt, usminkede spørgsmål, såsom Shane spørgsmål til mig i den tidligere citerede e-mail, er ikke uhøflige enten. Spørgsmål som i andre sammenhænge kan virke kold, retorisk eller endda spottende, er ofte bestemt alvorligt, og har ingen skjult dagsorden andre end at indhente information så hurtigt som muligt. Den berømte teknisk support spørgsmålet «Er din computer tilsluttet?» er et klassisk eksempel på dette. Den støtte person virkelig behøver at vide om din computer er tilsluttet en stikkontakt, og efter de første par dage på jobbet, har fået træt af forudfastsætte hendes spørgsmål med høflige lokketoner («Undskyld, jeg ønsker blot at spørge et par enkle spørgsmål at udelukke nogle muligheder. Nogle af disse kan synes temmelig grundlæggende, men bær over med mig … «). På dette tidspunkt, hun ikke gider med padding mere, hun bare spørger lige ud: Er det sat i eller ej? Tilsvarende spørgsmål bliver stillet hele tiden på gratis software postlister. Hensigten er ikke at fornærme modtageren, men hurtigt udelukke de mest oplagte (og måske mest almindelige) forklaringer. Modtagere, der forstår dette og reagere i overensstemmelse hermed vinde point for at tage en frisindet visning uden at spørge. Men modtagere, der reagerer dårligt, bør ikke blive irettesat, enten. Det er bare en kollision af kulturer, ikke nogens skyld. Forklar venligt at dit spørgsmål (eller kritik) havde ingen skjulte betydninger; det var bare meningen, at få (eller sende) information så effektivt som muligt, intet mere.

Så hvad er uforskammet?

Ved samme princip, hvorefter detaljeret teknisk kritik er en form for smiger, kan undladelse af at levere kvalitet kritik være en slags fornærmelse. Jeg mener ikke bare ignorere en andens arbejde, det være sig forslag, kodeskift, nyt problem arkivering, eller hvad. Medmindre du udtrykkeligt lovet en detaljeret reaktion på forhånd, er det normalt i orden at simpelthen ikke reagere på alle. Folk vil antage, at du bare ikke har tid til at sige noget. Men hvis du gør reagere, ikke sjuske: tager sig tid til virkelig at analysere tingene, giver konkrete eksempler, hvor det er hensigtsmæssigt, grave rundt i arkiverne for at finde relaterede indlæg fra fortiden, osv. Eller hvis du ikke har tid til at sætte i denne form for indsats, men stadig nødt til at skrive en slags korte svar, så opgiv den mangel åbent i din besked («Jeg tror, der er et problem indgivet for dette, men desværre havde ikke tid til at søge efter det, sorry» ). Det vigtigste er at anerkende eksistensen af den kulturelle norm, enten ved at opfylde den, eller ved åbent at erkende, at man har levet op til denne gang. Uanset hvad, er normen styrkes. Men ikke opfylder denne norm, mens på samme tid ikke at forklare, hvorfor du har undladt at opfylde det, er som at sige emnet (og dem, der deltager i det) var ikke meget værd af din tid. Bedre at vise, at din tid er kostbar ved at være kortfattede end ved at være doven.

Der er mange andre former for uhøflighed, selvfølgelig, men de fleste af dem er ikke specifikke for fri software-udvikling, og sund fornuft er en god nok guide til at undgå dem. Se også afsnittet «Nip Uhøflighed i Bud» i kapitel 2, Introduktion, hvis du ikke allerede har gjort det.

Face

Der er en region i den menneskelige hjerne specielt omhandler genkende ansigter. Det er kendt uformelt som «fusiform ansigt område», og dens muligheder er for det meste medfødt, ikke lært. Det viser sig, at anerkendelse af de enkelte mennesker er sådan en afgørende overlevelse færdighed, som vi har udviklet specialiseret hardware til at gøre det.

Internet-baseret samarbejde er derfor psykologisk mærkeligt, fordi det involverer tæt samarbejde mellem mennesker, der næsten aldrig kommer til at identificere hinanden ved de mest naturlige, intuitive metoder: ansigtsgenkendelse først og fremmest, men også lyden af stemmen, kropsholdning, etc. Til kompensere for dette, så prøv at bruge en konsekvent skærmnavn overalt. Det bør være den forreste del af din e-mailadresse (den del før @-tegnet), din IRC brugernavn, dit repository committer navn, din issue tracker brugernavn, og så videre. Dette navn er din online «ansigt»: en kort identifikation streng, der serverer nogle af de samme formål som dit sande ansigt, selv om det ikke, desværre stimulere den samme indbyggede hardware i hjernen.

Skærmen navn skal være nogle intuitive permutation af dit rigtige navn (mine, for eksempel, er «kfogel»). I nogle situationer vil det være ledsaget af dit fulde navn alligevel, for eksempel i mail-brevhoveder:

Fra: «Karl Fogel» <kfogel@whateverdomain.com>
Faktisk er der to ting, der foregår i dette eksempel. Som nævnt tidligere, det skærmnavn matcher det rigtige navn på en intuitiv måde. Men også, det rigtige navn er reel. Det vil sige, det er ikke noget konfektionerede appellation som:

Fra: «Wonder Hacker» <wonderhacker@whateverdomain.com>
Der er en berømt tegneserie af Paul Steiner, fra 5 Juli 1993 nummer af The New Yorker, som viser én hund logget ind på en computer terminal, ser ned og fortæller en anden conspiratorially: «På internettet, ingen kender du er en hund. » Denne form for tænkning ligger formentlig bag en masse af de selv-omnipotente, betød-at-være-hip online identiteter folk giver sig selv, som om at kalde sig selv «Wonder Hacker» vil faktisk få folk til at tro, den ene er en vidunderlig hacker. Men faktum er: selv om ingen ved, du er en hund, er du stadig en hund. En fantastisk online identitet aldrig imponerer læsere. I stedet, det gør dem tror, du er mere til billedet end stof, eller at du er simpelthen usikker. Brug dit rigtige navn for alle interaktioner, eller hvis en eller anden grund ønskede anonymitet, og der fyldes op et navn, der lyder som en helt normal rigtige navn, og bruge det konsekvent.

Ud over at holde din online ansigt konsekvent, er der nogle ting, du kan gøre for at gøre det mere attraktivt. Hvis du har en officiel titel (eg, «læge», «professor», «instruktør»), ikke skilte med det, og heller ikke engang nævne det, undtagen når det er direkte relevant for samtalen. Hacker i almindelighed, og fri software kultur i særdeleshed, har en tendens til at se titel skærme som ekskluderende og et tegn på usikkerhed. Det er okay, hvis din titel vises som en del af en standard signatur blok i slutningen af hver mail, du sender, bare ikke nogensinde bruge det som et redskab til at styrke din position i en diskussion, forsøget er garanteret at give bagslag. Du ønsker folk til at respektere den person, ikke titlen.

Apropos signaturblokke: holde dem små og smagfuld, eller bedre endnu, ikke-eksisterende. Undgå store juridiske ansvarsfraskrivelser bygges oven på den i slutningen af hver post, især når de udtrykker følelser er uforenelige med deltagelse i et fri software projekt. For eksempel vises følgende klassiker i genren ved slutningen af hvert indlæg en bestemt bruger foretager en offentlig postliste jeg er på:

VIGTIG MEDDELELSE

Hvis du har modtaget denne e-mail ved en fejl eller ønsker at læse vores e-mail
ansvarsfraskrivelse erklæring og overvågning politik, henvises til
erklæring nedenfor eller kontakte afsenderen.

Denne meddelelse er fra Deloitte & Touche LLP. Deloitte &
Touche LLP er et aktieselskab partnerskab registreret i England
og Wales med registreringsnummer OC303675. En liste over medlemmernes navne
er fremlagt til gennemsyn på Stonecutter Court, 1 Stonecutter
Street, London EC4A 4TR, Storbritannien, virksomhedens hovedforretningssted
forretning og hjemsted. Deloitte & Touche LLP er
autoriseret og reguleret af Financial Services Authority.

Denne meddelelse og eventuelle vedhæftede filer indeholder oplysninger, der er
fortroligt og kan også være privilegeret. Det er udelukkende til brug
af den tilsigtede modtager (e). Hvis du ikke er den tiltænkte
modtager (e) bemærk at enhver form for offentliggørelse, distribution,
kopiering eller brug af denne meddelelse eller oplysningerne i det eller i
vedhæftede filer er strengt forbudt og kan være ulovligt. Hvis du
har modtaget denne meddelelse ved en fejl, bedes du returnere den med
Titlen «modtaget med fejl» at IT.SECURITY.UK @ deloitte.co.uk derefter slette
e-mail og destruere alle kopier af den.

E-mail-kommunikation kan ikke garanteres at være sikker eller fejlfri,
som oplysninger kan opsnappes, ødelagt, ændret, tabt,
ødelagt, ankommer sent eller ufuldstændige, eller indeholder virus. Vi gør ikke
drages til ansvar for sådanne spørgsmål eller deres konsekvenser. Enhver
der kommunikerer med os via e-mail er taget at acceptere de risici i
herfor.

Når adresseret til vores kunder, eventuelle udtalelser eller råd, der er indeholdt i
denne e-mail og eventuelle vedhæftede filer er underlagt de vilkår og
betingelser til udtryk i det regerende Deloitte & Touche LLP klient
aftalebrev.

Udtalelser, konklusioner og andre oplysninger i denne e-mail og eventuelle
vedhæftede filer, som ikke vedrører den officielle business af virksomheden
hverken givet eller godkendt af det.
For en person, der bare dukker op for at stille et spørgsmål nu og da, ser det enorme ansvarsfraskrivelse lidt fjollet, men sandsynligvis ikke gøre nogen varig skade. Men hvis denne person ønskede at deltage aktivt i projektet, ville denne juridiske standardtekst begynde at have en mere lumsk effekt. Det ville sende mindst to potentielt destruktive signaler: For det første, at denne person ikke har fuld kontrol over sin værktøjer-han er fanget inde i nogle corporate mailer at stifter en irriterende besked til slutningen af hver e-mail, og han ikke har fået nogen måde at rute omkring det-og det andet, at han har lidt eller ingen organisatorisk støtte for hans fri software virksomhed. Sandt nok, har organisationen tydeligvis ikke forbudt ham direkte fra udstationering til offentlige lister, men det har gjort hans indlæg ser tydeligt unwelcoming, som om risikoen for udlejning fortrolige oplysninger skal trumfe alle andre prioriteter.

Hvis du arbejder for en organisation, der insisterer på at tilføje sådanne signatur blokke til alt udgående post, og derefter overveje at få en gratis e-mail-konto fra for eksempel gmail.google.com, www.hotmail.com eller www.yahoo.com, og bruger det som din adresse til projektet.

Undgå Almindelige besværligheder

Må ikke lave indlæg uden et formål

En fælles faldgrube i online projekt deltagelse er at tro, at du er nødt til at reagere på alt. Du behøver ikke. Først og fremmest vil der normalt være flere tråde foregår end du kan holde styr på, i det mindste efter at projektet er forbi de første par måneder. For det andet vil selv i de tråde, du har besluttet at engagere sig i meget af det, folk siger ikke kræver et svar. Udvikling fora i særdeleshed tendens til at være domineret af tre typer beskeder:

Meddelelser foreslår noget ikke-triviel

Beskeder, der udtrykker støtte eller modstand mod noget en anden har sagt

Opsummering beskeder

Ingen af disse i sagens natur kræver et svar, især hvis du kan være temmelig sikker på, baseret på at se tråden så langt, at en anden er tilbøjelige til at sige, hvad du ville have sagt alligevel. (Hvis du er bekymret, at du vil blive fanget i en vent-vent loop, fordi alle de andre bruger denne taktik også, skal du ikke være, og der er næsten altid nogen derude, der får lyst til at hoppe ind i kampen.) En reaktion bør være motiveret af et bestemt formål. Spørg dig selv først: ved du, hvad du ønsker at opnå? Og for det andet: vil det ikke få gennemført, medmindre du sige noget?

To gode grunde til at føje din stemme til en tråd, er a) når du ser en fejl i et forslag, og har mistanke om at du er den eneste, der ser det, og b), når du ser, at fejlkommunikation der sker mellem andre, og ved, at du kan ordne det med en afklaring indlæg. Det er også generelt fint at skrive bare for at takke nogen for at gøre noget, eller at sige «Me too!», Fordi en læser kan fortælle det samme, at disse stillinger ikke kræver nogen respons eller yderligere foranstaltninger, og derfor den mentale indsats beordret af indlæg slutter rent når læseren når den sidste linje i mailen. Men selv da, mener to gange før at sige noget, det er altid bedre at lade folk, der ønsker du ville sende mere end ønske du ville skrive mindre. (Se anden halvdel af tillæg C, hvorfor skulle jeg ligeglad med, hvad farve den Bikeshed Er? For flere tanker om, hvordan man opfører sig på en travl postliste.)

Produktive vs uproduktive Tråde

På en travl mailingliste, har du to imperativer. Én, naturligvis, er at finde ud af, hvad du skal være opmærksom på, og hvad du kan ignorere. Den anden er at opføre sig på en måde, der ikke forårsager støj: ikke kun vil du have dine egne indlæg at have en høj signal / støj-forhold, skal du også have dem til at være den slags beskeder, der stimulerer andre mennesker til enten stilling med et tilsvarende høj signal / støj-forhold, eller ikke skrive overhovedet.

Hvis du vil se hvordan man gør det, lad os overveje, i hvilken sammenhæng det er gjort. Hvad er nogle af kendetegnene ved en uproduktiv tråd?

Argumenter, der er gjort allerede begynde at blive gentaget, som om plakaten tænker ingen hørte dem første gang.

Stigende niveauer af overdrivelse og engagement som indsatserne bliver mindre og mindre.

Et flertal af kommentarer fra folk, der gør lidt eller intet, mens de mennesker, der har tendens til at få tingene gjort, er tavse.

Mange ideer blev drøftet uden klare forslag nogensinde at blive lavet. (Selvfølgelig starter en interessant idé ud som en upræcis vision, det vigtige spørgsmål er, hvilken retning det går derfra Er tråden synes at dreje vision til noget mere konkret, eller er det spinding ud i sub-visioner, side. -visioner og ontologiske tvister?)

Bare fordi en tråd er ikke produktiv ved første betyder ikke, det er spild af tid. Det kan dreje sig om et vigtigt emne, i hvilket tilfælde det faktum, at det ikke laver nogen fremskridt er endnu mere besværlig.

Ledende en tråd mod nytte uden nøjeregnende er en kunst. Det vil ikke arbejde for blot at formane folk til at stoppe spilde deres tid, eller at bede dem om ikke at skrive, medmindre de har noget konstruktivt at sige. Du kan selvfølgelig tænke disse ting privat, men hvis du siger dem højt, så vil du være stødende. I stedet skal du foreslå betingelserne for yderligere fremskridt, give folk en rute, en vej at følge, der fører til de ønskede resultater, men uden at lyde som om du diktere adfærd. Sondringen er i høj grad en af tone. For eksempel er dette dårlige:

Denne diskussion går ingen steder. Kan vi så send dette emne indtil nogen har en patch til at gennemføre et af disse forslag? Der er ingen grund til at holde går rundt og rundt og siger de samme ting. Kode taler højere end ord, folkens.

Dette er godt:

Adskillige forslag er blevet flød i denne tråd, men ingen har haft alle detaljer konkretiseret, i hvert fald ikke nok til en op-eller ned-afstemning. Men vi heller ikke sige noget nyt nu, vi bare gentage hvad der er blevet sagt før. Så den bedste ting ved dette punkt ville sandsynligvis være yderligere stillinger til at indeholde enten en fuldstændig specifikation for den foreslåede opførsel, eller et plaster. Så i det mindste ville vi have en konkret indsats for at tage (dvs., få konsensus på specifikationen, eller anvende og afprøve patch).

Kontrast den anden fremgangsmåde med det første. Den anden måde ikke trække en linje mellem dig og de andre, eller beskylde dem for at tage diskussionen i en spiral. Der tales om «vi», hvilket er vigtigt, om du rent faktisk har deltaget i tråden før nu, fordi det minder alle om, at selv de, der har været tavse hidtil stadig har en interesse i trådens udfald. Det beskriver, hvorfor tråden går ingen steder, men gør det uden pejoratives eller domme-det bare lidenskabsløst hedder nogle kendsgerninger. Vigtigst er det, det giver en positiv fremgangsmåde, så i stedet for folk føle sig som diskussion bliver lukket (en begrænsning mod hvilken de kan kun blive fristet til at gøre oprør), vil de føle sig som om de bliver tilbudt en måde at tage samtalen til en mere konstruktiv niveau. Dette er en standard folk vil naturligvis gerne vil mødes.

Du vil ikke altid have en tråd at gøre det til det næste niveau af konstruktivitet-tider du ønsker det bare gå væk. Formålet med dit indlæg, så er at gøre det gøre det ene eller det andet. Hvis du kan fortælle fra den måde, hvorpå tråden er gået så langt, at ingen rent faktisk kommer til at tage de skridt, du foreslog, så dit indlæg effektivt lukker tråden uden tilsyneladende at gøre det. Selvfølgelig er der ikke nogen idiotsikker måde at lukke en tråd, og selv hvis der var, ville du ikke ønsker at bruge det. Men at spørge deltagerne til enten synliggøre fremskridt eller stoppe udstationering er helt forsvarligt, hvis det gøres diplomatisk. Vær på vagt over omstødelsen tråde for tidligt, dog. En vis mængde af spekulativ snak kan være produktiv, afhængigt af emnet, og beder om at blive løst for hurtigt vil kvæle den kreative proces, samt gøre dig se utålmodig.

Forvent ikke nogen tråd for at stoppe på en tallerken. Der vil sandsynligvis stadig være et par indlæg efter dit, enten fordi mails blev krydset i røret, eller fordi folk ønsker at have det sidste ord. Det er ikke noget at bekymre sig om, og du behøver ikke at skrive igen. Bare lad tråden dø ud, eller ikke ud i sandet, da omstændighederne. Du kan ikke have fuldstændig kontrol, og på den anden side, kan du forvente at have en statistisk signifikant effekt på tværs af mange tråde.

Jo blødere Topic, jo længere debat

Selvom diskussion kan Mæander i hvilket som helst emne, sandsynligheden for bugtende går op som de tekniske problemer med emnet går ned. Efter alt, jo større tekniske vanskeligheder kan jo færre deltagere virkelig at følge, hvad der sker. De, der kan forventes at være de mest erfarne udviklere, der allerede har deltaget i sådanne diskussioner tusindvis af gange før, og ved, hvad slags adfærd kan forventes at føre til en konsensus alle kan leve med.

Således konsensus er sværest at opnå i tekniske spørgsmål, der er let at forstå og let at have en mening om, og i «bløde» emner som organisation, reklame, finansiering, kan osv. Folk deltage i disse argumenter for evigt, fordi der er ingen kvalifikationer, der er nødvendige for at gøre det, ingen klare måder at afgøre (selv bagefter) hvis en afgørelse var rigtigt eller forkert, og fordi blot outwaiting andre debattører er nogle gange en succesfuld taktik.

Princippet om, at mængden af diskussionen er omvendt proportional med kompleksiteten af emnet har eksisteret i lang tid, og er kendt uformelt som Bikeshed Effect. Her er Poul-Henning Kamp forklaring på det, fra en nu berømt stilling til BSD udviklere:

Det er en lang historie, eller rettere det er en gammel historie, men det er ganske kort faktisk. C. Northcote Parkinson skrev en bog i de tidlige 1960′erne, kaldet «Parkinsons lov», som indeholder en masse indsigt i dynamikken i forvaltningen.

[...]

I det konkrete eksempel involverer cykelskur er den anden vital komponent en atomar kraftværk, jeg gætte, der illustrerer en alder af bogen.

Parkinson viser, hvordan du kan gå ind på bestyrelsen og få godkendelse til at bygge en multi-million eller endda milliarder dollar atomare kraftværk, men hvis du ønsker at opbygge et cykelskur vil du blive viklet ind i endeløse diskussioner.

Parkinson forklarer, at det er fordi en atomar plante er så stort, så dyrt og så kompliceret, at folk ikke kan forstå det, og snarere end at forsøge, de falder tilbage på den antagelse, at en anden tjekket alle detaljer, før det fik så langt. Richard P. Feynmann giver et par interessante, og meget til det punkt, eksempler vedrørende Los Alamos i sine bøger.

En cykelskur på den anden side. Alle kan bygge en af dem over en weekend, og stadig have tid til at se kampen på tv. Så uanset hvor godt forberedt, uanset hvor fornuftig du er med dit forslag vil nogen gribe chancen for at vise, at han gør sit job, at han er opmærksom, at han er her.

I Danmark kalder vi det «indstilling dit fingeraftryk». Det handler om personlig stolthed og prestige, det handler om at være i stand til at pege et sted og sige «Der! Jeg gjorde det.» Det er en stærk træk i politikerne, men er til stede i de fleste mennesker får chancen. Tænk bare fodspor i våd cement.

(Hans fuldstændige indlæg er meget værd at læse, også se tillæg C, hvorfor skulle jeg ligeglad med, hvad farve den Bikeshed Er.? Se også http://bikeshed.com.)

Enhver, der nogensinde taget regelmæssig del i gruppe beslutningstagning vil anerkende, hvad Kamp taler om. Men er det normalt umuligt at overtale alle til at undgå maleri bikesheds. Det bedste du kan gøre er at påpege, at fænomenet eksisterer, når man ser det ske, og overbevise senior udviklere-folket hvis indlæg bære mest vægt til at droppe deres pensler tidligt, så i det mindste de er ikke bidrager til støj. Bikeshed maleri partier vil aldrig gå væk helt, men du kan gøre dem kortere og mindre hyppigt ved at sprede en bevidsthed om fænomenet i projektets kultur.

Undgå Holy Wars

En hellig krig er en tvist, der ofte, men ikke altid over et relativt mindre problem, som ikke kan løses på rigtigheden af de argumenter, men hvor folk føler lidenskabeligt nok til at fortsætte argumentere alligevel i håb om, at deres side vil sejre. Hellige krige er ikke helt det samme som bikeshed malerier. Folk maleri bikesheds er som regel hurtige til at hoppe i med en udtalelse (fordi de kan), men de vil ikke nødvendigvis føler stærkt for det, og faktisk vil undertiden udtrykke andre, uforenelige holdninger, at vise, at de forstår alle sider af problemet. I en hellig krig, på den anden side at forstå de andre sider er et tegn på svaghed. I en hellig krig, kender alle der er ét rigtigt svar, de bare ikke enige om, hvad det er.

Når en hellig krig er begyndt, er det generelt ikke kan løses til alles tilfredshed. Det nytter ikke at påpege, midt i en hellig krig, at en hellig krig, der foregår. Alle ved, at allerede. Desværre et fælles træk ved hellige krige er uenighed om selve spørgsmålet om, hvorvidt tvisten er løses ved fortsat diskussion. Set udefra er det klart, at ingen af parterne er ved at ændre den andens sind. Set indefra er den anden side er stump og ikke tænke klart, men de kan komme rundt, hvis browbeaten nok. Nu siger jeg ikke der er aldrig en højre side i en hellig krig. Nogle gange er der-i de hellige krige, jeg har deltaget i, har det altid været min side, selvfølgelig. Men det gør ikke noget, for der er ingen algoritme for overbevisende viser, at den ene eller den anden har ret.

En fælles, men utilfredsstillende, hvordan folk forsøger at løse hellige krige er at sige «Vi har allerede brugt langt mere tid og energi at diskutere dette, end det er værd! Kan vi bare droppe det?» Der er to problemer med dette. For det første har den tid og energi, der allerede er brugt, og kan aldrig blive inddrevet-det eneste spørgsmål er nu, hvor meget større indsats rester? Hvis nogle mennesker føler, at bare en lidt mere diskussion vil bringe problemet til en tæt, så er det stadig giver mening (fra deres synspunkt) for at fortsætte.

Det andet problem med at bede om, at sagen skal droppes, er, at dette ofte svarer til at tillade den ene side, status quo, at erklære sejr ved passivitet. Og i nogle tilfælde er status quo kendt for at være uacceptabel alligevel: alle enige om, at nogle skal træffes beslutning, nogle foranstaltninger, der træffes. Dropper emnet ville være værre for alle, end blot at give op argumentet ville være for nogen. Men da det dilemma gælder for alle lige, er det stadig muligt at ende op at skændes for evigt om, hvad de skal gøre.

Så hvordan skal du håndtere hellige krige?

Det første svar er, så prøv at sætte tingene op, så de ikke sker. Det er ikke så håbløs, som det lyder:

Du kan forudse visse standard hellige krige: de har en tendens til at komme op over programmeringssprog, licenser (se afsnittet «GPL og Licens Compatibility» i kapitel 9, licenser, Copyrights og patenter), svar-til munging (se afsnittet kaldet «Den Store Svar til debat» i Kapitel 3, teknisk infrastruktur), og et par andre emner. Hvert projekt har normalt en hellig krig eller to alle sine egne, såvel som mangeårige udviklere vil hurtigt blive fortrolig med. Teknikkerne til at stoppe hellige krige, eller i det mindste begrænse deres tab, er stort set den samme overalt. Selv hvis du er positiv din side er rigtig, så prøv at finde en måde at udtrykke sympati og forståelse for de punkter den anden side gør. Ofte problemet i en hellig krig er, at fordi hver side har bygget sine vægge så højt som muligt, og gjort det klart, at enhver anden udtalelse er ren og skær dumhed, den handling at overgive eller ændre ens sind bliver psykisk uudholdeligt: det ville være en indrømmelse ikke blot for at tage fejl, men for at have været sikker og stadig være forkert. Den måde, du kan gøre denne optagelse velsmagende for den anden side er at udtrykke en vis usikkerhed selv-netop ved at vise, at du forstår de argumenter, de gør, og finde dem i det mindste fornuftigt, hvis ikke endeligt overbevisende. Lav en gestus, der giver plads til en gensidig gestus, og som regel vil situationen forbedres. Du er ikke mere eller mindre tilbøjelige til at få det tekniske resultat du ønskede, men i det mindste du kan undgå unødvendig indirekte skader til projektets moral.

Når en hellig krig ikke kan undgås, beslutte tidligt, hvor meget du pleje, og så være villig til offentligt at give op. Når du gør det, kan du sige, at du bakker ud, fordi den hellige krig ikke er det værd, men udtrykker ikke nogen bitterhed og ikke benytte lejligheden til en sidste afsked skudt på den modstående side argumenter. At give op er kun effektiv, når du er færdig med ynde.

Programmeringssprog hellige krige er lidt af et særtilfælde, fordi de ofte er meget tekniske, men mange mennesker føler sig kvalificeret til at deltage i dem, og indsatserne er meget høje, da resultatet kan bestemme, hvad sprog en god portion af projektets koden er skrevet i. Den bedste løsning er at vælge det sprog tidligt, med buy-in fra indflydelsesrige indledende udviklere, og derefter forsvare den med den begrundelse, at det er hvad du er alle komfortable skrivning i, ikke med den begrundelse, at det er bedre end nogle andet sprog, som kunne have været brugt i stedet. Lad aldrig samtalen udarte sig til en akademisk sammenligning af programmeringssprog (dette synes at ske særligt ofte, når nogen bringer op Perl, en eller anden grund), det er en død emne, du bare skal nægte at blive trukket ind.

For mere historisk baggrund på hellige krige, se http://catb.org/ ~ esr / jargon / html / H / hellig-wars.html, og papiret af Danny Cohen, der populariseret udtrykket, http://www.ietf .org/rfc/ien/ien137.txt.

Den «Noisy Minority» Effekt

Under alle postliste diskussion, er det nemt for en lille minoritet at give indtryk af, at der er en stor uenighed, ved at oversvømme listen med talrige lange e-mails. Det er lidt ligesom en filibuster, bortset fra at illusionen af udbredt uenighed er endnu mere kraftfuld, fordi det er fordelt over et vilkårligt antal diskrete stillinger og de fleste mennesker vil ikke gider at holde styr på, hvem der sagde hvad, hvornår. De vil bare have en instinktiv indtryk, at emnet er meget kontroversielt, og vente på balladen at dø ned.

Den bedste måde at modvirke denne effekt er at påpege det meget klart og fremlægge dokumentation herfor viser, hvor lille det faktiske antal af afvigere er, sammenlignet med dem i enighed. For at øge uligheden, kan du privat polle folk, der har været det meste tavs, men hvem du har mistanke enig med flertallet. Sig ikke noget, der tyder på, at modstanderne var bevidst forsøger at puste det indtryk de gjorde. Chancerne er de ikke var, og selv hvis de var, ville der ikke være nogen strategisk fordel at pege det ud. Alt du skal gøre, er at vise de faktiske tal i en side-by-side sammenligning, og folk vil indse, at deres intuition af situationen ikke matcher virkeligheden.

Dette råd gælder ikke kun for problemer med klar for-og-imod positioner. Det gælder for enhver diskussion, hvor en ballade bliver gjort, men det er ikke klart, at de fleste mennesker overveje spørgsmålet til debat for at være et reelt problem. Efter et stykke tid, hvis du er enig, at spørgsmålet ikke er værdig handling, og kan se, at den har undladt at få meget trækkraft (selvom det har genereret en masse mails) kan du bare observere offentligt, at det ikke er ved at blive trækkraft. Hvis «Støjende Minority» effekt har været på arbejde, vil dit indlæg virke som et frisk pust. De fleste folks indtryk af diskussionen op til det tidspunkt vil have været noget skumle: «Huh, det sikker føles som om der er nogle big deal her, fordi der sikkert er en masse indlæg, men jeg kan ikke se nogen klare fremskridt sker.» Ved at forklare, hvordan formen af diskussionen gjort det forekommer mere turbulent end det egentlig var, med tilbagevirkende kraft du give det en ny form, hvorigennem folk kan omformulere deres forståelse af hvad der skete.

Besværlige mennesker

Vanskelige mennesker er ikke nemmere at håndtere i elektroniske fora, end de er i person. Med «vanskelige» Jeg mener ikke «rude». Rude mennesker er irriterende, men de er ikke nødvendigvis svært. Denne bog har allerede diskuteret, hvordan de skal håndtere dem: kommentere uhøflighed første gang, og fra da af, enten at ignorere dem eller behandle dem på samme måde som alle andre. Hvis de fortsætter at være uhøflige, vil de normalt gøre sig så upopulær, at de har nogen indflydelse på andre i projektet, så de er en selvstændig holdig problem.

De er virkelig vanskelige tilfælde er folk, der ikke åbenlyst uhøfligt, men der manipulerer eller misbruger projektets processer på en måde, der ender med at koste andre mennesker tid og energi, men ikke bringe nogen gavnlig for projektet [22].

Ofte er sådanne mennesker ser for wedgepoints i projektets procedurer, for at give sig selv mere indflydelse, end de ellers ville have. Det er langt mere lumsk end blot uhøflighed, fordi hverken adfærd eller skader, den forårsager, er indlysende for udenforstående. Et klassisk eksempel er filibuster, hvor nogen (altid lyde så fornuftig som muligt, selvfølgelig) holder påstand om, at sagen, der drøftes ikke er klar til opløsning, og tilbyder flere og flere mulige løsninger, eller nye synspunkter på gamle løsninger, når hvad der virkelig foregår på, er, at han fornemmer, at en konsensus eller en stemmeseddel er ved at form og han ikke kan lide, hvor det er på vej hen. Et andet eksempel er, når der er en debat, der ikke vil konvergere på konsensus, men gruppen forsøger at mindst klarlægge de omstridte punkter og udarbejde en sammenfatning for alle at henvise til fra da af. Det modarbejdende, som kender resumé kan føre til et resultat, han ikke kan lide, vil ofte forsøge at forsinke selv resuméet, ved utrætteligt at komplicere spørgsmålet om, hvad der skal være i det, enten ved at modsætte sig rimelige forslag eller ved at indføre uventet ny elementer.

Håndtering besværlige mennesker

For at modvirke en sådan adfærd, det hjælper til at forstå mentaliteten hos dem, der deltager i det. Folk i almindelighed ikke gør det bevidst. Ingen vågner op om morgenen og siger til sig selv: «I dag vil jeg kynisk manipulere proceduremæssige former for at være en irriterende modarbejdende.» I stedet er sådanne handlinger ofte indledes med en semi-paranoid følelse af at blive lukket ud af gruppe interaktioner og beslutninger. Den person føler han ikke bliver taget alvorligt, eller (i de mere alvorlige tilfælde), at der er næsten en sammensværgelse mod ham, at de øvrige projektdeltagere har besluttet at danne en eksklusiv klub, hvor han ikke er medlem. Det så retfærdiggør, i hans sind, idet reglerne bogstaveligt og indgå i en formel manipulation af projektets procedurer, for at gøre alle andre tage ham alvorligt. I ekstreme tilfælde kan den person, mener endda, at han kæmper en ensom kamp for at redde projektet fra sig selv.

Det er karakteren af et sådant angreb indefra, at ikke alle vil bemærke det på samme tid, og nogle mennesker kan ikke se det på alle medmindre præsenteret med meget stærke beviser. Det betyder, at neutralisere det kan være en hel del af arbejdet. Det er ikke nok til at overbevise dig selv, at det sker, er du nødt til marshal nok beviser til at overbevise andre også, og så er du nødt til at distribuere denne dokumentation i en tankevækkende måde.

Da det er så meget arbejde at kæmpe, er det ofte bedre bare at tolerere det i et stykke tid. Tænk på det som en parasitisk, men mild sygdom: hvis det ikke er for invaliderende, kan projektet råd til at forblive smittede, og medicin kan have skadelige bivirkninger. Men hvis det bliver for ødelæggende for tolerere, så er det tid til handling. Begynde at indsamle noter på de mønstre, du ser. Sørg for at inkludere henvisninger til offentlige arkiver, dette er en af grundene til, at projektet holder optegnelser, så du kan lige så godt bruge dem. Når du har fået en god bygget sag, begynde at få private samtaler med andre deltagere i projektet. Må ikke fortælle dem, hvad du har observeret, men i stedet først spørge dem, hvad de har observeret. Dette kan være din sidste chance for at få ufiltreret feedback om, hvordan andre ser ballademager adfærd, når du begynder åbent at tale om det, vil udtalelsen blive polariseret, og ingen vil være i stand til at huske, hvad han tidligere mente om sagen.

Hvis private drøftelser tyder på, at i det mindste nogle andre se problemet, så er det tid til at gøre noget. Det er, når du er nødt til at få virkelig forsigtig, fordi det er meget nemt for denne slags person til at forsøge at gøre det ud som om du er picking på dem uretfærdigt. Uanset hvad du gør, aldrig beskylde dem for skadeligt misbrug projektets procedurer, for at være paranoid, eller i almindelighed af nogen af de andre ting, du har mistanke om er formentlig rigtigt. Deres strategi bør være at se både mere fornuftigt og mere optaget af den samlede velfærd af projektet med det mål enten at reformere persons adfærd, eller få dem til at gå væk permanent. Afhængigt af de andre udviklere, og dit forhold til dem, kan det være fordelagtigt at samle allierede privat først. Eller det kan ikke, det kan bare skabe ond vilje bag kulisserne, hvis folk tror du er engagere sig i en forkert hviskekampagne.

Husk, at selv om den anden person kan være den opfører sig destruktivt, vil du være den, der vises ødelæggende, hvis du laver en offentlig afgift, som du ikke kan bakke op. Vær sikker på at have masser af eksempler at vise, hvad du siger, og sige det så skånsomt som muligt mens den stadig er direkte. Du må ikke overtale den pågældende person, men det er okay, så længe du overtale alle andre.

Case study

Jeg husker kun én situation, i mere end 10 års arbejde i fri software, hvor tingene blev så slemt, at vi faktisk havde at spørge nogen til at stoppe udstationering helt. Som det så ofte er tilfældet, var han ikke uhøfligt, og oprigtigt ønskede kun at være hjælpsom. Han vidste bare ikke, når at skrive, og når ikke at skrive. Vores lister var åbent for offentligheden, og han var udstationering så ofte, og stiller spørgsmål på så mange forskellige emner, som det var at få til at være et støjproblem for fællesskabet. Vi havde allerede prøvet at bede ham pænt at gøre lidt mere forskning for at få svar, før du sender, men det havde ingen effekt.

Den strategi, der til sidst virkede er et perfekt eksempel på, hvordan man opbygger en stærk sag på neutrale, kvantitative data. En af vores udviklere gjorde nogle grave i arkiverne, og derefter sendt følgende besked privat til et par udviklere. Gerningsmanden (den tredje navn på listen nedenfor, her vist som «J. Random») havde meget lidt historie med projektet, og havde bidraget ingen kode eller dokumentation. Men han var den tredje mest aktive plakat på postlister:

Fra: «Brian W. Fitzpatrick» <fitz@collab.net>
Til: [... modtagerliste udeladt for anonymitet ...]
Om: Subversion Energy Sink
Dato: Wed, 12 Nov 2003 23:37:47 -0600

I de sidste 25 dage, de top 6 plakater til svn [dev | users] have liste
været:

294 kfogel@collab.net
236 «C. Michael Pilato» <cmpilato@collab.net>
220 «J. tilfældige» <jrandom@problematic-poster.com>
176 Branko Čibej <brane@xbc.nu>
130 Philip Martin <philip@codematters.co.uk>
126 Ben Collins-Sussman <sussman@collab.net>

Jeg ville sige, at fem af disse mennesker bidrager til Subversion
rammer 1,0 i den nærmeste fremtid.

Jeg vil også sige, at en af disse mennesker konsekvent trækker tid
og energi fra den anden 5, for ikke at nævne listen som helhed, således
(Omend ubevidst) forsinke udviklingen af Subversion. Jeg gjorde
ikke gøre en gevind analyse, men vgrepping min Subversion mail spool fortæller
mig, at hver post fra denne person er reageret på mindst én gang af på
mindst 2 af de andre 5 personer på ovenstående liste.

Jeg tror, en slags radikal indgriben er nødvendig her, selvom vi
gøre skræmme den førnævnte person væk. Spidsfindigheder og venlighed har
allerede vist sig at have nogen virkning.

dev @ subversion er en postliste for at fremme udviklingen af en version
styresystem, ikke en gruppe behandlingssession.

-Fitz, der forsøger at vade gennem tre dages svn post, han lod
hober sig op
Selvom det måske ikke synes så i starten, J. Random adfærd var et klassisk tilfælde af misbrug af projektets procedurer. Han var ikke gør noget indlysende som at forsøge at filibuster en afstemning, men han tog fordel af den postliste politik for at påberåbe sig selv mådehold af dets medlemmer. Vi har overladt det til den enkeltes dømmekraft, når at skrive og på hvilke emner. Således havde vi ingen proceduremæssige retsmidler til behandling af en person, der enten ikke har, eller ikke ville udøve, sådan dom. Der var ingen regel kunne pege på og sige stipendiaten var overtræder det, men alle vidste, at hans hyppige udstationering var få til at være et alvorligt problem.

Fitz strategi var, set i bakspejlet, mesterlige. Han samlede fældende kvantitative data, men derefter distribueret det diskret, sender den først til et par folk, hvis støtte ville være nøglen i enhver drastisk handling. De var enige om at en form for handling var nødvendig, og i sidste ende vi kaldte J. Random på telefonen, beskrev problemet til ham direkte, og bad ham simpelthen holde op med udstationering. Han har aldrig rigtig forstod, hvorfor, hvis han havde været i stand til at forstå, at han sandsynligvis ville have udøvet passende dom i første omgang. Men han besluttede at stoppe udstationering, og postlister blev brugbart igen. En del af grunden til denne strategi virkede var måske den implicitte trussel om, at vi kunne begynde at begrænse hans indlæg via moderation software normalt anvendes til at forhindre spam (se afsnittet «Spam Prevention» i kapitel 3, teknisk infrastruktur). Men grunden til at vi var i stand til at have denne mulighed i reserve, var, at Fitz havde samlet den nødvendige støtte fra nøglepersoner først.

Håndtering Vækst

Prisen for succes er tung i open source-verdenen. Som din software bliver mere populært, antallet af mennesker, der dukker op på udkig efter oplysninger stiger dramatisk, mens antallet af folk i stand til at give oplysninger stiger meget langsommere. Selv om forholdet var jævnt afbalanceret, er der stadig et grundlæggende skalerbarhed problem med den måde mest open source projekter håndterer kommunikation. Overvej postlister, for eksempel. De fleste projekter har en postliste for almindelige bruger spørgsmål, undertiden listen navn er «brugere», «diskutere», «hjælp», eller noget andet. Uanset dens navn, formålet med listen er altid det samme: at skabe et sted, hvor folk kan få deres spørgsmål besvaret, mens andre ser og (formentlig) absorberer viden fra at observere disse udvekslinger.

Disse postlister arbejde meget godt op til et par tusinde brugere og / eller et par hundrede indlæg om dagen. Men et eller andet sted efter det, begynder systemet til at bryde ned, fordi hver abonnent ser alle indlæg, og hvis antallet af stillinger til listen begynder at overstige, hvad en individuel læser kan behandle på en dag, listen bliver en byrde for sine medlemmer. Forestil dig for eksempel, hvis Microsoft havde sådan en postliste for Windows XP. Windows XP har hundredvis af millioner af brugere, hvis selv en tiendedel af en procent af dem havde spørgsmål i en given 24 timer periode, så er dette hypotetiske liste ville få hundredtusindvis af indlæg per dag! Denne liste kan aldrig eksistere, selvfølgelig, fordi ingen ville bo abonnerer på den. Dette problem er ikke begrænset til postlister, den samme logik gælder for IRC-kanaler, online diskussionsfora, faktisk af et system, hvor en gruppe hører spørgsmål fra enkeltpersoner. Konsekvenserne er ildevarslende: den sædvanlige open source model af massivt paralleliseret støtte simpelthen ikke skaleres til de niveauer, der er nødvendige for verdensherredømmet.

Der vil ikke være eksplosion, når fora nå brudpunkt. Der er bare en stille negativ feedback-effekt: Folk afmelde fra listerne, eller forlade IRC kanal, eller i hvert fald stoppe bekymre sig om at stille spørgsmål, fordi de kan se, at de ikke vil blive hørt i alle støj. Efterhånden som flere og flere mennesker gør dette meget rationelt valg, vil det forum aktivitet synes at bo på et overkommeligt niveau. Men det opholder sig håndterbare netop fordi de rationelle (eller i det mindste erfaren) folk er begyndt at se andetsteds for informations-mens de uerfarne folk blive tilbage og fortsætte med at sende. Med andre ord, er en bivirkning af at fortsætte med at bruge unscalable kommunikation modeller som projektet vokser, at den gennemsnitlige kvalitet af både spørgsmål og svar tendens til at gå ned, hvilket gør det til at ligne nye brugere er dummere end de plejede at være, når de er i Faktisk er de sandsynligvis ikke. Det er bare, at benefit / cost-forhold på at bruge disse high-befolkningen fora går ned, så naturligvis dem med erfaringen til at gøre det begynde at søge andre steder for at få svar først. Justering kommunikation mekanismer til at klare projektet vækst indebærer således to beslægtede strategier:

Genkendelse af bestemte dele af et forum ikke lider ubegrænset vækst, selv om forummet som helhed, og adskille de dele ud i nye, mere specialiserede fora (dvs. lad ikke gode blive trukket ned af den dårlige).

At sikre at der er mange automatiserede informationskilder til rådighed, og at de holdes organiseret, up-to-date, og nemt at finde.

Strategi (1) er normalt ikke for hårdt. De fleste projekter starter ud med en vigtigste forum: en generel diskussion postliste, som omfatter ideer, design spørgsmål, og kodende problemer kan alle hashed ud. Alle involverede i projektet er på listen. Efter et stykke tid, normalt bliver det klart, at listen har udviklet sig til flere forskellige emne-baserede dellister. For eksempel er nogle tråde klart om udvikling og design, andre er brugernes spørgsmål «Hvordan gør jeg X?» sort, måske er der et tredje emne familie centreret omkring behandling af fejlrapporter og ekstraudstyr anmodninger, og så videre. En given person naturligvis deltage måske i mange forskellige gevindtyper, men det vigtige er, at der ikke er en masse overlap mellem de forskellige typer selv. De kan opdeles i separate lister uden at forårsage nogen skadelig balkanisering, fordi trådene sjældent krydser topic grænser.

Faktisk gør denne opdeling er en to-trins proces. Du opretter den nye liste (eller IRC-kanal, eller hvad det er at være), og så du bruger uanset tid er nødvendig blidt nagende og minde folk til at bruge de nye fora på passende vis. Sidstnævnte trin kan vare i flere uger, men til sidst vil folk få den idé. Du er simpelthen nødt til at gøre et punkt for altid at fortælle afsenderen, når en stilling bliver sendt til den forkerte destination, og gøre det synligt, så andre mennesker opfordres til at hjælpe med routing. Det er også nyttigt at have en webside giver en guide til alle de lister til rådighed, dine svar kan blot henvise til denne webside, og som en bonus, kan modtageren lære noget om på udkig efter retningslinjer, før udstationering.

Strategi (2) er en løbende proces, som varer i projektets løbetid og involverer mange deltagere. Selvfølgelig er det dels et spørgsmål om at have up-to-date dokumentation (se afsnittet «Dokumentation» i kapitel 2, Introduktion) og sørg for at pege folk der. Men det er også meget mere end det, de efterfølgende afsnit diskutere denne strategi i detaljer.

Iøjnefaldende brug af Arkiv

Typisk bliver al kommunikation i et open source-projekt (undtagen undertiden IRC samtaler) arkiveres. Arkiverne er offentlige og søgbare, og har referentiel stabilitet: det er, når et givet stykke af oplysninger registreres på en bestemt adresse, forbliver på denne adresse for evigt.

Anvende disse arkiver så meget som muligt, og som tydeligt som muligt. Selv når du kender svaret på nogle spørgsmål fra toppen af dit hoved, hvis du tror der er en henvisning i arkiver, der indeholder svaret, tilbringe tid til at grave det op og præsentere den. Hver gang du gør det i et offentligt synlig måde, lære nogle mennesker for første gang, at arkiverne er der, og at søge i dem kan producere svar. Også ved at henvise til arkiverne i stedet for at omskrive de råd, styrke dig den sociale norm imod duplikere information. Hvorfor har det samme svar i to forskellige steder? Når antallet af pladser den kan findes holdes på et minimum, personer, som har fundet det før, er mere tilbøjelige til at huske hvad man skal søge efter for at finde den igen. Velplacerede referencer også bidrage til kvaliteten af søgeresultaterne i almindelighed, fordi de styrker den målrettede ressources placering i søgemaskiner på internettet.

Der er tidspunkter, hvor duplikere information giver mening, dog. For eksempel antage, at der er et svar, der allerede i arkiverne, ikke fra dig, siger:

Det ser ud til, at dine Scanley indekser er blevet frobnicated. Til
unfrobnicate dem, køre disse trin:

1. Sluk for Scanley server.
2. Kør ‘defrobnicate «-programmet, der følger med Scanley.
3. Start serveren.
Så måneder senere, kan du se et andet indlæg indikerer, at en eller andens indekser er blevet frobnicated. Du søger i arkiverne og komme op med det gamle svar ovenfor, men du indser det mangler nogle trin (måske ved en fejltagelse, eller måske fordi softwaren har ændret sig siden denne post blev skrevet). Den fineste måde at håndtere dette på er at skrive en ny, mere komplet sæt af instruktioner, og eksplicit forældede gamle indlæg ved at nævne det:

Det ser ud til, at dine Scanley indekser er blevet frobnicated. Vi
så dette problem tilbage i juli, og J. Random postet en løsning på
http://blahblahblah/blah. Nedenfor er en mere komplet beskrivelse af
hvordan man kan unfrobnicate dine indekser, baseret på J. Tilfældige anvisninger
men udvide dem lidt:

1. Sluk for Scanley server.
2. Bliv brugeren den Scanley server normalt kører som.
3. Som den pågældende bruger, skal du køre ‘defrobnicate’ program på indekser.
4. Køre Scanley med hånden for at se, om de indekser virke nu.
5. Genstart serveren.
(I en ideel verden, ville det være muligt at fastgøre en note til den gamle post, siger, at der er nyere tilgængelige oplysninger og peger på den nye post. Men jeg kender ikke til nogen arkivering software, som tilbyder en «forældet ved «feature, måske fordi det ville være mildt vanskelig at gennemføre på en måde, der ikke krænker arkiverne ‘integritet som ordret rekord. Dette er en anden grund til, at oprette dedikerede websider med svar på almindelige spørgsmål er en god idé.)

Arkiver er formentlig oftest søgt efter svar på tekniske spørgsmål, men deres betydning for projektet går langt ud over det. Hvis et projekts formelle retningslinjer er dens lovpligtige lov, arkiverne er dens common law: en fortegnelse over alle beslutninger, der træffes, og hvordan de var nået frem til. I alle tilbagevendende diskussion, er det temmelig meget obligatorisk i dag at starte med et arkiv søgning. Dette giver dig mulighed for at begynde diskussionen med en oversigt over den aktuelle tingenes tilstand, foregribe indvendinger, forberede modargumenter, og muligvis opdage vinkler du ikke havde tænkt på. Desuden vil de øvrige deltagere forventer at du har gjort et arkiv søgning. Selv hvis de tidligere drøftelser gik ingen steder, bør du medtage henvisninger til dem, når du re-raise emnet, så folk selv kan se, a) at de gik ingen steder, og b) at du gjorde dit hjemmearbejde, og derfor sandsynligvis siger noget nu, ikke er blevet sagt tidligere.

Behandl alle ressourcer som arkiver

Alle de foregående råd gælder for mere end blot postlistearkiver. Under særlige stykker af information til stabile, bekvemt findable adresser skal være et organiserende princip for alle projektets oplysninger. Lad os tage projektet FAQ som case.

Hvordan folk bruger en FAQ?

1. De ønsker at søge i den efter bestemte ord og sætninger.
2. De ønsker at gennemse det, slikke information uden nødvendigvis søger svar på specifikke spørgsmål.
3. De forventer søgemaskiner såsom Google at vide om FAQ indhold, således at søgninger kan resultere i FAQ poster.
4. De ønsker at være i stand til at henvise andre mennesker direkte til specifikke elementer i FAQ.
5. De ønsker at være i stand til at tilføje nyt materiale til FAQ, men bemærk at dette sker langt sjældnere end svar er så op-ofte stillede spørgsmål er langt oftere læst fra end skrevet til.

Punkt 1 indebærer, at FAQ bør være tilgængelige i en form for tekstuel format. Punkt 2 og 3 indebærer, at FAQ skal være tilgængelig som en HTML-side, med punkt 2 yderligere indikerer, at HTML skal udformes for læsbarhed (dvs., vil du ønsker en vis kontrol over dens udseende), og bør have en tabel af indholdet. Punkt 4 betyder, at hver enkelt post i FAQ bør tildeles en HTML navngivet anker, et tag, der giver folk mulighed for at nå et bestemt sted på siden. Punkt 5 betyder kildefilerne for FAQ skal være tilgængelige på en praktisk måde (se afsnittet «Version alt» i kapitel 3, teknisk infrastruktur), i et format, der er let at redigere.

Navngivne Ankre og id-attributter

Der er to måder at få en browser til at springe til et bestemt sted i en webside: navngivne ankre og id attributter.

En navngiven anker er bare en normal HTML anker element (<a> … </ a>), men med et «navn» attribut:

<a name=»mylabel»> … </ a>
Nyere versioner af HTML understøtte en generisk id attribut, der kan fastgøres til ethvert HTML-element, ikke bare for at <a>. For eksempel:

<p id=»mylabel»> … </ p>
Både navngivne ankre og id attributter anvendes på samme måde. Man tilføjer en hash mærke og mærket til en URL, at få browseren til at springe direkte til det sted på siden:

http://myproject.example.com/faq.html # mylabel
Stort set alle browsere understøtter navngivne ankre, de fleste moderne browsere understøtter id-attribut. At spille det sikkert, vil jeg anbefale at bruge enten navngivne ankre alene eller navngivne ankre og id attributter sammen (med den samme etiket for både i en given par, selvfølgelig). Navngivne ankre kan ikke være selvlukkende-selvom der er ingen tekst inde i elementet, skal du stadig skrive det i to-sidet form:

<a name=»mylabel»> </ a>
… Men normalt ville der være noget tekst, som titlen på en sektion.

Uanset om du bruger en navngivet anker, eller et id attribut, eller begge, skal du huske, at etiketten ikke vil være synlig for en person, der gennemser til det pågældende sted uden at bruge mærket. Men en sådan person måske ønsker at opdage etiketten for et bestemt sted, så de kan sende URL-adressen til en FAQ svar på en ven, f.eks. For at hjælpe dem med at gøre dette, skal du tilføje en titel attribut til samme element (er), hvor du tilføjede «navn» og / eller «id» attribut, for eksempel:

<a name=»mylabel» title=»#mylabel»> … </ a>
Når musemarkøren holdes over teksten i titel-tilskrevet element, vil de fleste browsere poppe op en lille boks, der viser titlen. Jeg normalt omfatte den hash-tegn, for at minde brugeren om, at dette er, hvad hun ville sætte i slutningen af URL’en for at springe direkte til denne placering næste gang.

Formatering af FAQ som dette er blot ét eksempel på, hvordan man laver en ressource præsentabel. Det samme egenskaber-direkte søgbarhed, tilgængelighed til de store søgemaskiner på internettet, browsability, referentiel stabilitet, og (eventuelt) redigerbarhed-gælder for andre websider, kildekoden træet, bug tracker, osv. Det sker bare, at de fleste postliste arkivering software længe siden erkendt betydningen af disse egenskaber, hvilket er grunden til postlister tendens til at have denne funktionalitet indbygget, mens andre formater kan kræve en ekstra indsats på vedligeholderens del (kapitel 8, adm. Frivillige diskuterer, hvordan man sprede at vedligeholdelse byrde på tværs af mange volontører).

Kodificering Tradition

Som et projekt erhverver historie og kompleksitet, mængden af data hver indgående deltager skal absorbere stigninger. De, der har været med i projektet i lang tid var i stand til at lære, og opfinde, projektets konventioner, som de gik sammen. De vil ofte ikke være bevidst om, hvad en enorm mængde tradition er akkumuleret, og måske blive overrasket over, hvor mange fejltrin nytilkomne synes at gøre. Selvfølgelig er problemet ikke, at de nytilkomne er af nogen ringere kvalitet end før, det er, at de står over for en større akkulturation byrde end nyankomne gjorde i fortiden.

Traditionerne et projekt akkumuleres er lige så meget om, hvordan man kommunikerer og bevare oplysninger, som de om er kodning standarder og andre tekniske minutae. Vi har allerede set på begge slags standarder, i afsnittet «Developer dokumentation» i kapitel 2, Introduktion og afsnittet «skrive det hele ned» i kapitel 4, sociale og politiske infrastruktur henholdsvis, og eksempler gives der . Hvad dette afsnit er om, er hvordan man holder sådanne retningslinjer up-to-date, da projektet udvikler sig, især retningslinjer om, hvordan kommunikation er lykkedes, fordi det er dem, der ændrer mest som projektet vokser i størrelse og kompleksitet.

Først, se efter mønstre i hvordan folk bliver forvirrede. Hvis du ser de samme situationer kommer op igen og igen, især med nye deltagere, chancer er der er en retningslinje, der skal dokumenteres, men er det ikke. For det andet, skal du ikke bliver træt af at sige de samme ting igen og igen, og lyder ikke som om du er træt af at sige dem. Du og andre projektdeltagere veteraner bliver nødt til at gentage jer selv ofte, det er en uundgåelig bivirkning af ankomsten af nyankomne.

Hver webside, hver postliste besked, og hver IRC kanal bør betragtes reklameplads-ikke for kommercielle reklamer, men for annoncer om dit projekt egne ressourcer. Hvad du lægger i at rummet afhænger af demografien i de tilbøjelige til at læse den. En IRC kanal til spørgsmål fra brugerne, for eksempel, er tilbøjelige til at få folk, der aldrig har interageret med projektet, før-ofte en person, der netop har installeret softwaren, og har et spørgsmål, som han gerne vil besvaret straks (efter alle, hvis den kunne vente, ville han have sendt den til en postliste stedet, hvilket ville nok bruge mindre af sin samlede tid, selv om det ville tage længere tid for et svar at komme tilbage). Folk normalt ikke lave en permanent investering på IRC kanalen, de vil dukke op, så spørg deres spørgsmål, og forlade.

Derfor bør den kanal emne være rettet mod mennesker på udkig efter tekniske svar om softwaren lige nu, snarere end på, siger folk, der kan blive involveret med projektet i en langsigtet måde, og for hvem lokalsamfundet interaktion retningslinjer ville være mere passende. Her er hvordan en virkelig travl kanal håndterer det (sammenlign dette med det tidligere eksempel i afsnittet «IRC / real-time chat Systems» i kapitel 3, teknisk infrastruktur):

Du taler på # linuxhelp

Emne for # linuxhelp er Læs venligst
http://www.catb.org/ ~ esr / faqs / smart-questions.html &&
http://www.tldp.org/docs.html # howto inden du stiller spørgsmål | Kanal
regler er på http://www.nerdfest.org/lh_rules.html | Kontakt
http://kerneltrap.org/node/view/799 før vi beder om opgradering til en
2.6.x kerne | hukommelse læse muligt: http://tinyurl.com/4s6mc ->
opdatere til 2.6.8.1 eller 2.4.27 | hash algo katastrofe: http://tinyurl.com/6w8rf
| Reiser4 ud
Med postlister, er «annonceplads» en lille footer vedlagt hver besked. De fleste projekter sætter abonnement / afmelding anvisninger der, og måske en pointer til projektets hjemmeside eller FAQ side så godt. Du tror måske, at nogen abonnerer på listen ville vide hvor man kan finde disse ting, og de sandsynligvis gør-men mange flere mennesker end blot abonnenter se de postliste beskeder. En arkiveret Stillingen kan være knyttet til mange steder fra, ja, nogle stillinger blevet så almindeligt kendt, at de i sidste ende har flere læsere fra listen, end på det.

Formatering kan gøre en stor forskel. For eksempel, i Subversion-projektet var vi med begrænset succes ved hjælp af bug-filtrering teknikken beskrevet i afsnittet «Pre-Filtrering af Bug Tracker» i kapitel 3, teknisk infrastruktur. Mange falske fejlrapporter stadig blev indgivet af uerfarne folk, og hver gang det skete, at filer måtte blive uddannet på nøjagtig samme måde som de 500 mennesker før ham. En dag, efter at en af vores udviklere endelig havde fået til slutningen af hans reb og flammet nogle fattige bruger, der ikke har læst de issue tracker retningslinjer omhyggeligt nok, en anden udvikler besluttede dette mønster var varet længe nok. Han foreslog, at vi omformatere issue tracker forsiden, så den vigtigste del, et påbud om at drøfte bug på postlisterne eller IRC-kanaler før arkivering, ville skille sig ud i store, fede røde bogstaver, på en lys gul baggrund, centreret tydeligt over alt andet på siden. Vi gjorde det (du kan se resultaterne på http://subversion.tigris.org/project_issues.html), og resultatet var en mærkbar nedgang i antallet af falske udstede ansøgninger. Vi har stadig få dem, selvfølgelig, vi altid vil-men hastigheden er aftaget betydeligt, selv når antallet af brugere stiger. Resultatet er ikke kun, at fejldatabase indeholder mindre junk, men at dem, der reagerer på udstede Filspåner bo i et bedre humør, og er mere tilbøjelige til at forblive venlig når du svarer til en af de nu sjældne falske ansøgninger. Dette forbedrer både projektets image og den mentale sundhed sine frivillige.

Den lektie for os var, at blot skrive de retningslinjer, ikke var nok. Vi havde også at sætte dem hvor de ville blive set af dem, der har brug for dem mest, og formatere dem på en sådan måde, at deres status som indledende materiale ville være umiddelbart klart for folk kender til projektet.

Statiske websider er ikke den eneste mødested for reklame projektets skikke. En vis mængde interaktive politiarbejde (i det venlige-påmindelse forstand, ikke håndjern-og-fængsel forstand) er også påkrævet. Alle peer review, selv de begå vurderinger er beskrevet i afsnittet «Praksis Conspicuous Code Review» i Kapitel 2, Introduktion, bør omfatte gennemgang af folks overensstemmelse eller ikke-overensstemmelse med projektets normer, især med hensyn til kommunikation konventioner.

Et andet eksempel fra Subversion projektet: vi afgjort på en konvention om «r12908″ til at betyde «revision 12.908 i den version kontrol repository.» Den lavere-case «r» præfiks er let at skrive, og fordi det er halvdelen af højden af cifrene, det gør en let-genkendelige tekstblok, når det kombineres med cifrene. Selvfølgelig betyder afregning på konventionen betyder ikke, at alle vil begynde at bruge det konsekvent med det samme. Så når en commit mail kommer ind med en log besked som denne:

------------------------------------------------------------------------
r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines

Patch from J. Random Contributor <jrcontrib@gmail.com>

* trunk/contrib/client-side/psvn/psvn.el:
  Fixed some typos from revision 12828.
------------------------------------------------------------------------

… Del af revisionen, at commit er at sige «Af den måde, kan du bruge ‘r12828′, ikke ‘revision 12.828′, når der henvises til tidligere ændringer.» Det er ikke bare pedanteri, det er vigtigt så meget for automatisk parsability som for human læserskare.

Ved at følge det generelle princip, at der skal være kanoniske henvisning metoder til fælles enheder, og at disse henvisninger bør anvendes konsekvent overalt, at projektet i realiteten eksporten af visse standarder. Disse standarder giver folk mulighed for at skrive værktøjer, der præsenterer projektets kommunikation i mere brugbar måde, for eksempel kunne en revision formateret som «r12828″ blive omdannet til en levende link til lageret browsing system. Dette ville være sværere at gøre, hvis revisionen blev skrevet som «revision 12.828″, både fordi denne form kunne deles på tværs af et linjeskift, og fordi det er mindre tydelig (ordet «revision» vil ofte synes alene, og grupper af tal vil ofte vises alene, mens kombinationen «r12828″ kan kun betyde en revision nummer). Tilsvarende betænkeligheder gælder at udstede numre, FAQ poster (hint: brug en URL med en navngiven anker, som beskrevet i Navngivne Ankre og id-attributter), osv.

Selv for virksomheder, hvor der ikke er en oplagt kort, kanoniske form, skal folk stadig tilskyndes til at give vigtige stykker af information konsekvent. For eksempel, når der henvises til en postliste besked ikke bare give afsender og emne, også give arkivet URL og Message-ID header. Det sidste giver mulighed for folk, der har deres egen kopi af mailingliste (folk nogle gange holde offline kopier, for eksempel til brug på en bærbar computer mens rejser) til klart at identificere det rigtige budskab, selv om de ikke har adgang til arkiverne. Den afsender og emne ville ikke være nok, da samme person kan gøre flere indlæg i samme tråd, selv på den samme dag.

Jo mere et projekt vokser, jo vigtigere er denne form for konsekvens bliver. Overensstemmelse betyder, at overalt folk ser, de ser de samme mønstre, som følges, så de ved at følge disse mønstre selv. Dette vil igen, reducerer antallet af spørgsmål, de har brug for at spørge. Byrden af at have en million læsere ikke er større end det for at have en, skalerbarhed problemerne begynder at opstå, når en vis procentdel af de læsere stille spørgsmål. Som et projekt vokser, og derfor skal det nedsætte nævnte procentsats ved at øge tætheden og adgang til information, således at en given person er mere tilbøjelige til at finde, hvad han har brug for uden at skulle spørge.

Ingen Samtaler i Bug Tracker

I hvert projekt, der laver aktiv brug af sin bug tracker, er der altid en fare for trackeren bliver til et diskussionsforum sig selv, selv om de postlister ville virkelig være bedre. Normalt er det starter uskyldigt nok: nogen annotates et problem med, siger en foreslåede løsning, eller en delvis patch. Nogen ser dette, indser der er problemer med løsningen, og lægger en anden anmærkning påpege problemerne. Den første person reagerer, igen ved at føje til spørgsmålet … og sådan fortsætter det.

Problemet med dette er, for det første, at bug tracker er en temmelig besværlig sted at have en diskussion, og for det andet, at andre mennesker ikke kan betale opmærksomhed trods alt forventer de udvikling diskussion til at ske på udviklingen mailingliste, så det er her, de ser for det. De kan ikke tegnes til spørgsmålet ændrer listen overhovedet, og selv hvis de er, kan de ikke følge det meget nøje.

Men præcis hvor i processen gjorde noget gå galt? Var det da den oprindelige person tilknyttet hendes løsning på spørgsmålet, burde hun have bragt det til listen i stedet? Eller var det, når den anden person, der svarede på spørgsmålet, i stedet for på listen?

Der er ikke ét rigtigt svar, men der er et generelt princip: hvis du bare tilføje data til et problem, så gør det i den tracker, men hvis du starter en samtale, så gør det på mailinglisten. Du kan ikke altid være i stand til at fortælle hvilket er tilfældet, men bare bruge din sunde fornuft. For eksempel, når du vedhæfter et plaster, der indeholder et potentielt kontroversielt løsning kan du være i stand til at forudse, at folk er nødt til spørgsmål om det. Så selvom du normalt ville vedhæfte plastret til spørgsmålet (forudsat at du ikke vil eller ikke kan begå ændringen direkte), i dette tilfælde kan du vælge at sende det til en postliste stedet. I hvert fald, i sidste ende vil der komme et punkt i udvekslingen, hvor den ene part eller den anden kan fortælle, at det er ved at gå fra simpel tilføjelse af data til en egentlig samtale-in eksemplet, der startede dette afsnit, ville det være den anden respondent, der på indse, at der var problemer med patch, kunne forudsige, at en reel samtale er ved at opstå, og at det derfor skulle holdes i passende medium.

For at bruge en matematisk analogi, hvis oplysningerne ligner det vil være hurtigt konvergerende, og derefter sætte det direkte i bug tracker, hvis det ser ud som det vil være divergerende, så en mailingliste eller IRC kanal ville være et bedre sted.

Dette betyder ikke, at der bør aldrig være nogen centraler i bug tracker. Beder om yderligere oplysninger om reproduktion opskrift fra den oprindelige reporter tendens til at være en meget konvergent proces, for eksempel. Personens reaktion er det usandsynligt at rejse nye spørgsmål, det er simpelthen kommer til at konkretisere oplysninger, der allerede indgivet. Der er ingen grund til at distrahere postliste med denne proces, ved alle midler, pleje af det tage en række kommentarer i trackeren. Ligeledes, hvis du er temmelig sikker på, at fejlen har været fejlrapporteres (dvs. er ikke en fejl), så kan du bare sige det lige i spørgsmålet. Selv påpege et mindre problem med et løsningsforslag er fint, forudsat at problemet ikke er en showstopper for hele løsningen.

På den anden side, hvis du hæve filosofiske spørgsmål om bug anvendelsesområde eller softwarens korrekt adfærd kan du være temmelig sikker på andre udviklere vil ønske at blive inddraget. Diskussionen vil sandsynligvis afvige i et stykke tid, før den konvergerer, så gør det på mailinglisten.

Altid linke til postlisten tråd fra spørgsmålet, når du vælger at skrive til postlisten. Det er stadig vigtigt for nogen efter udstedelsen at være i stand til at nå diskussionen, selv om spørgsmålet i sig selv ikke den diskussionsforum. Den person, der starter tråden kan finde denne møjsommelige, men open source er fundamentalt et forfatter-ansvarlig kultur: det er meget mere vigtigt at gøre tingene let for snesevis eller hundredvis af mennesker, der kan læse fejlen end for de tre eller fem mennesker til at skrive om det.

Det er fint at tage vigtige konklusioner eller resuméer fra listen diskussion og indsætte dem i sagen, hvis det vil gøre tingene praktisk for læserne. En fælles formsprog er at starte en liste diskussion, lægge et link til tråden i dette spørgsmål, og derefter når diskussion er færdig, skal du indsætte afsluttende sammenfatning i spørgsmålet (sammen med et link til den meddelelse, der indeholder det resumé), så nogen browsing spørgsmålet kan nemt se, hvad konklusion nåede uden at skulle klikke på et andet sted. Bemærk, at den sædvanlige «to herrer» data dobbeltarbejde problem ikke eksisterer her, fordi både arkiver og udstede kommentarer er normalt statiske, uforanderlige data alligevel.

Offentlighed

I fri software, er der en forholdsvis glat kontinuum mellem rent interne drøftelser og public relations erklæringer. Det er dels fordi målgruppen er altid dårligt defineret: eftersom de fleste eller alle indlæg er offentligt tilgængelige, er projektet ikke har fuld kontrol over det indtryk verden bliver. Nogen-sige, en slashdot.org redaktør-kan trække millioner af læsernes opmærksomhed til en stilling, som ingen nogensinde forventes at blive set uden for projektet. Det er en kendsgerning, at alle open source-projekter leve med, men i praksis er risikoen normalt lille. I almindelighed er udmeldingerne, at projektet helst vil publiceret dem, der vil være mest offentliggøres, forudsat at du bruger de rigtige mekanismer til at angive relative nyhedsværdi til omverdenen.

For store annonceringer, har en tendens der at være fire eller fem vigtigste kanaler for distribution, hvor meddelelser skal foretages som næsten samtidig som muligt:

1. Dit projekt forside er sandsynligvis set af flere mennesker end nogen anden del af projektet. Hvis du har en virkelig vigtig meddelelse, sætte en bagsidetekst der. Den bagsidetekst bør være en meget kort synopsis, der linker til pressemeddelelsen (se nedenfor) for at få flere oplysninger.
2. Samtidig skal du også have en «News» eller «Press Releases» område af hjemmesiden, hvor meddelelsen kan skrives op i detaljer. En del af formålet med en pressemeddelelse er at tilvejebringe en enkelt, kanonisk «annonceringen objekt», at andre sites kan linke til, så sørg for at det er struktureret i overensstemmelse hermed: enten som en webside per udgivelse, som en diskret blogoptegnelse, eller som anden form for enhed, der kan linkes til, mens stadig holdes adskilt fra andre pressemeddelelser i samme område.
3. Hvis dit projekt har en RSS-feed (se afsnittet «RSS-feeds»), skal du sørge meddelelsen går ud der også. Dette kan ske automatisk, når du opretter pressemeddelelsen, afhængigt af hvordan tingene er sat op på dit websted.
4. Hvis meddelelsen handler om en ny version af softwaren, derefter opdatere dit projekt indtræden på http://freecode.com/ (se afsnittet «Annoncerer» om at skabe angivelsen i første omgang). Hver gang du opdaterer en Freecode indrejse, at indrejse går på Freecode ændre listen for dagen. Ændringen Listen opdateres ikke kun på Freecode sig selv, men på forskellige portalwebsteder (herunder http://slashdot.org), som bliver overvåget ivrigt af horder af mennesker. Freecode også tilbyder de samme data via RSS-feed, så folk, der ikke abonnerer på dit projekt egen RSS-feed kan stadig se annonceringen via Freecode er.
5. Send en mail til dit projekt udmelding postliste. Denne liste navn burde faktisk være «annoncere», det vil sige announce@yourprojectdomain.org, fordi det er en temmelig standard konvention nu, og listen fundats bør gøre det klart, at det er meget lav trafik, der er reserveret til store projekt annonceringer. De fleste af disse meddelelser vil være omkring nye versioner af softwaren, men lejlighedsvis andre begivenheder, såsom en fundraising-drev, opdagelsen af en sårbarhed (se afsnittet «Annoncerer Sikkerhedssvagheder») senere i dette kapitel, eller et stort skift i projekt retning kan blive offentliggjort der. Fordi det er lav trafik og bruges kun til vigtige ting, announce listen typisk har den højeste subscribership af enhver mailingliste i projektet (selvfølgelig, det betyder, at du må ikke misbruge det, overveje nøje, før udstationering). For at undgå tilfældige mennesker gør annonceringer, eller værre, spam komme igennem, skal announce listen altid være modereret.

Prøv at gøre meddelelserne i alle disse steder på samme tid, så nær som muligt. Folk kan få forvirret, hvis de ser en meddelelse på postlisten, men så skal du ikke se det afspejlet på projektets hjemmeside eller i dets pressemeddelelser område. Hvis du får de forskellige ændringer (e-mails, webside redigeringer osv.), kø og derefter sende dem alle i en række, kan du holde vinduet for inkonsekvens meget lille.

For en mindre vigtig begivenhed, kan du fjerne nogle eller alle de ovennævnte forretninger. Arrangementet vil stadig blive bemærket af omverdenen i direkte forhold til dens betydning. For eksempel, mens en ny version af softwaren er en stor begivenhed blot at fastsætte datoen for den næste udgivelse, mens stadig noget nyhedsværdi, er ikke nær så vigtigt som frigivelsen selv. Indstilling af en dato er værd en e-mail til de daglige postlister (ikke announce listen), og en opdatering af projektets tidslinje eller status webside, men ikke mere.

Men du kan stadig se denne dato er anført i diskussioner andre steder på internettet, hvor der er folk interesserede i projektet. Folk, der er lurkers på dine mailinglister, bare lytter og aldrig at sige noget, er ikke nødvendigvis tavs andetsteds. Word of mouth giver meget bred distribution, og du skal regne med det, og konstruere selv mindre meddelelser på en sådan måde, at det fremmer nøjagtig uformel transmission. Specielt bør stillinger, som du forventer at blive noteret have en klart betydet-til-være-citerede del, lige som om du skrev en formel pressemeddelelse. For eksempel:

Blot et fremskridt update: vi planlægger at frigive version 2.0 af Scanley i midten af august 2005. Du kan altid tjekke http://www.scanley.org/status.html for opdateringer. Den største nye funktion vil være regelmæssige-udtryk søgninger.

Andre nye funktioner omfatter: … Der vil også være forskellige fejlrettelser, herunder: …

Første afsnit er kort, giver de to vigtigste stykker information (udgivelsesdato og de store nye funktion) og en webadresse til at besøge for yderligere nyheder. Hvis dette stykke er det eneste, der krydser en eller andens skærm, er du stadig klarer sig ganske godt. Resten af post kunne gå tabt uden at påvirke essensen af indholdet. Selvfølgelig, folk nogle gange vil linke til hele post alligevel, men lige så ofte, vil de citerer kun en lille del. Da sidstnævnte er en mulighed, kan du lige så godt gøre det nemt for dem, og oven i købet få en vis indflydelse på, hvad der bliver citeret.

Annoncerer Sikkerhedssvagheder

Håndtering af et sikkerhedsproblem er forskellig fra håndtering af enhver anden form for fejlrapport. I fri software, er at gøre tingene åbent og gennemsigtigt normalt næsten en religiøs credo. Alle trin af standard bug-handling proces er synlig for alle, der gider se: ankomsten af den første rapport, den efterfølgende debat, og den endelige løsning.

Sikkerhed bugs er forskellige. De kan kompromittere brugeres data, og muligvis brugernes hele computere. At diskutere et sådant problem åbent ville være at annoncere sin eksistens til hele verden, inklusive alle de parter, der kan gøre ondsindet brug af fejlen. Selv blot at begå en rettelse effektivt annoncerer bug eksistens (der er potentielle angribere, der ser de tilsagn kævler af offentlige projekter, systematisk at se efter ændringer, som indikerer sikkerhedsproblemer i pre-change-kode). De fleste open source-projekter har slået sig ned på omtrent det samme sæt af trin til at håndtere denne konflikt mellem åbenhed og hemmeligholdelse, baseret på de disse grundlæggende retningslinjer:

Tal ikke om fejlen offentligt indtil der findes en rettelse, så skal forelægge fix på nøjagtigt samme øjeblik du annoncere fejlen.

Kom op med at fix så hurtigt som du kan, især hvis nogen udenfor projektet rapporterede fejlen, fordi så du ved, der er mindst én person udenfor projektet, som er i stand til at udnytte sårbarheden.

I praksis fører disse principper til en temmelig standardiseret række trin, som er beskrevet i de følgende afsnit.

Modtag rapporten

Det er klart, et projekt har brug for evnen til at modtage sikkerhedsopdateringer fejlrapporter fra nogen. Men den regelmæssige bug rapportering adresse vil ikke gøre, fordi det kan ses af alle, også. Derfor har en separat postliste for modtage sikkerhedsopdateringer fejlrapporter. Denne postliste må ikke have offentligt læsbare arkiver, og dens subscribership skal være strengt kontrolleret kun lang tid, kan betroede udviklere være på listen. Hvis du har brug for en formel definition af «betroede», kan du bruge «enhver, der har haft commit adgang til to år eller mere», eller sådan noget, for at undgå favorisering. Det er den gruppe, der vil håndtere sikkerhed bugs.

Ideelt set bør sikkerheden liste ikke være beskyttet mod spam, eller modereret, da du ikke ønsker en vigtig rapport for at få filtreret ud eller forsinket bare fordi nogen moderatorer tilfældigvis online denne weekend. Hvis du gør brug automatiseret spam-beskyttelse software, kan du prøve at konfigurere den med høj tolerance-indstillinger, det er bedre at lade et par spams igennem end at gå glip af en rapport. For listen for at være effektiv, skal du reklamere sin adresse, selvfølgelig, men i betragtning af, at det vil være modereret, og i bedste fald let beskyttet mod spam, så prøv at aldrig at skrive sin adresse uden en form for adresse skjule transformation, som beskrevet i afsnittet «Address gemmer sig i arkiverne» i kapitel 3, teknisk infrastruktur. Heldigvis adresse-skjul behøver ikke gøre adressen ulæseligt; se http://subversion.tigris.org/security.html, og se at sidens HTML-kilde, for et eksempel.

Udvikle fix roligt

Så hvad betyder den sikkerhed liste gøre, når den modtager en rapport? Den første opgave er at vurdere problemets alvorlighed og presserende:

1. Hvor alvorligt er sårbarheden? Betyder det give en ondsindet hacker at overtage computeren af en person, der bruger din software? Eller gør det, siger blot lække oplysninger om størrelsen af nogle af deres filer?
2. Hvor let er det at udnytte sårbarheden? Kan et angreb være scripted, eller kræver det indicier viden, uddannet gætte, og held?
3. Hvem rapporteret problemet for dig? Svaret på dette spørgsmål ændrer ikke karakteren af sårbarhed, selvfølgelig, men det giver dig en idé om, hvor mange andre mennesker kan vide om det. Hvis rapporten kommer fra en af projektets egne udviklere, kan du trække vejret lidt lettere (men kun lidt), fordi du kan have tillid til dem ikke at have fortalt andre om det. På den anden side, hvis det kom i en e-mail fra anonymous14@globalhackerz.net så du må hellere handle så hurtigt som du kan. Den person har du en fordel ved at informere dig om problemet på alle, men du har ingen idé om, hvor mange andre mennesker, hun har fortalt, eller hvor længe hun vil vente, før at udnytte sårbarheden på levende installationer.

Bemærk, at forskellen vi taler om her, er ofte blot et snævert interval mellem presserende og yderst presserende. Selv når rapporten kommer fra en kendt, venlig kilde, kan der være andre mennesker på nettet, der opdagede fejlen længe siden og har bare ikke rapporteret det. Den eneste gang tingene ikke presserende er, når fejlen sagens natur ikke kompromitterer sikkerheden meget alvorligt.

Den «anonymous14@globalhackerz.net» eksempel er ikke spottende, ved den måde. Du virkelig kan få fejlrapporter fra identitetsskabende Tilsløret mennesker, som ved deres ord og adfærd, aldrig helt afklaret, om de er på din side eller ej. Det betyder ikke noget: hvis de har rapporteret den sikkerhed hul til dig, vil de føle, at de har gjort dig en god tur, og du skal reagere i naturalier. Tak dem for rapporten, give dem en dato på eller før, hvor du planlægger at frigive en offentlig fix, og holde dem i løkken. Nogle gange kan de give dig en dato, det vil sige, en implicit trussel at offentliggøre fejl på en bestemt dato, uanset om du er klar eller ej. Det kan føles som en mobning power play, men det er mere sandsynligt en forebyggende virkning grundet tidligere skuffelse med reagerer software-producenter, som ikke tager sikkerheden rapporter alvorligt nok. Uanset hvad, kan du ikke råd til at afkrydse denne person off. Efter alt, hvis fejlen er svær at han har kendskab til, som kan forårsage dine brugere store problemer. Behandle sådanne reportere godt, og håber, at de behandler dig godt.

En anden hyppig reporter af sikkerhed bugs er sikkerheden professionelle, en person, der revisioner kode for et levende og holder op på de seneste nyheder om software-sårbarheder. Disse mennesker har som regel erfaring på begge sider af hegnet, they’ve både modtagne og sendte rapporter, sandsynligvis mere end de fleste udviklere i projektet har. Også de vil normalt give en frist for fastsættelse af en sårbarhed, før de går offentligheden. Fristen kan være noget forhandles, men det er op til den reporter, deadlines er blevet anerkendt blandt professionelle sikkerhedsfolk, som stort set den eneste pålidelige måde at få organisationerne til at løse sikkerhedsproblemer hurtigt. Så du skal ikke behandle den frist, uhøflige, det er en hævdvunden tradition, og der er gode grunde til det.

Når du kender alvoren og hastende, kan du begynde at arbejde på en rettelse. Der er nogle gange en afvejning mellem at gøre et fix elegant og gør det hurtigt, det er derfor, du skal være enige om, at det haster, før du starter. Hold diskussion af rettelsen begrænset til de sikkerhedsmæssige liste medlemmer, selvfølgelig, plus den oprindelige reporter (hvis hun ønsker at blive involveret) samt eventuelle udviklere, der har brug for at blive bragt i af tekniske grunde.

Må ikke begå den fix til lageret. Hold det i patch form, indtil den go-offentlig dato. Hvis du skulle begå den, selv med en uskyldigt udseende logmeddelelse kan nogen mærke og forstå ændringen. Du ved aldrig, hvem der ser din repository, og hvorfor de måske ville være interesseret. Slå e-mail ved ikke ville hjælpe, først og fremmest vil hullet i commit mail sekvens selv ser mistænkelige, og alligevel, vil de data stadig være i arkivet. Bare gør al udvikling i et plaster og holde plasteret i nogle private sted, måske en separat, privat arkiv kun kendes af de mennesker, der allerede opmærksomme på fejlen. (Hvis du bruger en decentral version control system som Arch eller SVK, kan du gøre det arbejde under fuld version kontrol, og bare holde dette register utilgængelige for udenforstående.)

CAN/CVE numre

Du har måske set en CAN nummer eller et CVE-nummer i forbindelse med sikkerhedsproblemer. Disse tal ligner normalt «CAN-2004-0397″ eller «CVE-2002-0092″, for eksempel.

Begge tal repræsenterer den samme type enhed: en post i listen over «Common Vulnerabilities and Exposures» liste, der holdes på http://cve.mitre.org/. Formålet med listen er at levere standardiserede navne for alle kendte sikkerhedsproblemer, så alle har et unikt, kanonisk navn til at bruge, når man diskuterer en, og et centralt sted at gå for at finde ud af mere information. Den eneste forskel mellem en «CAN» nummer og en «CVE» nummer er, at førstnævnte repræsenterer en kandidat indrejse, som endnu ikke er godkendt til optagelse på den officielle liste af CVE Editorial Board, og sidstnævnte udgør en godkendt post. Men begge typer oplysninger er synlige for offentligheden, og en post nummer ændres ikke, når den er godkendt, den «kan» præfiks er simpelthen erstattet med «CVE».

A CAN / CVE indrejse, ikke selv indeholder en fuldstændig beskrivelse af fejlen og hvordan du beskytter imod det. I stedet indeholder et kort resumé, og en liste over referencer til eksterne ressourcer (såsom postlistearkiver), hvor folk kan gå for at få mere detaljerede oplysninger. Det egentlige formål med http://cve.mitre.org/ er at tilvejebringe et velorganiseret rum, hvor hver sårbarhed kan have et navn og en klar vej til flere data. Se http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 for et eksempel på en post. Bemærk, at referencerne kan være meget kortfattede, med kilder, der optræder som kryptiske forkortelser. En nøgle til disse forkortelser er http://cve.mitre.org/data/refs/refkey.html.

Hvis din sårbarhed opfylder CVE kriterier, kan du ønsker at erhverve det en CAN-nummer. Processen til at gøre det bevidst gated: dybest set, er du nødt til at kende nogen, eller kender nogen, der kender nogen. Det er ikke så vanvittigt som det måske lyder. For det CVE Editorial Board for at undgå at blive overvældet med falske eller dårligt skrevet indlæg, de tager kun indberetninger fra kilder, de allerede kender og stoler på. For at få din sårbarhed på listen, derfor skal du finde en sti af bekendtskab fra dit projekt til CVE Editorial Board. Spørg rundt blandt dine udviklere, den ene af dem vil sandsynligvis kender nogen andre, der enten har gjort det kan behandle før, eller kender nogen, der har, osv. Fordelen ved at gøre det på denne måde er også, at et eller andet sted i kæden, kan nogen ved nok at fortælle dig, at a) det ikke ville tælle som en sårbarhed eller eksponering i henhold til Mitre kriterier, så der er ingen mening at sende den, eller b) sårbarheden allerede har en CAN eller CVE-nummer. Sidstnævnte kan ske, hvis fejlen allerede er blevet offentliggjort på en anden sikkerhedsmeddelelse liste, for eksempel ved http://www.cert.org/ eller på BugTraq mailingliste på http://www.securityfocus.com/. (Hvis det skete, uden at dit projekt at høre om det, så skal du bekymre hvad der ellers måtte være at gå på, at du ikke kender til.)

Hvis du får en CAN / CVE-nummer på alle, du normalt ønsker at få det i de tidlige stadier af din bug undersøgelse, således at alle yderligere kommunikation kan henvise til dette nummer. CAN poster embargo indtil den go-offentlige dato posten vil eksistere som en tom pladsholder (så du ikke mister navnet), men det vil ikke afsløre nogen oplysninger om sårbarheden indtil den dato, hvor du vil blive annoncere fejlen og rettelsen.

Mere information om CAN / CVE-processen kan findes på http://cve.mitre.org/cve/identifiers/candidates_explained.html, og en særlig klar belysning af en open source-projekt brug af kan / CVE tal er på http: / / www.debian.org / security / CVE-kompatibilitet.

Pre-meddelelse

Når din sikkerhed Response Team (dvs. de udviklere, der er på sikkerheden mailingliste, eller som er blevet bragt i at beskæftige sig med en bestemt rapport) har en rettelse klar, skal du beslutte, hvordan du distribuerer det.

Hvis du blot forpligte fix til din depot eller på anden måde meddele det til verden, du effektivt tvinger alle, der bruger din software til at opgradere straks eller risikere at blive hacket. Det er undertiden derfor hensigtsmæssigt at gøre forud for anmeldelsen til visse vigtige brugere. Dette er især tilfældet med klient / server-software, hvor der kan være kendte servere, der er fristende mål for hackere. Disse servere «administratorer ville sætte pris på at have en ekstra dag eller to til at gøre opgraderingen, så de allerede er beskyttet af den tid, den exploit bliver offentlig viden.

Pre-meddelelse betyder blot at sende mails til de administratorer, før go-offentlig dato, fortæller dem om sårbarhed og hvordan man kan løse det. Du bør sende forud for anmeldelsen kun til folk, du har tillid til at være diskret med oplysningerne. Det vil sige, at kvalifikation til modtagelse af forhåndsanmeldelse er dobbelt: modtageren skal køre en stor, vigtig server, hvor et kompromis ville være en alvorlig sag, og modtageren skal være kendt for at være nogen, der ikke vil blab om sikkerheden problemet før go-offentlige dato.

Send hver forud for anmeldelsen post individuelt (et ad gangen) til hver modtager. Må ikke sende til hele listen over modtagere på én gang, for så ville de se hinandens navne-betyder, at du hovedsageligt vil være advare hver modtager på, at hver anden modtager kan have et sikkerhedshul i hendes server. Sende det til dem alle via blind CC (BCC) er ikke en god løsning, enten fordi nogle admins beskytte deres indbakker med spamfiltre, der enten blokerer eller reducere prioriteringen af BCC mail, fordi så meget spam sendes via BCC disse dage.

Her er en prøve før anmeldelsen mail:

Fra: Dit navn her
Til: admin@large-famous-server.com
Svar-til: Dit navn her (ikke den sikkerhed listens adresse)
Om: Fortrolig Scanley sårbarhed meddelelse.

Denne e-mail er en fortrolig forudgående meddelelse om en sikkerhedsadvarsel
i Scanley serveren.

Vær * ikke fremad * nogen del af denne mail til nogen. offentligheden
meddelelse er ikke før 19. maj og vi vil gerne holde den
information embargo indtil da.

Du modtager denne mail, fordi (vi tror) du kører en Scanley
server, og vil gerne have det repareres, før denne sikkerhedsopdatering hul er
offentliggjort den 19. maj.

Referencer:
===========

    CAN-2004-1771: Scanley stack overflow i forespørgsler

Svaghed:
==============

    Serveren kan gøres for at køre vilkårlige kommandoer, hvis serverens
locale er konfigureret korrekt og kunden sender en misdannet forespørgsel.

Severity:
=========

    Meget svær, kan involvere vilkårlig kode på serveren.

Løsninger:
============

    Indstilling af «naturlige sprogbehandling ’til’ off ‘i
scanley.conf lukker denne sårbarhed.

Patch:
======

    Plastret nedenfor gælder Scanley 3,0, 3,1, og 3,2.

    En ny offentlig frigivelse (Scanley 3.2.1) vil ske på eller lige før
May 19th, således at den er tilgængelig på samme tid som dette
sårbarhed er blevet offentliggjort. Du kan lappe nu, eller bare vente på
den offentlige udgivelse. Den eneste forskel mellem 3,2 og 3.2.1 vil
være denne patch.

[... patch går her ...]

Hvis du har et CAN nummer, medtage det i forudgående anmeldelse (som vist ovenfor), selv om oplysningerne er stadig embargo og derfor MITRE side vil vise noget. Herunder CAN nummer tillader modtageren at vide med sikkerhed, at fejlen blev de præ-anmeldt over, er den samme, de senere hører om gennem offentlige kanaler, så de ikke behøver at bekymre sig om yderligere handling er nødvendig eller ej, hvilket er netop det punkt kan / CVE numre.

Fordel fix offentligt

Det sidste trin i at håndtere en sikkerhed bug er at fordele rettelsen offentligt. I et enkelt, omfattende annoncering, skal du beskrive det problem, giver CAN / CVE-nummer eventuelt beskrive hvordan du kan løse det, og hvordan man permanent ordne det. Normalt «fix» betyder at opgradere til en ny version af softwaren, men nogle gange kan det betyde, at et plaster, især hvis softwaren er normalt kører i kildekode alligevel. Hvis du gør en ny udgivelse, bør det afvige fra nogle eksisterende frigivelse af præcis den sikkerhedsrettelse. På den måde kan konservative admins opgradere uden at bekymre sig om hvad de ellers kan påvirke, de også ikke behøver at bekymre sig om fremtidige opgraderinger, fordi sikkerheden fix vil være i alle fremtidige udgivelser som en selvfølge. (Nærmere oplysninger om procedurer for frigivelse diskuteres i afsnittet «Sikkerhed Releases» i kapitel 7, Packaging, slipper, og Daily Development.)

Hvorvidt den offentlige fix indebærer en ny udgivelse, gøre annonceringen med nogenlunde samme prioritet, som du ville en ny udgivelse: Send en mail til projektets annoncere liste, lave en ny pressemeddelelse, opdatere Freecode indrejse, osv. Mens du bør aldrig forsøge at bagatellisere eksistensen af en sikkerhed bug ud af bekymring for projektets omdømme, kan du helt sikkert sætte tonen og fremtrædende en sikkerhed meddelelse at matche den konkrete belastningsgrad af problemet. Hvis sikkerheden hul er blot en mindre information eksponering, ikke en exploit, der gør det muligt for brugeren hele computeren skal overtages, så kan det ikke begrunde en masse postyr. Du kan endda beslutte ikke at distrahere announce listen med det. Efter alt, hvis projektet råber ulven hver gang kan brugerne ender med at tro softwaren er mindre sikker end den egentlig er, og også måske ikke tro dig, når du har en virkelig stort problem at annoncere. Se http://cve.mitre.org/about/terminology.html for en god introduktion til problemet med at dømme sværhedsgrad.

Generelt, hvis du er usikker på, hvordan man behandler en sikkerheds problem finde en person med erfaring og tale med dem om det. Vurdering og håndtering af sårbarheder er i høj grad en erhvervet færdighed, og det er nemt at lave fejltrin de første par gange.

Se også Apache Software Foundation retningslinjer for håndtering af sikkerhedsproblemer på http://www.apache.org/security/committers.html. De er en glimrende tjekliste kan du sammenligne imod at se, hvis du laver alt omhyggeligt.

[21] Der har været nogle interessante akademisk forskning om dette emne, for eksempel Group Awareness se Distribueret Software Development ved Gutwin, Penner, og Schneider. Dette papir var online i et stykke tid, så utilgængelig, så online igen ved http://www.st.cs.uni-sb.de/edu/empirical-se/2006/PDFs/gutwin04.pdf. Så prøv der først, men være parat til at bruge en søgemaskine, hvis den bevæger sig igen.

[22] For en længere diskussion om én bestemt underart af vanskelige person, se Amy Hoy er afsindigt on target Hjælp Vampires: En Spotter Guide. Citere Hoy: «Det er så regelmæssig du kunne sætte dit ur efter det forfald af et fællesskab er lige så forudsigeligt som henfaldet af visse stabile nukleare isotoper Så snart et open source-projekt, sprog, eller hvad-har-du opnår.. en vis berygtet — dets halveringstid, om man vil — de sværmer i, tilsyneladende dræner selve livet ud af samfundet selv De er de Hjælp Vampyrer Og jeg er her for at stoppe dem … «..

Kapitel 7. Packaging, slipper, og Daily Development

Dette kapitel handler om, hvordan fri software-projekter pakke og frigive deres software, og hvordan de samlede udviklingsmønstre organisere sig omkring disse mål.

En væsentlig forskel mellem open source-projekter og proprietære dem er manglen på centraliseret kontrol over udviklingen team. Når en ny udgivelse er under udarbejdelse, denne forskel er især skarp: et selskab kan bede hele sin udvikling team til at fokusere på en kommende udgivelse, at man skubber ny funktion udvikling og ikke-kritiske fejlrettelser indtil udgivelsen er færdig. Frivilliggrupper er ikke så monolitisk. Folk arbejder på projektet i alle mulige grunde, og dem, der ikke er interesseret i at hjælpe med en given release stadig ønsker at fortsætte med regelmæssig udviklingsarbejde, mens udsætningen foregår. Fordi udvikling ikke stopper, open source frigivelse processer tendens til at tage længere tid, men være mindre forstyrrende, end kommercielle frigivelse processer. Det er lidt ligesom motorvej reparation. Der er to måder at løse en vej: du kan lukke den helt ned, så at en reparation besætning kan sværm over det hele med fuld kapacitetsudnyttelse indtil problemet er løst, eller du kan arbejde på et par baner ad gangen, samtidig med at de andre er åbne for trafik. Den første måde er meget effektiv til reparation besætning, men ikke for nogen anden-vejen er helt lukket ned, indtil arbejdet er gjort. Den anden måde involverer meget mere tid og besvær til reparation besætningen (nu de har at arbejde med færre mennesker og mindre udstyr, under trange forhold, med flaggers til langsom og direkte trafik, etc.), men i det mindste vejen forbliver anvendelig, omend ikke på fuld kapacitet.

Open source-projekter har en tendens til at arbejde den anden vej. I virkeligheden, for et modent stykke software med flere forskellige release linjer opretholdes samtidigt projektet er slags i en permanent tilstand af bivej reparation. Der er altid et par baner lukket, en konsistent men lavt baggrund ulejlighed altid blive tolereret af udviklingen gruppen som helhed, således at udledninger få lavet på en regelmæssig tidsplan.

Den model, der gør dette muligt generaliserer til mere end bare udgivelser. Det er princippet om parallelizing opgaver, der ikke indbyrdes afhængige, et princip, der er på ingen måde enestående til open source udvikling, selvfølgelig, men en, som open source-projekter gennemføre i deres egen særlige måde. De har ikke råd til at irritere enten vejarbejde besætning eller den almindelige trafik for meget, men de kan heller ikke råd til at have folk dedikeret til stående ved de orange kegler og aftagende trafik langs. Derfor er de drages mod processer, som har flade, konstante niveauer af administrativt overhead, snarere end toppe og dale. Frivillige er generelt villige til at arbejde med små, men konsekvente mængder af besvær, forudsigeligheden giver dem mulighed for at komme og gå uden at skulle bekymre sig om deres tidsplan vil kollidere med, hvad der sker i projektet. Men hvis projektet var genstand for en master schedule, hvor nogle aktiviteter er udelukket andre aktiviteter, ville resultatet være en masse udviklere siddende tomgang en stor del af tiden, hvilket ville være ikke blot ineffektiv, men kedeligt, og derfor farlig, idet en keder udvikler sandsynligvis snart være en ex-udvikler.

År arbejde er som regel den mest mærkbare manglende udvikling opgave, der sker parallelt med udvikling, så de metoder, der er beskrevet i de følgende afsnit er rettet primært mod muligt udgivelser. Bemærk dog, at de også gælder for andre parallelizable opgaver såsom oversættelser og internationalisering, brede API ændringer, der foretages gradvist til hele kodebase osv.

Udgivelse Nummerering

Før vi taler om, hvordan man laver en release, lad os se på, hvordan du navngiver udgivelser, som kræver at vide, hvad frigiver egentlig betyder for brugerne. En frigivelse betyder, at:

• Gamle fejl er blevet rettet. Dette er sandsynligvis den ene ting brugerne kan regne med at være sandt for hver udgivelse.
• Nye fejl er blevet tilføjet. Dette også kan normalt tælles på, undtagen nogle gange i tilfælde af sikkerhedstrusler udgivelser eller andre engangsforanstaltninger (se afsnittet «Sikkerhed Releases» senere i dette kapitel).
• Nye funktioner kan være tilsat.
• Nye konfigurationsmuligheder muligvis er blevet tilføjet, eller de betydninger af gamle indstillinger kan have ændret subtilt. Installationsprocedurerne kan have ændret sig en smule siden sidste udgivelse også, selvom man altid håber ikke.
• Inkompatible ændringer kan have været indført, således at dataformater, der anvendes af ældre versioner af softwaren er ikke længere brugbar uden at undergå en form for (muligvis manual) envejs-konvertering trin.

Som du kan se, ikke alle disse er gode ting. Dette er grunden til erfarne brugere nærmer nye udgivelser med nogen bæven, især når softwaren er modent og blev allerede for det meste gør, hvad de ønskede (eller troede de ville have). Selv ankomsten af nye funktioner er en blandet velsignelse, fordi det kan betyde, at softwaren vil nu opføre sig på uventede måder.

Formålet med udgivelsen nummerering er derfor dobbelt: naturligvis tallene bør utvetydigt kommunikere bestilling af udgivelser (dvs. ved at kigge på hvilke som helst to udgivelser numre, kan man vide, hvilke kom senere), men også de bør angive så kompakt som muligt graden og arten af ændringerne i frigivelsen.

Alt dette i et nummer? Nå, mere eller mindre, ja. Udgivelsesnoter nummereringssystemer strategier er en af de ældste bikeshed diskussioner omkring (se afsnittet «jo blødere Topic, jo længere debat» i kapitel 6, Communications), og verden er usandsynligt, at slå sig ned på en enkelt, komplet standard helst snart. Imidlertid har et par gode strategier opstod, sammen med en alment anerkendt-on princippet: være konsekvente. Vælg en nummerering ordning, dokumentere det, og holde sig til det. Dine brugere vil takke dig.

Release-nummer Components

Dette afsnit beskriver de formelle konventioner frigivelse nummerering i detaljer, og antager meget lidt forudgående viden. Det er meningen, hovedsageligt som en reference. Hvis du allerede er bekendt med disse konventioner, kan du springe dette afsnit over.

Frigivelse numre er grupper af cifre adskilt af punktummer:

Scanley 2,3
Singer 5.11.4

… Og så videre. Prikkerne er ikke decimaler, er de blot separatorer, «5.3.9″ ville blive efterfulgt af «5.3.10″. Et par projekter har lejlighedsvis antydet ellers, mest berømt Linuxkernen med sin «0,95″, «0,96″ … «0,99″ sekvens, der fører op til Linux 1,0, men den konvention, at prikkerne ikke er decimaltal er nu et fast og bør betragtes som en standard. Der er ingen grænse for antallet af komponenter (cifrede portioner indeholdende ingen prikker), men de fleste projekter ikke går ud over tre eller fire. Årsagerne vil fremgå senere.

Udover de numeriske komponenter, projekter undertiden hæfte på en beskrivende etiket, såsom «Alpha» eller «beta» (se alfa og beta), for eksempel:

Scanley 2.3.0 (Alpha)
Singer 5.11.4 (Beta)

En Alpha eller Beta qualifier betyder, at denne udgivelse går forud for en fremtidig udgivelse, der vil have det samme antal uden kvalifikationskamp. Således er «2.3.0 (Alpha)» fører i sidste ende til «2.3.0″. For at give flere sådanne kandidatlande udgivelser i træk, at kvalifikationen selv kan have meta-kvalifikationskampe. For eksempel er her en serie af udgivelser i den rækkefølge, de kan stilles til rådighed for offentligheden:

Scanley 2.3.0 (Alpha 1)
Scanley 2.3.0 (Alpha 2)
Scanley 2.3.0 (Beta 1)
Scanley 2.3.0 (Beta 2)
Scanley 2.3.0 (Beta 3)
Scanley 2.3.0

Bemærk, at når den har «Alpha» kvalificering, Scanley «2,3″ er skrevet som «2.3.0″. De to numre er tilsvarende-trailing all-nul komponenter kan altid blive sløjfet i korthed-men når en kvalifikationskamp er til stede, kortfattethed er ud af vinduet alligevel, så man kan lige så godt gå til fuldstændighed i stedet.

Andre qualifiers i semi-regelmæssig brug omfatter «Stabil», «ustabil», «Udvikling», og «RC» (for «Release Candidate»). De mest brugte er stadig «Alpha» og «Beta», med «RC» kører en tæt tredjeplads, men bemærke, at «RC» altid indeholder et numerisk meta-kvalifikationskamp. Det er, behøver du ikke «Scanley 2.3.0 (RC)», du slipper «Scanley 2.3.0 (RC 1)», efterfulgt af RC2, osv.

Disse tre etiketter, «Alpha», «Beta» og «RC», er temmelig almindeligt kendt nu, og jeg anbefaler ikke at bruge nogen af de andre, selv om andre måske ved første øjekast synes som bedre valg, fordi de er normale ord, ikke jargon. Men folk, der installerer software fra udsætninger er allerede bekendt med de tre store, og der er ingen grund til at gøre tingene umotiveret på en anden måde alle andre gør dem.

Selv om de prikker i frigivelse numre ikke er decimaler, de indikerer sted-værdi betydning. Alle «0.XY» udgivelser forud «1,0″ (hvilket svarer til «1.0.0″, selvfølgelig). «3.14.158″ går umiddelbart forud «3.14.159″, og ikke-går umiddelbart forud «3.14.160″ samt «3.15.anything», og så.

En konsekvent frigivelse nummerering politik giver en bruger til at se på to release numre for det samme stykke software og fortælle, lige fra de tal, de betydelige forskelle mellem disse to udgivelser. Ved en typisk tre-komponentsystem, er den første bestanddel af store antal, den anden er mindre del, og den tredje er mikro nummer. For eksempel, slip «2.10.17″ er det syttende micro udgivelse i tiende mindre frigivelse linje inden for det andet store udgivelse serien. Ordene «line» og «serier» anvendes uformelt her, men de mener, hvad man kunne forvente. En stor serie er simpelthen alle de udgivelser, der deler samme store tal, og en mindre serie (eller mindre linie) består af alle de udgivelser, der deler samme mindre og større tal. Det vil sige, «2.4.0″ og «3.4.1″ er ikke i samme mindre serier, selv om de begge har «4″ for deres mindre antal og på den anden side «2.4.0″ og «2.4.2 «er i samme mol linie, selvom de ikke er tilgrænsende, hvis» 2.4.1 «udgivet mellem dem.

Betydningen af disse numre er præcis, hvad du ville forvente: en forøgelse af den store antal tyder på, at store forandringer skete, en forøgelse af den mindre tal angiver mindre ændringer, og en stigning af mikro tal angiver virkelig trivielle ændringer. Nogle projekter tilføje en fjerde komponent, normalt kaldet patch nummer, for især finkornet kontrol over forskellene mellem deres udgivelser (forvirrende, andre projekter bruger «patch» som et synonym for «mikro» i en tre-komponent system). Der er også projekter, der bruger den sidste komponent som et build, der stiger fortløbende hver gang software er bygget og repræsenterer ingen ændringer bortset bygge. Dette hjælper projektet link hver fejlrapport med en specifik bygge, og er nok mest nyttig, når binære pakker er standard metode, der fordeler.

Selvom der er mange forskellige konventioner for, hvor mange komponenter til at bruge, og hvad de komponenter betyder, at forskellene tendens til at være mindre, får du en lille spillerum, men ikke meget. De næste to afsnit diskuterer nogle af de mest anvendte konventioner.

Den enkle strategi

De fleste projekter har regler om, hvilke former for ændringer er tilladt i en frigivelse, hvis man kun er inkrementere mikro nummer, forskellige regler for mindre antal, og stadig forskellige dem for det store antal. Der er ingen faste standarder for disse regler endnu, men her vil jeg beskrive en politik, der er blevet brugt med succes af flere projekter. Du ønsker måske at bare vedtage denne politik i dit eget projekt, men selv hvis du ikke gør det, er det stadig et godt eksempel på den form for information frigivelse numre skal formidle. Denne politik er tilpasset fra nummereringssystem der anvendes af ÅOP-projektet, se http://apr.apache.org/versioning.html.

Ændringer i mikro nummer (det vil sige, ændringer inden for samme minor linie) skal være både fremad og bagud-kompatibel. Det vil sige, bør ændringerne være fejlrettelser kun, eller meget små forbedringer til eksisterende funktioner. Nye funktioner bør ikke indføres i en mikro udgivelse.

Ændringer i mindre antal (dvs. inden for det samme store slangen) bagudkompatibelt, men ikke nødvendigvis frem-kompatibel. Det er normalt at introducere nye funktioner i en mindre frigivelse, men normalt ikke for mange nye funktioner på én gang.

Ændringer i de store antal mark kompatibilitet grænser. En ny større version kan være fremad og bagud uforenelige. En større frigivelse forventes at have nye funktioner, og kan endda have helt nye feature sæt.

Hvad bagudkompatibelt og fremad-kompatibel betyder, præcis, afhænger af, hvad din software gør, men i sammenhæng de er som regel ikke åbne for meget fortolkning. For eksempel, hvis dit projekt er en klient / server-program derefter «bagudkompatible» betyder, at en opgradering af serveren til 2.6.0 ikke burde føre til en eksisterende 2.5.4 kunder til at miste funktionalitet eller opføre sig anderledes, end de gjorde før (undtagen fejl, der blev fastsat, selvfølgelig). På den anden side, opgradering af en af disse kunder til 2.6.0, sammen med serveren kan gøre ny funktionalitet til rådighed for den pågældende klient, funktionalitet, 2.5.4 klienter ikke ved, hvordan at drage fordel af. Hvis det sker, så opgraderingen er ikke «forward-kompatibel»: klart du kan ikke nu nedgradere at klienten tilbage til 2.5.4 og holde alle de funktioner, det havde på 2.6.0, da nogle af denne funktionalitet var nyt i 2,6 .0.

Dette er grunden til mikro udgivelser er hovedsagelig til fejlrettelser kun. De skal være forenelige i begge retninger: hvis du opgraderer fra 2.5.3 til 2.5.4 og derefter ændre dit sind og nedgradere tilbage til 2.5.3, ingen funktionalitet skal gå tabt. Selvfølgelig ville bugs fastsat i 2.5.4 igen efter nedjusteringen, men du ville ikke miste nogen funktioner, undtagen for så vidt som de restaurerede bugs forhindre brugen af nogle af de eksisterende funktioner.

Klient / server-protokoller er blot én af mange mulige kompatibilitetsproblemer domæner. En anden er dataformater: Har softwaren skrive data til permanent lagring? Hvis det er tilfældet, behøver de formater den læser og skriver til følge kompatibilitet retningslinjer lovet frigivelse nummer politik. Version 2.6.0 skal være i stand til at læse filerne skrevet af 2.5.4, men kan stille opgradere det format, til noget, som 2.5.4 ikke kan læse, da evnen til at nedgradere ikke kræves over en mindre del grænse. Hvis dit projekt distribuerer kode biblioteker for andre programmer til at bruge, så API’er er et kompatibilitet domæne også: du skal sørge for, at kilde-og binær kompatibilitet reglerne er stavet på en sådan måde, at den informerede bruger behøver aldrig spekulerer på, om eller ikke det er sikkert at opgradere i stedet. Hun vil være i stand til at se på tallene og vide med det samme.

I dette system, får du ikke en chance for en ny start, indtil du øg større antal. Det kan ofte være en reel ulempe: der kan være funktioner, du ønsker at tilføje, eller protokoller, som du ønsker at redesigne, der simpelthen ikke kan gøres, uden at kompatibilitet. Der er ingen magisk løsning på dette, bortset fra at forsøge at designe ting i en Extensible måde i første omgang (et emne nemt værd sin egen bog, og i hvert fald uden for denne ene). Men offentliggøre en release kompatibilitet politik, og overholde det, er en uundgåelig del af at distribuere software. En grim overraskelse kan fremmedgøre en masse brugere. Politikken netop beskrevne er godt dels fordi det er allerede meget udbredt, men også fordi det er let at forklare og huske, selv for dem, der ikke allerede er bekendt med det.

Det er generelt enighed om, at disse regler ikke gælder at pre-1,0 udgivelser (selvom din release politik sandsynligvis bør fremgå så eksplicit, bare for at være klar). Et projekt, der stadig er i indledende udvikling kan frigive 0,1, 0,2, 0,3, og så videre i rækkefølge, indtil den er klar til 1,0, og forskellene mellem disse udgivelser kan være vilkårligt stor. Micro numre i pre-1.0 udgivelser er valgfrie. Afhængigt af arten af dit projekt og forskellene mellem de udgivelser, kan du finde det nyttigt at have 0.1.0, 0.1.1, etc., eller måske ikke. Konventioner for præ-1.0 release numre er temmelig løs, hovedsageligt fordi folk forstår, at stærke kompatibilitet begrænsninger hindrer tidlig udvikling for meget, og fordi early adopters tendens til at være tilgivende alligevel.

Husk, at alle disse forskrifter kun for denne særlige tre-komponentsystem. Dit projekt kunne nemt komme op med en anden tre-komponent-system, eller endda beslutte det behøver ikke sådan fine granularitet og bruge en to-komponent system i stedet. Det vigtige er at afgøre tidligt, offentliggøre, hvad de komponenter betyder, og holde sig til det.

Den Lige/Ulige strategi

Nogle projekter bruger paritet mindre antal komponent for at angive stabiliteten af softwaren: selv betyder stabile, ulige midler ustabil. Dette gælder kun for det mindre antal, ikke de store og meget små tal. Forhøjelser i mikro antal stadig indikerer fejlrettelser (ingen nye funktioner), og forhøjelser i større antal stadig viser store forandringer, nye indslag apparater, osv.

Fordelen ved den lige / ulige system, som er blevet brugt af Linuxkernen projektet blandt andet er, at det giver en måde at frigive ny funktionalitet til test uden at udsætte produktionen brugere til potentielt ustabil kode. Folk kan se fra tallene, at «2.4.21″ er okay at installere på deres live web-server, men at «2.5.1″ bør sandsynligvis forblive begrænset til hjemmearbejdsplads eksperimenter. Udviklingsholdet håndterer fejlrapporter, der kommer ind fra den ustabile (ulige-mol-nummererede) serie, og når tingene begynder at slå sig ned efter nogle antallet af mikro udgivelser i denne serie, de øg mindre antal (og dermed gøre det endnu) , skal du nulstille mikro nummer tilbage til «0″, og frigive en formentlig stabil pakke.

Dette system bevarer eller i det mindste, ikke i strid med de kompatibilitetsproblemer retningslinjerne tidligere. Det er simpelthen overbelaster mindre antal med nogle ekstra oplysninger. Dette tvinger mindre nummer, som øges omkring dobbelt så ofte som ellers ville være nødvendigt, men der er ingen stor skade i det. Den jævne / ulige system er nok bedst til projekter, der har meget lange release cyklusser, og som i sagens natur har en høj andel af konservative brugere, der værdsætter stabilitet over nye funktioner. Det er ikke den eneste måde at få ny funktionalitet testes i naturen, dog. afsnittet «Stabiliserende en Release» senere i dette kapitel beskriver en anden, måske mere almindelig, metode til at frigive potentielt ustabil kode til offentligheden, mærket, så folk har en idé om risk / benefit afvejninger straks på at se udgivelsen navn .

Udgivelse Branches

Fra en udviklers synspunkt er et gratis software-projekt i en tilstand af kontinuerlig frigivelse. Udviklere normalt kører den nyeste tilgængelige kode på alle tidspunkter, fordi de ønsker at få øje på fejl, og fordi de følger projektet tæt nok til at være i stand til at holde sig væk fra de nuværende ustabile områder af funktion plads. De har ofte opdatere deres kopi af softwaren hver dag, nogle gange mere end en gang om dagen, og når de tjekker en forandring, kan de med rimelighed forvente, at alle andre udviklere vil have det inden for 24 timer.

Hvordan skal bør projektet gøre en formel udgivelse? Skulle det simpelthen tage et snapshot af træet på et tidspunkt, pakke det op, og aflevere det til verden som fx version «3.5.0″? Almindelig sund fornuft siger nej. For det første kan der ikke være nogen tidspunkt, hvor hele udviklingen træet er ren og klar til udgivelse. Nystartede funktioner kunne blive liggende rundt i forskellige stater i færdiggørelse. Nogen kan have checket i en større ændring af rette en fejl, men at ændringen kunne være kontroversiel og under debat i det øjeblik øjebliksbilledet. Hvis det er tilfældet, vil det ikke virke til blot udskyde snapshot indtil debatten slutter, fordi en anden, uafhængig debat kunne begynde i mellemtiden, og så ville du have vente på, at man til slut også. Denne proces er ikke garanteret at standse.

Under alle omstændigheder ville bruge full-træ snapshots for udgivelser forstyrre igangværende udviklingsarbejde, selvom træet kunne blive sat ind i en udløselig tilstand. Sig denne snapshot bliver «3.5.0″, formentlig, ville det næste snapshot være «3.5.1″, og ville indeholde det meste rettelser til bugs fundet i 3.5.0 udgivelse. Men hvis begge er snapshots fra det samme træ, hvad er udviklerne formodes at gøre i tiden mellem de to udgivelser? De kan ikke tilføje nye funktioner, de kompatibilitetsproblemer retningslinjer forhindre det. Men ikke alle vil være begejstrede for at rette fejl i 3.5.0 kode. Nogle mennesker kan have nye funktioner, de forsøger at fuldføre, og bliver vrede, hvis de tvinges til at vælge mellem at sidde tomgang og arbejde på ting, de er ikke interesseret i, bare fordi projektet udgivelse processer krav om, at udviklingen træet forbliver unaturligt uvirksomme.

Løsningen på disse problemer er at altid bruge en release gren. En release gren er blot en filial i den version kontrolsystem (se gren), som koden er bestemt for denne udgivelse kan isoleres fra hovedspor udvikling. Begrebet frigivelse filialer er bestemt ikke original til fri software, mange kommercielle udviklingsorganisationer bruger dem også. Men i kommercielle miljøer, er frigivelse grene undertiden betragtes som en luksus-en form for formel «bedste praksis», som kan, i varmen i en større frist, ophæves, uden at alle på holdet krypterer at stabilisere den vigtigste træ.

Frigivelse filialer er temmelig meget påkrævet i open source-projekter, dog. Jeg har set projekter do udgivelser uden dem, men det har altid resulteret i nogle udviklere siddende tomgang, mens andre-normalt et mindretal-arbejde på at få udgivelsen ud af døren. Resultatet er normalt dårligt på flere måder. For det første er overordnede udvikling momentum bremset. For det andet, frigivelse er af ringere kvalitet end det skulle være, fordi der var kun et par folk, der arbejder på det, og de skyndte sig at slutte, så alle andre kunne komme tilbage til arbejdet. For det tredje, den deler udviklingsteamet psykologisk, ved at oprette en situation, hvor forskellige typer af arbejde forstyrrer hinanden unødigt. Udviklerne sidder tomgang ville sandsynligvis være glad for at bidrage med nogle af deres opmærksomhed på en release gren, så længe der var et valg, de kunne gøre i henhold til deres egne tidsplaner og interesser. Men uden den gren, bliver deres valg «Skal jeg deltage i projektet i dag eller ej?» i stedet for «Må jeg arbejde på frigivelse i dag eller arbejde på den nye funktion, jeg har været under udvikling i det ordinære kode?»

Mechanics om frigivelse Branches

De nøjagtige mekanik for at skabe et release gren afhænger af din version styresystem, selvfølgelig, men de generelle begreber er de samme i de fleste systemer. En gren normalt spirer fra en anden filial eller fra stammen. Traditionelt stammen er, hvor mainline udvikling fortsætter, uhindret af frigivelse begrænsninger. Den første udgivelse gren, den ene fører til «1,0″ release, spirer væk fra stammen. I CVS, vil filialen kommandoen være noget lignende dette

$ Cd trunk-arbejde-kopi
$ Cvs tag-b RELEASE_1_0_X
eller i Subversion, som denne:

$ Svn kopi http://…/repos/trunk http://…/repos/branches/1.0.x
(Alle disse eksempler antager en tre-komponent release nummersystem. Selv om jeg ikke kan vise de nøjagtige kommandoer for hver version control system, jeg vil give eksempler i CVS og Subversion og håber, at de tilsvarende kommandoer i andre systemer kan udledes de to.)

Bemærk, at vi har skabt gren «1.0.x» (med en bogstavelig «x») i stedet for «1.0.0″. Dette skyldes den samme mindre line-dvs. den samme gren-vil blive anvendt for alle mikro udslip i denne linje. Selve processen med at stabilisere gren for frigivelsen er dækket i afsnittet «Stabiliserende en Release» senere i dette kapitel. Her er vi bekymret lige med samspillet mellem den version styresystem og frigivelsen proces. Når frigivelsen filialen er stabiliseret og klar, er det tid til at tagge et snapshot fra filialen:

$ Cd RELEASE_1_0_X-arbejdende-kopi
$ Cvs tag RELEASE_1_0_0
eller

$ Svn kopi http://…/repos/branches/1.0.x http://…/repos/tags/1.0.0
Denne tag udgør nu den nøjagtige tilstand af projektets kilde træ i 1.0.0 frigivelse (dette er nyttigt i tilfælde af at nogen nogensinde brug for at få en gammel version efter de emballerede fordelinger og binære filer er blevet taget ned). Den næste micro udgivelse i samme linje er ligeledes udarbejdet på 1.0.x gren, og når den er klar, er et tag lavet til 1.0.1. Skumme, skyl, gentag for 1.0.2, og så videre. Når det er tid til at begynde at tænke på en 1.1.x version, lave en ny filial fra stammen:

$ Cd trunk-arbejde-kopi
$ Cvs tag-b RELEASE_1_1_X
eller

$ Svn kopi http://…/repos/trunk http://…/repos/branches/1.1.x
Vedligeholdelse kan fortsætte parallelt langs både 1.0.x og 1.1.x, og frigiver kan gøres uafhængigt af begge linjer. Faktisk er det ikke usædvanligt at offentliggøre næsten samtidige udslip fra to forskellige linjer. Den ældre serier anbefales til mere konservative site administratorer, som måske ikke ønsker at gøre det store spring til (sige) 1.1 uden omhyggelig forberedelse. I mellemtiden mere eventyrlystne folk normalt tager den nyeste udgivelse på det højeste linje, for at sikre at de får de nyeste funktioner, selv med risiko for større ustabilitet.

Dette er ikke den eneste release gren strategi, naturligvis. Under visse omstændigheder kan det ikke engang være den bedste, selvom det har fungeret ganske godt for projekter jeg har været involveret i. Brug enhver strategi, der ser ud til at virke, men husk de vigtigste punkter: Formålet med en release gren er at isolere frigivelse arbejde fra udsving i daglige udvikling, og at give projektet en fysisk enhed rundt til at organisere dets udgivelse proces. Denne fremgangsmåde er beskrevet detaljeret i næste afsnit.

Stabilisering en Release

Stabilisering er processen med at få en udgivelse gren ind i en udløselig tilstand, det er, for at beslutte, hvilke ændringer vil være i udgivelsen, som ikke vil, og forme grenen indhold i overensstemmelse hermed.

Der er en masse potentiale sorg er indeholdt i det ord, «besluttende». Den sidste øjeblik træk rush er et velkendt fænomen i samarbejdsprojekter software-projekter: så snart udviklerne se, at en udgivelse er ved at ske, de scramble at afslutte deres aktuelle ændringer, for ikke at gå glip af båden. Det er selvfølgelig er det stik modsatte af, hvad du vil have på release tid. Det ville være meget bedre for folk at arbejde med funktioner i et behageligt tempo, og ikke bekymre sig for meget om, hvorvidt deres ændringer gøre det til denne udgivelse, eller den næste. Jo flere ændringer man forsøger at proppe ind i en frigivelse i sidste øjeblik, jo mere den kode destabiliseret, og (normalt) de mere nye fejl er oprettet.

De fleste software ingeniører er enige i teorien om uslebne kriterier for, hvilke ændringer der bør tillades i en release linje under sin stabiliseringsperioden. Naturligvis kan rettelser til alvorlige bugs gå i, især for bugs uden workarounds. Dokumentation opdateringer er fint, som er rettelser til fejlmeddelelser (undtagen når de betragtes som en del af grænsefladen og skal forblive stabil). Mange projekter også tillade visse former for lav risiko eller ikke-core forandringer til at gå i løbet af stabilisering, og kan have formelle retningslinjer for måling risiko. Men ingen mængde af formalisering kan fjerne behovet for menneskelig dom. Der vil altid være tilfælde, hvor projektet simpelthen er nødt til at træffe en beslutning om, hvorvidt en given ændring kan gå ind i en udgivelse. Faren er, at eftersom hver person ønsker at se deres egen favorit ændringer optaget i udgivelsen, så der vil være masser af mennesker motiverede for at tillade ændringer, og ikke nok folk motiverede til bar dem.

Således processen med at stabilisere en udgivelse handler mest om at skabe mekanismer til at sige «nej». Tricket for open source-projekter, i særdeleshed, er at komme op med måder at sige «nej», der ikke resulterer i alt for mange sårede følelser eller skuffet udviklere, og også vil ikke forhindre fortjener ændringer fra at komme ind i frigivelsen. Der er mange forskellige måder at gøre dette. Det er temmelig nemt at designe systemer, der opfylder disse kriterier, når holdet har fokuseret på dem som vigtige kriterier. Her vil jeg kort beskrive to af de mest populære systemer, på den ekstreme ende af spektret, men lad ikke at afskrække dit projekt fra at være kreativ. Masser af andre arrangementer er mulige, disse er blot to, som jeg har set i praksis.

Diktatur af Release Owner

Gruppen indvilliger i at lade en person være frigivelsen ejer. Denne person har det sidste ord om, hvad ændringer gør det i frigivelsen. Selvfølgelig er det normale og forventede, at der er diskussioner og argumenter, men i sidste ende gruppen skal give frigivelsen ejer tilstrækkelig autoritet til at træffe de endelige beslutninger. For at systemet skal fungere, er det nødvendigt at vælge en person med den tekniske kompetence til at forstå alle de ændringer, og den sociale anseelse og folk færdigheder til at navigere de drøftelser, der fører op til offentliggørelsen uden at forårsage for mange sårede følelser.

En fælles mønster er for frigivelse ejeren til at sige «Jeg tror ikke, der er noget galt med denne ændring, men vi har ikke haft tid nok til at teste det endnu, så det burde ikke gå ind i denne udgivelse.» Det hjælper meget, hvis frigivelse ejeren har bred teknisk viden om projektet, og kan begrunde, hvorfor ændringen kunne være potentielt destabiliserende (for eksempel dets interaktion med andre dele af softwaren, eller portabilitet bekymringer). Folk vil undertiden bede sådanne afgørelser skal begrundes, eller vil argumentere for, at en ændring ikke er så risikable som det ser ud. Disse samtaler behøver ikke at være konfronterende, så længe release ejeren er i stand til at gennemgå samtlige argumenter objektivt og ikke refleksivt graver i hælene.

Bemærk, at frigivelsen ejeren ikke behøver at være den samme person som projektleder (i tilfælde, hvor der er en projektleder på alle, se afsnittet «velvillige diktatorer» i kapitel 4, sociale og politiske Infrastructure). Faktisk er det nogle gange er godt at sikre, at de er ikke den samme person. De færdigheder, der gør en god udvikling leder er ikke nødvendigvis de samme som dem, der gør en god release ejer. I noget så vigtigt som frigivelse proces, kan det være klogt at have nogen skabe en modvægt til projektlederen dom.

Kontrast frigivelse ejeren rolle med mindre diktatorisk rolle beskrevet i afsnittet kaldet «Release manager» senere i dette kapitel.

Skift Afstemningen

På den modsatte yderlighed fra diktatur ved frigivelse ejer, kan udviklere simpelthen stemme om, hvilke ændringer der skal medtages i frigivelsen. Da den vigtigste funktion af frigivelsen stabilisering er at udelukke ændringer, er det vigtigt at designe afstemningssystemet på en sådan måde, at få en ændring i frigivelsen indebærer positiv særbehandling af flere udviklere. Herunder en ændring skulle have behov for mere end blot et simpelt flertal (se afsnittet «Hvem Stemmer?» I kapitel 4, sociale og politiske Infrastructure). Ellers ville en stemme for og ingen imod en given ændring tilstrækkeligt til at få det ind i udgivelse, og en uheldig dynamik vil blive oprettet, hvor hver udvikler ville stemme for hendes egne ændringer, men alligevel ville være tilbageholdende med at stemme imod andres ændringer, frygt for eventuel gengældelse. For at undgå dette, skal systemet være indrettet således, at undergrupper af udviklere skal handle i et samarbejde for at få en ændring i frigivelsen. Dette betyder ikke kun, at flere mennesker gennemgår hver ændring, det gør også en individuel udvikler mindre tilbageholdende med at stemme imod en ændring, fordi hun ved, at nogen bestemt en blandt dem, der stemte for det ville tage hendes stemme imod som en personlig fornærmelse. Jo større antallet af involverede mennesker, jo mere diskussionen bliver om ændringen og mindre om de enkelte personer.

Det system vi bruger i Subversion-projektet synes at have ramt en god balance, så jeg vil anbefale det her. For at en ændring, der skal anvendes til frigivelsen filial, skal mindst tre udviklere stemme for det, og ingen imod. En enkelt «nej» er nok til at stoppe ændringen fra at blive medtaget, det er, er et «nej» i en release sammenhæng svarer til en veto (se afsnittet «vetoer»). Naturligvis skal et sådant afstemning skal ledsages af en begrundelse, og i teorien veto kunne tilsidesættes, hvis nok mennesker føler, at det er urimeligt og tvinge en særlig afstemning over det. I praksis er dette aldrig sket, og jeg forventer ikke, at det nogensinde vil. Folk er konservative omkring udgivelser alligevel, og når nogen føler sig stærkt nok til at nedlægge veto mod optagelsen af en ændring, er der normalt en god grund til det.

Fordi release procedure bevidst er forudindtaget mod konservatisme, de begrundelser, der tilbydes til vetoer er undertiden proceduremæssige snarere end teknisk. For eksempel kan en person føler, at en ændring er velskrevet og næppe volde nogen nye fejl, men stemme imod dets optagelse i en mikro release simpelthen fordi det er for stort-måske det tilføjer en ny funktion, eller på en eller anden subtil måde svigter til fuldt ud at følge de kompatibilitetsproblemer retningslinjer. Jeg har til tider endog set udviklere veto noget, fordi de simpelthen havde en god fornemmelse for, at ændringen er nødvendig flere tests, selv om de kunne ikke få øje på nogen fejl i det ved inspektion. Folk brokkede en lille smule, men de vetoer stod og ændringen blev ikke medtaget i udgivelsen (jeg kan ikke huske om eventuelle fejl blev fundet i senere test eller ej, selvom).

Håndtering af kollaborativ release stabilisering

Hvis dit projekt vælger en ændring afstemningssystem, er det bydende nødvendigt, at de fysiske mekanik i forbindelse med oprettelse afstemninger og stemmeafgivelse være så bekvemt som muligt. Selv om der er masser af open source elektronisk stemmeafgivelse software til rådighed i praksis den letteste ting at gøre, er bare at oprette en tekstfil i frigivelsen gren, kaldet STATUS eller stemmer eller sådan noget. Denne fil indeholder hver foreslået ændring-enhver udvikler kan foreslå en ændring til optagelse-sammen med alle stemmer for og imod det, plus eventuelle noter eller kommentarer. (Foreslå en ændring betyder ikke nødvendigvis at stemme for det, ved den måde, selv om de to går ofte sammen.) En post i en sådan fil kan se sådan ud:

* R2401 (issue # 49)
Undgå klient / server håndtryk sker to gange.
Begrundelse:
Undgår ekstra netværk turnaround, småpenge og let at gennemgå.
Bemærkninger:
Dette blev drøftet i http://…/mailing-lists/message-7777.html
og andre meddelelser i den tråd.
Stemmer:
+1: Jsmith, kimf
-1: Tmartin (pauser kompatibilitet med nogle pre-1.0-servere;
ganske vist disse servere er buggy, men hvorfor være
uforenelige, hvis vi ikke behøver at?)
I dette tilfælde erhvervet ændringen to positive stemmer, men blev nedlagt veto af tmartin, som gav årsag til veto i en parentetisk bemærkning. Den nøjagtige udformning af posten ligegyldigt, hvad dit projekt lægger sig på er fint, måske tmartin forklaring for veto bør gå op i «Noter:» sektion, eller måske ændringen beskrivelse bør få en «Beskrivelse:» header til matche de andre sektioner. Det vigtige er, at alle de nødvendige oplysninger for at vurdere ændringen være tilgængelig, og at mekanismen til afgivelse af stemmer være så let som muligt. Den foreslåede ændring er nævnt af sin revision nummer i lageret (i dette tilfælde en enkelt revision, r2401, selv om en foreslået ændring kunne lige så let består af flere revisioner). Revisionen antages at henvise til en ændring, der foretages på stammen, hvis ændringen allerede var på release gren, ville der ikke være noget behov for at stemme om det. Hvis din version kontrol system ikke har en indlysende syntaks til at henvise til enkelte ændringer, så projektet bør gøre en op. For at stemme for at være praktisk, skal enhver ændring under overvejelse være entydigt identificerbare.

De, foreslå eller stemme for en ændring er ansvarlige for at sikre, at det gælder rent til frigivelsen gren, der er, anvendes uden konflikter (se konflikt). Hvis der er konflikter, så posten skal enten pege på en justeret patch, der faktisk finder anvendelse rent, eller til en midlertidig filial, der holder en justeret udgave af ændringen, for eksempel:

* R13222, r13223, r13232
Omskrive libsvn_fs_fs auto-merge algoritme
Begrundelse:
uacceptabel præstation (> 50 minutter for en lille commit) i
et arkiv med 300.000 revisioner
Branch:
1.1.x-r13222 @ 13.517
Stemmer:
+1: EPG, ghudson
Dette eksempel er taget fra det virkelige liv, det kommer fra STATUS filen for Subversion 1.1.4 release proces. Bemærk, hvordan det bruger de oprindelige revisioner kanoniske håndtag på ændringen, selv om der også er en gren med en konflikt-justeret udgave af ændringen (filialen også kombinerer de tre bagagerum revisioner i én, r13517, for at gøre det lettere at fusionere ændringen i udgivelsen, bør det få godkendelse). De oprindelige revisioner tilvejebragt, fordi de er stadig den nemmeste enhed til at gennemgå, da de har de oprindelige logmeddelelser. Den midlertidige filial ville ikke have disse logmeddelelser, for at undgå gentagelse af oplysninger (se afsnittet «Singularity af information» i kapitel 3, teknisk infrastruktur), skal filialens logbesked for r13517 blot sige «Tilpas r13222, r13223 , og r13232 for backport til 1.1.x gren. » Alle andre oplysninger om ændringer kan blive jaget ned på deres oprindelige revisioner.

Release Manager

Selve processen med at fusionere (se merge (aka port)) godkendte ændringer i udgivelsen gren kan udføres af enhver udvikler. Der behøver ikke at være en person, hvis job det er at flette ændringer, hvis der er en masse ændringer, kan det være bedre at sprede byrden omkring.

Men selvom både stemme og sammenlægning ske på en decentraliseret måde, i praksis er der som regel en eller to personer køre frigivelsen proces. Denne rolle er undertiden formelt velsignet som release manager, men det er helt anderledes fra en release ejer (se afsnittet «Diktatur af Release Owner» tidligere i dette kapitel), der har det sidste ord over ændringerne. Frigivelse managers holde styr på hvor mange ændringer er i øjeblikket under overvejelse, hvor mange er blevet godkendt, hvor mange synes at ville blive godkendt, osv. Hvis de fornemmer, at vigtige ændringer ikke får nok opmærksomhed, og kan udelades af overgang til mangel af stemmer, vil de blidt nag andre udviklere til at gennemgå og stemme. Når en batch af ændringer godkendt, vil disse mennesker ofte tage det på sig at flette dem ind i release gren, det er fint, hvis andre overlade opgaven til dem, så længe alle forstår, at de ikke er forpligtet til at gøre alt arbejdet, medmindre de udtrykkeligt har forpligtet sig til det. Når tiden er inde til at sætte frigivelsen ud af døren (se afsnittet «Test og Frigivelse» senere i dette kapitel), frigivelse ledere også tage sig af logistikken i at skabe den endelige frigivelse pakker, indsamle digitale signaturer, uploade pakkerne , og gøre den offentlig annoncering.

Emballage

Den kanoniske form for distribution af gratis software er i kildekode. Dette gælder uanset om software normalt kører i source form (dvs. kan fortolkes, ligesom Perl, Python, PHP, osv.) eller skal udarbejdes først (ligesom C, C + +, Java, osv.). Med kompileret software, vil de fleste brugere sandsynligvis ikke kompilere kilderne selv, men vil i stedet installere fra præ-byggede binære pakker (se afsnittet «binære pakker», senere i dette kapitel). Men disse binære pakker stadig stammer fra en mester kilde distribution. Pointen med kilden pakke er at utvetydigt definere frigivelsen. Når projektet distribuerer «Scanley 2.5.0″, hvad det betyder, specifikt er «Træet af kildekodefiler, at når kompileret (om nødvendigt) og installeret, producerer Scanley 2.5.0.»

Der er en temmelig streng standard for, hvordan source udgivelser skal se ud. Man vil lejlighedsvis se afvigelser fra denne standard, men de er undtagelsen, ikke reglen. Medmindre der er en tvingende grund til at gøre noget andet, skal dit projekt følge denne standard også.

Format

Kildekoden skal sendes i de standardformater til transport mappetræer. For Unix og Unix-lignende styresystemer, er konventionen at bruge TAR format, komprimeret med komprimere, gzip, bzip eller bzip2. For MS Windows, standardmetoden for distribution mappetræer er zip-format, hvilket sker for at gøre kompression så godt, så der er ingen grund til at komprimere arkivet efter at skabe det.

TAR Files

TAR står for «Tape Archive», fordi tjære format er en mappetræ som en lineær datastrøm, hvilket gør den ideel til at spare mappetræer til bånd. Den samme egenskab gør det også standarden for distribution mappetræer som en enkelt fil. Produktion komprimeret tar-filer (eller tarballs) er temmelig let. På nogle systemer kan det tjære kommandoen producere en komprimeret arkiv selv, på andre, er et særskilt kompression program anvendes.

Navn og layout

Navnet på pakken bør bestå af softwaren navn plus frigivelse nummer, plus format suffikser passer til arkivet type. For eksempel pakket Scanley 2.5.0, for Unix bruger GNU Zip (gzip) komprimering, ville se sådan ud:

scanley-2.5.0.tar.gz

eller for Windows ved hjælp af zip kompression:

scanley-2.5.0.zip

Enten af disse arkiver, når de pakkes ud, bør oprette en enkelt ny mappetræ navnet scanley-2.5.0 i det aktuelle bibliotek. Nedenunder den nye mappe, skal kildekoden være arrangeret i et layout klar til kompilering (hvis opgørelse er påkrævet) og installation. I det øverste niveau af ny bibliotekstræet, bør der være en almindelig tekst README-fil forklarer hvad softwaren gør, og hvad release dette er, og give henvisninger til andre ressourcer, såsom projektets hjemmeside, andre filer af interesse, osv. Blandt disse andre filer skal være en INSTALL fil, søskende til README filen, der giver vejledning i, hvordan man opbygger og installere softwaren for alle operativsystemer, den støtter. Som nævnt i afsnittet «Sådan ansøger en Licens til din software» i kapitel 2, Introduktion, skal der også være en KOPIERING eller licens fil, der giver softwarens hensyn til distribution.

Der bør også være en ÆNDRINGER fil (også kaldet NEWS), forklarer, hvad der er nyt i denne udgivelse. De ændringer Filen akkumulerer changelists for alle udgivelser, i omvendt kronologisk rækkefølge, således at listen for denne udgivelse vises øverst i filen. Færdiggørelse denne liste er normalt den sidste ting gjort på en stabiliserende release filial nogle projekter skriver listen stykkevis, som de er ved at udvikle, andre foretrækker at gemme det hele op for enden og har en person skrive det, at få information ved kæmning den version kontrol logs. Listen ser nogenlunde sådan her ud:

Version 2.5.0
(20. december 2004, fra / branches/2.5.x)

http://svn.scanley.org/repos/svn/tags/2.5.0/

Nye funktioner, forbedringer:
* Tilføjet regulære udtryk forespørgsler (emne # 53)
* Tilføjet understøttelse af UTF-8 og UTF-16 dokumenter
* Dokumentation oversat til polsk, russisk, Madagaskars
* …

Fejlrettelser:
* Fast Genindeksering bug (udg. # 945)
* Rettet nogle forespørgsel bugs (spørgsmål # 815, # 1007, # 1008)
* …
Listen kan være så længe det er nødvendigt, men ikke gider at medtage hver eneste lille bugfix og funktion ekstraudstyr. Dens formål er simpelthen at give brugerne et overblik over, hvad de ville vinde ved at opgradere til den nye version. Faktisk er changelist sædvanligvis indgår i annonceringen e-mail (se afsnittet «Test og Frigivelse» senere i dette kapitel), så skriv det med at publikum i tankerne.

Ændringer i forhold til ChangeLog

Traditionelt en fil med navnet ChangeLog lister hver ændring der nogensinde er lavet til et projekt det vil sige, hver revision forpligtet til version control system. Der er forskellige formater for ChangeLog filer, detaljerne i de formater er ikke vigtigt her, da de alle indeholder de samme oplysninger: datoen for ændringen, dens forfatter, og et kort resumé (eller bare logbesked for denne ændring) .

A ændrer fil er anderledes. Det er også en liste over ændringer, men kun dem mente vigtig for et bestemt publikum at se, og ofte med metadata ligesom den nøjagtige dato og forfatter krængede. For at undgå forvirring, skal du ikke bruge udtrykkene i flæng. Nogle projekter bruger «NEWS» i stedet for «ændringer», selv om dette undgår risikoen for forveksling med «ChangeLog», det er lidt af en misvisende, da ændringerne fil bevarer ændre oplysninger for alle udgivelser, og derfor har en masse gamle nyheder ud over den nye nyheder i toppen.

ChangeLog filer kan være langsomt forsvinde alligevel. De var nyttige i de dage, hvor CVS var det eneste valg af version control system, fordi ændrer data ikke var let at udvinde fra CVS. Men med nyere version kontrolsystemer, kan de data, der bruges til at blive holdt i ChangeLog rekvireres fra versionskontrol lageret til enhver tid, hvilket gør det meningsløst for projektet at holde en statisk fil, der indeholder disse data, i virkeligheden, værre end meningsløst, ville da ChangeLog blot duplikere logmeddelelser allerede er gemt i lageret.

Den konkrete udformning af kildekoden inde i træet bør være den samme som eller så ens som muligt, kildekoden layout man ville få ved at tjekke projektet direkte fra sin version kontrol repository. Normalt er der et par forskelle, for eksempel fordi pakken indeholder nogle genererede filer, der er nødvendige til konfiguration og udarbejdelse (se afsnittet «Kompilering og installation» senere i dette kapitel), eller fordi det indeholder tredjeparts software, der ikke vedligeholdes af projektet, men det er nødvendigt, og at brugerne ikke er sandsynligt, at allerede har. Men selv hvis det distribueret træet svarer nøjagtigt til en vis udvikling træ i version kontrol repository, bør fordelingen selv ikke være en fungerende kopi (jf. arbejdsdokument kopi). Frigivelsen skal forestille at repræsentere en statisk referencepunkt-en bestemt, uforanderlig konfiguration af kildefiler. Hvis det var en fungerende kopi, ville faren være, at brugeren kan opdatere den, og bagefter tror, at han stadig har frigivelsen når de i virkeligheden har han noget andet.

Husk, at pakken er den samme uanset emballagen. Frigivelsen det vil sige, den præcise omhandlede enhed, når nogen siger «Scanley 2.5.0″-er træet skabt ved udpakning af en zip-fil eller tarball. Så projektet kan tilbyde alle disse til download:

scanley-2.5.0.tar.bz2
scanley-2.5.0.tar.gz
scanley-2.5.0.zip

… Men kilden træ skabt ved udpakning dem skal være den samme. Denne kilde træ er fordelingen, den form, hvori det er downloadet, er blot et spørgsmål om bekvemmelighed. Visse trivielle forskelle mellem kildekodepakker er tilladelige: for eksempel i Windows-pakken bør tekstfiler have linjer slutter med CRLF (Carriage Return og Line Feed), mens Unix-pakker skal bruge bare LF. Træerne kan være anbragt lidt anderledes mellem kildekodepakker bestemt til forskellige operativsystemer, også hvis disse operativsystemer kræver forskellige former for layout til kompileringen. Men disse er alle dybest set trivielle transformationer. De grundlæggende kildefiler skal være den samme på tværs af alle emballager af en given udgivelse.

At kapitalisere eller ikke at udnytte

Når der henvises til et projekt ved navn, folk generelt udnytte det som et egennavn, og kapitalisere forkortelser, hvis der er nogen: «MySQL 5,0″, «Scanley 2.5.0″ osv. Hvorvidt denne kapitalisering er gengivet i pakken navn er op til projektet. Enten Scanley-2.5.0.tar.gz eller scanley-2.5.0.tar.gz ville være fint, for eksempel (jeg personligt foretrækker den sidstnævnte, fordi jeg ikke kan lide at gøre folk ramt shift-tasten, men masser af projekter skib kapitaliserede pakker). Det vigtige er, at den mappe, der oprettes ved udpakning tarball’en bruge den samme bogstaver. Der bør ikke være nogen overraskelser: brugeren skal være i stand til at forudsige med perfekt nøjagtighed navnet på den mappe, der vil blive oprettet, når hun udpakker en distribution.

Pre-udslip

Ved forsendelse af en pre-release eller kandidat udgivelse, qualifier er virkelig en del af frigivelsen nummer, så medtage det i navnet på den pakke navn. For eksempel ordnet følge af alfa og beta udgivelser givet tidligere i afsnittet «release-nummer Components» ville resultere i pakkenavne som dette:

scanley-2.3.0-alpha1.tar.gz
scanley-2.3.0-alpha2.tar.gz
scanley-2.3.0-beta1.tar.gz
scanley-2.3.0-beta2.tar.gz
scanley-2.3.0-beta3.tar.gz
scanley-2.3.0.tar.gz

Den første ville pakke i en mappe med navnet scanley-2.3.0-alfa1, den anden til scanley-2.3.0-alpha2, og så videre.

Kompilering og installation

For software kræver kompilering eller installation fra kilden, er der som regel standardprocedurer, som erfarne brugere forventer at være i stand til at følge. For eksempel, for programmer skrevet i C C + +, eller visse andre kompilerede sprog, standard under Unix-lignende systemer er for brugeren at skrive:

$. / Configure
$ Gøre
# Make install
Den første kommando detekterer automatisk lige så meget om miljøet, som det kan, og forbereder til byggeprocessen, den anden kommando bygger softwaren i stedet (men ikke installere det), og den sidste kommando installerer den på systemet. De første to kommandoer udføres som en almindelig bruger, den tredje som root. For flere detaljer om oprettelsen af dette system, se den fremragende GNU Autoconf, Automake, og Libtool bog af Vaughan, Elliston, Tromey, og Taylor. Det udgives som treeware af New Riders, og dens indhold er også gratis tilgængelig online på http://sources.redhat.com/autobook/.

Dette er ikke den eneste standard, selvom det er en af de mest udbredte. Myren (http://ant.apache.org/) build-system er ved at vinde popularitet, især med projekter skrevet i Java, og det har sine egne standardprocedurer for opbygning og installation. Også visse programmeringssprog, såsom Perl og Python, anbefaler, at den samme metode anvendes til de fleste programmer skrevet i dette sprog (for eksempel bruge Perl-moduler kommandoen perl Makefile.PL). Hvis det ikke er indlysende for dig, hvad de gældende standarder er til dit projekt, så spørg en erfaren udvikler, og du kan roligt gå ud fra, at nogle standard gælder, selvom du ikke ved, hvad det er i første omgang.

Uanset relevante normer for dig projekt er, ikke afviger fra dem, medmindre du absolut skal. Standard installationsprocedurer er praktisk spinale reflekser for en masse systemadministratorer nu. Hvis de ser velkendte påkaldelser dokumenteret i dit projekts INSTALL fil, som øjeblikkeligt hæver deres tro på, at dit projekt er generelt opmærksomme på konventioner, og at det er sandsynligt at have fået andre ting lige så godt. Også, som omtalt i afsnittet «Downloads» i kapitel 2, Introduktion, der har en standard build procedure behager potentielle udviklere.

På Windows, er standarderne for bygge og installere en smule mindre afgjort. For projekter der kræver udarbejdelse, den almindelige overenskomst synes at være at sende et træ, der kan passe ind i arbejdsområdet / projektmodel af standard Microsoft udviklingsmiljøer (Developer Studio, Visual Studio, VS.NET, MSVC + +, etc.). Afhængigt af arten af din software, kan det være muligt at tilbyde et Unix-lignende bygge option på Windows via Cygwin (http://www.cygwin.com/) miljø. Og selvfølgelig, build, hvis du bruger et sprog eller programmeringsramme, der kommer med sin egen og installere konventioner-eg, Perl eller Python-du skal blot bruge uanset standardmetoden er for disse rammer, uanset om Windows, Unix, Mac OS X, eller ethvert andet operativsystem.

Vær villig til at sætte i en masse ekstra indsats for at gøre dit projekt opfylder de relevante build eller installation standarder. Opbygning og installation er en indgang: det er okay, at tingene bliver sværere efter det, hvis de absolut skal, men det ville være en skam for brugerens eller udviklers allerførste interaktion med softwaren til at kræve uventede skridt.

Binære pakker

Selv om den formelle frigivelse er en kildekode pakke, vil de fleste brugere installerer fra binære pakker, enten af deres operativsystem software distribution mekanisme, eller indhentet manuelt fra projektets hjemmeside eller fra en tredje part. Her «binary» ikke nødvendigvis betyder «kompileret», det betyder bare, enhver præ-konfigureret form af den pakke, der giver brugeren mulighed for at installere det på sin computer uden at gå gennem den sædvanlige kilde-baserede bygge og installere procedurer. On RedHat GNU / Linux, er det RPM system på Debian GNU / Linux, er det APT (deb.) System, på MS Windows, er det normalt MSI filer eller selv-installation exe-filer…

Hvorvidt disse binære pakker er samlet af personer tæt forbundet med projektet, eller ved fjerne tredjeparter, brugere kommer til at behandle dem som svarende til projektets officielle udgivelser, og vil indsende spørgsmål i projektets bug tracker baseret på adfærd af den binære pakker. Derfor er det i projektets interesse at give packagers med klare retningslinjer, og arbejde tæt sammen med dem for at sørge for, at det, de producerer repræsenterer softwaren retfærdigt og præcist.

Det vigtigste programpakker behøver at vide er, at de altid skal basere deres binære pakker på en officiel kilde udgivelse. Sommetider pakkere er fristet til at trække en senere inkarnation af koden fra lageret, eller inkluderer udvalgte ændringer, der blev begået efter udgivelsen blev gjort, for at give brugerne med visse fejlrettelser eller andre forbedringer. Den pakkevirksomheden tror, han gør sine brugere en tjeneste ved at give dem den nyere kode, men faktisk denne praksis kan medføre en stor forvirring. Projekterne er parate til at modtage rapporter om bugs fundet i frigivne versioner, og bugs fundet i nyere bagagerum og større gren kode (dvs. fundet af folk, der bevidst kører blødning kanten kode). Når en fejlrapport kommer fra disse kilder, vil responder ofte være i stand til at bekræfte, at fejlen er kendt for at være til stede i dette øjebliksbillede, og måske, at det siden er blevet rettet, og at brugeren bør opgradere eller vente på den næste udgivelse . Hvis det er en hidtil ukendt fejl, der har den præcise release gør det lettere at reproducere og lettere at kategorisere i tracker.

Projekterne er ikke forberedt, men at modtage fejlrapporter baseret på uspecificerede mellemliggende eller hybrid versioner. Sådanne fejl kan være svære at gengive, også, kan de være på grund af uventede interaktioner i isolerede ændringer trækkes ind fra senere udvikling, og derved forårsager dårlig opførsel, at projektets udviklere ikke behøver at tage skylden for. Jeg har endda set dismayingly store mængder af tid spildt, fordi en fejl var fraværende, når det skulle have været til stede: en person kørte en lidt lappet version, baseret på (men ikke identisk med) en officiel udgivelse, og når den forudsagte bug ikke ske, alle havde at grave rundt en masse at finde ud af hvorfor.

Alligevel vil der undertiden være omstændigheder, hvor en emballeringsvirksomhed insisterer på, at ændringer til kilden release er nødvendige. Pakkere bør tilskyndes til at bringe dette op med projektets udviklere og beskrive deres planer. De kan få godkendt, men hvis dette ikke, vil de i det mindste har anmeldt projektet om deres planer, så projektet kan holde øje med usædvanlige fejlrapporter. Udviklerne kan reagere ved at sætte en ansvarsfraskrivelse på projektets hjemmeside, og kan anmode om, at emballeringsvirksomhedens gøre det samme på et passende sted, så brugerne af denne binære pakke ved, hvad de får, er ikke helt det samme som, hvad projektet officielt frigivet. Der behøver ikke være nogen fjendskab i en sådan situation, men desværre er der ofte er. Det er bare at aftapningsvirksomhederne har en lidt anderledes sæt af mål fra udviklere. De pakkere hovedsageligt ønsker det bedste out-of-the-box oplevelse for deres brugere. Udviklerne vil have, at alt, selvfølgelig, men de har også brug for at sikre, at de ved, hvad versioner af softwaren er derude, så de kan modtage sammenhængende fejlrapporter og gøre kompatibilitet garantier. Sommetider disse mål konflikt. Når de gør det, er det godt at huske på, at projektet ikke har nogen kontrol over de pakkere, og at obligationerne af forpligtelse køre begge veje. Det er rigtigt, at projektet gør de packagers en tjeneste ved blot at producere software. Men pakkere laver også projektet en tjeneste, ved at tage på en for det meste glamourøse job for at gøre softwaren mere bredt tilgængelige, ofte ved størrelsesordener. Det er fint at være uenig med pakkere, men ikke flamme dem, bare prøve at arbejde ting ud, så godt du kan.

Test og Frigivelse

Når kilden tarball er fremstillet af den stabiliserede release gren, den offentlige del af frigivelsen begynder. Men før tarball stilles til rådighed for verden som helhed, bør det være testet og godkendt af nogle minimum antal udviklere, som regel tre eller flere. Godkendelsen er ikke kun et spørgsmål om at inspicere overgang til åbenlyse fejl, ideelt set, udviklerne hente tarball, bygge og installere det på en ren system, skal du køre regression test suite (se afsnittet «Automatisk test») i kapitel 8, Håndtering af de frivillige og gøre nogle manuelle test. Hvis man antager det passerer denne kontrol, såvel som alle andre frigivelse tjekliste kriterier som projektet kan have, udviklerne derefter digitalt signere tarball bruger GnuPG (http://www.gnupg.org/), PGP (http://www.pgpi . org /) eller et andet program kan frembringe PGP-kompatible signaturer.

I de fleste projekter, bare udviklerne bruge deres personlige digitale signaturer, i stedet for et fælles projekt nøgle, og så mange udviklere som ønsker at kan underskrive (dvs. at der er et minimalt antal, men ikke et maksimum). Jo flere udviklere tegn, flere tests udgivelsen undergår, og også større sandsynlighed for, at en sikkerhed-bevidste bruger kan finde en digital tillid sti fra sig selv til tarball.

Når det er godkendt, bør release (det vil sige, alle tarballs, zip-filer, og hvad andre formater bliver distribueret) anbringes i projektets download-området, ledsaget af de digitale signaturer, og ved MD5/SHA1 kontrolsummer (se http:// en.wikipedia.org / wiki / Cryptographic_hash_function). Der er forskellige standarder for at gøre dette. En måde er at lade hvert frigivet pakke med en fil, der giver de tilsvarende digitale signaturer, og en anden fil giver checksum. For eksempel, hvis en af de frigivne pakker scanley-2.5.0.tar.gz, sted i det samme bibliotek en fil scanley-2.5.0.tar.gz.asc indeholder den digitale signatur for at tarball, en anden fil scanley- 2.5.0.tar.gz.md5 indeholdende dens MD5 checksum, og eventuelt en anden, scanley-2.5.0.tar.gz.sha1, indeholdende SHA1 checksum. En anderledes måde at give kontrol er at indsamle alle de underskrifter for alle de frigivne pakker i en enkelt fil, scanley-2.5.0.sigs, det samme kan gøres med kontrolsummer.

Det er faktisk ligegyldigt, hvilken vej du gør det. Bare holde til en simpel ordning, beskrive det tydeligt, og være konsistente fra udgivelse til udgivelse. Formålet med al denne undertegnelse og kontrolsumberegning er at give brugerne en måde at kontrollere, at den kopi de modtager ikke er blevet ondsindet manipuleret med. Brugerne er i færd med at køre denne kode på deres computere, hvis koden er blevet manipuleret med, kan en hacker pludselig have en bagdør til alle deres data. Se afsnittet «Sikkerhed Releases» senere i dette kapitel for yderligere oplysninger om paranoia.

Ansøgerlandene Releases

For vigtige udgivelser, der indeholder mange ændringer, foretrækker mange projekter at sætte ud frigivelse kandidater først, fx scanley-2.5.0-beta1 før scanley-2.5.0. Formålet med en kandidat er at underkaste koden til brede test, før velsigne det som en officiel udgivelse. Hvis der opstår problemer, er de fast på release filial og en ny kandidat udgivelse er rullet ud (scanley-2.5.0-beta2). Denne cyklus fortsætter, indtil der ikke uacceptable bugs er tilbage, på hvilket tidspunkt den sidste kandidat release bliver den officielle release-det er den eneste forskel mellem den sidste kandidat frigivelse og den reelle udgivelse er fjernelsen af qualifier fra den version nummer.

I de fleste andre henseender bør overvejes release behandles på samme måde som en virkelig frigivelse. Den alfa, beta eller rc kvalifikationskamp er nok til at advare konservative brugere til at vente, indtil den virkelige frigørelse, og selvfølgelig e-mails med for kandidatlandene udgivelser bør påpege, at deres formål er at anmode feedback. Bortset fra det, giver kandidatlandene frigiver den samme mængde pleje som almindelige udgivelser. Efter alt, ønsker du folk til at bruge de kandidater, fordi eksponeringen er den bedste måde at afdække fejl, og også fordi du aldrig vide, hvilken kandidat udgivelse vil ende med at blive den officielle udgivelse.

Annoncerer Udgivelser

Annoncerer en udgivelse er ligesom at annoncere enhver anden begivenhed, og bør anvende de procedurer, der er beskrevet i afsnittet «Offentlighed» i kapitel 6, Communications. Der er et par specifikke ting at gøre for udgivelser, selv om.

Når du giver URL’en til den downloades release tarball, skal du sørge for også at give de MD5/SHA1 kontrolsummer og henvisninger til den digitale signatur fil. Siden annonceringen sker i flere fora (mailingliste, nyhedsside, etc.), kan dette betyder, at brugerne får de kontrolsummer fra flere kilder, hvilket giver den mest sikkerhedsbevidste blandt dem ekstra sikkerhed for, at kontrolsummer selv ikke er blevet pillet ved. Giver linket til de digitale signaturfiler flere gange gør ikke disse underskrifter mere sikker, men det gør berolige folk (især dem, der ikke følger projektet tæt), at projektet tager sikkerhed alvorligt.

I annonceringen e-mail, og på nyhedssider, der indeholder mere end bare en bagsidetekst om udgivelsen, skal du sørge for at inkludere den relevante del af de ændringer filen, så folk kan se, hvorfor det kan være i deres interesse at opgradere. Det er lige så vigtigt med kandidatlandene udgivelser som med de endelige udslip tilstedeværelsen af fejlrettelser og nye funktioner er vigtige i fristende folk til at afprøve en kandidat udgivelse.

Endelig, så glem ikke at takke udviklingsteam, de testere, og alle de mennesker, der tog sig tid til at indgive gode fejlrapporter. Må ikke enkelt ud nogen ved navn, selv om, medmindre der er nogen, der er individuelt ansvarlig for et enormt stykke arbejde, hvis værdi bredt anerkendt af alle i projektet. Bare vær forsigtig med at glide ned ad skråplan af kredit inflation (se afsnittet «Credit» i kapitel 8, adm. Frivillige).

Vedligeholder flere release Lines

De fleste modne projekter opretholde flere frigivelse linjer i parallel. For eksempel, efter 1.0.0 kommer ud bør denne linje fortsætte med mikro (bugfix) udledninger 1.0.1, 1.0.2 osv., indtil projektet udtrykkeligt beslutter at afslutte linjen. Bemærk, at blot frigivelse 1.1.0 ikke er tilstrækkelig grund til at afslutte 1.0.x linje. For eksempel lave nogle brugere er det en politik aldrig at opgradere til den første udgivelse i en ny mindre eller større serie-de lader andre ryste bugs ud af, siger 1.1.0, og vent 1.1.1. Dette er ikke nødvendigvis egoistisk (husk, de er afkald på fejlrettelser og nye funktioner også), det er bare, at uanset årsagen, har de besluttet at være meget forsigtig med opgraderinger. Følgelig hvis projektet hører om en stor fejl i 1.0.3, lige før det handler om at frigive 1.1.0, ville det være en smule svær at bare sætte den bugfix i 1.1.0 og fortælle alle de gamle 1.0.x brugere, de bør opgradering. Hvorfor ikke frigive både 1.1.0 og 1.0.4, så alle kan være lykkelig?

Efter 1.1.x linje er godt i gang, kan du erklære 1.0.x at være i slutningen af livet. Dette bør annonceres officielt. Meddelelsen kunne stå alene, eller det kan nævnes som en del af en 1.1.x release meddelelse, men du gør det, skal brugerne vide, at den gamle linje ved at blive udfaset, så de kan træffe opgradering beslutninger i overensstemmelse hermed.

Nogle projekter sat et vindue af tid, hvor de forpligter sig til at støtte den forrige udgave linje. I en open source sammenhæng, «støtte» betyder at acceptere fejlrapporter mod denne linje, og gør vedligeholdelse udgivelser når væsentlige fejl er fundet. Andre projekter giver ikke en bestemt mængde af tid, men se indkommende fejlrapporter at måle, hvor mange mennesker stadig bruger den ældre linje. Når andelen falder til under et vist punkt, erklærer de udrangering for linjen og ophører med at støtte det.

For hver udgivelse, så sørg for at have et mål version eller target milepæl rådighed i bug tracker, så folk arkivering bugs vil være i stand til at gøre det mod den korrekte version. Glem ikke også at have et mål der hedder «udvikling» eller «seneste» for den seneste udvikling kilder, da nogle mennesker, ikke kun aktive udviklere-vil ofte være på forkant med de officielle udgivelser.

Sikkerhed Releases

De fleste af de oplysninger om håndtering af sikkerhed bugs blev dækket i afsnittet «Annoncerer Sikkerhedssvagheder» i kapitel 6, Kommunikation, men der er nogle specielle detaljer at diskutere for at gøre sikkerheden udgivelser.

En sikkerhed udgivelse er en udgivelse der alene for at lukke en sikkerhedsbrist. Koden, der løser fejlen ikke kan gøres offentligt indtil udgivelsen er tilgængelig, hvilket betyder ikke blot, at de rettelser ikke kan forpligtes til lageret indtil dagen for udgivelsen, men også at frigivelsen ikke kan offentligt testes, inden det går ud dør. Naturligvis kan udviklerne undersøge fix indbyrdes, og teste frigivelsen privat, men udbredt virkelige verden test er ikke mulig.

På grund af denne manglende afprøvning, bør der stilles sikkerhed release altid bestå af nogle eksisterende frigivelse plus rettelser til sikkerhed bug, uden andre ændringer. Dette skyldes, at flere ændringer, du skib uden prøvning, jo mere sandsynligt, at en af dem vil medføre en ny fejl, måske endda en ny sikkerhedspolitisk bug! Denne konservatisme er også venlig over for administratorer, der kan have brug for at implementere sikkerhedsopdateringen fix, men hvis opgraderingen politik foretrækker, at de ikke anvende eventuelle andre ændringer på samme tid.

Realiseringen af en sikkerhed release sommetider medfører nogle mindre bedrag. For eksempel kan projektet har arbejdet på en 1.1.3 udgivelse, med visse fejlrettelser til 1.1.2 allerede offentligt erklæret, hvis en sikringsrelateret rapport kommer i. Naturligvis kan udviklerne ikke tale om den sikkerhed problem, indtil de gør fix rådighed indtil da, skal de fortsat tale offentligt som om 1.1.3 vil være, hvad det har altid været planlagt til at være. Men da 1.1.3 faktisk kommer ud, vil det afvige fra 1.1.2 kun i sikkerhedsrettelser, og alle de andre rettelser vil være blevet udskudt til 1.1.4 (hvilket selvfølgelig vil nu også indeholde sikkerhed fix, som vil alle andre fremtidige udgivelser).

Du kan tilføje en ekstra komponent til en eksisterende udgivelse at indikere, at det indeholder sikkerhedsmæssige ændringer kun. For eksempel ville folk være i stand til at fortælle lige fra de tal, 1.1.2.1 er en sikkerhed frigivelse mod 1.1.2, og de ville vide, at enhver udgivelse «højere» end det (f.eks 1.1.3, 1.2.0, osv. .) indeholder de samme sikkerhedsrettelser. For de indviede, formidler dette system en masse information. På den anden side, for dem, der ikke følger projektet tæt kan det være en smule forvirrende at se en tre-komponent release nummer meste af tiden med en lejlighedsvis fire-komponent en kastet i tilsyneladende tilfældigt. De fleste projekter, jeg har kigget på vælger konsistens og blot bruge det næste regelmæssigt planlagte antal af sikkerhedsmæssige udgivelser, selv når det betyder at flytte andre planlagte udgivelser med én.

Udledninger og daglige udvikling

Opretholdelse af parallelle udgivelser samtidig har konsekvenser for, hvordan daglige udvikling foregår. Især gør det praktisk obligatorisk en disciplin, som anbefales alligevel: har hver commit være en enkelt logisk forandring, og bland aldrig uafhængige ændringer i samme commit. Hvis en ændring er for stort eller for forstyrrende at gøre i en begå, bryde det på tværs N forpligter, hvor hver commit er et godt partitioneret delmængde af den samlede ændring, og omfatter ikke noget relateret til den samlede forandring.

Her er et eksempel på et dårligt gennemtænkt begå:

————————————————— ———————-
r6228 | jrandom | 2004/06/30 22:13:07 -0500 (Wed, 30 Jun 2004) | 8 linjer

Fix Issue # 1729: Gør indeksering yndefuldt advare brugeren, når en fil
ændrer sig som det bliver indekseret.

* Ui / repl.py
(ChangingFile): Ny undtagelse klasse.
(DoIndex): Handle ny undtagelse.

* Indexer / index.py
(FollowStream): Hæv ny undtagelse, hvis filændringer under indeksering.
(Builddir): Unrelatedly, fjerne nogle forældede bemærkninger, omformatere
noget kode, og rette fejlen kontrollere, når du opretter en mappe.

Andre uafhængige oprydninger:

* Www / index.html: Fix nogle stavefejl, indstille næste udgivelsesdato.
————————————————— ———————-
Problemet med det viser sig, så snart nogen har brug for at overføre den builddir fejl tjek ordne over til en filial for en kommende vedligeholdelse udgivelse. Porter ønsker ikke nogen af de andre ændringer, for eksempel, måske fix til at udstede # 1729 blev ikke godkendt til vedligeholdelse gren på alle, og de index.html tweaks ville simpelthen være irrelevant der. Men hun kan ikke nemt få fat i bare builddir ændring via den version kontrol værktøjets merge-funktionalitet, fordi den version kontrolsystem fik at vide, at denne ændring er logisk grupperet med alle disse andre uafhængige ting. Faktisk ville problemet blive synlige, selv før sammenfletningen. Blot notering ændringen til afstemning ville blive problematisk: i stedet for bare at give revisionen nummer, ville forslagsstilleren nødt til at gøre en særlig patch eller ændre filial blot at isolere den del af commit, der foreslås. Det ville være et stort arbejde for andre at lide igennem, og alle, fordi den oprindelige committer kunne ikke gidet at bryde ting i logiske grupper.

Faktisk tilsagn om, at egentlig burde have været fire separate begår: en til at løse problemet # 1729, en anden for at fjerne overflødige bemærkninger og omformatere kode i builddir, en anden til at rette fejlen check i builddir, og endelig til en tweak index.html. Den tredje af disse forpligter ville være den, der foreslås til vedligeholdelse frigivelse gren.

Selvfølgelig er release stabilisering ikke den eneste grund til, at der hver commit være et logisk ændring er ønskelig. Psykologisk et semantisk forenet commit er lettere at gennemgå, og lettere at vende tilbage hvis det er nødvendigt (i nogle versioner kontrolsystemer, reversion er virkelig en særlig slags fletningen alligevel). En lille up-front disciplin fra alle parter kan gemme projektet en masse hovedpine senere.

Planlægning Releases

Et område, hvor open source-projekter har historisk adskilte sig fra proprietære projekter er i release planlægning. Farmaceutiske projekter har normalt fastere frister. Nogle gange er det, fordi kunderne blev lovet, at en opgradering ville være til rådighed inden en bestemt dato, fordi den nye release bør koordineres med nogle andre indsats med henblik på markedsføring, eller fordi de venturekapitalinvestorer, der investerede i det hele har brug for at se nogle resultater inden de sat i noget mere finansiering. Fri software-projekter, på den anden side var indtil for nylig hovedsagelig motiveret af amatørisme i den mest bogstavelige forstand: de blev skrevet af kærlighed til det. Ingen følte behov for at sende før alle de funktioner var klar, og hvorfor skulle de? Det var ikke som om nogens job var på linjen.

I dag er mange open source-projekter finansieret af virksomheder, og er tilsvarende mere og mere påvirket af deadline-bevidste virksomhedskultur. Dette er på mange måder en god ting, men det kan skabe konflikter mellem de prioriterede områder i de udviklere, der bliver betalt og dem, der frivilligt deres tid. Disse konflikter ofte ske omkring spørgsmålet om, hvornår og hvordan du planlægger udgivelser. De lønnede udviklere, der er under pres vil naturligvis bare ønsker at vælge en dato, hvor udsætningerne vil opstå, og har alles aktiviteter falder i tråd. Men de frivillige kan have andre dagsordener-måske funktioner, de ønsker at gennemføre, eller nogle test de vil have gjort, at de føler frigivelsen skal vente på.

Der findes ingen generel løsning på dette problem undtagen diskussion og kompromis, selvfølgelig. Men du kan minimere hyppigheden og graden af skyldes friktion, ved at afkoble den foreslåede eksistensen af en given udgivelse fra det tidspunkt, hvor det ville gå ud af døren. Det er, så prøv at styre diskussionen hen mod emnet som frigiver projektet vil være at gøre i den nærmeste til mellemlang sigt, og hvilke funktioner vil være i dem, uden i første omgang at nævne noget om datoer, undtagen for uslebne gæt med bred fejlmarginer [23]. Ved sømning ned funktionssæt tidligt, kan du reducere kompleksiteten af diskussionen centreret om en individuel frigørelse, og dermed sikre bedre forudsigelighed. Dette skaber også en slags inerti fordomme mod enhver, der foreslår at udvide definitionen af en frigivelse ved at tilføje nye funktioner eller andre komplikationer. Hvis frigivelse indhold nogenlunde er veldefinerede, påhviler det initiativtageren at begrunde en udvidelse, selv om tidspunktet for offentliggørelse er måske ikke blevet indstillet endnu.

I sin multi-volumen biografi af Thomas Jefferson, Jefferson og hans tid, fortæller Dumas Malone historien om, hvordan Jefferson håndterede det første møde at beslutte tilrettelæggelsen af den fremtidige University of Virginia. Universitetet havde været Jefferson idé i første omgang, men (som det er tilfældet overalt, ikke kun i open source-projekter) mange andre partier havde klatrede om bord hurtigt, hver med deres egne interesser og dagsordener. Da de samledes på det første møde til hash ting ud, Jefferson sørget for at dukke op med sirligt forberedt arkitekttegninger, detaljerede budgetter for anlæg og drift, en foreslået undervisningsplaner, samt navnene på specifikke fakultet han ønskede at importere fra Europa. Ingen andre i værelset var bare tilnærmelsesvis så forberedt, gruppen hovedsageligt måtte kapitulere til Jefferson vision, og universitetet blev til sidst grundlagt for mere eller mindre i overensstemmelse med hans planer. De faktiske omstændigheder, at opførelsen gik langt over budget, og at mange af hans ideer ikke gjorde det, af forskellige årsager, træne i sidste ende, var alle ting Jefferson sandsynligvis vidste udmærket ville ske. Hans formål var strategisk: at dukke op på mødet med noget så omfattende, at alle andre ville have til at falde ind i rollen som blot foreslå ændringer til det, således at den overordnede form, og derfor planlægge, af projektet vil være nogenlunde som han ønskede.

I tilfælde af et gratis software-projekt, er der ingen enkelt «møde», men i stedet en række små fremsatte forslag hovedsagelig ved hjælp af issue tracker. Men hvis du har en vis troværdighed i projektet til at starte med, og du begynder at tildele forskellige funktioner, forbedringer og fejl, der målrettes mod udgivelser i issue tracker, ifølge nogle annoncerede samlet plan, vil folk det meste gå sammen med dig. Når du har fået tingene lagt ud mere eller mindre som du vil have dem, vil de samtaler om faktiske udgivelsesdatoer gå meget mere glat.

Det er afgørende, naturligvis aldrig præsentere enhver individuel beslutning som skrevet i sten. I bemærkningerne i forbindelse med hver opgave af et problem til en bestemt fremtidig udgivelse, invitere diskussion, uenighed, og være virkelig villig til at blive overtalt når det er muligt. Aldrig udøve kontrol alene af hensyn til at udøve kontrol: jo mere dybt andre deltager i frigivelsen planlægningsprocessen (se afsnittet «Del styringsopgaver samt teknisk Tasks» i kapitel 8, adm. Frivillige), jo lettere vil det være at overtale dem til at dele dine prioriteter på de spørgsmål, der virkelig tæller for dig.

Den anden måde, hvorpå projektet kan sænke spændinger omkring release planlægning er at gøre udgivelser temmelig ofte. Når der er en lang tid mellem udgivelser, er betydningen af en individuel frigørelse forstørret i alles sind, folk er så meget mere knust, når deres kode ikke gøre det i, fordi de ved, hvor lang tid det kan være indtil den næste chance. Afhængig af kompleksiteten af udsætningen processen og karakteren af dit projekt, et sted mellem hver tredje og seks måneder er normalt omkring den rette afstand mellem udgivelser, selvom vedligeholdelse linjer kan sætte ud mikro udgivelser lidt hurtigere, hvis der er efterspørgsel efter dem.

[23] For en alternativ tilgang, kan du ønsker at læse Martin Michlmayr Ph.D. afhandling kvalitetsreform i Frivilliges gratis og open source software-projekter: om betydningen af Release Management (http://www.cyrius.com/publications/michlmayr-phd.html). Det handler om at bruge tidsbaserede frigivelse processer, i modsætning til feature-baseret, i store fri software-projekter. Michlmayr gav også en tale på Google om emnet, der findes på Google Video på http://video.google.com/videoplay?docid=-5503858974016723264.

Kapitel 8. Håndtering af Frivillige

Få folk til at blive enige om hvad et projekt behov, og til at arbejde sammen for at opnå det, kræver mere end blot en genial stemning og mangel på indlysende dysfunktion. Det kræver nogen eller flere someones, bevidst forvalte alle de involverede personer. Administration af frivillige kan ikke være en teknisk håndværk i samme forstand som edb-programmering, men det er et håndværk i den forstand, at den kan forbedres gennem studier og praksis.

Dette kapitel er en grab-pose af specifikke teknikker til styring frivillige. Den trækker, måske hårdere end tidligere kapitler, på Subversion projektet som et casestudie, dels fordi jeg arbejdede på dette projekt, som jeg skrev dette og havde alle de primære kilder lige ved hånden, og dels fordi det er mere acceptabelt at kaste kritiske sten i ens eget glashus end i andres. Men jeg har også set i forskellige andre projekter fordelene ved at anvende-og konsekvenserne af ikke at anvende-anbefalingerne, der følger, når det er politisk muligt at give eksempler fra nogle af de andre projekter, vil jeg gøre det.

Apropos politik, det er så god en tid som enhver til at trække det meget udskældte ord ud for at se nærmere. Mange ingeniører lide at tænke på politik som noget andre mennesker engagere sig i. «Jeg er bare fortaler for bedste kursus for projektet, men hun gøre indsigelse af politiske grunde.» Jeg mener, at denne afsmag for politik (eller for hvad der er forestillet at være politik) er især stærk inden ingeniører, fordi ingeniører er købt ind i tanken om, at nogle løsninger er objektivt bedre end andre. Så når nogen handler på en måde, der synes motiveret af udenfor overvejelser-sige, opretholdelse af sin egen position af indflydelse, formindskelsen af en andens indflydelse, decideret studehandler, eller at undgå at såre nogens følelser, andre deltagere i projektet kan få irriteret. Selvfølgelig sjældent dette forhindrer dem i at handle på samme måde, når deres egne vitale interesser er på spil.

Hvis du mener, «politik» et beskidt ord, og håber at holde dit projekt fri for det, give op lige nu. Politik er uundgåelige, når folk er nødt til at samarbejdsvilligt styre en delt ressource. Det er absolut fornuftigt, at en af de overvejelser, der går ind i hver enkelt persons beslutningsproces er spørgsmålet om, hvordan en given handling kan påvirke sin egen fremtid indflydelse i projektet. Efter alt, hvis du stoler på din egen dømmekraft og færdigheder, som de fleste programmører så gøre det potentielle tab af fremtidige indflydelse må anses for et teknisk resultat, i en vis forstand. Tilsvarende ræsonnement gælder for andre handlinger, der kan synes, på deres ansigt, ligesom «rene» politik. I virkeligheden er der ikke sådan noget som rene politik: Det er netop, fordi handlinger har flere virkelige verden konsekvenser, folk bliver politisk bevidst i første omgang. Politik er i sidste ende blot en erkendelse af, at alle konsekvenser af beslutninger skal tages i betragtning. Hvis en bestemt afgørelse fører til et resultat, at de fleste deltagere teknisk finde tilfredsstillende, men medfører en ændring i magtforhold, der efterlader nøglepersoner følelse isoleret, sidstnævnte er lige så vigtigt et resultat som førstnævnte. At ignorere det ville ikke være høj-minded, men kortsigtet.

Så som du læser de råd, der følger, og når du arbejder med dit eget projekt, så husk at der ikke er en der er over politik. Ser ud til at være over politik er blot en bestemt politisk strategi, og til tider en meget nyttig, men det er aldrig en realitet. Politik er simpelthen, hvad der sker, når folk er uenige, og vellykkede projekter er dem, der udvikler politiske mekanismer til styring af uenighed konstruktivt.

Sådan får du mest ud af frivillige

Hvorfor frivillige arbejde på fri software-projekter? [24]

Når du bliver spurgt, mange hævder de gør det, fordi de ønsker at producere god software, eller ønsker at være personligt involveret i fastsættelse af fejl, der betyder noget for dem. Men disse grunde er normalt ikke hele historien. Efter alt, kunne du forestille dig en frivillig opholder sig med et projekt, selv om ingen nogensinde sagt et ord i påskønnelse af hans arbejde, eller lyttede til ham i diskussioner? Selvfølgelig ikke. Det er klart, folk bruger tid på fri software af årsager, bare et abstrakt ønske om at producere god kode. Forståelse frivilliges sande motivationer vil hjælpe dig med at arrangere tingene således at tiltrække og beholde dem. Ønsket om at producere god software kan være blandt de motivationer, sammen med udfordringen og uddannelsesmæssige værdi af at arbejde på hårde problemer. Men mennesker har også en indbygget ønske om at arbejde sammen med andre mennesker, og til at give og opnå respekt gennem samarbejdsaktiviteter. Grupper, der udøver samarbejdsaktiviteter skal udvikle normer for adfærd, således at status erhverves og holdt gennem aktioner, der hjælper koncernens mål.

Disse normer vil ikke altid opstå af sig selv. For eksempel kan på nogle projekter erfarne open source-udviklere sandsynligvis navn flere off toppen af deres hoveder-folk åbenbart føler, at status erhverves ved udstationering ofte og udførligt. De kommer ikke til denne konklusion ved et uheld, de kommer til det, fordi de bliver belønnet med respekt for at gøre lange, indviklede argumenter, uanset om der rent faktisk hjælper projektet. Følgende er nogle teknikker til at skabe en atmosfære, hvor status-erhverver handlinger er også konstruktive handlinger.

Delegationen

Delegationen er ikke blot en måde at sprede arbejdsbyrden omkring, det er også en politisk og social værktøj. Overvej alle de effekter, når du beder nogen om at gøre noget. Den mest indlysende virkning er, at hvis han accepterer, han gør opgaven og gør du ikke. Men en anden effekt er, at han er gjort opmærksom på, at du har tillid til ham til at håndtere opgaven. Desuden, hvis du fremsatte anmodningen i et offentligt forum, så han ved, at andre i gruppen er blevet gjort opmærksom på, at tillid også. Han kan også føle et vist pres for at acceptere, hvilket betyder, at du skal spørge på en måde, der tillader ham at falde yndefuldt, hvis han ikke virkelig ønsker jobbet. Hvis opgaven kræver koordinering med andre i projektet, er du faktisk foreslår, at han bliver mere involveret, danner obligationer, der ellers ikke ville have været dannet, og måske blive en kilde til autoritet i nogle underdomæne af projektet. Den ekstra engagement kan være skræmmende, eller det kan føre ham til at blive engageret i andre måder så godt, fra en øget følelse af den samlede forpligtelse.

På grund af alle disse effekter, ofte giver det mening at bede en anden om at gøre noget selv, når du ved, du kan gøre det hurtigere eller bedre selv. Selvfølgelig er der nogle gange en streng økonomisk effektivitet argument for dette alligevel: måske muligheden for omkostningerne ved at gøre det selv ville være for høj kan der være noget endnu mere vigtigt, at du kunne gøre med den tid. Men selv når offeromkostninger argument gælder imidlertid ikke, kan du stadig ønsker at bede en anden om at påtage sig opgaven, fordi det i det lange løb du ønsker at tegne denne person dybere ind i projektet, selv om det betyder at bruge ekstra tid på at se over dem i første omgang. Det modsatte teknik gælder også: hvis du lejlighedsvis frivilligt arbejde, at en anden ikke ønsker eller har tid til at gøre, vil du få hans gode vilje og respekt. Delegation og substitution er ikke bare om at få de enkelte opgaver gjort, de er også om at tegne mennesker ind i en tættere opbakning af projektet.

Skelne klart mellem undersøgelse og tildeling

Nogle gange er det rimeligt at forvente, at en person vil acceptere en bestemt opgave. For eksempel, hvis nogen skriver en fejl i koden, eller begår kode, der ikke overholder projektets retningslinjer i nogle indlysende måde, så er det nok til at påpege problemet og derefter opfører sig som om du antager personen vil tage sig af det . Men der er andre situationer, hvor det er på ingen måde klart, at du har ret til at forvente handling. Den person kan gøre, som du beder, eller måske ikke. Da ingen kan lide at blive taget for givet, er du nødt til at være opmærksomme på forskellen mellem disse to typer af situationer, og skræddersy dine anmodninger herom.

En ting, der næsten altid får folk øjeblikkelig irritation er blevet bedt om at gøre noget på en måde, der indebærer, at du synes, det er helt klart deres ansvar at gøre det, når de føler sig anderledes. For eksempel er tildeling af indkommende spørgsmål særligt frugtbart grundlag for denne slags irritation. Deltagerne i et projekt som regel hvem der er ekspert i hvilke områder, så når en fejlrapport kommer ind, vil der ofte være en eller to personer, som alle kender sandsynligvis kunne ordne det hurtigt. Men hvis du tildeler problemet over til en af de mennesker uden hendes forudgående tilladelse, kan hun føler, hun er blevet lagt i en ubehagelig position. Hun føler presset af forventning, men også kan føle, at hun er i realiteten straffet ved at blive for hendes ekspertise. Efter alt, er den måde, man får ekspertise ved fastsættelse bugs, så måske en anden skulle tage denne ene! (Bemærk, at udsteder trackers, der automatisk tildeler spørgsmål til bestemte personer, baseret på oplysninger i fejlrapporten er mindre tilbøjelige til at fornærme, fordi alle ved, at opgaven er foretaget af en automatiseret proces, og er ikke en indikation af menneskers forventninger.)

Selv om det ville være rart at fordele belastningen så jævnt som muligt, er der visse tidspunkter, hvor du bare ønsker at fremme den person, der kan rette en fejl den hurtigste til at gøre det. Eftersom du ikke har råd til en kommunikations turnaround for hver sådan overdragelse («Ville du være villig til at se på denne fejl?» «Ja.» «Okay, jeg tildele problemet over til dig dengang.» «Okay.» ), skal du blot gøre opgaven i form af en undersøgelse, fremføring ingen pres. Stort set alle udstede trackers tillader en kommentar til at være forbundet med tildeling af et problem. I denne kommentar, kan du sige noget som dette:

Tildeling af denne over til dig, jrandom, fordi du er mest fortrolig med denne kode. Du er velkommen til at hoppe dette tilbage, hvis du ikke har tid til at se på det, selv om. (Og lad mig vide, hvis du foretrækker ikke at modtage sådanne anmodninger i fremtiden.)

Dette adskiller klart mellem anmodningen om opgaven og modtagerens accept af den opgave. Publikum her er ikke kun erhververen, er det alle: hele gruppen ser en offentlig bekræftelse af erhververen ekspertise, men budskabet gør det også klart, at erhververen er fri til at acceptere eller afvise ansvaret.

Opfølgning efter delegering

Når du beder nogen om at gøre noget, så husk at du har gjort det, og følge op med ham uanset hvad. De fleste anmodninger er lavet i offentlige fora, og de er stort set af formen «Kan du tage dig af X Lad os vide enten måde,? Noget problem, hvis du ikke kan, bare brug for at vide.» Du kan eller ikke kan få et svar. Hvis du gør det, og svaret er negativt, sløjfen er lukket-vil du nødt til at prøve nogle andre strategi for håndtering af X. Hvis der er et positivt svar, så hold øje for fremskridt i spørgsmålet og kommentere de fremskridt, du gør eller ikke se (alle arbejder bedre, når de kender en anden person værdsætte deres arbejde). Hvis der ikke er noget svar efter et par dage, så spørg igen, eller sende siger, at du fik noget svar og er på udkig efter en anden til at gøre det. Eller bare gøre det selv, men stadig sørge for at sige, at du fik noget svar på den oprindelige undersøgelse.

Formålet med offentligt at bemærke den manglende respons er ikke at ydmyge person, og Deres bemærkninger bør formuleres, så de ikke har denne virkning. Formålet er simpelthen at vise, at du holder styr på, hvad du har bedt om, og at du bemærker de reaktioner, du får. Dette gør folk mere tilbøjelige til at sige ja næste gang, fordi de vil observere (selv om det kun ubevidst), at du sandsynligvis vil mærke nogen arbejde, de udfører, da du lagde mærke til meget mindre synlige tilfælde af nogen ikke at reagere.

Læg mærke til, hvad folk er interesseret i

En anden ting, der gør folk glade, er at få deres interesser bemærket-i almindelighed, flere aspekter af en person personlighed du opdager og husk, jo mere tryg vil være, og jo mere han vil ønske at samarbejde med grupper, som du er en del .

For eksempel var der en skarp skelnen i Subversion projekt mellem folk, der ønskede at nå frem til en endelig 1,0 frigivelse (som vi gjorde til sidst), og folk der primært ønskede at tilføje nye funktioner og arbejder på interessante problemer, men hvem gjorde ikke meget pleje da 1,0 kom ud. Ingen af disse positioner er bedre eller dårligere end den anden, de er blot to forskellige slags udviklere, og begge former gøre masser af arbejde på projektet. Men vi hurtigt lært, at det var vigtigt ikke at antage, at spændingen ved 1,0-drev blev delt af alle. Elektroniske medier kan være meget misvisende: du kan fornemme en atmosfære af fælles formål, når det i virkeligheden er det kun deles af de personer, du tilfældigvis har talt med, mens andre har helt andre prioriteter.

Jo mere bevidst du er om, hvad folk vil have ud af projektet, jo mere effektivt du kan fremsætte anmodninger af dem. Selv bare demonstrerer en forståelse af, hvad de vil, uden at nogen tilknyttede anmodning, er nyttig, idet den bekræfter til hver person, at hun ikke er bare en anden partikel i en udifferentieret masse.

Ros og kritik

Ros og kritik er ikke modsætninger, på mange måder, er de meget ens. Begge er primært former for opmærksomhed, og er mest effektive, når specifikke snarere end generiske. Begge bør anvendes med konkrete mål for øje. Begge kan fortyndes med inflation: ros for meget eller for tit, og du vil devaluere din ros, det samme gælder for kritik, men i praksis, kritik er normalt reaktivt og derfor en smule mere modstandsdygtige over for devaluering.

Et vigtigt træk ved teknisk kultur er, at detaljeret, lidenskabsløse kritik tages ofte som en slags ros (som omtalt i afsnittet «erkender Uhøflighed» i kapitel 6, Communications), på grund af den implikation, at modtageren arbejde er værd at tiden forpligtet til at analysere det. Men begge disse betingelser, detaljeret og lidenskabsløs-skal være opfyldt for at dette kan være sandt. For eksempel, hvis nogen laver en sjusket ændring i koden det er nytteløst (og faktisk er skadeligt) for at følge op siger bare «Det var sjusket.» Sjusk er i sidste ende en egenskab ved en person, ikke af deres arbejde, og det er vigtigt at holde dine reaktioner fokuseret på arbejdet. Det er langt mere effektivt at beskrive alle de ting galt med den ændring, taktfuldt og uden ondskab. Hvis dette er den tredje eller fjerde skødesløs ændring i træk af den samme person, er det passende at sige, at-igen uden vrede-i slutningen af din kritik, for at gøre det klart, at mønsteret er blevet bemærket.

Hvis nogen ikke forbedres som reaktion på kritikken, at løsningen ikke er mere eller stærkere kritik. Løsningen er, at koncernen skal fjerne denne person fra stillingen af inkompetence, på en måde, der minimerer sårede følelser så meget som muligt, se afsnittet «Transitions» senere i dette kapitel for eksempler. Det er en sjælden begivenhed, dog. De fleste mennesker reagerer ganske godt på kritik, der er specifik, detaljeret og indeholder en klar (selvom uudtalt) forventning om forbedring.

Ros vil ikke såre nogens følelser, selvfølgelig, men det betyder ikke, det skal bruges noget mindre omhyggeligt end kritik. Ros er et værktøj: før du bruger det, så spørg dig selv, hvorfor du ønsker at bruge det. Som regel er det ikke en god ide at rose folk for at gøre hvad de normalt gør, eller for handlinger, der er en normal og forventet del af at deltage i gruppen. Hvis du skulle gøre det, ville det være svært at vide, hvornår de skal stoppe: skal du rose alle for at gøre de sædvanlige ting? Efter alt, hvis du forlader nogle mennesker ud vil de undre sig over hvorfor. Det er meget bedre til at udtrykke ros og taknemmelighed sparsomt, som reaktion på usædvanlige eller uventede indsats, med den hensigt at fremme flere af disse bestræbelser. Når en deltager synes at have flyttet permanent ind i en tilstand af højere produktivitet, justere din ros tærskel for den pågældende person i overensstemmelse hermed. Gentagen ros for normal adfærd gradvist bliver meningsløst alligevel. I stedet bør den pågældende person føle, at hendes højt produktivitetsniveau nu anses for normal og naturlig, og kun arbejde, der går ud over dette bør være specielt bemærket.

Dette er ikke til at sige, at personens bidrag ikke bør anerkendes, selvfølgelig. Men husk, at hvis projektet er sat rigtig op, alt det personen gør, er allerede synlig alligevel, og så gruppen vil vide (og personen vil vide, at resten af gruppen kender) alt, hvad hun gør. Der findes også måder at anerkende en andens arbejde ved andre midler end direkte ros. Du kunne nævne i forbifarten, mens der diskuteres et relateret emne, som hun har gjort et stort arbejde i et givet område og er bosat ekspert der, man kunne offentligt konsultere hende på nogle spørgsmål om koden, eller måske mest effektivt, kunne du iøjnefaldende gøre yderligere brug af det arbejde, hun har gjort, så hun ser at andre har det nu godt at stole på resultaterne af sit arbejde. Det er nok ikke nødvendigt at gøre disse ting på nogen beregnede måde. Nogen, der jævnligt gør store bidrag i et projekt vil vide det, og vil indtage en position af indflydelse som standard. Der er normalt ingen grund til at tage eksplicitte skridt til at sikre dette, medmindre du fornemmer, at en eller anden grund, en bidragyder er underappreciated.

Forhindre Geografisk område

Watch out for deltagere, der forsøger at udstikke eneret til visse områder af projektet, og som synes at ville gøre alt arbejdet i disse områder, i det omfang aggressivt overtager arbejdet, at andre begynder. En sådan adfærd kan endda virke sundt i første omgang. Efter alt, er det på overfladen ser ud som den person tager mere ansvar, og som viser øget aktivitet inden for et givet område. Men i det lange løb, er det ødelæggende. Når folk fornemmer en «Adgang forbudt» skilt, de holde sig væk. Dette resulterer i reduceret revision på dette område, og større skrøbelighed, fordi enlige udvikleren bliver et single point of failure. Hvad værre er, det frakturer kooperativet, egalitære ånd af projektet. Teorien bør altid være, at enhver udvikler er velkomne til at hjælpe på enhver opgave til enhver tid. Selvfølgelig tingene i praksis fungerer en smule anderledes: folk har områder, hvor de er mere og mindre indflydelsesrige, og ikke-eksperter ofte udskyde til eksperter i visse områder af projektet. Men det vigtigste er, at alt dette er frivillig: uformel myndighed gives baseret på kompetence og bevist dom, men det må aldrig aktivt taget. Selv hvis den person, som ønsker myndigheden virkelig er kompetent, er det stadig vigtigt, at hun holder denne myndighed uformelt gennem konsensus i gruppen, og at myndigheden ikke få hende til at udelukke andre fra at arbejde på dette område.

Afvise eller redigere en andens arbejde af tekniske årsager er en helt anden sag, selvfølgelig. Der er den afgørende faktor er indholdet af arbejdet, ikke som tilfældigvis fungere som gatekeeper. Det kan være, at den samme person tilfældigvis gøre det meste af revisionen for et givet område, men så længe han aldrig forsøger at forhindre andre i at gøre det arbejde også, tingene er sandsynligvis okay.

For at bekæmpe begyndende territorialism, eller endda udseendet af det, har mange projekter taget skridtet til at forbyde optagelse af forfatternavne eller udpegede vedligeholder navne i kildefiler. Jeg er helt enig med denne praksis: vi følger det i Subversion-projektet, og det er mere eller mindre officiel politik på Apache Software Foundation. ASF medlem Sander Striker udtrykker det på denne måde:

På Apache Software Foundation vi fraråder brug af forfatter tags i kildekoden. Der er forskellige årsager til dette, bortset fra de juridiske konsekvenser. Collaborative udvikling handler om at arbejde på projekter som en gruppe og omsorg for projektet som en gruppe. At give kredit er god, og der bør gøres, men på en måde, der ikke giver mulighed for falsk tildeling, endog indirekte. Der er ikke nogen klar linje for, hvornår at tilføje eller fjerne en forfatter tag. Vil du tilføje dit navn, når du ændrer en kommentar? Når du sætter en one-line fix? Vil du fjerner andre forfatter tags, når du refactor koden og det ser 95% anderledes? Hvad vil du gøre ved mennesker, der går om at røre hver fil, ændre bare nok til at gøre den virtuelle forfatter tag kvote, således at deres navn vil være overalt?

Der er bedre måder at give kredit, og vores præference er at bruge dem. Fra et teknisk synspunkt forfatter tags er unødvendig, hvis du ønsker at finde ud af, hvem skrev et bestemt stykke kode, kan den version kontrolsystem konsulteres for at finde ud af. Forfatter tags også en tendens til at komme ud af dato. Vil du virkelig ønsker at blive kontaktet i private omkring et stykke kode, du skrev for fem år siden og var glad for at have glemt?

En software projektets kildekodefiler er kernen i sin identitet. De bør afspejle det faktum, at udvikleren samfund som helhed er ansvarlig for dem, og ikke deles op i små kongeriger.

Folk undertiden går ind for forfatter eller reparatør tags i kildefiler den begrundelse, at dette giver synlig kredit til dem, der har gjort mest arbejde dér. Der er to problemer med denne argumentation. For det første har tags rejser uundgåeligt akavet spørgsmål om, hvor meget arbejde man skal gøre for at få sit eget navn opført der også. For det andet har de sammensmelte spørgsmålet om kredit med den for autoritet: Efter at have udført arbejde i fortiden ikke nødvendigvis ejerskab af det område, hvor arbejdet blev udført, men det er vanskeligt, hvis ikke umuligt at undgå en sådan konsekvens, når de enkelte navne er opført på toppe af kildefilerne. Under alle omstændigheder kan kredit oplysninger allerede fås fra versionsstyring logs og andre out-of-band mekanismer som postlistearkiver, er så ingen oplysninger går tabt ved at forbyde det fra kildefilerne selv. [25]

Hvis dit projekt beslutter at forbyde individuelle navne fra kildefiler, så sørg for ikke at gå overbord. For eksempel har mange projekter et contrib / område, hvor mindre værktøj og hjælper scripts holdes, ofte skrevet af folk, der ellers ikke er forbundet med projektet. Det er fint for disse filer til indeholder forfatternavne, fordi de ikke er virkelig opretholdes af projektet som helhed. På den anden side, at få, hvis en medvirkende værktøj starter hacket på af andre mennesker i projektet, i sidste ende kan du ønsker at flytte den til et mindre isolerede beliggenhed og under antagelse af den oprindelige forfatter godkender, skal du fjerne forfatterens navn, så koden ser som enhver anden der vedligeholdes ressource. Hvis forfatteren er følsom over dette, kompromisløsninger er acceptable, for eksempel:

# Indexclean.py: Fjern gamle data fra en Scanley indeks.
#
# Original Forfatter: K. Maru <kobayashi@yetanotheremailservice.com>
# Vedligeholdes nu af: The Scanley Project <http://www.scanley.org/>
# Og K. Maru.
#
# …

Men det er bedre at undgå sådanne kompromiser, hvis det er muligt, og de fleste forfattere er villige til at blive overtalt, fordi de er glade for, at deres bidrag bliver gjort en mere integreret del af projektet.

Det vigtigste er at huske, at der er en sammenhæng mellem kernen og periferien af ethvert projekt. De vigtigste kildekodefiler for softwaren er tydeligvis en del af kernen, og bør betragtes som vedligeholdes af fællesskabet. På den anden side kan følgesvend værktøjer eller stykker af dokumentation være det arbejde, de enkelte individer, der vedligeholder dem væsentlige alene, selv om de arbejder kan være forbundet med, og endda fordelt med, projektet. Der er ingen grund til at anvende en one-size-fits-all reglen til hver fil, så længe princippet om, at der vedligeholdes ressourcer ikke får lov til at blive individuelle områder opretholdes.

Den Automation Ratio

Prøv ikke at lade mennesker hvad maskiner kan gøre i stedet. Som en tommelfingerregel, er at automatisere en fælles opgave, en værdi af mindst ti gange den indsats en udvikler ville tilbringe gøre denne opgave manuelt én gang. For meget hyppige eller meget komplekse opgaver, kunne dette forhold nemt gå op til 20 eller endnu højere.

Tænker på dig selv som en «projektleder», snarere end blot en anden udvikler, kan være et nyttigt holdning her. Sommetider individuelle udviklere er også pakket ind i lav-niveau arbejde for at se det store billede og indse, at alle er spilder en stor indsats udfører automatiserbar opgaver manuelt. Selv dem, der indser det måske ikke tage sig tid til at løse problemet: fordi hver enkelt udførelse af opgaven ikke føler sig som en enorm byrde, ingen nogensinde bliver irriteret nok til at gøre noget ved det. Det, der gør automatisering overbevisende, at den lille belastning ganges det antal gange hver udvikler pådrager det, og så at antallet multipliceres med antallet af udviklere.

Her bruger jeg udtrykket «automation» bredt, ikke kun forstås gentagne handlinger, hvor en eller to variabler ændres, hver gang, men enhver form for teknisk infrastruktur, der hjælper mennesker. Den mindste standard automation kræves for at køre et projekt i disse dage blev beskrevet i kapitel 3, teknisk infrastruktur, men hvert projekt, kan have sine egne særlige problemer også. For eksempel kan en gruppe, der arbejder på dokumentation ønsker at have en hjemmeside der viser de mest up-to-date versioner af dokumenterne på alle tidspunkter. Da dokumentation ofte er skrevet i et kodesprog ligesom XML, kan der være en samling trin, ofte ganske indviklet, der er involveret i at skabe kan vises eller downloades dokumenter. Arrangere en hjemmeside, hvor en sådan opgørelse sker automatisk på hver commit kan være kompliceret og tidskrævende-men det er det værd, selv om det koster dig en dag eller mere til at sætte op. De overordnede fordele ved at have up-to-date sider til rådighed på alle tidspunkter er enorme, selvom omkostningerne ved ikke at have dem kan synes som kun en lille irritation over et enkelt øjeblik, til en enkelt bygherre.

Under sådanne skridt eliminerer ikke blot spildt tid, men det griping og frustration, som følger, når mennesker gør fejltrin (som de uundgåeligt vil) i forsøget på at udføre komplicerede procedurer manuelt. Multi-step, deterministiske operationer er præcis, hvad computere blev opfundet til, gemme dine mennesker til mere interessante ting.

Automatiseret test

Automatiserede testkørsler er nyttige for enhver software-projekt, men specielt for open source-projekter, fordi automatiseret test (især regressionstest) giver udviklere mulighed for at føle sig godt tilpas skiftende kode i områder, de ikke er bekendt med, og dermed fremmer sonderende udvikling. Da afsløre brud er så svært at gøre i hånden-one hovedsagelig har at gætte, hvor man kunne have brudt noget, og prøve forskellige eksperimenter for at bevise, at en didn’t-der automatiserede måder at opdage sådan brud gemmer projektet en masse tid. Det gør også folk meget mere afslappet omkring refactoring store skår af kode, og bidrager derfor til den software langsigtede vedligeholdelse.

Regression Test

Regression test betyder testning for genopblussen af allerede faste bugs. Formålet med regressionstest er at reducere chancerne for, at kodeændringer vil bryde softwaren på uventede måder. Som et software projekt bliver større og mere kompliceret, er chancerne for sådanne uventede bivirkninger stige støt. Godt design kan reducere den hastighed, hvormed det chancerne stigningen, men det kan ikke fjerne problemet helt.

Som et resultat heraf har mange projekter en test suite, et særskilt program, der påberåber projektets software på måder, der har været kendt i fortiden for at stimulere specifikke bugs. Hvis testen suite lykkes at gøre en af disse fejl sker, er dette kendt som en regression, hvilket betyder, at en eller andens forandring uventet ufikseret en tidligere fast bug.

Se også http://en.wikipedia.org/wiki/Regression_testing.

Regressionstest er ikke et universalmiddel. For én ting, virker det bedst for programmer med batch-stil grænseflader. Software, der drives primært via grafiske brugergrænseflader er meget sværere at køre programmeringsmæssigt. Et andet problem er, at regression test suite ramme i sig selv ofte kan være meget komplekse, med en indlæringskurve og vedligeholdelse byrde alle sine egne. Reduktion denne kompleksitet er en af de mest nyttige ting, du kan gøre, selvom det kan tage lang tid. Jo lettere det er at tilføje nye test til pakken, vil de flere udviklere gøre det, og jo færre fejl vil overleve at frigive. Enhver indsats brugt lave tests nemmere at skrive vil blive betalt tilbage mangfoldige over projektets levetid.

Mange projekter har en «Bryd ikke bygge!» regel, der betyder: ikke begå en ændring, som gør softwaren stand til at opstille eller løbe. Som den person, der brød build er normalt anledning til mild forlegenhed og ribkanter. Projekter med regression test suiter har ofte en naturlig følge reglen: ikke begå nogen ændring, der forårsager tests til at mislykkes. Sådanne fejl er lettest at få øje på, hvis der er automatiske natlige kørsler af hele test suite, med de resultater, sendt ud til udviklingen listen eller til en dedikeret test-resultater postliste, det er et andet eksempel på en god automation.

De fleste frivillige udviklere er villige til at tage den ekstra tid til at skrive regressionstest, når testsystemet er forståelig og let at arbejde med. Ledsagende ændringer med tests forstås at være den ansvarlige ting at gøre, og det er også en nem mulighed for samarbejde: ofte to udviklere vil opdele arbejdet for en bugfix, med en skrive ordne sig selv, og den anden skriftligt testen. Sidstnævnte udvikler kan ofte ende med mere arbejde, og siden skrive en test er allerede mindre tilfredsstillende end rent faktisk rette fejlen, er det bydende nødvendigt, at test suite ikke gøre oplevelsen mere smertefuldt end det skal være.

Nogle projekter går endnu videre og kræver, at en ny test ledsager alle bugfix eller ny funktion. Hvorvidt dette er en god idé eller ej, afhænger af mange faktorer: arten af den software, makeup af udviklingen team, og det er vanskeligt at skrive nye tests. CVS (http://www.cvshome.org/) projekt har længe haft en sådan regel. Det er en god politik i teorien, da CVS er version kontrol software og derfor meget risikosky om muligheden for munging eller forkert håndtering af brugerens data. Problemet i praksis er, at CVS s regression test suite er en enkelt enorm shell script (amusingly navngivne sanity.sh), svært at læse og svært at ændre eller udvide. Vanskeligheden ved at tilføje nye tests, kombineret med kravet om, at patches blive ledsaget af nye tests, betyder, at CVS reelt afholder patches. Da jeg plejede at arbejde på CVS, jeg nogle gange så folk starte på og endda gennemføre en patch til CVS egen kode, men give op, når fortalte om kravet om at tilføje en ny test til sanity.sh.

Det er normalt at bruge mere tid på at skrive en ny regression test end på at fastsætte det oprindelige bug. Men CVS gennemførte dette fænomen til en ekstrem: man kunne bruge timer på at forsøge at designe en test ordentligt, og stadig få det galt, fordi der er bare alt for mange uforudsigelige komplekse involveret i at ændre en 35.000-line Bourne shell script. Selv mangeårige CVS udviklere ofte brokkede når de skulle tilføje en ny test.

Denne situation skyldtes en fejl på alle vores dele til at overveje automatisering ratio. Det er rigtigt, at et skift til en reel test rammer, uanset om specialbyggede eller off-the-shelf-ville have været en stor indsats. [26] Men forsømme at gøre det har kostet projektet meget mere, i årenes løb. Hvor mange fejlrettelser og nye funktioner er ikke i CVS i dag, på grund af hindring af en akavet test suite? Vi kan ikke kende det nøjagtige antal, men det er helt sikkert mange gange større end antallet af fejlrettelser eller nye funktioner udviklerne kan give afkald på for at udvikle et nyt testsystem (eller integrere en off-the-shelf system). Denne opgave vil kun tage en endelig mængde tid, mens straffen for at bruge den aktuelle test suite vil fortsætte for evigt, hvis der ikke gøres noget.

Pointen er ikke at have strenge krav til at skrive test er dårlig, eller at skrive dit testsystem som et Bourne shell script er nødvendigvis dårligt. Det kan fungere fint, afhængigt af hvordan du designe det, og hvad den har brug for at teste. Pointen er blot, at når testsystemet bliver en væsentlig hindring for udvikling, der skal ske noget. Det samme gælder for ethvert rutinemæssig proces, der bliver til en barriere eller en flaskehals.

Behandl Hver bruger som en potentiel frivillig

Hver interaktion med en bruger er en mulighed for at få en ny frivillig. Når en bruger tager sig tid til at skrive til en af projektets postlister, eller at indsende en fejlrapport, har han allerede taggede sig selv som havende mere potentiale for involvering end de fleste brugere (fra hvem projektet vil aldrig høre på alle). Følg op på dette potentiale: hvis han beskrev en bug, takke ham for betænkningen og spørge ham, om han vil forsøge at løse det. Hvis han skrev at sige, at et vigtigt spørgsmål manglede i FAQ, eller at programmets dokumentation var mangelfuld eller anden måde, så frit anerkende problemet (forudsat det virkelig eksisterer) og spørge, om han er interesseret i at skrive det manglende materiale selv. Naturligvis meste af tiden vil brugeren kny. Men det behøver ikke koste meget at bede, og hver gang du gør det, det minder de andre lyttere i dette forum, at få involveret i projektet, er noget alle kan gøre.

Må ikke begrænse dine mål at erhverve nye udviklere og dokumentation forfattere. For eksempel betaler selv uddanne folk til at skrive gode fejlrapporter fra i det lange løb, hvis du ikke bruger for meget tid per person, og hvis de går på at forelægge flere fejlrapporter i fremtiden, som de er mere tilbøjelige til at gøre, hvis de fik en konstruktiv reaktion på deres første rapport. En konstruktiv reaktion behøver ikke være en rettelse til fejlen, selvom det er altid den ideelle, og det kan også være en opfordring til mere information, eller bare en bekræftelse af, at adfærden er en fejl. Folk ønsker at blive lyttet til. Sekundært de vil have deres bugs fast. Du kan ikke altid være i stand til at give dem det sidste i tide, men du (eller rettere, at projektet som helhed) kan give dem den førstnævnte.

En naturlig følge heraf er, at udviklere bør ikke udtrykke vrede på folk, der indgiver velmente, men vag fejlrapporter. Dette er en af mine personlige kæledyr peeves, jeg ser udviklerne gør det hele tiden på diverse open source postlister, og den skade, det gør, er håndgribelig. Nogle ulykkelige newbie vil sende en ubrugelig rapport:

Hej, jeg kan ikke få Scanley til at køre. Hver gang jeg starter det op, det bare fejl. Er der nogen ellers ser dette problem?

Nogle udvikler-, der har set denne type rapport tusind gange, og har ikke holdt op med at tro, at newbie har ikke-vil reagere på denne måde:

Hvad skal vi gøre med så lidt information? Sheesh. Giv os i det mindste nogle detaljer, ligesom den version af Scanley, dit operativsystem, og fejlen.

Denne udvikleren har undladt at se tingene fra brugerens synspunkt, og undlod ligeledes at undersøge effekten sådan reaktion kan få på alle de andre mennesker ser børsen. Naturligvis en bruger, der ikke har nogen erfaring med programmering, og ingen forudgående erfaring rapportering af fejl, vil ikke vide, hvordan man skriver en fejlrapport. Hvad er den rigtige måde at håndtere en sådan person? Uddan dem! Og gør det på en sådan måde, at de kommer tilbage efter mere:

Undskyld du har problemer. Vi har brug for flere oplysninger for at finde ud af hvad der sker her. Fortæl os hvilken version af Scanley, dit operativsystem, og den nøjagtige ordlyd af fejlen. Den allerbedste ting du kan gøre er at sende en udskrift der viser de nøjagtige kommandoer, du løb, og den produktion, de producerede. Se http://www.scanley.org/how_to_report_a_bug.html for mere.

Denne måde at reagere er langt mere effektiv til at ekstrahere den nødvendige information fra brugeren, da den er skrevet til brugerens synspunkt. For det første udtrykker sympati: Du havde et problem, og vi føler din smerte. (Dette er ikke nødvendigt i alle fejlrapport svar, det afhænger af sværhedsgraden af problemet, og hvordan forstyrre brugeren syntes.) For det andet, i stedet for selvglad hende for ikke at vide, hvordan at rapportere en fejl, det fortæller hende, hvordan og i nok detalje at være faktisk nyttigt for eksempel, at mange brugere ikke klar over, at «vise os fejlen» betyder «vise os den nøjagtige ordlyd af fejlen, uden udeladelser eller Abridgements.» Første gang du arbejder med sådan en bruger, skal du være specifik omkring det. Endelig, det giver en pegepind til langt mere detaljerede og fuldstændige vejledning i fejlrapportering. Hvis du med succes har beskæftiget med brugeren, vil hun ofte tage sig tid til at læse dette dokument og gøre, hvad den siger. Det betyder selvfølgelig, at man skal have det dokument, forberedt på forhånd. Det bør give klare instrukser om, hvad slags oplysninger din udvikling team ønsker at se i hver fejlrapport. Ideelt set bør det også udvikle sig med tiden som svar på de særlige former for udeladelser og misreports brugere har tendens til at gøre for dit projekt.

The Subversion projektets fejlrapporteringsinstruktioner er en temmelig standard eksempel på formen (se bilag D, eksempel vejledning i fejlrapportering). Bemærk, hvordan de lukker med en opfordring til at give en patch til rette fejlen. Det er ikke fordi en sådan invitation vil føre til en større patch / rapport ratio-de fleste brugere, der er i stand til at rette fejl allerede ved, at en patch ville være velkommen, og behøver ikke at blive fortalt. Invitationen egentlige formål er at understrege over for alle læsere, især de nye til projektet eller nye til fri software generelt, at projektet kører på frivillige bidrag. I en vis forstand er projektets nuværende udviklere ikke mere ansvarlig for at rette fejlen end er den person, der meldte den. Dette er en vigtig pointe, at mange nye brugere ikke vil være bekendt med. Når de indser det, de er mere tilbøjelige til at hjælpe med at gøre den rettelse ske, hvis ikke ved at bidrage kode så ved at give en mere grundig gengivelse opskrift, eller ved at tilbyde at teste rettelser, som andre mennesker post. Målet er at gøre alle brugere indse, at der ikke er nogen medfødt forskel mellem sig selv og de mennesker, der arbejder på projektet, at det er et spørgsmål om hvor meget tid og kræfter man lægger i, ikke et spørgsmål om, hvem man er.

Den formaning mod at reagere vredt gælder ikke for uhøflige brugere. Lejlighedsvis folk sende fejlrapporter eller klager, at uanset deres informative indhold, viser en spottende foragt på projektet for nogle fejl. Ofte er sådanne mennesker er skiftevis fornærmende og smigrende, som den person, der indsendt dette til en Subversion mailing liste:

Hvorfor er det, at efter næsten 6 dage der stadig ikke er nogen binære filer posteret til Windows-platformen?!? Det er den samme historie hver gang, og det er temmelig frustrerende. Hvorfor ikke disse ting automatiseret, så de kunne være til rådighed straks? Når du sender en «RC» bygge, jeg tror, at idéen er, at du ønsker, at brugerne til at teste build, men alligevel giver ikke nogen måde at gøre det. Hvorfor selv har en sættetid periode, hvis du giver ingen mulighed for test?

Første reaktion på dette temmelig provokerende indlæg blev overraskende behersket: folk påpegede, at projektet havde en offentliggjort politik om ikke at give officielle binære filer, og sagde, med varierende grader af irritation, at han burde melde sig frivilligt til at producere dem selv, hvis de var så vigtige ham. Tro det eller ej, hans næste indlæg startede med disse linjer:

Først og fremmest, lad mig sige, at jeg synes Subversion er awesome og jeg virkelig sætter pris på den indsats, som alle involverede. [...]

… Og så gik han på at skælde projektet igen for ikke at give binaries, mens stadig ikke frivilligt at gøre noget ved det. Efter dette, bare omkring 50 mennesker sprang over ham, og jeg kan ikke sige jeg virkelig minded. Den «nul-tolerance»-politik over for uhøflighed anbefalet i afsnittet «Nip Uhøflighed i Bud» i kapitel 2, Introduktion gælder for personer, som projektet har (eller gerne vil have) et vedvarende samspil. Men når nogen gør det klart fra starten, at han kommer til at være et springvand af galde, er der ingen mening at gøre ham til at føle sig velkommen.

Sådanne situationer er heldigvis ret sjældne, og de er mærkbart sjældnere i projekter, der gør en indsats for at inddrage brugerne konstruktivt og høfligt fra deres allerførste interaktion.

Del styringsopgaver samt teknisk opgaver

Del den administrative byrde samt den tekniske byrde ved at drive projektet. Som et projekt bliver mere kompleks, mere og mere af arbejdet handler om at styre mennesker og informationsstrømmen. Der er ingen grund til ikke at dele denne byrde, og dele det kræver ikke nødvendigvis en top-down hierarki enten-hvad der sker i praksis er en tendens til at være mere af en peer-to-peer-netværk topologi end en militær-stil kommandostruktur.

Sommetider lederstillinger formaliseres, og nogle gange det sker spontant. I Subversion-projektet, har vi en patch manager, en oversættelse manager, dokumentation ledere, udstede ledere (omend uofficiel), og en release manager. Nogle af disse roller vi gjort en bevidst beslutning om at indlede, andre lige er sket af sig selv, efterhånden som projektet vokser, jeg forventer flere roller, der skal tilføjes. Nedenfor vil vi undersøge disse roller, og et par andre, i detaljer (bortset fra udslip manager, som allerede var dækket i afsnittet kaldet «Release manager» og afsnittet «Diktatur af Release Owner» tidligere i dette kapitel).

Som du læser rollebeskrivelser, bemærke, at ingen af dem kræver eksklusiv kontrol over det pågældende domæne. Spørgsmålet manager ikke forhindre andre mennesker i at foretage ændringer i forhold databasen, betyder FAQ lederen ikke insisterer på at være den eneste person at redigere FAQ, og så videre. Disse roller er alle omkring ansvar uden monopol. En vigtig del af hvert domæne jobbet som manager er at lægge mærke til, når andre mennesker der arbejder i dette domæne, og uddanne dem til at gøre de ting, den måde leder gør, således at de mange bestræbelser styrker frem for konflikt. Domæne ledere skal også dokumentere de processer, hvorved de gør deres arbejde, så når man forlader, en anden kan afhente slap med det samme.

Nogle gange er der en konflikt: to eller flere mennesker ønsker den samme rolle. Der er ingen rigtige måde at håndtere dette. Du kan foreslå, at hver frivillig sende et forslag (en «ansøgning»), og har alle de committere afstemning om hvilken der er bedst. Men det er besværligt og potentielt akavet. Jeg synes, at en bedre teknik er bare at spørge de mange kandidater at bilægge dem indbyrdes. De vil normalt, og vil være mere tilfredse med det resultat, end hvis en beslutning var blevet pålagt udefra.

Patch manager

I et frit software-projekt, som modtager en masse patches, holde styr på, hvilke patches er ankommet, og hvad der er blevet besluttet om dem kan være et mareridt, især hvis det sker på en decentraliseret måde. De fleste patches kommer som stillinger til projektets udvikling mailing liste (selvom nogle kan forekomme først i issue tracker, eller på eksterne websteder), og der er en række forskellige ruter en patch kan tage efter ankomsten.

Sommetider nogen gennemgår patch, finder problemer, og bounces den tilbage til den oprindelige forfatter til oprydning. Dette fører som regel til en iterativ proces-alle synlige på postlisten-in, som den oprindelige forfatter stillinger reviderede udgaver af plasteret indtil korrekturlæseren har ikke mere at kritisere. Det er ikke altid let at fortælle, når denne proces er færdig: hvis korrekturlæseren begår patch, så klart er færdig. Men hvis hun ikke gør det, kan det være fordi hun simpelthen ikke har tid, eller ikke har begå adgang selv og kunne ikke reb nogen af de andre udviklere til at gøre det.

En anden hyppig reaktion på en patch er en fritløbende diskussion, ikke nødvendigvis om selve programrettelsen, men om, hvorvidt konceptet bag plasteret er god. For eksempel kan plasteret rette en fejl, men projektet foretrækker at fastsætte denne fejl på en anden måde, som en del af at løse en mere generel klasse af problemer. Ofte er dette ikke er kendt på forhånd, og det er plasteret, der stimulerer den opdagelse.

Lejlighedsvis, er en udstationeret plaster mødt med dyb tavshed. Normalt er dette grundet ingen udvikleren har tid på det tidspunkt at gennemgå patch, så hver håber, at en anden vil gøre det. Da der ikke er nogen bestemt grænse for, hvor længe hver person venter på en anden til at samle bolden op, og imens andre prioriteringer er altid kommer op, det er meget let for en patch til at glide gennem revner uden nogen enkelt person, der agter for at det skal ske. Projektet måske glip af en nyttig patch på denne måde, og der er andre skadelige bivirkninger så godt: det er nedslående til forfatteren, der har investeret arbejde i plasteret, og det gør projektet som helhed ser lidt ude af trit , især til andre betragtning skrivning patches.

Patchen Lederens opgave er at sørge for, at patches ikke «glide gennem revner.» Dette gøres ved at følge hver patch igennem til en form for stabil tilstand. Patchen Manager ure hver postliste tråd, at resultaterne fra et plaster udstationering. Hvis det ender i en commit af plasteret, han gør ikke noget. Hvis det går ind i en gennemgang / revision iteration, slutter med en endelig version af plasteret, men ingen commit, han indgiver et spørgsmål peger på den endelige version, og til postlisten tråd omkring det, så der er en permanent rekord for udviklere at følge op på senere. Hvis patch løser et eksisterende problem, han annotates dette spørgsmål med de relevante oplysninger, i stedet for at åbne et nyt emne.

Når et plaster får ingen reaktion overhovedet, patch lederen venter et par dage, derefter følger op spørger, om nogen kommer til at gennemgå det. Denne regel får en reaktion: en udvikler kan forklare, at hun ikke mener, at Plasteret skal påføres, og hvilke grunde, eller hun kan gennemgå det, i hvilket tilfælde en af de tidligere beskrevne veje er taget. Hvis der stadig ikke er noget svar, kan plasteret manager eller måske ikke indgive et problem for plasteret, efter eget valg, men i det mindste den oprindelige indsender fik nogle reaktion.

Efter at have en patch manager har sparet Subversion udviklingsteam en masse tid og mental energi. Uden en udpeget person til at tage ansvar, ville alle udviklere konstant skal bekymre sig «Hvis jeg ikke har tid til at reagere på denne patch lige nu, kan jeg regne med en anden gør det? Skal jeg prøve at holde øje med det? Men hvis andre mennesker også holder øje med det, af de samme grunde, så ville vi have unødvendigt dobbeltarbejde indsats. » Plasteret leder fjerner den anden gætte fra situationen. Hver bygherren kan træffe den beslutning, der er det rigtige for hende i det øjeblik hun først ser plasteret. Hvis hun ønsker at følge op med en anmeldelse, kan hun gøre det-patch manager vil tilpasse sin adfærd herefter. Hvis hun ønsker at ignorere plasteret helt, det er også fint, at plasteret manager vil sørge for det er ikke glemt.

Fordi dette system fungerer kun, hvis folk kan afhænge af plasteret lederen være der uden at fejle, bør den rolle holdes formelt. I Subversion, reklameres vi for det om udvikling og brugernes postlister, fik flere frivillige, og tog den første, der svarede. Når denne person måtte træde ned (se afsnittet «Transitions» senere i dette kapitel), gjorde vi det samme igen. Vi har aldrig prøvet at have flere mennesker deler rollen, på grund af den kommunikation, overhead, ville være påkrævet mellem dem, men måske ved meget høje mængder af patch indsendelse, kan en multiheaded patch leder giver mening.

Translation Manager

I software-projekter, kan «oversættelse» refererer til to meget forskellige ting. Det kan betyde at oversætte softwarens dokumentation til andre sprog, eller det kan betyde at oversætte selve softwaren, der er, har programmet vise fejl og hjælpe meddelelser i brugerens foretrukne sprog. Begge er komplekse opgaver, men når den rette infrastruktur er på plads, er de i høj grad adskilles fra andre udvikling. Fordi opgaverne er ens på nogle måder, kan det give mening (afhængig af dit projekt) at have en enkelt oversættelse leder håndtere både, eller det kan være bedre at have to forskellige ledere.

I Subversion-projektet, har vi en oversættelse leder håndtere både. Han faktisk ikke skrive oversættelser selv, selvfølgelig, han kan hjælpe på en eller to, men da dette skrives, ville han nødt til at tale ti sprog (tolv tælle dialekter) med henblik på at arbejde på dem alle! I stedet han formår hold af frivillige oversættere: han hjælper dem koordinerer blandt hinanden, og han koordinerer mellem holdene og resten af projektet.

En del af grunden til, at oversættelsen manager er nødvendig, er, at oversættere er en anden demografisk fra udviklere. De undertiden har lidt eller ingen erfaring med at arbejde i en version kontrol repository, eller endog med at arbejde som en del af et distribueret frivillig hold overhovedet. Men i andre henseender er de ofte den bedste form for frivilligt: folk med specifik domæneviden der så et behov og valgte at blive involveret. De er som regel villige til at lære, og entusiastiske at komme på arbejde. Alt de behøver er nogen til at fortælle dem hvordan. Oversættelsen Manager sørger for, at oversættelserne ske på en måde, der ikke forstyrrer unødigt med almindelig udvikling. Han fungerer også som en slags repræsentant for de oversættere som et samlet organ, når udviklerne skal informeres om tekniske ændringer, der er nødvendige for at støtte oversættelse indsats.

Således positionen vigtigste færdigheder er diplomatisk, ikke teknisk. For eksempel har vi i Subversion har en politik, at alle oversættelser bør have mindst to mennesker, der arbejder på dem, for ellers er der ingen måde for tekst, der skal revideres. Når en ny volontør dukker op tilbyder at oversætte Subversion til f.eks madagaskisk, oversættelsen manager har enten hook ham op med en person, der har offentliggjort for seks måneder siden udtrykte interesse i at gøre en madagaskisk oversættelse, ellers høfligt bede den frivillige til at gå finde en anden Madagaskars oversætter til at arbejde med som partner. Når tilstrækkeligt mange mennesker er til rådighed, manager sætter dem op med den rette form for commit adgang, oplyser dem om projektets konventioner (såsom hvordan man skriver logmeddelelser), og derefter holder øje at sikre, at de overholder disse konventioner.

Samtaler mellem oversættelsen manager og udviklerne, eller mellem oversættelse manager og oversættelse teams, afholdes normalt i projektets oprindelige sprog, det vil sige, det sprog, hvorfra alle oversættelser bliver lavet. For de fleste fri software-projekter, er det engelsk, men det er ligegyldigt, hvad det er, så længe projektet enige om det. (Engelsk er nok bedst til projekter, der ønsker at tiltrække en bred international udvikling samfund, selv om.)

Samtaler inden for en bestemt oversættelse hold normalt ske på deres fælles sprog, dog, og en af de andre opgaver oversættelsen manager er at oprette en dedikeret mailingliste for hvert hold. På den måde oversættere kan diskutere deres arbejde frit, uden at distrahere folk på projektets vigtigste lister, ville de fleste af dem ikke være i stand til at forstå oversættelsen sproget alligevel.

Internationalisering Versus Localization

Internationalisering (i18n) og lokalisering (l10n) henviser begge til processen med at tilpasse et program til at arbejde i de sproglige og kulturelle miljøer, bortset fra det, som det oprindeligt blev skrevet. Udtrykkene er ofte behandlet som indbyrdes udskiftelige, men i virkeligheden er de ikke helt det samme. Som http://en.wikipedia.org/wiki/G11n skriver:

Sondringen mellem dem er subtil, men vigtig: Internationalisering er en tilpasning af produkter til potentiel brug praktisk talt overalt, mens lokalisering er tilføjelsen af særlige funktioner til brug i en specifik lokalitet.

For eksempel er at ændre din software til tabsfrit håndtere Unicode (http://en.wikipedia.org/wiki/Unicode) tekst kodninger en internationalisering flytte, da det ikke handler om et bestemt sprog, men snarere om at acceptere tekst fra enhver af et antal af sprog. På den anden side, gør dit software udskrive alle fejlmeddelelser i slovensk, når det registrerer, at det kører i en slovensk miljø, er en lokalisering træk.

Således oversættelsen lederens opgave er først og fremmest om lokalisering, ikke internationalisering.

Documentation Manager

Holde software dokumentation up-to-date er en uendelig opgave. Hver ny funktion eller ekstraudstyr, der går ind i koden har potentiale til at forårsage en ændring i dokumentationen. Også, når projektets dokumentation når et vist niveau af fuldstændighed, vil du opdage, at en masse af de patches folk sender i er for dokumentationen, ikke for at få koden. Dette er fordi der er mange flere mennesker er kompetente til at rette fejl i prosa end i kode: alle brugere er læsere, men kun få er programmører.

Dokumentation patches er normalt meget lettere at gennemgå og anvende end kode patches. Der er ringe eller ingen test, der skal udføres, og kvaliteten af ændringen kan vurderes hurtigt blot ved gennemgang. Da mængden er høj, men den fornyede byrde forholdsvis lav, forholdet mellem administrative overhead til produktivt arbejde er større for dokumentation patches end for kode patches. Desuden vil de fleste af patches sandsynligvis brug for en form for tilpasning, for at opretholde en konsekvent autorial stemme i dokumentationen. I mange tilfælde vil patches overlapper eller påvirke andre patches, og skal justeres i forhold til hinanden, før at blive begået.

Da det af hensyn til håndtering af dokumentation patches, og det faktum, at kodebase bør konstant overvåges, så dokumentationen kan holdes up-to-date, giver det mening at have en person, eller et lille team, dedikeret til opgaven. De kan registrere præcis hvor og hvordan dokumentationen halter bagefter software, og de kan have øvet procedurer for håndtering af store mængder af patches på en integreret måde.

Selvfølgelig betyder det ikke, at andre mennesker i projektet fra at anvende dokumentation patches på flue, især små, som tiden tillader det. Og det samme patch manager (se afsnittet «Patch Manager» tidligere i dette kapitel) kan spore både kode og dokumentation patches, arkivering dem hvor udvikling og dokumentation teams vil have dem, hhv. (Hvis den samlede mængde af patches nogensinde overstiger et menneskes evne til at spore, selv om, at skifte til adskille patch ledere for kode og dokumentation er formentlig et godt første skridt.) Spidsen af en dokumentation team er at få folk, der tænker på sig selv som ansvarlig for at opbevare dokumenterne organiseret, up-to-date, og i overensstemmelse med sig selv. I praksis betyder dette at kende dokumentation intimt, ser kodebase, ser de ændringer andre forpligte sig på den dokumentation, ser for indgående dokumentation patches, og ved hjælp af alle disse informationskilder til at gøre, hvad der er nødvendigt for at holde dokumentation sund.

Udstedelse manager

Antallet af spørgsmål i et projekts bug tracker vokser i forhold til antallet af mennesker, der bruger softwaren. Derfor, selv når du rette fejl og sende en stadig robust program, skal du stadig forventer, at antallet af åbne spørgsmål til at vokse væsentligt uden bundet. Hyppigheden af dobbelte spørgsmål vil også stige, som vil hyppigheden af ufuldstændige eller dårligt beskrevet spørgsmål.

Issue ledere bidrage til at afhjælpe disse problemer ved at se, hvad der går ind i databasen, og periodisk fejer gennem det på udkig efter specifikke problemer. Deres mest almindelige handling er nok at rette op indgående spørgsmål, enten fordi reporter ikke sat nogle af formularfelterne korrekt, eller fordi emnet er en kopi af et, der allerede i databasen. Det er klart, den mere velkendte et problem manager er med projektets fejldatabase, hun jo mere effektivt vil være i stand til at opdage dublerede spørgsmål-dette er en af de vigtigste fordele ved at have et par folk specialiserer sig i fejldatabase, i stedet for alle forsøger at gør det ad hoc. Når gruppen forsøger at gøre det på en decentralt, ingen enkeltperson får en dyb ekspertise i indholdet af databasen.

Issue ledere kan også hjælpe kort mellem spørgsmål og individuelle udviklere. Når der er en masse af fejlrapporter kommer ind, kan ikke alle udviklere læser spørgsmålet anmeldelsen mailingliste med samme opmærksomhed. Men hvis nogen, der kender udviklingen holdet holder øje med alle indgående spørgsmål, så hun kan diskret dirigere visse udviklere opmærksomhed på specifikke bugs når det er hensigtsmæssigt. Selvfølgelig skal dette gøres med en følsomhed over for alt andet foregår i udvikling, og til modtagerens ønsker og temperament. Derfor er det ofte bedst for udstede ledere til at være udviklere selv.

Afhængigt af hvordan dit projekt bruger issue tracker, kan udstede ledere også forme databasen til at afspejle projektets prioriteter. For eksempel har vi i Subversion planlægge problemstillinger i specifikke fremtidige udgivelser, så når nogen spørger: «Hvornår vil bug X blive fastsat?» vi kan sige «To udgivelser fra nu,» selv om vi ikke kan give en præcis dato. De udledninger er repræsenteret i issue tracker som mål milepæle, et område til rådighed i IssueZilla. [27] Som regel har hver Subversion release en større ny funktion og en liste over specifikke fejlrettelser. Vi tildeler passende mål milepæl for alle de spørgsmål der er planlagt for denne frigivelse (herunder den nye feature-det får et problem også), så folk kan se fejldatabase gennem linsen af release planlægning. Disse mål sjældent forbliver statiske, dog. Som nye bugs kommer ind, prioriteringer undertiden blive flyttet rundt, og spørgsmål skal flyttes fra den ene milepæl til en anden, således at hver udgivelse forbliver overskueligt. Dette fører igen til, gøres bedst ved folk, der har en generel følelse af, hvad der er i databasen, og hvordan forskellige spørgsmål relaterer sig til hinanden.

En anden ting udstede ledere gør, er varsel, når problemer bliver forældede. Nogle gange kan en fejl er rettet ved et uheld som en del af en ikke-relateret ændring i softwaren, eller undertiden projektet ændrer sin mening om, hvorvidt en bestemt adfærd er buggy. Finde forældede spørgsmål er ikke let: Den eneste måde at gøre det systematisk er ved at lave en feje hen over alle de emner i databasen. Fuld sweeps bliver mindre og mindre realistisk med tiden, men da antallet af problemer vokser. Efter et vist punkt, er den eneste måde at holde databasen SANE at bruge en del-og-hersk strategi: kategorisere spørgsmål straks ved ankomsten og lede dem i den rigtige udviklerens eller holdets opmærksomhed. Modtageren derefter tager ansvaret for sagen er for resten af dens levetid, shepherding det til opløsning eller glemsel efter behov. Når databasen er, at store, at spørgsmålet leder bliver mere af en overordnet koordinator, bruger mindre tid på at kigge på hvert spørgsmål selv og mere tid på at få det ind i den rette persons hænder.

FAQ manager

FAQ vedligeholdelse er en overraskende vanskeligt problem. I modsætning til de fleste andre dokumenter i et projekt, hvis indhold er planlagt på forhånd af forfatterne, er en FAQ et helt reaktiv dokument (se Opretholdelse af en FAQ). Ligegyldigt hvor stor den bliver, har du stadig aldrig vide, hvad det næste vil desuden være. Og fordi det altid sættes til stykkevis, er det meget let for dokumentet som helhed bliver usammenhængende og uorganiseret, og endog indeholder dublerede eller semi-dobbelte poster. Selv når det ikke har nogen åbenlyse problemer som disse, der ofte ubemærket samspil mellem poster-links, der bør gøres, men aren’t-fordi de relaterede poster blev et år fra hinanden.

Den rolle, som en FAQ leder er dobbelt. Først, hun fastholder den overordnede kvalitet af FAQ ved opholder sig bekendt med i det mindste de emner af alle spørgsmålene i det, så når folk tilføje nye elementer, der er dubletter af, eller relateret til, eksisterende elementer kan de passende justeringer . For det andet, hun ser projektets postlister og andre fora for tilbagevendende problemer eller spørgsmål, og til at skrive nye FAQ poster baseret på denne indgang. Sidstnævnte opgave kan være ganske kompliceret: man skal være i stand til at følge en tråd, anerkende de centrale spørgsmål i det, sende et forslag FAQ post, optage kommentarer fra andre (da det er umuligt for FAQ manager til at være ekspert i hvert emne omfattet af FAQ), og mening, når processen er færdig, så varen kan omsider blive tilføjet.

Det FAQ Lederen normalt også bliver standard ekspert i FAQ formatering. Der er en masse små detaljer, der er involveret i at holde en FAQ i form (se afsnittet «Behandl alle ressourcer som arkiver» i kapitel 6, kommunikation), når tilfældige mennesker redigere FAQ, vil de sommetider glemmer nogle af disse detaljer. Det er okay, så længe FAQ manager er der for at rydde op efter dem.

Forskellige gratis software er tilgængelig til at hjælpe med processen med FAQ vedligeholdelse. Det er fint at bruge det, så længe det ikke kompromitterer kvaliteten af FAQ, men pas på over-automation. Nogle projekter forsøger at fuldt ud at automatisere processen med FAQ vedligeholdelse, så alle kan bidrage og redigere FAQ elementer på en måde svarende til en wiki (se afsnittet «Wikis» i kapitel 3, teknisk infrastruktur). Jeg har set det ske især med Faq-O-Matic (http://faqomatic.sourceforge.net/), selvom det kan være, at de sager, jeg så, var simpelthen misbrug, der gik ud over, hvad Faq-O-Matic var oprindeligt tænkt for. Under alle omstændigheder, mens fuldstændig decentralisering af FAQ vedligeholdelse ikke reducere arbejdsbyrden for projektet det resulterer også i en dårligere FAQ. Der er ingen én person med en bred udsigt over hele FAQ, ingen at bemærke, når visse elementer skal opdateres eller forældes helt, og ingen holder vagt for samspil mellem poster. Resultatet er en FAQ, der ofte undlader at give brugerne det, de ledte efter, og i de værste tilfælde vildleder dem. Brug de redskaber, du har brug for at vedligeholde dit projekts FAQ, men aldrig lade den bekvemmelighed af værktøjerne forføre dig ind i det går ud over kvaliteten af FAQ.

Se Sean Michael Kerner ‘artikel, The stillede spørgsmål om ofte stillede spørgsmål, ved http://osdir.com/Article1722.phtml, for beskrivelser og vurderinger af open source FAQ vedligeholdelsesværktøjer.

Overgange

Fra tid til anden, vil en frivillig i en position løbende ansvar (f.eks patch manager, oversættelse manager, etc.) bliver i stand til at udføre de opgaver af positionen. Det kan være, fordi jobbet viste sig at være mere arbejde, end han forventede, eller det kan skyldes helt eksterne faktorer: Ægteskab, en ny baby, en ny arbejdsgiver, eller hvad.

Når en frivillig bliver overdænget sådan, han normalt ikke mærke til det med det samme. Det sker ved langsomme grader, og der er ingen punkt, hvor han bevidst indser, at han ikke længere kan opfylde de pligter, som rollen. I stedet for resten af projektet bare ikke høre meget fra ham et stykke tid. Så vil der pludselig være en hektisk aktivitet, da han føler sig skyldig for at negligere projektet så længe og afsætter en nat til at fange op. Så vil du ikke høre fra ham et stykke tid længere, og så er der måske eller måske ikke være en anden byge. Men der er sjældent en uopfordret formel resignation. Den frivillige gjorde jobbet i sin fritid, så afgående ville betyde åbent at erkende sig selv, at hans fritid permanent reduceres. Folk er ofte tilbageholdende med at gøre det.

Derfor er det op til dig og de andre i projektet at lægge mærke til, hvad der sker-eller rettere ikke sker-og bede den frivillige, hvad der foregår. Undersøgelsen skal være venlig og 100% skyld-fri. Dit formål er at finde ud af et stykke information, ikke at gøre den person føler sig dårligt. Generelt bør undersøgelsen være synligt for resten af projektet, men hvis du kender nogle særlige grunde til, at en privat undersøgelse ville være bedre, det er også fint. Den vigtigste grund til at gøre det offentligt, er således, at hvis den frivillige reagerer ved at sige, at han ikke vil være i stand til at gøre arbejdet mere, er der en sammenhæng etableret for din næste offentlig post: en anmodning om en ny frivillig til at udfylde denne rolle.

Nogle gange, en frivillig ikke er i stand til at gøre det job, han har taget på, men er enten uvidende eller uvillige til at indrømme, at kendsgerning. Selvfølgelig kan enhver have problemer i starten, især hvis ansvaret er kompleks. Men hvis nogen bare ikke fungerer ud i den opgave, han har påtaget sig, selv efter alle andre har givet al den hjælp og forslag, de kan, så den eneste løsning er for ham at træde til side og lade en ny have en prøve. Og hvis personen ikke se dette selv, vil han nødt til at blive fortalt. Der er dybest set kun én måde at håndtere dette, tror jeg, men det er en flertrinsproces og hvert trin er vigtigt.

Først skal du sikre at du ikke er sindssyg. Privat tale med andre i projektet for at se, om de er enige om, at problemet er så alvorligt som du tror det er. Selv hvis du allerede er positive, det tjener det formål at lade andre vide, at du overvejer at spørge personen til at træde til side. Normalt ingen vil modsætte sig, at-De bare være glad du tager på akavet opgave, så de ikke behøver at!

Dernæst privat kontakte frivillig i spørgsmål og fortælle ham, venligt, men direkte, om de problemer, du ser. Vær specifik, giver så mange eksempler som muligt. Sørg for at påpege, hvordan folk havde forsøgt at hjælpe, men at der fortsat var problemer uden at forbedre. Du skal forvente denne e-mail til at tage lang tid at skrive, men med denne slags meddelelse, hvis du ikke bakke op, hvad du siger, bør du ikke sige det overhovedet. Sig, at du gerne vil finde en ny frivillig til at udfylde rollen, men også påpege, at der er mange andre måder at bidrage til projektet. På dette stadium, ikke sige, at du har talt med andre om det, ingen kan lide at vide, at folk konspirerede bag hans ryg.

Der er et par forskellige måder ting kan gå efter det. Den mest sandsynlige reaktion er, at han er enig med dig, eller i hvert fald ikke ønsker at argumentere, og være villig til at træde tilbage. I så fald tyder på, at han gør annonceringen selv, og så kan du følge op med en stilling søger en udskiftning.

Eller kan han enig i, at der har været problemer, men beder om lidt mere tid (eller for en chance til, i tilfælde af diskret-task roller som release manager). Hvordan du reagerer på det er en vurderingssag, men uanset hvad du gør, ikke accepterer, at det bare fordi du føler at du ikke kan afslå en sådan rimelig anmodning. Det ville forlænge smerten, ikke mindske den. Der er ofte en meget god grund til at afvise anmodningen, nemlig, at der allerede har været masser af chancer, og det er, hvordan tingene kom til hvor de er nu. Her er hvordan jeg sætte det i en mail til en person, der var fyldte udgivelsesansvarlige rolle, men var ikke rigtig egnet til det:

> Hvis du ønsker at erstatte mig med nogle et andet, vil jeg yndefuldt
> Videregive den rolle, hvem der kommer næste. Jeg har en anmodning, som
> Jeg håber er ikke urimeligt. Jeg vil gerne forsøge endnu en
> Udgivelse i et forsøg på at bevise mig selv.

Jeg er helt forstå ønsket (været der selv!), Men i
dette tilfælde bør vi ikke gøre det «One more try» ting.

Dette er ikke den første eller anden udgivelse, det er den sjette eller
7:e … Og for alle dem, ved jeg, du har været utilfredse
med resultaterne for (fordi vi har talt om det før). Så
vi har faktisk allerede været nede one-more-prøve ruten.
Til sidst, en af de prøver skal være den sidste … Jeg tror
[Denne sidste udgivelse] bør være det.
I værste fald kan den frivillige uenige direkte. Så er du nødt til at acceptere, at tingene kommer til at være akavet og pløje videre alligevel. Nu er det tid til at sige, at du talte med andre mennesker om det (men stadig ikke sige, hvem, indtil du har deres tilladelse, da disse samtaler var fortroligt), og at du ikke tror, det er godt for projektet til at fortsætte som ting er. Vær vedholdende, men aldrig truende. Husk, at med de fleste roller, overgangen virkelig sker det øjeblik, nogen ny begynder at gøre jobbet, ikke det tidspunkt den gamle person holder op med at gøre det. For eksempel, på noget tidspunkt, hvis påstanden er over den rolle, siger, issue manager, du og andre indflydelsesrige personer i projektet kan hverve for en ny emission manager. Det er faktisk ikke nødvendigt, at den person, der tidligere var at gøre det stoppe med at gøre det, så længe han ikke sabotere (bevidst eller ubevidst) bestræbelser på den nye frivillige.

Hvilket fører til en fristende tanke: i stedet for at bede personen om at træde tilbage, hvorfor ikke bare indramme det som et spørgsmål om at få ham nogle hjælpe? Hvorfor ikke bare have to udstede ledere, eller patch ledere, eller uanset hvilken rolle er?

Selv om det kan lyde godt i teorien, er det generelt ikke en god idé. Hvad gør lederroller arbejds-hvad der gør dem anvendelige i virkeligheden-er deres centralisering. De ting, der kan gøres på en decentraliseret måde er normalt allerede bliver gjort på den måde. Har to mennesker udfylde en lederrolle introducerer kommunikation hovedhøjde mellem disse to personer, samt mulighederne for glat forskydning af ansvar («Jeg troede, du bragte den førstehjælpskasse» «Mig? Nej, jeg troede, du bragte den førstehjælpskasse ! «). Selvfølgelig er der undtagelser. Sommetider to mennesker arbejder meget godt sammen, eller karakteren af den rolle er sådan, at det nemt kan spredes på tværs af flere mennesker. Men det er ikke sandsynligt, at være til megen nytte, når du ser nogen flailing i en rolle, han er ikke egnet til. Hvis han havde værdsat problemet i første omgang, ville han have søgt sådan hjælp før nu. Under alle omstændigheder ville det være respektløst at lade nogen spilde tid fortsætter med at gøre et job ingen vil være opmærksom på.

Den vigtigste faktor i at spørge nogen til at træde tilbage, er privatlivets fred: at give ham plads til at tage en beslutning uden at føle sig som andre ser og venter. Jeg har engang lavet den fejl-en åbenlys fejl, set i bakspejlet, for at sende alle tre parter på én gang for at spørge Subversion udgivelse manager til at træde til side til fordel for to andre frivillige. Jeg havde allerede talt med de to nye folk privat, og vidste, at de var villige til at påtage sig ansvaret. Så jeg tænkte, naivt og noget ufølsomt, at jeg ville spare lidt tid og besvær ved at sende en mail til dem alle til at indlede overgangen. Jeg antog, at den nuværende release manager var allerede fuldt ud klar over de problemer og ville se det rimelige i min pointe med det samme.

Jeg tog fejl. Den aktuelle udgivelse manager var meget fornærmet, og med rette. Det er én ting at blive bedt om at aflevere opgaven, det er en anden ting at blive spurgt, at foran de mennesker, du vil give det ud til. Når jeg fik det gennem mit hoved, hvorfor han blev fornærmet, jeg undskyldte. Han til sidst gjorde træde tilbage yndefuldt, og fortsætter med at være involveret i projektet i dag. Men hans følelser blev såret, og overflødigt at sige, det var ikke den mest lovende af begyndelser til de nye frivillige enten.

Committere

Som det eneste formelt forskellig klasse af mennesker findes i alle open source-projekter, fortjener committere særlig opmærksomhed her. Committere er en uundgåelig indrømmelse til diskrimination i et system, der ellers er så ikke-diskriminerende som muligt. Men «diskrimination» er ikke ment som en nedsættende her. De funktionelle committere udføre, er fuldstændig nødvendigt, og jeg tror ikke, at et projekt kan lykkes uden den. Kvalitetskontrol kræver godt, kontrol. Der er altid mange mennesker, der føler sig kompetente til at foretage ændringer til et program, og nogle mindre antal, der faktisk er. Projektet kan ikke påberåbe sig folks egen dømmekraft, det skal indføre standarder og give afsætter kun adgang til dem, der møder dem [28]. På den anden side,. Der folk, der kan begå ændringer direkte arbejder side om side med folk der ikke kan sætter op en indlysende effekt dynamisk Denne dynamik skal forvaltes således, at det ikke skader projektet.

I afsnittet der hedder «Hvem stemmer?» I kapitel 4, sociale og politiske infrastruktur, vi allerede diskuteret mekanikken i at overveje nye committere. Her vil vi se på de standarder, som potentielle nye committere skal bedømmes, og hvordan denne proces bør præsenteres for de større samfund.

Valg committere

I Subversion-projektet, vælger vi committere primært på den hippokratiske Princip: For det første, gør ingen skade. Vores vigtigste kriterium er ikke teknisk dygtighed eller endda kendskab til koden, men blot, at committer viser god dømmekraft. Dom kan betyde blot at vide hvad man ikke skal tage på. En person kan skrive kun små lapper, fastsættelse forholdsvis simple problemer i koden, men hvis de patches gælder rent, ikke indeholder fejl, og er for det meste i overensstemmelse med projektets logmeddelelsen og kodning konventioner, og der er nok patches til at vise et klart mønster, så en eksisterende committer vil normalt foreslå, at person for commit adgang. Hvis mindst tre personer siger ja, og ingen objekter, så tilbuddet afgives. True, kan vi ikke have nogen beviser for, at personen er i stand til at løse komplekse problemer på alle områder af kodebase, men det gør ikke noget: den pågældende har gjort det klart, at han er i stand til i det mindste at dømme sine egne evner. Tekniske færdigheder kan læres (og undervist), men dom, for de flestes vedkommende, ikke kan. Derfor er det én ting, du vil være sikker på en person har, før du giver ham begå adgang.

Når en ny committer forslaget dog fremprovokere en diskussion, er det normalt ikke om teknisk kunnen, men snarere om en persons adfærd på postlisterne eller i IRC. Sommetider nogen viser tekniske færdigheder og en evne til at arbejde inden for projektets formelle retningslinjer, men er også konsekvent krigerisk eller usamarbejdsvillig i offentlige fora. Det er en alvorlig bekymring; hvis personen ikke synes at forme op over tid, selv som reaktion på hints, så vil vi ikke tilføje ham som en committer uanset hvor dygtig han er. I en frivillig gruppe, sociale færdigheder, eller evnen til at «spille godt i sandkassen», er lige så vigtige som rå teknisk kunnen. Fordi alt er under versionskontrol, straffen for at tilføje en committer du bør ikke have er ikke så meget de problemer, det kunne forårsage i koden (revurdering ville spotte dem hurtigt alligevel), men at det i sidste ende kan tvinge projektet til at tilbagekalde persons commit adgang-en handling, der er aldrig rart, og kan nogle gange være konfronterende.

Mange projekter insistere på, at den potentielle committer demonstrere et vist niveau af teknisk ekspertise og vedholdenhed, ved at indsende nogle flere nontrivial patches det vil sige, ikke kun disse projekter ønsker at vide, at personen vil gøre nogen skade, de ønsker at vide, at hun er sandsynligt, at gøre godt på tværs af kodebase. Det er fint, men pas på, at det ikke begynder at vende committership til et spørgsmål om medlemskab i en eksklusiv klub. Spørgsmålet til at holde i alles sind bør være «Hvad vil bringe de bedste resultater for koden?» ikke «Vil vi devaluere den sociale status er forbundet med committership ved at indrømme denne person?» Pointen med commit adgang er ikke at styrke folks selvværd, det er at give gode ændringer for at indtaste koden med et minimum af ballade. Hvis du har 100 committere, hvoraf 10 foretage store ændringer på en regelmæssig basis, og de øvrige 90 af dem bare fastsætte slåfejl og små bugs et par gange om året, det er stadig bedre end kun at have de 10.

Tilbagekaldelse Commit Access

Den første ting at sige om tilbagekaldelse commit adgang er: prøv ikke at være i denne situation i første omgang. Afhængigt hvis adgangen bliver tilbagekaldt, og hvorfor kan drøftelserne omkring et sådant søgsmål være meget splittende. Selv når der ikke splittende, vil de være en tidskrævende distraktion fra produktivt arbejde.

Men hvis du skal gøre det, skal diskussionen tages privat blandt de samme mennesker, der ville være i stand til at stemme for at give den pågældende person uanset smag af commit adgang, de har i øjeblikket. Den person selv skal ikke medtages. Dette er i modstrid den sædvanlige forbud mod hemmeligholdelse, men i dette tilfælde er det nødvendigt. Først ville ingen være i stand til at tale frit andet. For det andet, hvis bevægelsen lykkes, behøver du ikke nødvendigvis ønsker den person til at vide det var nogensinde overvejet, fordi det kunne åbne op spørgsmål («Hvem var på min side? Hvem var imod mig?»), Der fører til den værste slags fraktionalisme. I visse sjældne tilfælde kan gruppen ønsker nogen at vide, at tilbagekaldelse af commit adgang er eller har været under overvejelse, som en advarsel, men denne åbenhed bør være en beslutning i gruppen gør. Ingen bør nogensinde, på eget initiativ, afsløre oplysninger fra en diskussion og afstemning, der antages andre var hemmelige.

Når en persons adgang tilbagekaldes, at faktum er uundgåeligt offentligheden (se afsnittet «Undgå Mystery» senere i dette kapitel), så prøv at være så taktfuld som du kan i hvordan det præsenteres for omverdenen.

Delvis Commit Access

Nogle projekter tilbyder gradueringer af commit adgang. For eksempel kan der være bidragydere, som commit adgang giver dem frie tøjler i dokumentationen, men som ikke forpligte sig til selve koden. Fælles områder for delvis commit adgang vedlægge dokumentation, oversættelser, bindende kode til andre programmeringssprog, specifikation filer til emballeringsbrug (fx RedHat RPM spec-filer, osv.), og andre steder, hvor en fejl vil ikke medføre et problem for kerne-projektet .

Da commit adgang handler ikke kun om at begå, men om at være en del af et vælgerkorps (se afsnittet «Hvem Stemmer» i kapitel 4, sociale og politiske Infrastructure), er spørgsmålet naturligvis opstår: hvad kan de partielle committere stemme om? Der er ingen rigtige svar, det afhænger af, hvad slags delvise begå domæner dit projekt har. I Subversion har vi holdt tingene forholdsvis enkel: en delvis committer kan stemme om spørgsmål begrænset udelukkende til at committer domæne, og ikke på noget andet. Vigtigt er det, vi har en mekanisme til støbning rådgivende stemmer (væsentlige den committer skriver «+0″ eller «+1 (ikke-bindende)» i stedet for bare «+1″ på stemmesedlen). Der er ingen grund til at lukke munden på folk helt bare fordi deres stemme er ikke formelt bindende.

Fuld committere kan stemme på noget, bare fordi de kan begå overalt, og kun hele committere stemme om at tilføje nye committere af nogen art. I praksis dog er muligheden for at tilføje nye delvise committere normalt uddelegeret: enhver fuld committer kan «sponsorere» en ny delvis committer, og delvise committere i et domæne kan ofte væsentligt vælge nye committere for det samme domæne (dette er specielt nyttigt i fremsætter en oversættelsesarbejde kører problemfrit).

Dit projekt kan have brug for en lidt anderledes arrangement, afhængigt af arbejdets art, men de samme generelle principper gælder for alle projekter. Hver committer skal kunne stemme om spørgsmål, der hører ind under hendes commit adgang og ikke om spørgsmål uden for dette, og afstemninger om procedurespørgsmål spørgsmål burde som standard de fulde committere, medmindre der er en eller anden grund (som besluttet af de fulde committere) at udvide vælgerne.

Med hensyn til håndhævelsen af delvis commit adgang: det er ofte bedst ikke at have den version kontrolsystem håndhæve partielle begå domæner, selv om det kan. Se afsnittet «Authorization» i kapitel 3, teknisk infrastruktur til hvorfor.

Inaktive committere

Nogle projekter automatisk fjerne folks commit adgang, hvis de går en vis tid (fx et år) uden at begå noget. Jeg tror, det er normalt lidet formålstjenligt og endda kontraproduktivt, af to grunde.

For det første kan det friste nogle mennesker til at begå acceptable, men unødvendige ændringer, bare for at forhindre deres commit adgang fra udløber. For det andet betyder det ikke rigtig noget formål. Hvis det vigtigste kriterium for at begå adgang er god dømmekraft, så hvorfor antager en dom ville blive forværret, bare fordi han er væk fra projektet i et stykke tid? Selv hvis han helt forsvinder i årevis, uden at se på koden eller efter udviklingssamtaler, da han dukker op igen, han vil vide, hvordan ude af trit han er, og handle i overensstemmelse hermed. Du betroede sin dom før, så hvorfor ikke tillid til det altid? Hvis high school-eksamensbeviser ikke udløbe, så begå adgang sikkert burde ikke.

Nogle gange kan en committer kan bede om at blive fjernet, eller til at blive eksplicit markeret som hvilende på listen over committere (se afsnittet «Undgå Mystery» nedenfor for mere om denne liste). I disse tilfælde bør projektet tiltræde persons ønsker, selvfølgelig.

Undgå Mystery

Selv om de drøftelser omkring tilføje en bestemt ny committer skal være fortrolig, de regler og procedurer selv behøver ikke at være hemmelig. Faktisk er det bedst at udgive dem, så folk indser, at committere ikke er nogle mystiske stjerne Afdeling, lukket for almindelige dødelige, men at alle kan deltage blot ved udstationering gode patches og vide, hvordan man håndterer sig selv i samfundet. I Subversion-projektet, satte vi denne information til højre i bygherren retningslinjer dokument, da folk mest tilbøjelige til at være interesseret i, hvordan commit der gives adgang, er de tænker på at bidrage kode til projektet.

Ud over at offentliggøre de procedurer, offentliggør den aktuelle liste over committere. Det traditionelle sted for dette er en fil, der hedder vedligeholdere eller committere i det øverste niveau af projektets kildekode træ. Det bør opregne alle de fulde committere først, efterfulgt af de forskellige partielle begå domæner og medlemmerne af hvert domæne. Hver person skal opføres ved navn og e-mail-adresse, men adressen kan kodes for at forhindre spam (se afsnittet «Address gemmer sig i arkiverne» i kapitel 3, teknisk infrastruktur) hvis den person foretrækker det.

Da sondringen mellem fuld commit og delvis commit adgang er indlysende og veldefineret, det er passende for listen for at gøre denne sondring også. Ud over dette, bør listen ikke forsøge at angive de uformelle sondringer, der uundgåeligt opstår i et projekt, som der er særligt indflydelsesrige og hvordan. Det er en offentlig registrering, ikke en kvitteringer fil. Liste committere enten i alfabetisk rækkefølge, eller i den rækkefølge, som de ankom.

Credit

Kredit er den primære valuta for den gratis software verden. Uanset folk kan sige om deres motivation for at deltage i et projekt, jeg ikke kender nogen udviklere, der ville være glade for at gøre alle deres arbejde anonymt eller under en andens navn. Der er håndgribelige grunde til dette: ens omdømme i et projekt groft regulerer, hvor meget indflydelse, man har, og deltagelse i et open source-projekt kan også indirekte have en monetær værdi, fordi nogle arbejdsgivere ser nu for det på genoptages. Der er også uhåndgribelige grunde, måske endda mere kraftfuld: folk blot ønsker at blive værdsat, og instinktivt kigge efter tegn på, at deres arbejde blev anerkendt af andre. Løftet om kredit er derfor en af de bedste motivatorer projektet har. Når små bidrag er anerkendt, folk kommer tilbage til at gøre mere.

Et af de vigtigste træk ved kollaborativ udvikling software (se kapitel 3, teknisk infrastruktur) er, at det holder nøjagtige optegnelser af, hvem der gjorde hvad, hvornår. Hvor det er muligt, skal du bruge de eksisterende mekanismer til at sikre, at kredit er fordelt præcist, og være specifik om arten af bidraget. Må ikke bare skrive «Tak til J. Random <jrandom@example.com>» hvis du i stedet kan skrive «Tak til J. Random <jrandom@example.com> for fejlrapporten og reproduktion opskrift» i en log besked.

I Subversion, har vi en uformel, men konsekvent politik kreditering reporteren af en fejl i hverken spørgsmålet indgivet, hvis der er en, eller log budskab commit det løser fejlen, hvis ikke. En hurtig undersøgelse af Subversion commit logs op til at begå nummer 14.525 viser, at omkring 10% af forpligter give kredit til en person ved navn og e-mail adresse, som regel den person, der rapporterede eller analyseret fejlen er fastsat i denne commit. Bemærk, at denne person er forskellig fra den udvikler, der faktisk gjort commit, hvis navn allerede er registreret automatisk af version control system. Af de 80-ulige fulde og delvise committere Subversion har i dag, blev 55 krediteret i COMMIT logfiler (normalt flere gange), før de blev committere selv. Det betyder ikke, selvfølgelig bevise, at blive krediteret var en faktor i deres fortsatte engagement, men i det mindste etablerer en atmosfære, hvor folk ved, at de kan regne med deres bidrag bliver anerkendt.

Det er vigtigt at skelne mellem rutinemæssig anerkendelse og særlig tak. Når vi diskuterer et bestemt stykke kode, eller nogle andre bidrag nogen, det er fint at anerkende deres arbejde. For eksempel siger «Daniels seneste ændringer i delta-koden betyder, at vi nu kan gennemføre funktion X» samtidigt hjælper folk identificere, hvilke ændringer du taler om og anerkender Daniels arbejde. På den anden side tjener udstationering udelukkende takke Daniel for delta kodeændringer ingen umiddelbare praktiske formål. Det tilføjer ikke nogen oplysninger, da den version kontrolsystem og andre mekanismer, der allerede har indspillet det faktum, at han lavede ændringerne. Takke alle for alt ville være distraherende og i sidste ende information-fri, da tak er effektive i høj grad af, hvor meget de skiller sig ud fra standard, baggrund niveau af positiv kommentar foregår hele tiden. Dette betyder ikke, selvfølgelig, at du bør aldrig takke folk. Bare sørg for at gøre det på måder, der har tendens til ikke at føre til kredit inflation. Efter disse retningslinjer vil hjælpe:

Jo mere flygtig forummet, jo mere fri du skal føle at udtrykke tak dér. For eksempel er takke nogen for deres bugfix i forbifarten under en IRC samtale fint, som det er en sidebemærkning i en e-mail i hovedsagen rettet mod andre emner. Men du behøver ikke skrive en email til kun at takke nogen, medmindre det er for en virkelig usædvanlig bedrift. Ligeledes ikke fylder projektets websider med udtryk for taknemmelighed. Når du starter det, vil det aldrig være klart, hvornår eller hvor de skal stoppe. Og aldrig sat tak til kommentarer i koden, det ville kun være en distraktion fra det primære formål med bemærkninger, som er at hjælpe læseren til at forstå koden.

Jo mindre involveret nogen er i projektet, jo mere relevant er det at takke hende for noget, hun gjorde. Det lyder måske ulogisk, men det passer med den holdning, at udtrykke tak er noget man gør, når nogen bidrager endnu mere, end du troede, hun ville. Således konstant at takke regelmæssige bidragydere til at gøre hvad de normalt ville være at udtrykke en lavere forventning om dem, end de har af sig selv. Hvis der er noget, du ønsker at sigte efter den modsatte effekt!

Der er lejlighedsvis undtagelser fra denne regel. Det er acceptabelt at takke nogen for at opfylde sit forventede rolle, når denne rolle indebærer midlertidige, intense bestræbelser fra tid til anden. Den kanoniske eksempel er udgivelsen manager, der går i højt gear omkring tidspunktet for hver udgivelse, men ellers ligger i dvale (sovende som en release manager, i hvert fald, han kan også være en aktiv udvikler, men det er en anden sag).

Som med kritik og kreditering, bør taknemmelighed være specifik. Tak ikke folk bare for at være stor, selv om de er. Tak dem for noget, de gjorde, var ud over det sædvanlige, og for bonuspoint, præcis hvorfor, hvad de gjorde, var så stor sige.

Generelt er der altid en spænding mellem at sikre, at folks individuelle bidrag indregnes, og sikrer, at projektet er en gruppe indsats snarere end en samling af individuelle herligheder. Bare være opmærksom på denne spænding og forsøge at fejle på siden af gruppen, og tingene vil ikke komme ud af hånden.

Forks

I afsnittet der hedder «Forkability» i kapitel 4, sociale og politiske infrastruktur, så vi, hvordan potentialet til bord har vigtige konsekvenser for, hvordan projekterne er underlagt. Men hvad sker der, når en gaffel faktisk finder sted? Hvordan skal du håndtere det, og hvad effekter kan du forvente, at det have? Omvendt bør når du starter en gaffel?

Svarene afhænger af hvilken type gaffel det er. Nogle gafler skyldes venskabelige men uforenelige uenighed om ledelsen af projektet, måske mere skyldes både tekniske uenigheder og interpersonelle konflikter. Selvfølgelig er det ikke altid muligt at se forskel mellem de to, da de tekniske argumenter kan involvere personlige elementer. Hvad alle gafler har til fælles, er, at en gruppe af udviklere (eller nogle gange bare en developer) har besluttet, at omkostningerne ved at arbejde med nogle af eller alle de andre nu opvejer fordelene.

Når et projekt gafler, er der ingen endeligt svar på spørgsmålet om, hvilken gaffel er den «sande» eller «original»-projektet. Folk vil i daglig tale taler om gaffel F kommer ud af projektet P, som om P fortsætter uændret ned nogle natursti mens F divergerer ind på nyt territorium, men dette er i realiteten en erklæring om, hvordan den pågældende observatør føler om det. Det er grundlæggende et spørgsmål om opfattelsen: når en tilstrækkelig stor andel af observatører er enige, påstanden begynder at blive sandt. Det er ikke sådan, at der er en objektiv sandhed fra starten, som vi er kun ufuldkomment i stand til at opfatte i første omgang. Snarere opfattelser er den objektive sandhed, da i sidste ende et projekt-eller en gaffel-er en enhed, der kun eksisterer i folks bevidsthed alligevel.

Hvis der har indledt gaffel føler, at de er spiring en ny gren ud for den vigtigste projekt er opfattelsen spørgsmål løses straks og nemt. Alle, både udviklere og brugere, vil behandle gaflen som et nyt projekt, med et nyt navn (måske baseret på det gamle navn, men let at skelne fra det), en særskilt hjemmeside, og en separat filosofi eller mål. Tingene bliver Messier, men når begge parter føler, at de er legitime vogtere af det oprindelige projekt, og derfor har ret til at fortsætte med at bruge det oprindelige navn. Hvis der er nogle organisation med varemærkerettigheder til navnet, eller den juridiske kontrol over domænet eller websider, der normalt løser problemet ved fiat: denne organisation vil afgøre, hvem der er i projektet, og hvem er gaflen, fordi det holder alle kortene i en public relations krig. Naturligvis tingene sjældent når så langt: da alle allerede ved, hvad de kraftdynamik er, vil de undgå kæmper en kamp, hvis udfald er kendt på forhånd, og bare springe direkte til det sidste.

Heldigvis, i de fleste tilfælde er der ikke meget tvivl om, hvilken er projektet, og som er gaflen, fordi en gaffel er i det væsentlige en tillidserklæring. Hvis mere end halvdelen af udviklerne går ind for den linie gaflen agter at træffe, normalt er der ingen grund til bord-projektet kan simpelthen gå den vej selv, medmindre den køres som et diktatur med en særlig stædig diktator. På den anden side, hvis færre end halvdelen af udviklerne er for gaflen er et klart mindretal oprør, og både høflighed og sund fornuft viser, at det burde tænke på sig selv som den divergerende gren snarere end den vigtigste linie.

Håndtering af en Fork

Hvis nogen truer en gaffel i dit projekt, bevare roen og huske dine langsigtede mål. Den blotte eksistens af en gaffel er ikke, hvad gør ondt et projekt, men snarere, det er tabet af udviklere og brugere. Deres virkelige mål er derfor ikke at squelch gaflen, men at minimere disse skadelige virkninger. Du kan være gal, kan du føle, at gaflen var uretfærdig og malplaceret, men udtrykker, at offentligt kun kan fremmedgøre ubeslutsomme udviklere. I stedet må du ikke tvinge folk til at gøre eksklusive valg, og være så samarbejdsvillig som praktisk med gaflen. Til at begynde med, må du ikke fjerne nogens commit adgang i dit projekt, bare fordi han har besluttet at arbejde på gaflen. Arbejdet på gaflen betyder ikke, at personen har pludselig mistet sin kompetence til at arbejde på det oprindelige projekt, committere før bør forblive committere bagefter. Derudover bør du udtrykke dit ønske om at forblive så kompatibelt som muligt med gaflen, og sige, at du håber udviklere vil portere ændringer mellem de to, når det er relevant. Hvis du har administrativ adgang til projektets servere, offentligt tilbyde forkers infrastrukturen hjælp ved start tidspunkt. For eksempel tilbyder dem en komplet, dyb-historie kopi af versionsstyring repository, hvis der ikke er anden måde for dem at få det, så de ikke behøver at starte uden historiske data (dette kan ikke være nødvendige afhængigt af den version kontrol system). Spørg dem, hvis der er noget andet, de har brug for, og give det, hvis du kan. Bøje bagud for at vise, at du ikke står i vejen, og at du ønsker gaflen til at lykkes eller mislykkes på sine egne præmisser og intet andet.

Grunden til at gøre alt dette, og gøre det offentligt, er ikke til rent faktisk at hjælpe gaflen, men at overbevise udviklerne, at din side er en sikker satsning, ved at optræde som ikke-hævngerrig som muligt. I krig er det somme tider giver mening (strategisk sans, hvis ikke den menneskelige forstand) for at tvinge folk til at vælge side, men i fri software er det næsten aldrig gør. Faktisk nogle udviklere efter en gaffel ofte åbent arbejde på begge projekter, og gøre deres bedste for at holde de to kompatible. Disse udviklere hjælper med at holde kommunikationslinjerne åbne efter gaflen. De giver dit projekt at drage fordel af interessante nye funktioner i gaflen (ja, kan gaflen have ting, du ønsker), og også øge chancerne for en fusion ned af vejen.

Nogle gange kan en gaffel bliver så vellykket, at selv om det blev betragtet selv af sine egne ophavsmænd som en gaffel i starten, bliver det den version alle foretrækker, og i sidste ende træder i stedet for oprindelige by popular demand. En berømt eksempel på dette var GCC / egcs gaffel. GNU Compiler Collection (GCC, tidligere GNU C Compiler) er den mest populære open source native-kode compiler, og også en af de mest bærbare compilers i verden. På grund af uenighed mellem GCC officielle vedligeholdere og Cygnus Software, [29] en af GCC mest aktive udviklingsgrupper, Cygnus skabt en gaffel af GCC kaldet egcs. Gaflen var bevidst ikke-konfrontatorisk: De egcs udviklerne ikke på noget tidspunkt, så prøv at skildre deres version af GCC som en ny officiel version. I stedet koncentrerede de sig om at gøre egcs så godt som muligt, med patches i et hurtigere tempo end de officielle GCC vedligeholdere. Egcs vundet i popularitet, og i sidste ende nogle store operativsystemer distributører besluttede at pakke egcs som deres standard compiler i stedet for GCC. På dette tidspunkt blev det klart for GCC vedligeholdere at holde på den «GCC» navn, mens alle skiftede til egcs gaffel ville byrde alle med en unødvendig navneændring, men ikke gør noget for at forhindre overgangen. Så GCC vedtog egcs kodebase, og der er igen en enkelt GCC, men i høj grad forbedret på grund af gaflen.

Dette eksempel viser, hvorfor du ikke kan altid betragte en gaffel som en unadulteratedly dårlig ting. En gaffel kan være smertefuld og uvelkomne på det tidspunkt, men du kan ikke nødvendigvis vide, om det vil lykkes. Derfor bør du og resten af projektet holde øje med det, og være parat til ikke blot at absorbere funktioner og kode, hvor det er muligt, men i det mest ekstreme tilfælde til selv tilslutte gaflen hvis det opnår hovedparten af projektets Mindshare. Selvfølgelig, vil du ofte være i stand til at forudsige en gaffel s sandsynlighed for succes ved at se der slutter det. Hvis gaflen er startet af projektets største complainer og følgeskab af en håndfuld utilfredse udviklere, der ikke opfører sig konstruktivt alligevel, har de hovedsagelig løst et problem for dig ved forking, og du sandsynligvis ikke behøver at bekymre sig om gaflen tager momentum væk fra det oprindelige projekt. Men hvis du ser indflydelsesrige og respekterede udviklere støtter gaffel, bør du spørge dig selv hvorfor. Måske blev projektet at være alt for restriktiv, og den bedste løsning er at vedtage i det ordinære project nogle eller alle af de aktioner, der påtænkes af gaflen-i det væsentlige at undgå gaflen ved at blive det.

Starte en Fork

Alle råd her forudsætter, at du forking som en sidste udvej. Udtømme alle andre muligheder, før du starter en gaffel. Forking betyder næsten altid at miste udviklere, med kun et usikkert løfte om at få nye senere. Det betyder også, at starte ud med konkurrence om brugernes opmærksomhed: alle, der er ved at downloade softwaren må spørge sig selv: «Hmm, jeg ønsker at den ene eller den anden?» Uanset hvilken en du er, at situationen er rodet, fordi et spørgsmål er blevet indført, som ikke var der før. Nogle mennesker hævder, at gaflerne er sundt for software-økosystem som helhed ved en standard naturlig udvælgelse argument: the fittest vil overleve, hvilket betyder, at i sidste ende, at alle får bedre software. Dette kan være sandt fra økosystemets synspunkt, men det er ikke sandt fra det synspunkt af ethvert individuelt projekt. De fleste gafler ikke lykkes, og de fleste projekter er ikke glad for at blive kløvet.

En konsekvens er, at du ikke skal bruge truslen om en gaffel som en ekstremist diskuterer teknik-»Gør tingene min måde eller jeg gaffel projektet!»-Fordi alle er klar over, at en gaffel, der undlader at tiltrække udviklere væk fra den oprindelige Projektet er usandsynligt at overleve længe. Alle observatører-ikke bare udviklere, men brugere og operativsystem aftappere også-vil gøre deres egen dømmekraft om, hvilken side til at vælge. Du bør derfor være yderst tilbageholdende med at gaffel, så hvis du endelig gør det, kan du troværdig hævde det var den eneste venstre rute.

Må ikke forsømme at tage alle faktorer i betragtning ved bedømmelsen af den potentielle succes for din gaffel. For eksempel, hvis mange af de udviklere på et projekt har samme arbejdsgiver så selv om de er utilfredse og privat til fordel for en gaffel, er det usandsynligt at sige så højt, hvis de ved, at deres arbejdsgiver er imod det. Mange gratis software programmører gerne tro, at have en gratis licens på koden betyder ingen virksomhed kan dominere udviklingen. Det er rigtigt, at licensen er i en ultimativ forstand, en garant for frihed, hvis andre ønsker dårligt nok til bord projektet, og har ressourcer til at gøre det, de kan. Men i praksis er nogle projekternes udviklingsteams meste finansieres af én enhed, og der er ingen grund at foregive, at virksomhedens support ikke betyder noget. Hvis det står i modsætning til gaflen, dets udviklere er usandsynligt, at deltage, selv om de i al hemmelighed vil.

Hvis du stadig konkludere, at du skal punge, line up support privat først, og derefter bekendtgøre gaflen i en ikke-fjendtlig tone. Selv hvis du er vred på, eller skuffet over de nuværende vedligeholdere, siger ikke, at der i meddelelsen. Lige lidenskabsløst oplyse, hvad fik dig til beslutningen om at punge, og at du betyder ingen uvilje mod projektet, hvorfra du forking. Antages det, at du betragter det som en gaffel (i modsætning til en nødsituation bevarelse af det oprindelige projekt), at understrege, at du forking koden og ikke navnet, og vælg et navn, der ikke er i strid med projektets navn. Du kan bruge et navn, der indeholder eller henviser til det oprindelige navn, så længe det ikke åbner døren for identitetsforvirring. Selvfølgelig er det fint at forklare tydeligt på gaflen hjemmeside, at det nedstammer fra det oprindelige program, og selv at den håber at fortrænge det. Bare ikke gøre brugernes liv hårdere ved at tvinge dem til at udrede en identitet tvist.

Endelig kan du få tingene i gang på højre fod ved automatisk at give alle committere af det oprindelige projekt commit adgang til gaflen, herunder også dem, der åbenlyst uenige i behovet for en gaffel. Selv om de aldrig bruger adgang, dit budskab er klart: Der er uenighed her, men ingen fjender, og du velkommen kode bidrag fra enhver kompetent kilde.
[24] Dette spørgsmål blev undersøgt i detaljer, med interessante resultater, i en artikel af Karim Lakhani og Robert G. Wolf, med titlen Hvorfor Hackere gør hvad de gør: Understanding Motivation og kræfter i Free / Open Source Software projekter. Se http://freesoftware.mit.edu/papers/lakhaniwolf.pdf.

[25] Men se postliste tråd med titlen «med forfattere navne i. Py-filer» på http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee for en god modargument, især indlæg fra William Stein. Nøglen i denne sag, tror jeg, er, at mange af forfatterne kommer fra en kultur (den akademiske matematik samfund), hvor kreditering direkte ved kilden er normen og er højt værdsat. Under sådanne omstændigheder kan det være at foretrække at sætte forfatternavne i kildefilerne, sammen med præcise beskrivelser af, hvad hver enkelt forfatter gjorde, da størstedelen af de potentielle bidragsydere vil forvente, at stil af kvittering.

[26] Bemærk, at der ikke ville være noget behov for at konvertere alle de eksisterende test til de nye rammer, de to kunne heldigvis eksistere side om side med gamle tests konverteret over kun som de havde brug for at blive ændret.

[27] IssueZilla er spørgsmålet tracker vi bruge, da det er en efterkommer af Bugzilla.

[28] Bemærk, at commit adgang betyder noget lidt anderledes i decentrale versionskontrolsystemer, hvor alle kan oprette et arkiv, der er knyttet til projektet, og give sig selv begå adgang til dette register. Alligevel er begrebet commit adgang stadig gælder: «begå adgang» er en forkortelse for «retten til at foretage ændringer i den kode, der vil skib i koncernens næste version af softwaren.» I centraliseret version kontrolsystemer betyder dette har direkte commit adgang i decentraliserede dem, betyder det at have en forskydning trukket ind hoveddistributionen som standard. Det er den samme idé enten måde, mekanikken, hvorved det realiserede er ikke frygtelig vigtig.

[29] Nu en del af RedHat (http://www.redhat.com/).

Kapitel 9. Licenser, copyrights og patenter

Den licens du vælger sandsynligvis ikke vil have en stor indflydelse på vedtagelsen af dit projekt, så længe licensen er open source. Brugere generelt vælger software baseret på kvalitet og funktioner, ikke på detaljerne i licensen. Ikke desto mindre, har du stadig brug for en grundlæggende forståelse af gratis software licenser spørgsmål, både for at sikre, at projektet licens er foreneligt med sine mål, og at være i stand til at diskutere licensafgørelser med andre mennesker. Bemærk dog, at jeg ikke er jurist, og at intet i dette kapitel, må tolkes som en formel juridisk rådgivning. Til det, skal du hyre en advokat eller være en.

Terminologi

I enhver diskussion om open source licenser, er den første ting, der bliver klart, at der synes at være mange forskellige ord for det samme: gratis software, open source, FOSS, F / OSS, og FLOSS. Lad os starte med at sortere dem ud, sammen med et par andre vilkår.

gratis software
Software, der frit kan deles og ændres, herunder i kildekode form. Udtrykket blev først opfundet af Richard Stallman, som kodificeret det i GNU General Public License (GPL), og der grundlagde Free Software Foundation (http://www.fsf.org/) at fremme konceptet.

Selv om «fri software» dækker næsten nøjagtig den samme vifte af software som «open source», FSF, bl.a. foretrækker den tidligere sigt, fordi det understreger ideen om frihed, og begrebet frit videredistribution software som primært en social bevægelse snarere end et teknisk. FSF anerkender, at udtrykket er tvetydigt, det kunne betyde «fri» som i «nul-cost», i stedet for «gratis» som i «frihed»-men mener, at det er stadig det bedste ord, alt taget i betragtning, og at andre muligheder på engelsk har deres egne uklarheder. (I denne bog, «gratis» bruges i den «frihed» mening, ikke den «nul-cost» sense.)

open source-software
Gratis software under et andet navn. Men det andet navn afspejler en vigtig filosofisk forskel: «open source» blev opfundet af Open Source Initiative (http://www.opensource.org/) som et bevidst alternativ til «fri software», for at gøre sådan software en mere spiselig valg for virksomheder, ved at præsentere den som en udviklingsmetode snarere end en politisk bevægelse. De kan også have ønsket at overvinde en anden stigmatisering: at noget «gratis» skal være lav kvalitet.

Mens enhver licens, der er gratis, er også open source, og omvendt (med et par mindre undtagelser), folk har tendens til at vælge et semester og holde sig til det. I almindelighed er dem, der foretrækker «fri software» mere tilbøjelige til at have en filosofisk eller moralsk holdning til spørgsmålet, mens dem, der foretrækker «open source» enten ikke se det som et spørgsmål om frihed, eller ikke er interesseret i reklamer det faktum, at de gør. Se afsnittet «» Free «Versus» Open Source «» i Kapitel 1, Indledning for en mere detaljeret historie af dette skisma.

The Free Software Foundation har en fremragende-aldeles unobjective, men nuanceret og helt fair-eksegese af de to begreber, i http://www.fsf.org/licensing/essays/free-software-for-freedom.html. Open Source Initiative os tage på den (eller var, i 2002) fordelt på to sider: og http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/free-notfree.php.

FOSS, F / OSS, FLOSS
Hvor der er to af noget, vil der snart være tre, og det er præcis, hvad der sker med hensyn til fri software. Den akademiske verden, måske ønsker præcision og rummelighed i løbet af elegance, synes at have afviklet på FOSS, eller nogle gange F / OSS, står for «Free / Open Source Software». En anden variant vinder momentum er FLOSS, der står for «Free / Libre Open Source Software» (libre er velkendt på mange sprog og ikke lider under det tvetydige «gratis», se http://en.wikipedia.org/wiki/ FLOSS for mere).

Alle disse termer betyder det væsentlige det samme: software, der kan ændres og videredistribueres af alle, nogle gange, men ikke altid, med kravet om, at afledte værker frit videredistribution under de samme vilkår.

DFSG-kompatibel
Overholder de Debian Free Software Guidelines (http://www.debian.org/social_contract # guidelines). Det er et udbredt test for, om en given licens er virkelig open source (gratis, libre, etc.). Debian-projektet har til opgave at opretholde et helt frit styresystem, sådan at nogen installerer det behøver aldrig tvivl om, at hun har ret til at ændre og videredistribuere en eller alle af systemet. Debians retningslinjer for fri software er de krav, som en software-pakke licens skal opfylde for at blive inkluderet i Debian. Fordi Debianprojektet tilbragt en god del tid på at tænke, hvordan man opfører en sådan test, har de retningslinjer, de kom op med vist sig meget robust (se http://en.wikipedia.org/wiki/DFSG), og så vidt Jeg er klar over, har nogen alvorlig indvending mod dem blevet rejses enten af Free Software Foundation eller Open Source Initiative. Hvis du ved, at en given licens er DFSG-kompatibel, ved du, at det sikrer, at alle de vigtige friheder (som forkability selv mod den oprindelige forfatters ønsker) kræves for at opretholde dynamikken i et open source-projekt. Alle de licenser, der omtales i dette kapitel, er DFSG-kompatibelt.

OSI-godkendt
Godkendt af Open Source Initiative. Dette er et andet meget udbredte test af, om en licens tillader alle nødvendige friheder. OSI definition af open source software er baseret på Debian Free Software Guidelines, og enhver licens, der opfylder en definition næsten altid møder den anden. Der har været nogle få undtagelser i årenes løb, men kun involverer niche licenser og ingen af nogen relevans her. I modsætning til Debian-projektet, fastholder OSI en liste over alle licenser det nogensinde har godkendt, at http://www.opensource.org/licenses/, så at være «OSI-godkendt» er en entydig tilstand: en licens enten er eller er ikke på listen.

The Free Software Foundation også en liste over licenser http://www.fsf.org/licensing/licenses/license-list.html. FSF kategoriserer licenser ikke alene af, om de er fri, men om de er forenelige med GNU General Public License. GPL kompatibilitet er et vigtigt emne, dækket i afsnittet kaldet «GPL og Licens Compatibility» senere i dette kapitel.

proprietær, closed-source

Det modsatte af «gratis» eller «open source». Det betyder software, der distribueres under traditionelle, royalty-baserede licensbetingelser, hvor brugerne betaler per kopi, eller under andre vilkår tilstrækkeligt restriktive til at forhindre open source dynamik i at fungere. Selv software, der distribueres uden beregning kan stadig være beskyttet, hvis dets licens ikke tillader fri omfordeling og ændring.

Generelt «proprietære» og «lukket kildekode» er synonymer. Men «lukket-source» desuden indebærer, at kildekoden ikke engang kan ses. Da kildekoden ikke kan ses med de fleste proprietær software, er dette normalt en skelnen uden forskel. Men lejlighedsvis nogen frigiver proprietær software under en licens, der tillader andre at se kildekoden. Forvirrende, de undertiden kalder det «open source» eller «næsten open source,» osv., men det er vildledende. Synligheden af kildekoden er ikke problemet, det vigtige spørgsmål er, hvad du får lov til at gøre med det. Forskellen mellem proprietære og lukkede source er for det meste irrelevant, og de to kan betragtes som synonymer.

Sommetider kommercielle bruges som et synonym for «proprietære», men ret beset er de to er ikke det samme. Gratis software kan være kommerciel software. Efter alt, kan gratis software sælges, så længe køberne ikke begrænset fra at give væk kopierer sig selv. Det kan kommercialiseres på andre måder så godt, for eksempel ved at sælge support, tjenester og certificering. Der er multimillion dollar virksomheder bygget på fri software i dag, så det er klart hverken sagens natur anti-kommerciel eller anti-corporate. På den anden side er det anti-specifik ifølge sin natur, og det er det vigtigste måde, hvorpå den adskiller sig fra traditionelle per-kopi kørekortmodeller.

offentlige domæne
Under ingen copyright indehaver, hvilket betyder, at der ikke er nogen, der har ret til at begrænse kopiering af værket. At være i det offentlige rum er ikke det samme som at have nogen forfatter. Alt har en forfatter, og selv om et værk er forfatter eller forfattere vælger at sætte det i det offentlige rum, ændrer det ikke ved det faktum, at de skrev det.

Når et værk er i det offentlige domæne, materiale fra det kan inkorporeres i et ophavsretligt beskyttet værk, og derefter at kopi af materialet er dækket af den samme ophavsret som hele værket. Men det betyder ikke påvirke tilgængeligheden af det originale værk, som forbliver i det offentlige domæne. Således frigiver noget i det offentlige rum er teknisk én måde at gøre det «fri» i henhold til retningslinjerne for de fleste gratis software attesterende organisationer. Men der er som regel gode grunde til at bruge en licens i stedet for bare at slippe ind i det offentlige rum: selv med gratis software, kan visse begrænsninger være nyttig, ikke kun for indehaveren af ophavsretten, men selv til modtagere så godt, som det næste afsnit gør det klart .

copyleft
En licens, der bruger loven om ophavsret at opnå et resultat modsat traditionel ophavsret. Afhængigt af hvem man spørger, betyder det enten licenser, der tillader de friheder, der drøftes her, eller mere snævert, licenser, som ikke kun tillade disse friheder, men håndhæve dem, ved at præcisere, at de frihedsrettigheder skal rejse med arbejdet. The Free Software Foundation bruger den anden definition udelukkende, andre steder, det er en toss-up: en masse mennesker bruger udtrykket på samme måde FSF gør, men andre, herunder nogle, der skriver for mainstream medier, har tendens til at bruge den første definition. Det er ikke klart, at alle, der bruger udtrykket er klar over, at der er en sondring.

Den kanoniske eksempel på smallere, strengere definition er GNU General Public License, som fastsætter, at eventuelle afledte værker også skal være licenseret under GPL, se afsnittet kaldet «GPL og Licens Compatibility» senere i dette kapitel for mere.

Aspekter af licenser

Selvom der er mange forskellige gratis softwarelicenser til rådighed, i de vigtige henseender de alle siger de samme ting: at alle kan ændre koden, at nogen kan omfordele det både i original og modificeret form, og at rettighedshaverne og forfattere giver ingen garantier overhovedet (undgå ansvar er særlig vigtigt i betragtning af, at folk kan køre modificerede versioner uden selv at vide det). Forskellene mellem licenser koges ned til nogle få ofte tilbagevendende spørgsmål:

kompatibilitet med proprietære licenser
Nogle gratis licenser tillader den overdækkede kode, der skal bruges i proprietære programmer. Dette påvirker ikke licensbetingelserne for proprietære program: det er stadig så proprietære som nogensinde, det bare sker for at indeholde noget kode fra en ikke-proprietær kilde. The Apache License, X Consortium License, BSD-stil licens, og MIT-stil licens er alle eksempler på proprietære-kompatible licenser.

kompatibilitet med andre frie licenser

De fleste gratis licenser er kompatible med hinanden, hvilket betyder, at kode under én licens kan kombineres med kode under en anden, og resultatet distribueres i henhold til enten licens uden at overtræde vilkårene for den anden. Den vigtigste undtagelse til dette er GNU General Public License, som kræver, at ethvert arbejde med GPLed kode være sig selv distribueret under GPL, og uden at tilføje yderligere restriktioner ud over, hvad GPL kræver. GPL er kompatibel med nogle gratis licenser, men ikke med andre. Dette diskuteres mere detaljeret i afsnittet «GPL og Licens Compatibility» senere i dette kapitel.

håndhævelse af kreditering
Nogle gratis licenser fastsættes, at enhver brug af det dækkede kode være ledsaget af en meddelelse, hvis placering og visning er sædvanligvis angivet, give kredit til forfatterne eller rettighedshavere af koden. Disse licenser er ofte stadig proprietær-kompatibel: de ikke nødvendigvis kræver, at afledt arbejde frit, blot, at kredit gives til den fri kode.

beskyttelse af varemærke
En variant af kredit håndhævelse. Varemærke-beskyttelse licenser angiver, at navnet på den oprindelige software (eller dets rettighedshaverne eller deres institutioner osv.) ikke kan anvendes af afledte værker uden forudgående skriftlig tilladelse. Selv om kredit håndhævelse insisterer på, at et bestemt navn skal anvendes, og varemærkebeskyttelse insisterer på, at det ikke bruges, de er begge udtryk for det samme ønske: at den oprindelige kode omdømme bevares og transmitteres, men ikke plettet af foreningen.

patent snapback
Både GNU General Public License version 3 og Apache License version 2 indeholder sprog designet til at forhindre folk i at bruge patentret for at tage væk de rettigheder, (loven om ophavsret) af licenser. De kræver bidragydere til meddele patentlicenser sammen med deres bidrag, der dækker eventuelle patenter licenseable af bidragyder, der ville blive krænket af deres bidrag (eller ved inkorporering af deres bidrag til værket som helhed). Så de går videre: Hvis nogen ved hjælp af software under licensen indleder patentsager mod en anden part, hævder, at den dækkede arbejdet strid, initiativtager automatisk mister al patentet tilskud andet er fastsat for dette arbejde af licensen, og i tilfælde af GPLv3 mister deres ret til at distribuere under licensen helt.

beskyttelse af «kunstneriske integritet»
Nogle licenser (Artistic License, der bruges til de mest populære implementering af programmeringssproget Perl, og Donald Knuth er TeX licens, for eksempel) kræver, at ændringer og omfordeling gøres på en måde, der adskiller klart mellem uberørt oprindelige version af koden og eventuelle ændringer. De tillader stort set de samme friheder som andre gratis licens, men stille visse krav, der gør integriteten af den oprindelige kode let at kontrollere. Disse licenser har ikke fanget på meget ud over de specifikke programmer, de blev lavet til, og vil ikke blive behandlet i dette kapitel; de er nævnt her kun for fuldstændighedens skyld.

De fleste af disse bestemmelser ikke udelukker hinanden, og nogle licenser omfatter flere. Den fælles tråd blandt dem er, at de stiller krav til modtageren i bytte for modtagerens ret til at bruge og / eller videredistribuere koden. For eksempel vil nogle projekter deres navn og rygte skal sendes sammen med koden, og det er værd at pålægge den ekstra byrde af en kredit-eller varemærke klausul, afhængigt af dens onerousness, kan denne byrde resultere i nogle brugere vælger en pakke med en mindre krævende licens.

GPL og Licens kompatibilitet

Langt det skarpeste skillelinje i licens er, at mellem proprietære-stridige og proprietære-kompatible licenser, der er mellem den GNU General Public License og alt andet. Fordi det primære mål med GPL forfattere er fremme af fri software, de bevidst udformet licens til at gøre det umuligt at blande GPLed kode ind i proprietære programmer. Specifikt blandt GPL krav (se http://www.fsf.org/licensing/licenses/gpl.html for sin fulde tekst) er disse to:

Enhver afledt arbejde, der er, ethvert arbejde, der indeholder en nontrivial mængde GPLed code-selv skal fordeles under GPL.

Ingen yderligere begrænsninger kan anbringes på omfordeling af enten den oprindelige værk eller et afledt værk. (Den nøjagtige sprog er: «Du må ikke opstille yderligere begrænsninger i udøvelsen af rettighederne eller bekræftet under denne licens.»)

Med disse betingelser lykkes det GPL i at gøre frihed smitsom. Når et program er ophavsretligt beskyttet under GPL, dens form af omfordeling er viral-de videre til noget andet koden bliver inkorporeret i, hvilket gør det reelt umuligt at anvende GPLed kode i closed-source-programmer. Men disse samme klausuler også gøre GPL uforeneligt med visse andre frie licenser. Den sædvanlige måde dette sker, er, at den anden licens indføres et krav, for eksempel, en kredit klausul, hvorefter de originale forfattere at blive nævnt i en eller anden måde, der er uforenelig med GPL er «Du må ikke pålægge yderligere begrænsninger …» sprog. Fra synspunkt af Free Software Foundation, er disse anden ordens konsekvenser ønskelig, eller i det mindste ikke beklageligt. Den GPL ikke kun holder din software gratis, men reelt gør din software en agent i at skubbe anden software til at håndhæve frihed så godt.

Spørgsmålet om, hvorvidt dette er en god måde at fremme fri software er en af de mest vedholdende hellige krige på internettet (se afsnittet «Undgå Holy Wars» i kapitel 6, Communications), og vi vil ikke undersøge det her. Hvad er vigtigt for vort formål er at GPL kompatibilitet er et vigtigt spørgsmål, når de vælger en licens. GPL er langt den mest populære open source-licens, på et tidspunkt Freecode havde det på 68%, med den næsthøjeste licens på 6% [30]. Hvis du vil have din kode for at kunne blandes frit med GPLed kode-og der er en masse GPLed kode derude-så skal du vælge en GPL-kompatibel licens. De fleste af de GPL-kompatible open source licenser er også proprietær-kompatibel: det er, kode under en sådan licens kan bruges i et GPLed program, og det kan bruges i et proprietært program. Selvfølgelig ville resultaterne af disse tidsintervaller ikke kompatible med hinanden, da man ville være under GPL og den anden vil være underlagt en lukket source licens. Men denne bekymring gælder kun for de afledte værker, ikke til den kode du distribuerer i første omgang.

Heldigvis Free Software Foundation vedligeholder en liste over hvilke licenser er kompatible med GPL, og som ikke på http://www.gnu.org/licenses/license-list.html. Alle de licenser, der omtales i dette kapitel, er til stede på denne liste, på den ene eller den anden side.

Vælge en Licens

Når du vælger en licens til at anvende til dit projekt, hvis det overhovedet er muligt brug en eksisterende licens i stedet for at gøre op en ny. Der er to grunde til, at eksisterende licenser er bedre:

Kendskab. Hvis du bruger en af de tre eller fire mest populære licenser, vil folk ikke føler, at de er nødt til at læse den juridiske aftaler for at bruge din kode, fordi de vil allerede har gjort det for denne licens for længe siden.

Kvalitet. Medmindre du har et team af advokater til din rådighed, du er usandsynligt at komme op med en juridisk solid licens. De licenser, der er nævnt her, er de produkter af megen eftertanke og erfaring med mindre dit projekt har virkelig usædvanlige behov, er det usandsynligt at du ville gøre det bedre.

At anvende en af disse licenser til dit projekt, se afsnittet «Sådan ansøger en Licens til din software» i kapitel 2, Introduktion.

MIT/X Window System Licens

Hvis dit mål er at din kode være tilgængelig ved det størst mulige antal udviklere og afledte værker, og du har ikke noget imod den kode, der bruges i proprietære programmer, skal du vælge MIT / X Window System-licens (dette navn, fordi det er den relevante tilladelse under som Massachusetts Institute of Technology frigivet den oprindelige X Window System-kode). Denne licens grundlæggende budskab er «Du er velkommen til at bruge denne kode, som du ønsker.» Den er kompatibel med GNU GPL, og det er kort, enkel og let at forstå:

Copyright (c) <year> <copyright holders>

Der gives hermed tilladelse, gratis, til enhver person, som fik
en kopi af denne software og tilhørende dokumentation (
«Software»), til at handle med Softwaren uden begrænsning, herunder
uden begrænsning rettighederne til at bruge, kopiere, modificere, flette, offentliggøre,
distribuere, underlicensere og / eller sælge kopier af Softwaren samt at
tillade personer til hvem Softwaren er indrettet til at gøre det, med forbehold
følgende betingelser:

Ovenstående meddelelse om ophavsret og denne tilladelse skal være
inkluderes i alle kopier eller væsentlige dele af Softwaren.

SOFTWAREN LEVERES «SOM DEN ER» UDEN NOGEN FORM FOR GARANTI,
UDTRYKKELIGT ELLER STILTIENDE, HERUNDER, MEN IKKE BEGRÆNSET TIL ANSVAR FOR
SALGBARHED, EGNETHED TIL ET BESTEMT FORMÅL OG
KRÆNKELSE. UNDER INGEN OMSTÆNDIGHEDER SKAL FORFATTERNE ELLER OPHAVSRETTIGHAVERNE BE
ANSVARLIG FOR KRAV, SKADER ELLER ANDET ANSVAR, UANSET OM
AF KONTRAKT, TORT ELLER ANDET, OPSTÅET FRA, UD AF ELLER I FORBINDELSE
MED SOFTWAREN ELLER BRUGEN ELLER ANDRE FORHOLD VED SOFTWAREN.
(Taget fra http://www.opensource.org/licenses/mit-license.php.)

GNU General Public License

Hvis du foretrækker, at dit projekt kode ikke anvendes i proprietære programmer, eller hvis du i det mindste er ligeglad, om det kan bruges i proprietære programmer, skal du vælge GNU General Public License (http://www.fsf.org / licensing / licenser / gpl.html). GPL er nok den mest udbredte fri software licens i verden i dag, dette øjeblik genkendelighed er i sig selv en af GPL største fordele.

Når du skriver en kode bibliotek, der menes hovedsageligt at blive brugt som en del af andre programmer, skal du overveje nøje, om de restriktioner, som GPL er i overensstemmelse med dit projekt mål. I nogle tilfælde, for eksempel, når du forsøger at vælte en konkurrerende, proprietær bibliotek, der gør det samme, det kan gøre mere strategisk mening at licensere din kode på en sådan måde, at det kan blandes ind i proprietære programmer, selvom De ville ellers ikke ønsker dette. The Free Software Foundation selv skabte et alternativ til GPL for sådanne omstændigheder: GNU Library GPL, senere omdøbt til GNU Lesser GPL (de fleste mennesker bare bruge forkortelsen LGPL, i hvert fald). Den LGPL har færre restriktioner end GPL, og kan blandes lettere med ikke-fri kode. Men det er også en smule kompliceret og tager noget tid at forstå, så hvis du ikke skal bruge GPL, jeg anbefale bare at bruge MIT / X-stil licens.

GNU Affero GPL: En version af GNU GPL for server-side kode

I 2007 udgav den Free Software Foundation en variant af GPL kaldet GNU Affero GPL (http://www.fsf.org/licensing/licenses/agpl.html) [31]. Dens formål er at håndhæve GPL-lignende deling bestemmelser vedrørende det stigende antal virksomheder, der tilbød hostede tjenester-software, der kører på deres servere, som brugerne interagerer med kun over netværket, og at der derfor aldrig direkte distribueret til brugere som eksekverbare eller kilde kode. Mange sådanne tjenester havde brugt GPL’d software, ofte med modifikationer, men ikke behøvede at dele deres ændringer med verden, fordi de ikke var distribuere nogen kode.

GNU AGPLv3 løsning på dette var at tage den regelmæssige GPL og tilføje en «Remote Network Interaction»-klausul, idet «… hvis du modificere Programmet, skal din modificeret version fremtrædende give alle brugere interagerer med den afstand via et computernetværk. .. en mulighed for at modtage den tilsvarende kilde på din version … uden beregning, gennem nogle standard eller sædvane midler til at lette kopiering af software. » Det udvidede GPL håndhævelsesbeføjelser ind i den nye verden af Application Service Provider. The Free Software Foundation anbefaler, at GNU AGPLv3 anvendes til noget software, der vil almindeligvis blive kørt over et netværk.

Bemærk, at AGPLv3 ikke er direkte kompatible med GPLv2 (selvom det er kompatibelt med GPLv3, selvfølgelig). Men de fleste software licenseret under GPLv2 omfatter «eller enhver nyere version» klausul alligevel, så du kan bare flytte det til GPLv3 hvis og når du har brug for at blande det med AGPLv3 kode. Men hvis du skal blande med programmer licenseret strengt under GPLv2 (dvs. uden «eller enhver nyere version» klausul), så AGPLv3 vil ikke fungere.

Selvom historien om den AGPLv3 er en smule kompliceret, selve licensen er enkel: det er bare den GPLv3 med en ekstra klausul om netværk interaktion. Wikipedia artikel om AGPLv3 er fremragende: http://en.wikipedia.org/wiki/Affero_General_Public_License

Er GPL gratis eller ikke gratis?

En konsekvens af at vælge GPL er muligheden-small, men ikke uendeligt små-for at finde dig selv eller dit projekt involveret i en tvist om, hvorvidt GPL er virkelig «gratis», da det lægger nogle begrænsninger på, hvad du kan gøre med kode-nemlig. den begrænsning, at koden ikke kan distribueres under nogen anden licens For nogle mennesker betyder eksistensen af denne restriktion GPL er «mindre fri» end mere liberale licenser såsom MIT / X-licens. Hvor dette argument normalt går, er naturligvis, at da «mere fri» skal være bedre end «mindre fri» (efter alle, der ikke er til fordel for frihed?), Følger det, at disse licenser er bedre end GPL.

Denne debat er en anden populær hellig krig (se afsnittet «Undgå hellige krige» i kapitel 6, Communications). Undgå at deltage i det, i hvert fald i projektets fora. Forsøg ikke at bevise, at GPL er mindre fri, som frie, eller mere fri end andre licenser. I stedet understreger de specifikke årsager dit projekt har valgt GPL. Hvis genkendelighed af licens var en grund, sige. Hvis håndhævelsen af en gratis licens på afledte værker var også en grund, siger, at også, men nægter at blive trukket ind i diskussionen om, hvorvidt det gør koden mere eller mindre «gratis». Frihed er et komplekst emne, og der er ikke megen mening at tale om det, hvis terminologi vil blive brugt som en stalking hest for stof.

Da dette er en bog og ikke en mailingliste tråd, dog vil jeg indrømme, at jeg aldrig har forstået «GPL er ikke gratis» argument. Den eneste begrænsning GPL pålægger, er, at det forhindrer folk i at indføre yderligere begrænsninger. At sige, at dette resulterer i mindre frihed altid har forekommet mig at sige, at forbud mod slaveri reducerer frihed, fordi det forhindrer nogle mennesker fra at eje slaver.

(Åh, og hvis du bliver trukket ind i en debat om det, ikke øge indsatsen ved at gøre inflammatoriske analogier.)

Hvad Om BSD-licens?

En hel del af open source software er distribueret under en BSD-licens (og undertiden en BSD-stil licens). Den originale BSD-licensen blev anvendt til Berkeley Software Distribution, hvor University of California frigivet vigtige dele af et Unix implementering. Denne licens (den nøjagtige ordlyd kan ses i afsnit 2.2.2 http://www.xfree86.org/3.3.6/COPYRIGHT2.html # 6) var ens i ånden til MIT / X-licens, bortset fra én klausul :

Alt reklamemateriale, der nævner funktioner eller brug af denne software skal vise følgende anerkendelse: Dette produkt indeholder software udviklet af University of California, Lawrence Berkeley Laboratory.

Tilstedeværelsen af denne klausul ikke kun gjort den originale BSD-licens GPL-uforenelige, men også en farlig præcedens: som andre organisationer sætter lignende reklame klausuler i deres gratis software-erstatte deres egen organisations navn i stedet for «University of California, Lawrence Berkeley Laboratory «-software videredistributører står over for en stadig stigende byrde i, hvad de skulle vise. Heldigvis er mange af de projekter, der brugte denne licens blev opmærksom på problemet, og blot faldt reklame klausul. I 1999 gjorde selv University of California så.

Resultatet er den reviderede BSD-licens, der er simpelthen den oprindelige BSD-licensen med reklame klausul fjernet. Men denne historie gør udtrykket «BSD-licens» lidt tvetydig: betyder det henviser til den oprindelige, eller den reviderede version? Det er derfor, jeg foretrækker MIT / X-licens, der er det væsentlige tilsvarende, og som ikke lider af nogen tvetydighed. Men der er måske en grund til at foretrække den reviderede BSD licens til MIT / X-licens, som er, at BSD indeholder denne klausul:

Hverken navnet på <ORGANIZATION> eller navnene på dets bidragydere kan anvendes til at støtte eller reklamere for produkter afledt af denne software uden specifik forudgående skriftlig tilladelse.

Det er ikke klart, at uden en sådan klausul, ville en modtager af softwaren have haft ret til at benytte licensgiverens navn alligevel, men den klausul fjerner enhver tvivl. For organisationer bekymrede varemærke kontrol, derfor kan den reviderede BSD-licensen være lidt at foretrække frem for MIT / X. I almindelighed, dog ikke en liberal licens på ophavsret ikke, at modtagere har ret til at bruge eller fortynde dine varemærker — ophavsret og varemærkeret er to forskellige dyr.

Hvis du ønsker at bruge den reviderede BSD licens, en skabelon er tilgængelig på http://www.opensource.org/licenses/bsd-license.php.

Copyright Overdragelse og Ejerskab

Der er tre måder at håndtere copyright ejerskab til fri kode og dokumentation, der blev bidraget til af mange mennesker. Den første er at ignorere spørgsmålet om ophavsrettigheder helt (jeg ikke anbefale dette). Den anden er at indsamle en bidragyder licensaftale (CLA) fra hver person, der arbejder på projektet, udtrykkeligt give projektet retten til at bruge denne persons bidrag. Dette er normalt nok for de fleste projekter, og det gode er, at i nogle jurisdiktioner, kan CLA sendes via e-mail. Den tredje måde er at få de faktiske ophavsret opgaver fra bidragydere, således at projektet (dvs. nogle juridisk enhed, som regel en nonprofit) er indehaver af ophavsretten til alt. Dette er den mest juridisk lufttæt måde, men det er også den mest belastende for bidragydere, kun et par projekter insistere på det [32].

Bemærk, at selv under centraliseret ophavsretsejerskab, koden [33] er fortsat gratis, fordi open source-licenser ikke giver indehaveren af ophavsretten ret til med tilbagevirkende kraft proprietize alle kopier af koden. Så selv om projektet, som en juridisk enhed, pludselig skulle vende rundt og begyndte at distribuere al den kode under en restriktiv licens, ville det ikke give problemer for den offentlige samfund. De andre udviklere ville simpelthen starte en gaffel baseret på den seneste gratis kopi af koden, og fortsætte, som om intet var hændt. Fordi de ved, de kan gøre det, de fleste bidragydere samarbejde, når bedt om at underskrive en CLA eller en overdragelse af ophavsretten.

Doing Nothing

De fleste projekter aldrig indsamle CLA eller ophavsret opgaver fra deres bidragydere. I stedet, de accepterer kode hver gang det forekommer rimeligt klart, at bidragyderen tænkt sig, det skal indarbejdes i projektet.

Under normale omstændigheder er det okay. Men nu og da kan nogen beslutte at sagsøge for krænkelse af ophavsretten, hvorefter at de er den sande ejer af den pågældende kode, og at de aldrig accepteret, at denne distribueret af projektet under en open source licens. For eksempel gjorde den SCO Group noget som dette til Linux-projektet, se http://en.wikipedia.org/wiki/SCO-Linux_controversies for detaljer. Når dette sker, vil projektet ikke have nogen dokumentation for, at indskyderen formelt får ret til at bruge koden, hvilket kan gøre nogle juridiske forsvar vanskeligere.

Bidragyder Licensaftaler

CLA sandsynligvis tilbyde den bedste afvejning mellem sikkerhed og bekvemmelighed. En CLA er typisk en elektronisk formular, at en udvikler udfylder og sender ind til projektet. I mange jurisdiktioner, er e-mail indsendelse nok. En sikker digital signatur kan eller kan ikke være krævet, rådføre sig med en advokat for at finde ud af, hvad metode vil være bedst til dit projekt.

De fleste projekter bruge to lidt forskellige CLA, et for enkeltpersoner og et for virksomhedernes bidragydere. Men i begge typer, er kernen sprog det samme: bidragyderen giver projektet «… evig, verdensomspændende, ikke-eksklusiv, uden betaling, royalty-fri, uopsigelig licens på ophavsret til at reproducere, udarbejde afledte værker af, vise offentligt , offentligt udføre, give i underlicens, og distribuere [de] Bidrag og sådanne afledte værker. » Igen, bør du have en advokat godkende enhver CLA, men hvis du får alle disse adjektiver i det, er du sikkert fint.

Når du anmoder om CLA fra bidragydere, skal du sørge for at understrege, at du ikke beder om egentlig ophavsret opgave. Faktisk begynder mange CLA ud ved at minde læseren af dette:

Dette er en licensaftale kun og kan ikke overføre ophavsretligt ejerskab og ændrer ikke dine rettigheder til at bruge dine egne bidrag til andre formål.

Her er nogle eksempler:

Enkelte bidragyder CLA:

http://apache.org/licenses/icla.txt

http://code.google.com/legal/individual-cla-v1.0.html

Corporate bidragyder CLA:

http://apache.org/licenses/cla-corporate.txt

http://code.google.com/legal/corporate-cla-v1.0.html

Overførsel af ophavsret

Copyright overførsel betyder, at bidragyder tildeler til projektet copyright ejerskab på hendes bidrag. Ideelt set sker dette på papir og enten faxes eller snail-mail til projektet.

Nogle projekter insistere på fuld opgave, fordi der har en enkelt juridisk enhed ejer ophavsretten på hele kodebase kan gøre håndhævelsen af licensvilkårene lidt mere praktisk, hvis de skulle få brug for at blive håndhævet i retten. Forskellige organisationer anvender forskellige mængder af strenghed til opgave at indsamle opgaver. Nogle blot få en uformel erklæring fra en bidragyder på en offentlig liste postliste-noget til virkningen af «jeg hermed overdrage ophavsretten i denne kode til projektet, som skal licenseres under de samme vilkår som resten af koden.» Mindst én advokat jeg har talt med siger, det er virkelig nok, formentlig fordi det sker i en sammenhæng, hvor copyright opgave er normale og forventede alligevel, og fordi det repræsenterer en bona fide indsats på projektets del at fastslå bygherrens egentlige hensigter. På den anden side går den Free Software Foundation til den modsatte yderlighed: de kræver bidragydere til fysisk underskrive og mail i (eller fax) et stykke papir, der indeholder en formel erklæring om ophavsret opgave, nogle gange for blot én bidrag, undertiden for nuværende og fremtidige bidrag. Hvis bygherren er ansat, FSF anmoder om, at arbejdsgiveren underskriver det også.

FSF paranoia er forståeligt. Hvis nogen overtræder vilkårene i GPL ved at inkorporere nogle af deres software ind i et proprietært program, vil FSF nødt til at bekæmpe den i retten, og de ønsker deres ophavsrettigheder skal være så lufttæt som muligt, når det sker. Da FSF er indehaveren af ophavsretten til en masse populære software, de ser det som en reel mulighed. Uanset om din organisation har brug for at være lige samvittighedsfulde er noget kun du kan beslutte, i samråd med advokater. I almindelighed, medmindre der er nogle specifikke grund til, at dit projekt har brug for fuld copyright opgave bare gå med CLA, de er nemmere for alle.

Dual licensordninger

Nogle projekter forsøger at finansiere sig selv ved hjælp af en dobbelt licensordning, hvor proprietære afledte værker kan betale indehaveren af ophavsretten for retten til at bruge koden, men koden er stadig gratis til brug af open source-projekter. Denne tendens til at arbejde bedre sammen med kode biblioteker end med selvstændige programmer, naturligvis. De nøjagtige betingelser forskellige fra sag til sag. Ofte licens til fri side er GNU GPL, da det allerede spærrer andre fra at inkorporere den overdækkede kode i deres proprietære produkt uden tilladelse fra indehaveren af ophavsretten, men nogle gange er det en skik licens, der har samme virkning. Et eksempel på førstnævnte er MySQL-licens, der er beskrevet i http://www.mysql.com/company/legal/licensing/, et eksempel på det sidste er Sleepycat Softwares licens strategi, beskrevet på http://www.oracle. dk / teknologi / software / products / berkeley-db / htdocs / licensing.html.

Du kan være undrende: hvordan kan indehaveren af ophavsretten tilbyde proprietære licenser for en obligatorisk afgift, hvis betingelserne i GNU GPL fastslår, at koden skal være til rådighed under mindre restriktive vilkår? Svaret er, at GPL præmisser er noget indehaveren af ophavsretten pålægger alle andre, ejeren er derfor fri til at beslutte ikke at anvende disse begreber til sig selv. En god måde at tænke på det er at forestille sig, at indehaveren af ophavsretten har et uendeligt antal kopier af softwaren gemt i en spand. Hver gang, det tager én ud af spanden til at sende ud i verden, kan det beslutte, hvad licens til at sætte på det: GPL, ophavsretlige eller noget andet. Sin ret til at gøre dette er ikke bundet til GPL eller en anden open source-licens, det er simpelthen en bemyndigelse givet af loven om ophavsret.

Tiltrækningskraft dobbelt licens er, at når det er bedst, det giver en måde for en gratis software-projekt for at få en pålidelig indtægtskilde. Desværre kan det også forstyrre de normale dynamik open source-projekter. Problemet er, at enhver frivillig, der gør en kode bidrag nu bidrager til to forskellige enheder, nemlig den gratis version af koden og den proprietære version. Mens bidragyder vil være behageligt at bidrage til den gratis version, da det er normen i open source-projekter, kan hun føle sjovt om at bidrage til en andens semi-proprietære indtægtskilde. Den kejtethed forværres af det faktum, at i dual licensering, indehaveren af ophavsretten virkelig brug for at samle formelle, underskrevet ophavsret opgaver fra alle bidragydere, for at beskytte sig selv fra en misfornøjet bidragyder senere hævder en procentdel af royalties fra den proprietære strøm. Processen med at indsamle disse overdragelse papirer betyder, at bidragyderne står i skarp konfronteres med det faktum, at de gør arbejdet, der gør penge til en anden.

Ikke alle frivillige vil blive generet af dette, da der jo gå deres bidrag til den open source-udgave så godt, og som kan være, hvor deres hovedinteresse ligger. Ikke desto mindre er dobbelt licensering er en instans af indehaveren af ophavsretten tildeler sig selv en særlig ret, som andre i projektet ikke har, og er derfor forpligtet til at hæve spændingerne på et tidspunkt, i hvert fald med nogle frivillige.

Hvad synes at ske i praksis er, at virksomheder baseret på dual licenseret software ikke har virkelig egalitære udvikling samfund. De får mindre fejlrettelser og oprydning patches fra eksterne kilder, men ender med at gøre det meste af det hårde arbejde med interne ressourcer. For eksempel fortalte Zack Urlocker, vice president for marketing hos MySQL, mig, at firmaet generelt ender ansætte de mest aktive frivillige alligevel. Selv selve produktet er open source, licenseret under GPL, dens udvikling er mere eller mindre kontrolleret af virksomheden, dog med den (meget usandsynligt) muligheden for, at nogen virkelig utilfredse med selskabets håndtering af software kunne gaffel projektet. I hvilken grad denne trussel forebyggende former virksomhedens politik, jeg ikke kender, men i hvert fald ikke MySQL ikke synes at have accept problemer enten i open source-verdenen eller udenfor.

Patenter

Softwarepatenter er lynafleder spørgsmålet om det øjeblik i fri software, fordi de udgør den eneste reelle trussel mod hvilken fri software-fællesskabet kan ikke forsvare sig selv. Ophavsret og varemærke problemer kan altid fået omkring. Hvis en del af din kode ligner det kan krænke andres ophavsret, kan du bare omskrive den del. Hvis det viser sig nogen har et varemærke på dit projekts navn, i det værste du kan bare omdøbe projektet. Selvom skiftende navne ville være en midlertidig ulempe, ville det ikke noget i det lange løb, da koden selv ville stadig gøre, hvad den altid har gjort.

Men et patent er et tæppe fogedforbud mod at gennemføre en bestemt idé. Det er ligegyldigt, hvem skriver koden, og heller ikke hvad programmeringssprog bruges. Når nogen har beskyldt en gratis software-projekt for at krænke et patent, skal projektet enten stoppe gennemførelsen af denne bestemt funktion, eller står over for en dyr og tidskrævende retssag. Da ophavsmændene til sådanne retssager er normalt selskaber med dybe lommer-Det er, hvem der har de ressourcer og lyst til at erhverve patenter i første omgang, de fleste fri software-projekter har ikke råd til den sidstnævnte mulighed, og skal kapitulere straks, selv om de synes, det meget sandsynligt, at patentet ville kunne håndhæves i retten. For at undgå at komme i en sådan situation i første omgang, er fri software-projekter begynder at kode defensivt, så man undgår patenterede algoritmer i forvejen, selv når de er de bedste eller eneste løsning på et programmerings problem. [34]

Undersøgelser og anekdotiske beviser viser, at ikke kun det store flertal af open source programmører, men et flertal af alle programmører, mener, at softwarepatenter skal afskaffes helt. [35] Open source programmører tendens til at føle særlig stærkt om det, og kan nægte at arbejde på projekter, der er for tæt forbundet med indsamling eller håndhævelsen af softwarepatenter. Hvis din organisation indsamler softwarepatenter, så gør det klart, i en offentlig og uigenkaldelig måde, at patenterne aldrig ville blive håndhævet på open source-projekter, og at de kun bruges som et forsvar i tilfælde af et en anden part indleder en overtrædelse retssag mod din organisation. Det er ikke kun det rigtige at gøre, det er også gode open source public relations. [36]

Desværre indsamling patenter for defensive formål er en rationel handling. Det nuværende patentsystem, i hvert fald i USA, er i sagens natur et våbenkapløb: Hvis dine konkurrenter har opnået en masse patenter, så vil din bedste forsvar er at erhverve en masse patenter selv, så hvis du nogensinde ramt med en patentkrænkelse jakkesæt du kan reagere med en lignende trussel, så de to parter plejer at sidde ned og udarbejde en cross-licensaftale, således at ingen af dem er nødt til at betale noget, bortset fra at deres intellektuelle ejendomsret advokater selvfølgelig.

Den skade, der til gratis software softwarepatenter er mere lumsk end blot direkte trusler mod kode udvikling, dog. Softwarepatenter fremmer en atmosfære af hemmelighed blandt firmware designere, der med rette bekymrede for, at ved at offentliggøre oplysninger om deres grænseflader de giver teknisk hjælp til konkurrenter, der søger at smække dem med patentkrænkelse jakkesæt. Dette er ikke blot en teoretisk fare, og det har tilsyneladende været tilfældet i lang tid i grafikkortets industri, for eksempel. Mange grafikkort producenter er tilbageholdende med at frigive de detaljerede programmering specifikationer, der er nødvendige for at producere højtydende open source drivere til deres kort, hvilket gør det umuligt for gratis operativsystemer til at understøtte disse kort til deres fulde potentiale. Hvorfor skulle producenterne gøre dette? Det giver ingen mening for dem at arbejde mod software-support, da der jo kan kompatibilitet med flere operativsystemer kun betyde flere kortsalg. Men det viser sig, at der bag designet døren, er disse butikker alle krænke hinandens patenter, nogle gange bevidst og nogle gange ved et uheld. Patenterne er så uforudsigelig, og så potentielt bred, at ingen kortproducenten nogensinde kan være sikker på det er sikkert, selv efter at gøre et patent søgning. Således vover producenterne ikke offentliggøre deres fulde grænsefladespecifikationer, da det ville gøre det meget lettere for konkurrenterne at finde ud af, om patenter bliver overtrådt. (Selvfølgelig er karakteren af denne situation, at du ikke vil finde en skriftlig indrømmelse fra en primær kilde, at det sker, jeg har lært det gennem en personlig meddelelse.)

Nogle gratis softwarelicenser har særlige klausuler til bekæmpelse eller i det mindste modvirke, softwarepatenter. GNU GPL, for eksempel indeholder dette sprog:

7. Hvis det som følge af en retsafgørelse eller påstand om patent
overtrædelse eller af nogen anden grund (ikke begrænset til patentspørgsmål),
betingelser er pålagt dig (enten ved retskendelse, aftale eller
andet), der i strid med betingelserne i denne Licens, de ikke
undskylde dig fra at betingelserne i denne Licens. Hvis du ikke kan
distribuere således at tilfredsstille samtidig dine forpligtelser i henhold til denne
Licens og alle andre relevante forpligtelser, som følge dig
må ikke distribuere Programmet overhovedet. For eksempel, hvis et patent
licens ikke ville tillade afgiftsfri videredistribution af Programmet ved
alle dem, der modtager kopier direkte eller indirekte igennem dig, så
den eneste måde du kan tilfredsstille både den og denne licens ville være at
afstå helt fra distribution af programmet.

[...]

Det er ikke formålet med denne paragraf at tilskynde Dem til at krænke nogen
patenter eller andre ejendomsrettigheder eller at bestride gyldigheden af ethvert
disse fordringer; denne sektion har udelukkende til formål at beskytte
integritet gratis software distributionssystem, der er
implementeret gennem offentlig licenspraksis. Mange mennesker har gjort
store bidrag til det brede distribueret udvalg af software
via dette system i tiltro til en konsekvent anvendelse af det
system, det er op til forfatteren / donoren at beslutte, om han eller hun er villig
at distribuere software via et andet system, og en licenstager kan ikke
pålægge dette valg.
The Apache License, Version 2,0 (http://www.apache.org/licenses/LICENSE-2.0) indeholder også anti-patentrettigheder krav. Første fastsættes det, at enhver, distribuere kode under licensen implicit skal indeholde en royalty-fri patent licens til patenter, de måtte være i besiddelse, som kunne gælde for koden. For det andet, og mest sindrigt, det straffer nogen, der indleder en patentkrænkelse fordring på den overdækkede arbejde ved automatisk at opsige deres implicitte patentlicens det øjeblik en sådan påstand er lavet:

3. Tildeling af Patent License. I henhold til vilkårene og betingelserne i
denne licens, hver bidragyder giver dig hermed en evig,
verdensomspændende, ikke-eksklusiv, ikke-charge, royalty-fri, uigenkaldelig (undtagen
som anført i dette afsnit) patent licens til at fremstille, har gjort, bruge,
tilbyde at sælge, sælge, importere, og på anden måde overføre Værket, hvor
sådan licens gælder kun for dem patentkravene licensløsning af en sådan
Bidragydere, der nødvendigvis tilsidesat af deres bidrag (s)
alene eller ved kombination af deres bidrag (r) med værket til
som sådan Bidrag (r) blev indgivet. Hvis du institut patent
søgsmål mod enhver enhed (inklusive en cross-kravet eller modkravet
i en retssag) påstand om, at værket eller et bidrag inkorporeret
inden for Work udgør en direkte eller medvirkende patent
overtrædelse, så eventuelle patentlicenser til Dig ifølge denne
Licens til at Work ophører fra den dato, hvor retssager
er gemt.
Selv om det er hensigtsmæssigt, både juridisk og politisk, til at bygge patent forsvar i gratis softwarelicenser på denne måde, i sidste ende disse skridt vil ikke være nok til at fjerne den afkølende virkning, at truslen om patentretssager har på fri software. Kun ændringer i stoffet eller fortolkningen af den internationale patentret vil gøre dette. Hvis du vil vide mere om problemet, og hvordan det er at blive udkæmpet, gå til http://www.nosoftwarepatents.com/. Wikipedia artiklen http://en.wikipedia.org/wiki/Software_patent har også en masse nyttig information om softwarepatenter. Jeg har også skrevet et blogindlæg sammenfatter argumenter mod softwarepatenter, på http://www.rants.org/2007/05/01/how-to-tell-that-software-patents-are-a-bad- ide /.

Yderligere ressourcer

Dette kapitel har kun været en introduktion til gratis software licenser spørgsmål. Selv om jeg håber, at det indeholder tilstrækkeligt med oplysninger til at få dig i gang på din egen open source-projekt, vil enhver seriøs efterforskning af licensproblemer hurtigt udstødning, hvad denne bog kan give. Her er en liste over yderligere ressourcer om open source licenser:

Forståelse Open Source og Free Software Licensing af Andrew M. St. Laurent. Udgivet af O’Reilly Media, første udgave august 2004, ISBN: 0-596-00581-4.

Dette er en fuld-længde bog om open source licenser i al dens kompleksitet, herunder mange emner udeladt fra dette kapitel. Se http://www.oreilly.com/catalog/osfreesoft/ for detaljer.

Gør din Open Source Software GPL-kompatible. Eller Else. af David A. Wheeler,. ved http://www.dwheeler.com/essays/gpl-compatible.html

Dette er en detaljeret og velskrevet artikel om hvorfor det er vigtigt at bruge en GPL-kompatibel licens, selvom du ikke bruger GPL selv. Artiklen berører også mange andre licenser spørgsmål, og har en høj tæthed af gode links.

http://creativecommons.org/

Creative Commons er en organisation, der fremmer en række mere fleksible og liberale ophavsrettigheder end traditionel ophavsret praksis opmuntrer. De tilbyder licenser ikke blot for software, men for tekst, kunst og musik, som alle er tilgængelige via en brugervenlig licens selector,, nogle af de licenser er copylefts nogle er ikke-copyleft, men stadig gratis, andre er simpelthen traditionelle ophavsrettigheder men med visse restriktioner afslappet. Creative Commons hjemmeside giver ekstremt klare beskrivelser af, hvad det handler om. Hvis jeg skulle vælge ét websted til at demonstrere de bredere filosofiske implikationer af fri software-bevægelsen, ville det være det.
[30] License statistikker, der bruges til at være til rådighed fra Freecode.com, tilbage, da det blev kaldt Freshmeat.net, men i 2008 skiftede de til en freeform metode til kodning projekter, der gjorde det sværere at generere pålidelige licens statistikker. Se http://help.freecode.com/discussions/questions/187-where-did-the-license-statistics-page-go for en drøftelse af eventuel restaurering af disse statistikker.

[31] Den historie af licensen og dens navn er en smule kompliceret. Den første udgave af kørekortet blev oprindeligt udgivet af Affero, Inc, der bygger det på GNU GPL version 2. Dette blev almindeligvis benævnt AGPL. Senere Free Software Foundation besluttede at vedtage den idé, men inden da havde de frigivet version 3 af deres GNU GPL, så de bygger deres nye Affero-ized licens på det og kaldte det «GNU AGPL». Den gamle Affero licensen er mere eller mindre forældet nu. Hvis du ønsker Affero-lignende bestemmelser, skal du bruge GNU version. For at undgå tvetydighed, kalder det «AGPLv3″, den «GNU AGPL», eller for maksimal præcision, «GNU AGPLv3″.

[32] Også den faktiske ophavsret overflytning er underlagt national ret, og licenser designet til USA kan støde på problemer andre steder (fx i Tyskland, hvor det er åbenbart ikke muligt at overføre copyright).

[33] Jeg vil bruge «kode» at henvise til både kode og dokumentation, fra nu af.

[34] Sun Microsystems og IBM har også lavet mindst en gestus på problemet fra den anden retning, ved at frigøre et stort antal software-patenter-1600 og 500 henholdsvis-til brug for open source-fællesskabet. Jeg er ikke jurist, og derfor ikke kan vurdere den reelle nytte af disse tilskud, men selv om de er alle vigtige patenter, og vilkårene for de tilskud gør dem virkelig fri benyttes af alle open source-projekt, ville det stadig kun være en dråbe i havet.

[35] Se http://groups.csail.mit.edu/mac/projects/lpf/Whatsnew/survey.html for én sådan undersøgelse.

[36] For eksempel har RedHat lovet, at open source-projekter er sikre fra sine patenter, http://www.redhat.com/legal/patent_policy.html se.

Tillæg A. Gratis version Control Systems

Disse er alle de open source-version kontrolsystemer jeg var klar over fra midten-2007, plus et par, som jeg tilføjet i slutningen af 2011. Dem jeg bruger på en regelmæssig basis er Subversion og Git, og jeg har brugt Bazaar og CVS udstrakt så godt. De andre jeg har lidt eller ingen erfaring med, og oplysningerne her er taget fra deres web-sites. Se også http://en.wikipedia.org/wiki/List_of_revision_control_software.

Subversion — http://subversion.tigris.org/

Subversion blev skrevet først og fremmest at være en erstatning for CVS-det vil sige at nærme versionskontrol i nogenlunde samme måde CVS gør, men uden de problemer og har undladelser, oftest irritere brugerne af CVS. Et af Subversion mål er for folk, der allerede er vant til CVS at finde overgangen til Subversion forholdsvis glat. Der er ikke plads her at gå i detaljer om Subversion funktioner, se sin hjemmeside for mere information. [Disclaimer:. Jeg er involveret i Subversion udvikling, og det er det eneste af disse systemer, som jeg bruger på en regelmæssig basis]

GIT — http://git.or.cz/

GIT er et projekt startet af Linus Torvalds til at styre Linux kerne-kildekode træ. Ved første GIT var temmelig snævert fokuseret på behovene i kernel udvikling, men det er vokset ud over dette, og anvendes nu af andre projekter end Linux-kernen. Dens hjemmeside siger, at det er «… designet til at håndtere meget store projekter med hurtighed og effektivitet, og det bruges primært til diverse open source-projekter, især Linux-kernen Git falder i kategorien af distribuerede kildekode styringsværktøjer, lignende. til f.eks GNU Arch eller Monotone (eller bitkeeper i den proprietære verden). Hver Git arbejder bibliotek er et fuldgyldigt repository med fuld revision sporingsmuligheder, ikke afhængig af netadgang eller en central server. »

Mercurial - http://www.selenic.com/mercurial/

Mercurial er et distribueret version control system, der tilbyder blandt andet «komplet cross-indeksering af filer og changesets, båndbredde og CPU effektive HTTP og SSH sync protokoller, vilkårlig sammenlægning mellem developer grene, integreret stand-alone web interface, [bærbarhed til ] UNIX, MacOS X og Windows «og mere (den foregående feature liste blev omskrevet fra Mercurial hjemmeside).

Bazaar — http://bazaar-vcs.org/

Bazaar (eller BZR) er et distribueret version control system, der koncentrerer sig om lethed-i-brug og med en fleksibel datamodel. Det er en officiel GNU-projektet, og er den native version control system for fri software-projekt-hosting-websted Launchpad.net. Bazaar er fuldt distribueret versionskontrol: alt arbejde foregår i grene, og alle udviklere har typisk en fuld kopi af filialen historie. Filialer kan flettes ind i hinanden i et decentralt, men Bazaar kan også konfigureres til at arbejde på en centraliseret måde. Bazaar startede ud som en fork af GNU Arch, men blev omskrevet fra bunden, og nu ikke har nogen direkte relation til GNU Arch.

SVK — http://svk.elixus.org/

Selvom det er bygget oven på Subversion, SVK sandsynligvis ligner nogle af de decentrale systemer under mere end det gør Subversion. SVK støtter distribueret udvikling, lokal begår, sofistikeret forandring sammenlægning, og evnen til at spejle træer fra ikke-SVK udgave kontrolsystemer. Se sin hjemmeside for yderligere oplysninger.

Sandfærdighed — http://veracity-scm.com/

Sandfærdighed er et distribueret version control system, som med Git, Mercurial, Bazaar, et al alle udviklere arbejder med en fuld lokalt lager, og ændringer skal skubbes og trækkes mellem repositories efter behov. Kommando-Wise, det er temmelig ligner disse systemer, er imidlertid, ud over at versionsstyring filer, inkluderer Veracity en distribueret bug tracking database, der er versioneret siden filerne. Med andre ord forsøger Veracity at tage hver artefakt skal du rent faktisk gøre udvikling — ikke bare kildekoden træet, men fejlrapporter også — og gøre dem tilgængelige via den version kontrolsystem. Det er en ambitiøs vision, og mens jeg ikke har haft en chance for at bruge det, ville jeg helt sikkert være interesseret i rapporter fra nogen, der har. Det er hovedsageligt skrevet af SourceGear, Inc, et selskab med en lang historie i version kontrol og software konfigurationsstyring.

Se også Fossil for et lignende system.

Fossil — http://www.fossil-scm.org/

Fossil ligner Veracity i, at det er et distribueret version control system, der versioner mere end blot de kode filer: Det versioner af fejlsporingsdatabase og en jævnt fordelt wiki og en jævnt fordelt blog. Andre funktioner omfatter en standard «autosync» mode, at gøre automatiseret sammenlægning af ikke-modstridende ændringer (dvs. Fossil kan operere i en centraliseret måde eller decentralt, hvilket i teorien er sandt for andre distribuerede systemer så godt, men det lader til, at Fossil gør en større indsats til rent faktisk at støtte den centraliserede workflow). Det er også skibe med en web-grænseflade, så folk kan gennemse koden repository.

Fossil er primært skrevet af Dr. Richard Hipp, måske bedre kendt som forfatter til SQLite database motor. Ligesom Veracity, jeg har ikke brugt Fossil, hvis du gør, så lad mig vide, hvordan det går.

CVS — http://www.nongnu.org/cvs/

CVS har eksisteret i lang tid, og mange udviklere allerede er bekendt med det. I sin tid var det revolutionerende: det var den første open source version control system med wide-area network adgang for udviklere (så vidt jeg ved), og den første til at tilbyde anonyme read-only kasserne, hvilket gav nye udviklere en nem måde at involvere sig i projekter. CVS-versioner kun filer, ikke mapper, det giver forgrening, tagging, og god på klientsiden ydeevne, men ikke håndtere store filer eller binære filer meget godt. Det understøtter heller ikke atomare begår. [Disclaimer: Jeg var aktiv i CVS udvikling for omkring fem år, før hjælpe med at starte Subversion projektet at erstatte det.]

Darcs — http://darcs.net

«David Advanced Revision Control System er endnu et erstatning for CVS. Der står skrevet i Haskell, og er blevet brugt på Linux, MacOS X, FreeBSD, OpenBSD og Microsoft Windows. Darcs indeholder en cgi script, der kan bruges til at se indholdet af dit arkiv. »

Arch — http://www.gnu.org/software/gnu-arch/

GNU Arch understøtter både distribueret og centraliseret udvikling. Udviklere forpligte deres ændringer til et «arkiv», som kan være lokal, og ændringerne kan skubbes og trækkes til andre arkiver, som lederne af disse arkiver forgodtbefindende. Som en sådan metode indebærer, Arch har mere sofistikeret merge støtte end CVS. Arch også tillader en at nemt lave grene af arkiver, som man ikke har commit adgang. Dette er kun en kort sammenfatning, se de Arch websider for detaljer.

monoton — http://www.venge.net/monotone/

«Monoton er en gratis distribueret version control system. Det giver en enkel, enkelt fil transaktionsbeslutning udgave butik med fuldt frakoblet drift og en effektiv peer-to-peer synkronisering protokol. Det forstår historie-følsomme sammenlægning, letvægts grene, integreret kode review og 3. parts test. det bruger kryptografisk udgave navngivning og klient-side RSA-certifikater. det har god internationalisering støtte, har ingen eksterne afhængigheder, kører på Linux, Solaris, OSX og Windows, og er licenseret under GNU GPL. »

Codeville — http://codeville.org/

«Hvorfor endnu en version control system? Alle andre versionshåndteringssystemer systemer kræver, at du holder nøje styr på forholdet mellem grenene, så de ikke behøver at gentagne gange fusionere de samme konflikter. Codeville er langt mere anarkistisk. Det giver dig mulighed for at opdatere fra eller forpligte sig til at enhver repository til enhver tid uden unødvendige re-fusionerer. »

«Codeville fungerer ved at oprette en identifikator for hver ændring, der er gjort, og huske en liste over alle de ændringer, som er blevet anvendt til hver enkelt fil og den sidste ændring, som ændret hver linje i hver fil. Når der er en konflikt, det undersøger, om en af de to sider er allerede blevet anvendt til den anden, og hvis det gør den anden side vinde automatisk. Når der er et virkeligt ikke automatisk mergeable udgave konflikt, Codeville opfører sig næsten på samme måde som CVS. »

Vesta - http://www.vestasys.org/

«Vesta er en bærbar SCM [Software Configuration Management] system målrettet på at støtte udvikling af software systemer af næsten enhver størrelse, fra forholdsvis lille (under 10.000 kildelinjer) til meget store (10.000.000 kildelinjer).»

«Vesta er et modent system. Den er resultatet af over 10 års forskning og udvikling på Compaq / Digital Systems Research Center, og det var i produktion brug af Compaqs Alpha mikroprocessor gruppe i over to og et halvt år. Alpha-gruppen havde over 150 aktive udviklere på to steder tusindvis af miles fra hinanden, på øst-og vestkysten af USA. Gruppen anvendte Vesta at administrere builds med så meget som 130 MB kildedata, der hver producerer 1,5 GB afledte data. bygger gøres på den østlige side i en gennemsnitlig dag produceres omkring 10-15 GB af afledte data samtlige forvaltes af Vesta. Selv om Vesta er designet med softwareudvikling i tankerne, Alpha-gruppen viste systemets fleksibilitet ved at bruge det til hardware udvikling, kontrol deres hardware beskrivende sprog filer til Vestas kildekode kontrol facilitet og bygge simulatorer og andre afledte objekter med Vestas builder. De medlemmer af det tidligere Alpha-gruppen, der nu er en del af Intel, fortsætter med at bruge Vesta dag i en ny mikroprocessor projekt. »

Aegis — http://aegis.sourceforge.net/