Navigazione

Unpacking SMAU Brescia 2009: le start-up

28 Marzo 2009

Ecco alcune delle start-up incontrate durante l’evento di Brescia.

Closr

Se ne è parlato su diversi blog nei giorni scorsi, e tra tutte le proposte sembra quella più interessante e promettente. Si tratta di una tecnologia che consente di caricare e condividere immagini di grandi dimensioni (fino a 100 megapixel), offrendo un visualizzatore in grado di gestire la rotazione e lo zoom delle immagini e ottimizzare il consumo di banda (fondamentale considerando le dimensioni dei file).

Le applicazioni possibili sono molte: immagini di natura medica (ad esempio una radiografia), architettura e beni culturali, cartografia, ecc. ecc. Closr non punta a diventare un rivale di Flickr, tant’è che l’aspetto community non viene preso in considerazione. Modello di business: account pro a pagamento (per il momento è gratuito).

WorkCity

Sistema web-based di gestione della fatturazione e della contabilità rivolto a piccoli professionisti. L’idea non è nuova, originale il modello di business:

  • la piattaforma è Open Source, rilasciata sotto licenza GPL;
  • il modello di business attualmente si basa sulla possibilità di avere un account pro a pagamento. L’obiettivo finale è quello di sostenersi “vendendo” la parte di consulenza contabile: il professionista inserisce le proprie fatture tramite l’applicazione web, un consulente gestisce la parte contabile.

Personalmente non sono così favorevole all’idea di avere un “consulente telematico”. Ci sono attività che non possono essere fatte a distanza: questo presuppone la presenza di una rete di consulenti distribuita in tutta Italia? Non si sta sottovalutando il rapporto di fiducia tra professionista e consulente?

Koinup

Un social network per mondi virtuali come Second Life o WoW. Idea interessante, se non fossi convinto del fatto che i mondi virtuali non abbiano margine di crescita (a meno di cambiamenti radicali nelle modalità di interazione), alla faccia dei grafici che prevedono l’esplosione di queste tecnologie nel 2011.

Modello di business: pubblicità (AdSense al momento, in futuro gestione diretta degli spazi pubblicitari e campagne mirate da parte dei gestori di mondi virtuali).

Cosmos

Sistema operativo realizzato in C# e rilasciato sotto licenza BSD. Forse avrebbe un senso se il progetto fosse mirato (ad esempio per sistemi embedded oppure per applicazioni real-time), personalmente non vedo l’utilità di reinventare la ruota. Modello di business non pervenuto.

Tag Technorati: , , , , ,

Related posts:

  1. Unpacking SMAU Brescia 2009: le riflessioni
  2. Unpacking Smau Brescia 2009
  3. Unpacking SMAU Brescia 2009
  4. Venerdì sera: cena a Brescia
Scritto da flod  Archiviato in blog, bloggers
5 commenti/trackback »

5 commenti/trackback a “Unpacking SMAU Brescia 2009: le start-up”

  1. Lombardo Simone Mario scrive:
    29 Marzo 2009 alle 18:29

    Salve, sono l’espositore di Cosmos ovviamente ero ovvio che mi sarei spiegato male data la mia inesperienza al pubblico.. 🙂

    Se me ne date la possibilità vorrei controbattere nella speranza di spiegarmi meglio

  2. flod scrive:
    29 Marzo 2009 alle 19:47

    Ciao, se vuoi i commenti sono a tua disposizione 😉

  3. Lombardo Simone Mario scrive:
    30 Marzo 2009 alle 09:10

    Grazie! 🙂

    Allora, alla fine, non era una vera e propria start-up siccome non c’è un azienda fisica… ma la SMAU l’aveva segnata come SRL, ma è piuttosto un gruppo di sviluppatori con un idea comune che opera tramite web(come tanti altri).

    Per il modello di business, avevamo ragionato così:
    secondo noi, è inutile “vendere license” del prodotto perché alla fine il lavoro del programmatore, se la persona interessata lo installa in 1 dispositivo o 100000 dispositivi il lavoro per il programmatore è già stato fatto alla fine. Perciò, a parte il supporto base e i driver base, esistono un enormità di categoria hardware che necessità di driver perciò volevamo instaurare un “bounty system” simile al sistema effettuato dal sistema Power2People: se si è interessati a introdurre una caratteristica nel sistema operativo da parte degli sviluppatori, accettiamo opinioni e possibilmente finanziamenti al fine di incrementarne la priorità. Ovviamente ciò è inutile per il supporto base di qualcosa, che tocca noi, ma è più per la “specializzazione”. L’idea è quindi più valorizzare il lavoro degli sviluppatori che del prodotto e tenere a contatto committente e sviluppatore.

    Per quanto “reinventare la ruota”, ha ragione, a primo sguardo può sembrare proprio quello e ne esistono a vagonate di sistemi(basta ad esempio dare un occhiata alla pagina italiana di Wikipedia http://it.wikipedia.org/wiki/Elenco_dei_sistemi_operativi). Ma a parte JNode (che è un concetto simile pero’ sviluppato in Java), i kernel sono tutti sviluppati in linguaggio che arriva “al massimo” al C++.
    La maggior parte dei programmatori adesso è orientata verso l’utilizzo dei linguaggi di alto livello orientati agli oggetti o agli esperti ma il kernel “non li supporta naturalmente”. Stile, Java richiede la JVM, C# richiede il .NET Framework che agigunge un altro layer al sistema. Avere il supporto nativo, significa anche ridurre drasticamente il numero delle chiamate di sistema perciò anche delle performance migliori rispetto ai sistemi attuali. Diciamo che preferiamo dare una prespodizione naturale ai linguaggi ad oggetti (sorpattuto anche definire le policy di sicurezza nativamente) unito ad un kit che permetta di scegliere esattamente cosa si vuole.

    Adesso alcuni driver sono rilasciati in BSD quindi importabili senza ledere la licenza, quindi non si tratta di inventare la ruota completamente bensì, a nostro parere, migliorarla del principio.

    Per quanto riguarda embedded e realtime, avrà anche il loro supporto con il tempo, già stiamo facendo studi per poterlo implementare come sistema su NintendoDS, iPhone ecc. per le applicazioni “real-time”, sta più all’interessato sapere se offrire un sistema del genere. Li daremo la possibilità, ovviamente. 🙂
    Ci vorrà taaanto tempo, noi ci stiamo metttendo in gioco in una cosa che può essere vista di cattivo occhio ovviamente, ma vediamo come va a finire.. 🙂

  4. flod scrive:
    30 Marzo 2009 alle 09:29

    Un’altra cosa che non mi è chiara: il sistema operativo deve essere “compilato” in modo specifico per funzionare su una determinata macchina? Almeno questo mi è sembrato di capire in fiera. Non è un limite enorme per la distribuzione di un OS?

  5. Lombardo Simone Mario scrive:
    30 Marzo 2009 alle 15:32

    Allora, il kit prevederà di scegliere la destinazione del sistema in termini di architettura (x86, ARM etc.) e in termini di driver da includere. Nell’obiettivo principale, non mira ad essere un OS da distribuire diciamo “alla Windows” ( e di esserne competitore in quel campo), bensì per chi sa già che elementi dove girerà il software.
    Adesso conviene che distingua due cose.
    Un blogger mi ha aveva chiesto riguardo all’implementazione del HAL nel sistema. L’HAL serve a fornire un livello generico di astrazione dall’hardware, non specificatamente a vincolare o meno un software verso una macchina. Se il problema è “fornire uno strato in modo che ci pensa il sistema a scegliere il driver giusto così da poter coprire un numero elevato di periferiche”, ciò è facilmente implementabile. Si possono includere volendo tutti i driver pronti, mettere il modulo che si occupa di interrogare le periferiche ricavando il loro vendor ID e product ID e scegliere il driver opportuno.

    Se invece l’idea è di “fornire un modello generico di driver”, è intriseco nel linguaggio di programmazione usato. Mi spiego meglio con un esempio…ammetto di voler costruire il supporto di una scheda audio. La scheda audio sicuramente conterrà dei DAC, che si occupano di tradurre i dati nel segnale analogico (dal mp3 all’altoparlante per dire) e degli ADC che prelevano il segnale analogico e lo trasformano nei dati voluti (e.g. dal microfono al wav). Quindi una rappresentazione del driver,può essere scritta ad alto livello

    public abstract class AudioDriver{
    List dacs;
    List adcs;
    public void Play(AudioStream a){…}
    …
    }
    I DacManager saranno fatti così
    private abstract class DACMAnager{
    List registers; //i registri che controlleranno i DAC
    }
    (private perchè “interessano” solo alla scheda audio)
    La classe è astratta perché rappresenta un modello generico, non fisico.
    Voglio progettare il driver dell’Ensoniq AudioPCI ES1370 (usata fra l’altro dall’emulatore QEmu), estendo e specializzo la classe astratta.

    public class ES1370 : AudioDriver{ … }

    (in C# : sta per estendi)

    in C non avrei le caratteristiche adatte per poter pensare direttamente in questo modo, sopratutto gestendo le eccezioni e le visioni.
    La stessa cosa posso farla anche con i DAC, così da poter riciclare il gestore in altri modelli di schede che usano lo stesso modello di DAC.
    Ecc.

    Direi dipende più che altro dall’utilizzatore..se vuole fornire una soluzione distribuibile, può scegliere di includere il sistema di scelta, se già sa che architetture utilizzeranno le sue periferiche può evitarlo (ed eventualmente, prevederemmo un sistema per iniettere i driver nel kernel, come succede in GNU/Linux).

Trackback e pingback

  1. Nessun trackback o pingback disponibile per questo articolo

Non è possibile inserire nuovi commenti. I commenti vengono disattivati automaticamente dopo 60 giorni.