Labview-skaber om Open Sourcing: En distraktion, som ville bremse os

Selvom National Instruments gerne tager imod forslag fra brugerne af virksomhedens programmeringsmiljø Labview, så ønsker virksomheden for øjeblikket ikke gøre produktet open source.

En af de pointer, der fra tid til anden bliver fremhævet om open source, er muligheden for, at brugerne dels kan ændre i koden, og at gode/geniale ændringer kan finde vej tilbage i den originale programdistribution til gavn og glæde for alle brugere.

Helt den model benytter National Instruments (NI) ikke i forbindelse med virksomhedens visuelle programmeringsmiljø Labview. Ikke desto mindre baserer produktets udvikling sig i høj grad på den såkaldte IdeaExchange, som er et NI-forum på nettet, hvor brugere kan foreslå og stemme på ændrings- og forbedringsforslag til Labview. Konceptet er forholdsvist nyt for NI, og i den seneste 2011-udgave fandt 14 brugerændringsforslag vej til Labview.

Skaber af Labview og medstifter af National Instruments Jeff Kodosky er så begejstret for brugerindsparkene, at han efter sigende hver dag er inde at tjekke forslag på IdeaExhange.

Version2 mødte Jeff Kodosky til dette års NI-Week i Austin, Texas, og spurgte ham, om det ikke ville være hurtigere, at gøre Labview til et open source-produkt, så brugerne selv kunne submitte ændringsforslag til programmeringsmiljøet direkte i stedet for at skulle formulere ændringsforslag via IdeaExchange.

Kodosky var dog ikke udelt begejstret for det perspektiv. Han frygter således, at open sourcing af Labview ligefrem vil gå udover udviklingen af produktet, i stedet for at forbedre den. Han begrunder det med, at et open source-Labview også ville betyde, at National Instruments skulle til at vedligeholde, supportere og dokumentere produktet, hvilket ville fjerne fokus fra udviklingen af programmeringsmiljøet.

Og derudover vil NI heller ikke uden videre kunne lave helt om i Labviews arkitektur fra den ene udgave til den næste, hvis der var tale om et open source-projekt, argumenterer han.

»Set fra vores perspektiv lige nu, hvor vi forsøger at levere høj produktivitet til ingeniører og forskere, så tror jeg, det ville være en distraktion, som ville bremse os,« siger Jeff Kodosky og tilføjer:

»På den anden side, kan jeg helt sikkert godt se værdien i crowd-sourcing og brugerbidrag, så vi forsøger fortsat at åbne Labview mere og mere.«

Ikke forretningshemmeligheder i koden

Jeff Kodosky, påpeger, at når han ikke umiddelbart går med planer om at gøre Labview open source, så er det ikke fordi, der som sådan er hemmeligheder i koden (længere).

»Der plejede at være visse forretningshemmelige algoritmer i den. Men dem har vi talt så meget om tidligere, og vi har samarbejdet med universiteter om at forbedre dem,« siger han.

Og som sådan mener Jeff Kodosky heller ikke, at der er noget at skamme sig over i Labview-koden, som skulle gøre den uegnet til offentliggørelse. Det kan dog knibe lidt med dokumentationen, og blandt andet derfor, ser Kodosky det også i første omgang som en byrde frem for en fordel at gå open source.

»Jeg mener, vi udvikler god kode, men koden er aldrig så veldokumenteret, som man godt kunne tænke sig. Hvis vi nu åbnede op for noget ... hvor meget dokumentation, skulle vi så levere? Hvor meget uddannelse skulle vi så stå for? Hvor meget skulle vi forklare, hvad der foregår hvor og hvorfor?,« siger han og fortsætter:

»Det er vanskeligt nok for os at holde trit med den slags internt. Vi havde en stor debat om, hvorvidt scripting var noget, vi skulle åbne op for og tillade at folk kan gøre. Jeg er en stor fortaler for det (at åbne op for scriptning, red.), men der har også været en masse folk, som har sagt, at det ville blive et supportproblem, fordi vi bliver nødt til at dokumentere det og forklare det til folk, som forsøger sig frem … og så virker det ikke på den måde, de forventer, det virker på og så videre.«

Og det er netop den slags hensyn, NI har i forhold til at gøre Labview mere åbent eller til et direkte open source-produkt, forklarer Kodosky.

»Jeg vil gerne presse på for at gøre det mere og mere åbent, men jeg vil stadig gerne have kontrol over det,« siger han.

Labview

Labivew adskiller sig fra gængse måder at sammensætte kode på ved, at programmeringen som udgangspunkt foregår grafisk. Det vil sige, at kasser og streger repræsenterer funktioner og metodekald, som kan manipuleres grafisk af programmøren – lidt som muligheden for at skabe klassediagrammer og dataflowdiagrammer i visse IDE'er, men hvor der i Labview er en del komplette funktioner i programmet på forhånd, så koden umiddelbart kan køre.

Programmeringsmiljøet bliver blandt andet brugt i kritiske miljøer, eksempelvis til at kalibrere magnetfeltet, der holder plasmaen på plads i eksperimentelle fusionsreaktorer. Et mere nede-på-jorden-eksempel på Labview-kode kan være styringen af en robot-arm, hvor drivere indbyggede i programmeringsmiljøet sørger for, at armen bevæger sig, når de grafiske elementer er manipuleret på plads, og programmet er kompileret.

Labview udkom for første gang for 25 år siden i 1986.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Jakob Møllerhøj Editor

Selvfølgeligt vedligeholder og supporterer NI Labview, som landet ligger nu - og nogen kunne måske ligefrem anføre, at virksomheden netop derfor ikke behøver score kassen på licenser, men kan gøre det på netop support, certificering el. tilpasning af produktet, sådan som open source vist nok plejer at løbe rundt. - Jakob

  • 2
  • 0
Log ind eller Opret konto for at kommentere