Gode råd om shareware

Af Jakob Paikin, forfatter til Rekon, der tidligere var shareware. Alle rettigheder forbeholdes! Teksten må ikke mangfoldiggøres, kopieres eller udgives uden forfatterens udtrykkelige skriftlige tilladelse!

Denne tekst er en stærkt udbygget udgave af min artikel i Datatid nr. 10/95, side 40. Offentliggjort her med tilladelse fra Datatid.


Oversigt over ændringer (nyeste først):


Mange programmører tror, at hvis man blot udsender et program som shareware kan man tjene store penge hurtigt og uden noget særligt arbejde. Intet kunne imidlertid være mere forkert. At få succes med shareware, og dermed få registreringer, kræver en del arbejde.

Her vil jeg give nogle gode råd til kommende og nuværende shareware-udviklere. Alle disse råd stammer enten fra mine egne erfaringer, eller fra iagttagelse af andre shareware-udviklere der har succes (eller det modsatte!) med deres produkt. Selv har jeg udviklet og solgt mine egne shareware-programmer i over seks år med rimelig succes (ca. 10 registreringer om måneden, over 300 registrerede brugere). Jeg forudsætter, at du kender shareware-princippet.

Det helt generelle råd er at betragte shareware-produktion på linie med kommerciel software. Både programmets kvalitet og support skal derfor være på et højt niveau. Helt overordnet kan de nedenstående råd sammenfattes i ordnene professionalisme og seriøsitet.

Indhold

Valg af produkt

De bedste chancer for succes findes naturligvis på områder, hvor der ikke findes konkurrende produkter. Manglende konkurrence kan opstå af flere grunde. De typiske er at dit program kan noget helt nyt og hidtil ukendt (det sker sjældent); at lignende produkter er for dyre eller at der ikke findes et sådant produkt på dansk.

Hvis du skal til at udvikle et helt nyt program, blot for at udsende det som shareware, er det derfor vigtigt at undersøge markedet og spørge dig selv - og eventuelt potentielle brugere - om produktet har en chance. Har du allerede et program, måske har udviklet til eget brug, er en 'markeds-undersøgelse' naturligvis overflødig.

Klargør målgruppen

Det er vigtigt at holde sig for øje, hvem der skal bruge programmet. Er det et hjælpeprogram til nye PC-brugere skal brugsanvisningen (manual) være mere udførlig, og kravene til programmets brugervenlighed og fejltolerance er langt højere. Samtidig skal man nautrligvis undgå avancerede tekniske udtryk, medmindre disse forklares grundigt.

Forsøg ikke at dække en alt for bred målgruppe - resultatet bliver ofte, at ingen i gruppen bliver tilfredse.

Gør klart for brugeren, hvem målgruppen er - også i beskrivelsen af programmet. På den måde undgår brugere at spilde tid på at afprøve et program, der i virkeligheden er irelevant.

Vær kritisk!

Intet er lettere end at overvurdere sine egne evner eller ens eget programs fortræffeligheder. Det er imidlertid meget vigtigt at have en kritisk og realistisk indstilling til sit eget produkt. I modsat fald bliver hverken produkt eller udvikler taget alvorligt. Få gerne venner, bekendte eller familie til at afprøve programmet og komme med kommentarer. Jo mere test-gruppen ligner målgruppen, jo mere værdifulde er kommentarerne.

Afprøvningen af programmet skal gerne være grundig. Jo mere gennemprøvet programmet er, jo lettere er det at få registreringer.

Vær ikke tilbageholdende med at foretage ændringer i programmet. Hvis en typisk bruger i din test-gruppe finder programmet ulogisk, så prøv at finde ud af, hvordan det kan gøres mere logisk. Husk på, at med shareware er det brugerne der bestemmer: Er de ikke tilfredse betaler de ikke!

Den kritiske holdning er vigtig både i forhold til valg af produkt, fastsættelse af pris, ved ydelsen af support og ved markedsføringen af programmet.

Prisen

Fastsætelse af registreringsprisen er ofte meget vanskeligt for selv garvede shareware-forfattere. På den ene side vil udvikleren gerne tjene mange penge hurtigt, på den anden side afskrækker høje priser brugerne fra at registrere. Oftest kan det bedre betale sig at satse på mange, billige registreringer end få, dyre.

Der kan ikke gives faste regler for, hvor meget et program må koste. Generelt er det dog opfattelsen, at priser under 300 kr. (inkl. eventuel moms) giver langt det bedste resultat. Meget afhænger af programmets type. Eksempelvis vil de færreste betale mere end ca. 100 kr. for et menuprogram, mens et avanceret billedbehandlingsprogram godt kan koste 350-400 kr.

Vær også opmærksom på, at en for lav pris kan være et problem. Brugeren kan da tro, at udvikleren ikke selv tror på sit produkt.

Fastsæt prisen ud fra hvilken nytte brugeren har af programmet, ikke ud fra hvor lang tid det har taget at udvikle. Se eventuelt på hvad lignende programmer koster, både kommercielt og som shareware.

Hvis du vælger at lade prisen stige i en senere version, så accepter den gamle pris, hvis en bruger registrerer en gammel version. Brugerne føler sig bondefanget, hvis de efter registrering (til gammel pris) afkræves endnu et beløb.

Hvordan får man brugerne til at betale?

Først og fremmest skal programmet naturligvis være godt og fungere korrekt. Det betyder også, at der skal medfølge en grundig brugsanvisning (manual), der skal sætte brugeren i stand til at afprøve programmet. Også installationen er vigtig, da det giver brugeren det allerførste indtryk af produktet.

Det er efterhånden blevet klart, at registreringer bedst opnås ved at lokke/presse brugeren en smule. Det kan enten gøres ved at tilbyde brugeren en fordel ved at registrere (eksempelvis specialtilpasning af programmet, tillægsprogrammer eller en trykt manual).

Den hyppigste løsning er dog at nogle funktioner i shareware-udgaven er begrænset eller slået fra. De 'lukkede' funktioner må ikke være centrale - så bliver programmet blot en demo-udgave.

Hovedreglen er, at de lukkede funktioner ikke må forhindre en komplet gennemprøvning af programmet. De lukkede funktioner bør være af en art, der gør programmet bedre, men som ikke er afgørende for brugen.

I et grafikprogram ville det eksempelvis være forkert at begrænse muligheden for at gemme og udskrive. Derimod vil en begrænsning i antallet af filformater der kan importeres være i orden.

I begrænset omfang kan såkaldte 'nag-screens' anvendes. Det er skærmbilleder, der husker brugern på, at vedkommende endnu ikke har registreret.

Sådanne skærme bør ikke forekomme mens programmet bruges. I stedet bør de vises lige når pgroammet starter, eller når det afsluttes - gerne sammen med en kort pause på 5-10 sekunder.

Tidsbegrænsning af programmet kan ikke anbefales. Dels kan tekniske fejl bevirke, at brugeren uretmæssigt afskæres fra at afprøve systemet. Dels kan en tidsfrist, beregnet fra første installation af programmet, blive overskredet, selvom brugeren reelt ikke har nået at prøve programmet (f.eks. på grund af ferie). Hvis du absolut vil have et tidsmæssigt aspekt ind, så kan en eventuel 'nag-screen'-pause gøres længere og længere, efterhånden som prøvetiden overskrides.

Giv en rimelig prøvetid, afpasset efter programmets kompleksitet. Typisk vil prøvetider under 30 dage være for lidt, da de færreste brugere benytter et program hver dag.

Som det også nævnes nedenfor vil personlig kontakt ofte få brugerne til at registrere. Det må dog ikke ske med 'trusler', pression eller andre 'dørsalgs-metoder'. Seriøs, høflig og imødekommende kontakt giver derimod bonus.

Giv brugeren noget for pengene!

De færreste shareware-brugere registrerer af rent moralske eller principielle grunde. Brugerne vil have noget for deres penge! Som minimum bør brugeren kontaktes af forfatteren, enten skriftligt eller telefonisk. Den personlige kontakt er meget væsentlig, da de fleste brugere godt kan lide at får en personlig betjening som de store softwarehuse ikke kan tilbyde.

Brugeren bør naturligvis også få fjernet de eventuelle begrænsninger der er i programmet. Det kan enten ske ved at brugeren får en personlig kode, der skal indtastes, eller ved at brugeren får tilsendt en diskette med en speciel registreret version.

Nogle brugere kan godt lide at modtage en trykt manual. Den enkelte forfatter må naturligvis afgøre med sig selv, om vedkommende vil bruge penge (trykning og porto) på dette. Et tilbud om, at brugerne kan bestille en trykt manual separat er ikke altid en god ide, blandt andet af praktiske grunde.

Det er en god ide at sende mindst een ny version til registrerede brugere. Registreres eksempelvis version 3.0, så send version 3.1 gratis, når den er klar.

Beskriv i manualen præcis, hvad brugeren får for sin registrering. Undlad useriøse kommentarer som 'du får fred i sjælen', 'du hjælper en stakkels fattig programmør' - det virker barnligt og uprofessionelt.

Flere registreringsformer?

Hvis programmet henvender sig til flere forskellige målgrupper, eksempelvis både privatpersoner og virksomheder, kan det være fristende at have flere forskellige registreringspriser. Mange forfattere føler sig også fristet til at tilbyde forskellige niveauer af support eller opgradering, med tilhørende forskellige priser.

En differentieret prisstruktur kan godt gennemføres med held, men det kræver mere administration fra forfatterens side og kan give anledning til tvivl hos brugerne. Er der eksempelvis forskellig pris for privat og kommerciel brug kræves en meget præcis definition af, hvad kommerciel brug betyder.

Som ny shareware-udvikler vil det klogeste nok være at nøjes med en pris for alle brugere. Viser programmet sig at være det ekstra arbejde værd kan det overvejes at differentiere priserne.

Selve registrerings-processen

Når en bruger beslutter sig for at registrere et program skal det være let at gøre. Indlæg gerne et registreringsskema i programmet online og/eller som tekst-fil. Skemaet skal kunne udfyldes og udskrives let og skal naturligvis indeholde de nødvendige oplysninger (brugerens navn, adresse, postnummer, evt. telefonnummer og diskettestørrelse). Det udskrevne skema bør angive din adresse og registreringsbeløbet.

Ved at bruge et fast registreringsskema opnås flere fordele: De nødvendige oplysninger anføres klart; brugeren er ikke i tvivl om, hvordan registreringen skal ske; og du får en let mulighed for at oprette et kartotek over registrerede brugere.

De fleste brugere kan betale med check, men har du en girokonto så angiv kontonummeret.

Distribution

Meningen med shareware er jo, at flest mulige potentielle brugere får mulighed for at afprøve programmet. Det er derfor afgørende at programmet spredes så meget som mulig.

Der er to kanaler som forfatteren direkte kan benytte: Dels BBS'er og Internet, dels egentlige shareware-distributører. På langt de fleste BBS'er kan enhver uploade filer. Det er derfor let for en shareware-udvikler at sprede sit program denne vej. Eneste udgift er her telefonregningen. På Internet kan man f.eks. fra sin homepage give brugere mulighed for at hente programmet. Det kan være sværere at finde et egnet FTP-site, der tillader at man lægger filer ind. Du kan også prøve at kontakte SunSITE Denmark, der stiller plads til rådighed til udvalgte projekter.

Shareware-distributører kan være en stor hjælp, når et program skal udbredes, specielt hvis målgruppen ikke kan forventes at have modem. Problemet er dog, at mange distributører er useriøse og forsøger at 'snyde' med shareware-princippet.

Generelt bør distributøren ikke tage mere end ca. 60 kr. for en diskette, for bliver prisen meget højere, tror brugerne at de har betalt for programmet samtidig - og så registrerer de ikke. Er der tale om CD-ROM udgivelser bør prisen ikke ligger over 150-200 kr.

Sørg også for, at distributøren tydeligt forklarer shareware-princippet for sine kunder. En del distributører omtaler shareware som 'gratis software' eller giver på anden måde det fejlagtige indtryk, at der kun skal betales for disketten.

Endelig vil der i større eller mindre grad forekomme 'personlig' spredning af programmet. Det vil sige, at en bruger ser eller hører om programmet hos en anden og derigennem får en kopi. Selvom dette oprindelig var den primære distributions-form, har den formentlig mindre betydning i dag. Ofte vil en bruger, der har set programmet hos en bekendt, ønske at få den nyeste version først eller spørge forfatteren om noget.

Support

Den bedste form for support er den telefoniske, men der er også risiko for, at dette kan bliver meget tidskrævende. Alternativerne er support gennem elektronisk post (Internet eller BBS) eller pr. brev.

Selvom man ikke ønsker at tilbyde telefon-support, bør der alligevel angives et telefonnummer, der kan bruges i nødstilfælde, eksempelvis hvis meget vigtige data er blevet ødelagt eller lignende.

Angiv klart, hvordan support ydes. Skriv det forrest i manualen og angiv det på et lettilgængeligt sted i selve programmet, f.eks. på en hjælpeskærm. Når en bruger her behov for hjælp har vedkommende ikke lyst til at skulle lede længe efter en kontaktmulighed.

Når en bruger skal have support er det meget vigtigt at huske på, at man som udvikler kender programmet betydelig bedre end en bruger nogensinde vil. Pas derfor på, at brugeren ikke kommer til at føle sig dum - selvom vedkommende måske er det! Henvisninger til manualen eller lignende er ikke godt nok - løs så vidt mulig problemet for brugeren.

Ydes telefonisk hjælp bør du så vidt mulig lede brugeren igennem løsningen skridt for skridt.

Hvis det viser sig, at der er en egentlig fejl i programmet, så erkend det. Forsøg på at skjule egne fejl giver ikke noget godt indtryk - dette er blandt andet illustreret ved regnefejlen i Pentium-chippen. Tilbyd brugeren en gratis rettet udgave når den er klar.

God service og support giver ofte mange registreringer. Samtidig giver det et godt indblik i hvilke problemer brugerne typisk har, hvilket gør det muligt at afhjælpe disse problemer i kommende versioner, eventuelt gennem uddybende forklaringer i manualen.

Image

Både når der ydes support, når programmet distribueres og i selve programmet bør du være opmærksom på hvilken fremtoning/image programmet har, da det uundgåeligt smitter af på hvordan brugerne opfatter dig. Sørg også her for at passe til målgruppen.

Sprogbrugen i programmet, i hjælpetekster og i manualen skal være det samme. Forsøg at holde samme stil igennem hele programmets design. Vælg om programmet skal fremstå som morsomt og farvestrålende, eller strømlinet og afdæmpet.

Vælg her, om du vil udgive programmet under et firmanavn eller dit eget navn. Et eventuelt firmanavn skal vælges med omtanke og ikke give et forkert indtryk af firmaets størrelse. Således vil eksempelvis 'European Software Center' nok være lidt overdrevent for et privatperson der programmerer i fritiden. Overdreven brug af 'smarte' ord kan også virke imod hensigten, eksempelvis vil 'Ultra-Power Super Cyber Software' ikke virke lige godt på alle kundergrupper.

Undgå for alt i verden falske (juridiske) betegnelser, f.eks. A/S, ApS, A.m.b.A, Inc., Corp.

Opdateringer

De færreste programmer er fejlfri eller perfekte i de første par versioner. Det er defor vigtigt at have en forholdsvis klar opdaterings-politk.

For det første bør nye versioner være kompatible med tidligere versioner. Er det umuligt, skal data i det mindste kunne konverteres. For det andet er det ofte uklogt at love noget om, hvornår en ny version er klar. Fortæl hellere brugerne, at der ikke kan sættes nogen fast dato - så ved brugerne hvad de har at rette sig efter.

Sørg også for, at få spredt den nye version så hurtigt som mulig, så brugerne ikke bliver ved med at få fat i de gamle versioner - det er særlig vigtigt hvis du flytter eller hæver prisen på programmet. Send den nye version til alle de shareware-distributører du har kendskab til.

Vær tålmodig!

Man bliver ikke rig i en fart af at udvikle shareware. Fra første udgivelse af et nyt program til den første registrering kan der let gå et år eller mere.

Det betyder ikke, at der ikke skal udsendes nye versioner i den periode - det er det derimod meget vigtigt at der bliver. På den måde kan brugerne se, at produktet ikke er en døgnflue, men at det derimod er alvorligt ment. Annoncer gerne nye versioner, f.eks. gennem en homepage på Internet.