Forum Mjukvara Programmering och digitalt skapande Tråd

Hjälp mig att förstå öppen källkod i praktiken

1
Skriv svar
Permalänk
Medlem
●

Hjälp mig att förstå öppen källkod i praktiken

Hej,

Behöver hjälp med att förstå öppen källkod i praktiken.

En organisation har ett behov och det behovet kan avhjälpas med stöd av ett IT-system. Eftersom det är 2021, snart 2022, vill man inte köpa ett färdigt system där leverantören äger koden och kanske även datan. Istället vill man utgå från öppen källkod.

Nu startar processen jag behöver hjälp att förstå.

Jag är med såhär långt:
Beställaren ordnar kravspec (lagom nivå då man tänker inte tillämpa någon gammal vattenfallsmetodik). I detta fallet har man ingen intern utvecklar-kompetens och upphandlar därför konsulter för utveckling.

Sen börjar frågorna:
1. Är det rimligt att konsulterna skannar den befintliga floran av öppna källkod eller bör beställaren ha gjort det innan? Jag antar att det förutsätter viss utvecklar-kompetens för att navigera i vad som redan finns/inte finns.

2. Eftersom det är öppen källkod behöver beställaren ordna en egen miljö att bygga och sedan köra systemet i? Antingen on-prem eller moln/driftcenter. Vid köp av hyllprodukt är det ju vanligt med drift i leverantörens moln.

3. Alla IT-system, oavsett hur bra de är, behöver förvaltning och vidareutveckling. Vid köp av en hyllprodukt löser man ofta detta i något form av avtal där leverantören har en supportorganisation. I fallet med öppen källkod förmodar jag att beställaren antingen behöver upphandla konsulter för systemförvaltning, alternativt anställa egen personal för det?

4. Systemet är i drift och allt är frid och fröjd. En annan organisation har samma behov och vill ju givetvis inte uppfinna hjulet på nytt så de bygger en likadan lösning utifrån den öppna källkoden. Den andra organisationen kan sedan, ifall deras behov förändras, ändra och bygga vidare med egna komponenter på sin instans av det som i grunden är samma källkod? Skulle någon av organisationerna lägga till nya funktioner så kan den andra kopiera den om det skulle vara relevant? På så vis sker en kollektiv utveckling av systemet?

Jag hoppas att det finns några insatta individer här på SweClockers som kan hjälpa mig förstå detta bättre

Tack på förhand och god jul!

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Alltså detta är ju väldigt luddigt då i vad beställaren faktiskt vill ha, "vi vill utgå från öppen källkod" betyder basically inget alls.

1. Om du beställer ett system på öppen källkod är det ju upp till konsulten att ta det eller inte, gissar dock att du kommer behöva specificera mer exakt vad du vill innan du får en offert och eller projektförslag (om du ens får det). Det är ju skillnad om ni vill anpassa ett system som finns eller bygga från grunden, eller att ni kräver att konsulten ska söka med lykta efter just det ni vill ha.

2. Återigen faller ju detta på vad du som beställare specificerar och även lägger som grund, konsultens jobb kan innefatta att hitta lösningarna åt dig men det kostar ju då med.

3. Ja du måste ju själv supporta det eller köpa in tjänsten, det gör du annars med bara att det är inbakat i priset och ofta det som är dyrast.

4. Delvis är det så öppen källkod är tänkt att fungera men mer troligt är att nya företag kommer utveckla egna system som bara hakar på open-source delen, företag är inte designade tyvärr för att dela med sig av fördelar till eventuella konkurrenter.

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Ferrat:

Alltså detta är ju väldigt luddigt då i vad beställaren faktiskt vill ha, "vi vill utgå från öppen källkod" betyder basically inget alls.

1. Om du beställer ett system på öppen källkod är det ju upp till konsulten att ta det eller inte, gissar dock att du kommer behöva specificera mer exakt vad du vill innan du får en offert och eller projektförslag (om du ens får det). Det är ju skillnad om ni vill anpassa ett system som finns eller bygga från grunden, eller att ni kräver att konsulten ska söka med lykta efter just det ni vill ha.

2. Återigen faller ju detta på vad du som beställare specificerar och även lägger som grund, konsultens jobb kan innefatta att hitta lösningarna åt dig men det kostar ju då med.

3. Ja du måste ju själv supporta det eller köpa in tjänsten, det gör du annars med bara att det är inbakat i priset och ofta det som är dyrast.

4. Delvis är det så öppen källkod är tänkt att fungera men mer troligt är att nya företag kommer utveckla egna system som bara hakar på open-source delen, företag är inte designade tyvärr för att dela med sig av fördelar till eventuella konkurrenter.

Gå till inlägget

Tack för din återkoppling och bra poänger!

Jag omformulerar:

Man vill inte ha en hyllprodukt från en leverantör utan själva ha full kontroll på koden och datan i syfte att inte ligga i händerna på leverantören. Eftersom man inte heller vill uppfinna hjulet på nytt så ger man de upphandlade konsulterna i uppdrag att se om det finns någon öppen källkod-lösning att helt eller delvis utgå ifrån. Om det inte finns kör man från scratch.

I detta fallet leker vi också med tanken att det är en offentlig organisation som vill ge medborgare insyn i systemets uppbyggnad och samtidigt göra det möjlighet för andra offentliga aktörer att kopiera lösningen och på så vis spara skattepengar.
Då publicerar man systemet som öppen källkod för att andra ska kunna ta del?

Genom att systemets källkod finns öppen kan intresserade medborgare själva läsa koden och lämna förslag på nya funktioner, förbättringar o.s.v.?

Om organisationen vill ta nästa steg och även ge andra tillgång till vissa data så behöver de upprätta API:er?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av A.H.Z:

Tack för din återkoppling och bra poänger!

Jag omformulerar:

Man vill inte ha en hyllprodukt från en leverantör utan själva ha full kontroll på koden och datan i syfte att inte ligga i händerna på leverantören. Eftersom man inte heller vill uppfinna hjulet på nytt så ger man de upphandlade konsulterna i uppdrag att se om det finns någon öppen källkod-lösning att helt eller delvis utgå ifrån. Om det inte finns kör man från scratch.

I detta fallet leker vi också med tanken att det är en offentlig organisation som vill ge medborgare insyn i systemets uppbyggnad och samtidigt göra det möjlighet för andra offentliga aktörer att kopiera lösningen och på så vis spara skattepengar.
Då publicerar man systemet som öppen källkod för att andra ska kunna ta del?

Genom att systemets källkod finns öppen kan intresserade medborgare själva läsa koden och lämna förslag på nya funktioner, förbättringar o.s.v.?

Om organisationen vill ta nästa steg och även ge andra tillgång till vissa data så behöver de upprätta API:er?

Gå till inlägget

Ja då kommer det kosta, först kommer det kosta för att få ett förslag från konsulten hur ni ska lösa det och sedan kommer det kosta att få den lösningen. Troligen blir det lättare att jobba från grunden om det inte är något vanligt ni är ute efter.
Vidare kommer "insyn" i koden för medborgare troligen ställa till mer problem än lösningar, alternativet som många kör är just att ha ett system med öppen API, det är något helt annat. Säkerheten på öppen källkod är ännu viktigare än closed source iom att alla hål är öppet annonserade annars.

Lämna förslag på förbättringar går ju utan kodinsyn? Det du eventuellt gör är mer arbete för den som måste granska eventuella kodförslag, features behövs ingen kodinsyn för och minskar risker. Du kan titta på historien som är relativt färsk om universitet som nu inte får skicka in något till linux kerneln för att de medvetet skicka in dålig kod som kosta massa tid och kom med risker.

Är det ett icke kritiskt system så visst men då ska det finnas en skäl för det, exempelvis om du har en router med open source som styr, då kan du låta communityn pilla med den medan företaget slipper leta vissa buggar och kan "låna" kod för updates etc. Det gör även en del "good will" och att produktens liv troligen räcker lite längre, men att bara ha open source för saken skull är nog inte att rekommendera.

Snarare borde isf beställaren har massiva krav på dokumentation och överskådlighet själva över koden samt modulär kod som underlättar eventuella tillägg av funktioner som folk ber om.

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Redigera
Citera flera Citera
Permalänk
Medlem
●

Allt beror på hur du beställer. Du kommer att få tillgång till all kod som är utvecklat av leverantören.
Om du vill kan du ställa kravet att lösningen ska kunnas släppas som öppen källkod av dig efter leverans.
Du kan också begära att lösningen ska byggas runt en befintlig produkt (som kanske är open-source).

Men många gånger är det inte rimligt att själv ta fram lösning när det finns färdiga tjänster att använda.
Tex, så tror jag ni använder Office365 istället för att ta fram eget. Använder kanske ett lönesystem som ligger i molnet och man betalar per år för använda.
Att utveckla & drifta egna system är mycket dyrare än COTS/hyllprodukt.
Alla större företag har idag samma syn. COTS först och om kostnaden blir för hög (eller inte går) att anpassa COTS systemet till sin egen process, köp in eller egenutveckla en egen lösning.

Allt utom de enklaste system brukar komma med en en del beroenden på andra mjukvarukomponenter, infrastruktur och tjänster.
Normalt så är det inte koden som gör att man blir beroende av leverantören efter leveransen är gjord, utan komplexiteten i integrationer, affärsprocesserna, drift och och felsökning. Kompetensen finns normalt inte hos beställaren, vilket är rimligt eftersom mjukvaru utveckling och system drift troligtvis inte är deras kärnverksamhet.

Tillbaka till open-source.
Leverantörer nästan garanterat använda komponenter eller tjänster som är open-source.
Att tillhandahålla en hel kundanpassad lösning som open-source ger inte mycket åt beställaren. Det är bara om man tar fram en tjänst/platform som är tänkt att andra ska kunna återanvända. Men de allra flesta sådana system tas fram från mjukvarubolagen själva så de kan få så stor spridning av tjänsten/komponenten och sedan ta betalt för support etc.

Sikta istället på att vara öppen med vilka tjänster och komponenter lösningen är uppbyggd av. Lägg sen till API'er som tredje part kan använda sig av för att hämta information eller utföra tjänster mot.

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara