Mówiąc o otwartości i aplikacjach internetowych nie sposób nie poruszyć innego istotnego tematu, który w nadchodzących latach stanie się bardzo istotny dla środowiska internautów: bezpieczeństwa. Powyżej była już mowa o niepewności, jaką wnoszą aplikacje internetowe: nie wiadomo, czy w miejscu, gdzie kiedyś był serwis udostępniający pewną funkcjonalność lub dane, nadal będzie ten sam serwis oraz czy czas jego odpowiedzi będzie akceptowany przez użytkownika naszej aplikacji.

Ponadto, Internet pełen jest ludzi, którzy poprzez "wstrzyknięcie" złośliwych danych lub kodu chcieliby przejąć kontrolę nad mocą obliczeniową i danymi zgromadzonymi na serwerach. Te powody są wystarczające, aby informatycy tworzący aplikacje dobrze nauczyli się pojęć takich jak "autoryzacja", "autentykacja", "walidacja danych" i "programowanie defensywne". Wymiar bezpieczeństwa przetwarzania oraz zgromadzonych danych w najbliższych latach będzie tym, co musi rozważyć każdy autor kodu, przy każdym rozwiązaniu, które tworzy.

Proces: zwinność kontra rygor

I wreszcie ostatni dylemat, przed jakim staje programowanie AD 2010. Od lat około dziesięciu środowiska programistyczne przez wszystkie przypadki odmieniają słowo "zwinny" (agile). Coraz więcej coraz poważniejszych projektów realizowanych jest dzięki pryncypiom charakterystycznym dla podejścia "lekkiego", a więc bliskiej interakcji z klientem, iteracyjnemu podejściu, pracy zespołowej, silnej koncentracji na produkcie i jego cechach oraz nadaniu "ludzkiego wymiaru" tworzeniu oprogramowania. W nieomal dekadę po podpisaniu tzw. Agile Manifesto, fundamentalnej deklaracji podkreślającej znaczenie interakcji, zmienności i współpracy ponad realizację planów i ustrukturalizowany proces, metodyki "zwinne" znalazły swoje miejsce w kursach akademickich i działach rozwoju wielu przedsiębiorstw (niektórzy twierdzą nawet, że większości).

Sprzyjający klimat na "zwinność" zapewniły niespełnione obietnice metod "ciężkich", czyli formalnych lub półformalnych. Przy dość dużym biurokratycznym narzucie na dokumentację, zdefiniowany proces i kontrolę jakości, nie oferowały efektów wyraźnie przerastających praktyczne osiągnięcia dobrze komunikujących się i ściśle współpracujących z klientem grup roboczych. Nade wszystko pozostawały odporne na problem zmienności wymagań.

Ale w pewnym momencie nastąpił chyba przesyt; zwłaszcza, że pod hasłem agile zaczęto promować tzw. wolną amerykankę i jakościową miałkość. W przeciwną stronę idzie inicjatywa SEMAT (Software Engineering Method and Theory) rozpoczęta pod koniec 2009 roku. U jej podstaw tkwi zasadnicze przekonanie, że budowa złożonego oprogramowania jest dziedziną inżynierii, a tym samym potrzebuje solidnej naukowej podbudowy. Tymczasem informatyka, jak piszą sygnatariusze tzw. Call for Action (równie prominentni co wcześniejsi sygnatariusze Agile Manifesto), zaczęła przypominać modę damską - zamiast solidnych badań nad tym co dobre, a co złe, pojawiły się sezonowe mody, zaś gromady wyznawców zastąpiły grupy solidnie przygotowanych specjalistów. Sygnatariusze SEMAT chcą więc wrócić do korzeni, przywrócić informatyce solidne podstawy formalne i wyesencjonować tzw. matkę wszystkich metod, czyli zestaw działań, narzędzi, wzorców, metod i praktyk dających w sumie to, co nazywają great software.

Szykuje się więc w informatyce kolejny spór o charakterze fundamentalnym. Zwykle takie spory okazywały się bardzo konstruktywne i dobrze służyły inżynierii oprogramowania. Oby tak było i tym razem.