Hey All, We've also had some discussion about the committer balance status and barrier-to-entry for shindig and how the trunk is used and I'd like to re-post my response since it contained a few insights in how the OpenSocial spec process works and how shindig is used by some:
I do see plenty of random small contributions, but so far no one sticks around longer then their OpenSocial/Shindig implementation phase. These are mostly people who are paid to implement shindig and then move on to something else; Which in a way is easy to imagine because as you know the social web is fast moving, margins are incredibly tight, and most social networks are more concerned about competing against the big other player in the market then they are about contributing to open source. A short sighted vision perhaps for some of them, but also something I can kind of understand. So my hope is more for someone who thinks 'Shindig is cool and I want to use this in imaginative ways" in a university or free time kind of environment, or a social site that is making enough money or has the right person to convince them that they should allocate time for it. As far as the release cycle and the stability of the branch goes, I can't speak for the teams who work on Orkut and iGoogle, but my speculation is that like for any social site, their main priority is to have features out there that attract developers that will make social apps that attract people to the site, make sure that things are secure and stable and fast enough, so that their site can function and grow in a very competitive market. OpenSocial is a bit of a different animal then most open source projects, we have an OpenSocial specification process that is completely separate from Apache Shindig, and in it's current state it evolves very quickly; Not because the people involved in it (which a much wider range of companies represented as Shindig has) like new and shiny things but because the social web is evolving at an incredibly rapid rate.. and there's plenty of competitive pressure at the same time too, for many it's a situation where OpenSocial represents the 'web like' way of doing things, open protocols and standards, with data portability and a place where any one can innovate, against a platform that doesn't have any of these things. So the pressure to keep the trunk stable not from Google or any affiliate or any of the consumers of shindig directly (if it were it wouldn't be such a big problem:), but more of the market and innovation pace in general, and from the desire to create an open and social web that anyone, anywhere in the world can use to develop their ideas on, and making sure that end users can own their own data and identity by giving them tools and protocols with which they can. (a great way to learn more about this topic is the archives from the http://www.thesocialweb.tv/ episodes. Those guys do a lot for the open social web) Now as a sanity check we've build in the requirement that any new spec proposal should have a prototype build before we call it final.. that prevents great ideas that don't work in practice ending up in the spec (which is why we now have 0.8.1 instead of the original 0.8:), and we also love it if we can get some OpenSocial gadget developer feedback and live experiences before we call it completely 'done'. To facilitate this you *do* need a stable experimentation tree, a place where you can code up these new features and put in production on large scale sites And that, well that very much that conflicts with the idea of having an unstable trunk.. trunk is where new code should go, but we need the new code to be stable to complete the feedback loop that is an important factor in the OpenSocial spec forming process. How you could combine those 2 concepts, well that's a riddle that I don't have an answer for either. If that coding was done on an alternative branch, then the trunk wouldn't see any development (and thus become the new 'stable branch'), and the experimentation branch would become the new trunk.. in other words that's only moving the problem around and creating more confusion for everyone involved. Now for PHP Shindig these pressures are slightly less (though far from non-existent), I can afford to have an unstable trunk for a few weeks here and there since there's no main stream sites driving sandboxes directly from it, however in practice when ever I do have some instability (like during the gadget rendering refactoring & templating implementation), I get lots of complaining and upset mails in various flavors and colors.. since we haven't had releases and people are used to the trunk being stable, well they are a bit taken aback when it's not, so there's a cultural problem we're facing as well. ---- (end of original post to shindig-private) Since writing that I've chatted with a couple of people about how we might be able to address this, and one of the ideas I've heard is that maybe we can move the OpenSocial new spec prototype development to experimental branches, this should relieve the pressure on the trunk a bit, and might have the added benefit of no old prototype code that didn't make it into the spec to still sneak into the release :) Also, there's some people who would like to see the next OpenSocial spec to be more of a bug fix with a few small additions rather then a huge major pile of changes again (it's up to the OpenSocial community as a whole though to decide), so perhaps some less churn there could make shindig easier to follow as well. Anyhow, hope this post provides some insights, and if anyone has any ideas or opinions, please share them! -- Chris
