Slēgtā koda iemesli

Pirms atvērtā koda biznesa modeļu taksonomijas mums jāņem vērā slēgtā koda kopējās izmaksas. Ko īsti mēs aizsargājam slēdzot kodu?

Pieņemsim, jūs pieņemat darbinieku, kas rakstītu (teiksim) specializētu jūsu biznesa grāmatvedības sistēmu. Ja kods būtu slēgts nevis atvērts, problēma netiktu atrisināta labāk.

Tātad acīmredzami jūs aizsargājat pārdošanas vērtību, bet uz 95% programmatūras, kas tiek rakstīta iekšējai lietošanai, tas neattiecas. Tad kādi vēl ir ieguvumi būt slēgtam?

Otrs gadījums (nodrošināt pārākumu pār konkurentiem) prasa lielāku pārbaudi. Pieņemsim, jūs atklājat savas grāmatvedības sistēmas kodu. Tā kļūs populāra un kopiena tajā rada uzlabojumus. Tagad arī jūsu konkurents sāk to izmantot. Konkurents iegūst labumu, nemaksājot izstrādes izmaksas un ielaužas jūsu biznesā. Vai tas ir arguments pret atvērto kodu?

Varbūt — jā, varbūt — nē . Patiesais jautājums ir — vai jūsu zaudējumi, izstrādes slodzi pārnesot uz kopienu, pārsniedz zaudējumus, ko rada brīvais kovbojs. Daudzi cilvēki nepietiekami novērtē šo zaudējumu iemeslu, jo:

1. ignorē funkcionālos ieguvumus savaņģojot lielāku izstrādes palīdzību, un 
2. nepietiekami novērtē izstrādes izmaksas.

Patiesībā izstrādes izmaksas jums vajadzēja nosegt tā kā tā, līdz ar to, uzskatīt tās par atvērtā koda izmaksām (ja jūs to nolemjat darīt) ir kļūda.

Šis arguments patiesībā ir nevis pret atvērto kodu, bet gan pret sliktu dizainu. Pareizi uzrakstītā grāmatvedības sistēmā biznesa zināšanām nevajadzētu parādīties kodā, bet gan kādā īpašas valodas specifikācijas shēmā, kas ir realizētās grāmatvedības sistēmas dzinējā (līdzīgi kā datu bāzu shēmas atdala biznesa zināšanas no datu bāzu dzinēja mehānikas). Funkciju atdalīšana ļautu jums sargāt kroņa dārgumus (shēmu), tai pat laikā gūstot maksimālu labumu no atvērtā koda dzinēja.

Ir arī citi slēgtā koda iemesli, kas ir absolūti iracionāli. Jūs varat, piemēram, dzīvot ar ilūziju, ka slēgtais kods padarīs jūsu sistēmu drošāku pret urķiem un krakeriem. Ja tā, es iesaku nekavējošu terapijas sarunu ar šifrētāju. Patiesi profesionāli paranoiķi labi zina, ka nevajag uzticēties slēgtā koda programmatūrai. To viņi zina no savas pieredzes. Drošība ir uzticamības aspekts — tikai algoritmus un implementācijas, kas ir izgājuši pamatīgu vienranga caurskati, var tikt uzskatīti par drošiem.