Środowiska według popularności:

1. WWW – 9
2. Windows – 8
3. Cross-platform – 5
4. MacOS – 2
5. Linux – 1

Nie da się wskazać dominującego języka programowania. Używaliście bardzo różnych technologii, w tym Ruby on Rails, C#, Pythona, PHP. Sporo widgetów było napisane w HTML+CSS+Javascript, lecz to głównie ze względu na platformy które wybieraliście.

Od każdego ze zgłaszających wymagany był kod źródłowy. Posłużył nam on do “postawienia” niektórych aplikacji na naszych wewnętrznych serwerach, a w pozostałych do weryfikacji czy program nie robi nic podejrzanego. Niektóre ze zgłoszeń mają ustaloną licencję (głównie GPL), większość nie ma. Bez Waszej zgody nie będziemy w żaden sposób udostępniać kodu czy aplikacji – chcemy z Wami współpracować w tej kwestii. O tym zresztą dalej. Wszyscy też wywiązaliście się z wymagań zadeklarowania używanych komponentów i ich praw autorskich. Była to w zasadzie tylko kwestia znalezienia sobie darmowych komponentów, i wypisania nam w skrócie na jakich licencjach są.

Sędziowanie zostawione było na ostatnią chwilę – gdy wszyscy członkowie Kapituły wreszcie mogli zasiąść z kawą i na spokojnie ocenić wszystkie zgłoszenia. Każdy z programów miał swoje 5 minut, i pierwsze wrażenie liczyło się mocno, choć nie było decydujące.

Z wieloma widgetami czy aplikacjami mieliśmy problem – ciężko je było nam uruchomić. Główne przyczyny tego to zaszyte w kodzie na stałe URLe, wymagania nietypowych bibliotek czy też specyficznej wersji PHP. Widget pod Adobe AIR nie chciał działać w najnowszej (nadal beta) wersji środowiska, ruszył dopiero po zainstalowaniu starszej. Podobnie było z widgetem pod Yahoo, choć tam trzeba było za to zainstalować najnowszą.

Regulamin konkursu określał jakie są główne kryteria oceny:

a) Funkcjonalność i ergonomia projektu,
b) Stopień wykorzystania zasobów Portalu,
c) Przejrzystość i zawartość merytoryczna dokumentacji
Dodatkowym kryterium wpływającym na ocenę Prac Konkursowych będzie funkcjonalność Pracy Konkursowej wspomagająca integrację społeczności Grono.net.

Kapituła zasiadła więc w sali konferencyjnej, skonfiskowano i podłączono do rzutnika pierwszy z brzegu laptop z Visŧą (potrzebną do odpalenia jednego z widgetów). Zabraliśmy ze sobą też jednego MacBooka, który był potrzebny w podobnym celu. I po kolei, każde zgłoszenie z przygotowanej uprzednio listy:

1. sprawdzamy czy działa. jeśli nie, naprawiamy lub instalujemy co trzeba. sporo rzeczy nie chodziło od razu.
2. prezentowany jest opis aplikacji, według autora i według mnie, czyli rezultaty wcześniejszych uruchomień
3. Kapituła podziwia sam program, czyli wygląd jak i funkcjonalność, oraz rozważa oryginalność pomysłu
4. jeśli uzna go za godny dalszej uwagi, zapisujemy nazwisko autora na tablicy

Po przedstawieniu wszystkich zgłoszeń, Kapituła, nadal zamknięta w pokoju, oddawała głosy. Każda z 8 obecnych osób mogła przyznać po jednym punkcie trzem różnym zgłoszeniom. Z obserwacji wynikało, że bardzo istotne było pierwsze wrażenie, a najważniejsze – czytelność i funkcjonalność interfejsu. Każdy ważył jednak różne czynniki nieco inaczej – niektórzy stawiali na aspekt integracji społeczności, inni na bogactwo funkcji, jeszcze inni próbowali zweryfikować oryginalność pomysłu. Zaawansowanie techniczne nie było decydujące bezpośrednio, ale zdecydowanie łatwiej było wyróżnić się projektom ukończonym i dopracowanym. Jeśli program czy widget był napisany na szybko lub niedokończony, było to widać wyraźnie. Istotne też było, aby widget prezentował wyniki działania szybko – Kapituła nie miała czasu czekać 5 minut aż coś wyliczy czy zaktualizuje.

Po oddaniu głosów, nie było problemu z rozstrzygnięciem decyzji. Choć Kapituła była daleka od jednomyślności, nagrodzone projekty mocno odstawały od konkurencji, i jasne było komu przyznać nagrodę.