I think there are different kinds of complexity and only one is really a problem for "uptake".
1) It is complex to install This is usually only the case because nobody invested the time in a good packaging. It just needs doing and can be fixed later. 2) It is complex inside This is a problem in attracting more core developers. If the project is sexy enough, some few excellent programmers will take up the challenge. Most open source programmers commit code to the "surrounding" code base or fix obvious mistakes. Only few people are required to maintain the algorithmic core, which can be as complex as necessary without killing the project. 3) It is complex outside This is the real killer. To make the project successful you need dozens of auxiliary projects, i.e. notifiers, gadgets, full-fledged clients for Win/Linux/Mac/iPhone/Windows Phone ... you name it. You want existing apps to integrate wave etc. Currently most of these auxiliary projects need to implement OT, protobuf, the wave document model, etc. This is COMPLEX. Few people will do this. Having a Java implementation is not helpful in general. Many projects are built on different languages. An OT-lib written in portable C/C++ might be a good idea, because it can be wrapped by ruby, python etc. This lib must encapsulate the complexity. It does not matter how complex it is on the inside. Another option is to provide a REST-like interface for the client/server protocol which can be used without OT. You could still read all wave content, you could even create new blips. You just cannot edit a blip concurrently. We need an upgrade path that allows developers to connect to wave using standard tools such as HTTP/JSON/XML. If they like it and users ask for more, it is likely that developers will upgrade to OT to allow for even better collaboration. Here is a rule of thumb: An open source programmer should be able to connect to wave and exchange some data during a weekend hack (in an ideal case without relying on any wave specific libraries). If the first encounter with wave programming takes longer, many programmers will turn away. Greetings Torben 2010/8/7 Dave butlerdi <[email protected]> > People here seem to be worried about uptake. I think that in the very short > period that the protocol > has been available that there has been fantastic uptake especially when one > considers the state of the > project last year. > > At present SAP, Salesforce.com, Novel, processWave and many more have > invested considerable effort > and have produced some impressive results. > > If complexity were a true problem then Hadoop and the related projects > would not have been so successful > as they can be very complex. > > It would seem as though a framework where the various components could be a > bit more modular would > be a good approach...But these are all things that could be considered > during an incubation and general > consultation period. > > I know that we have invested considerable time and resource to integrating > portions of this project and have in > fact based some of our EU funding on these activities. We will move forward > with the integration as going back is > really not an attractive option. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
