Lessons learned on OSS
Just wanted to make some general observations based on what I learned around the Symfony2 CMF initiative. I hope that these will be helpful to others working on other open source initiatives. Of course every initiative is born into different sub-communities and every set of leaders have other skill sets and networks but there might still be some general lessons to take home from my experience.
First up never plan a project to pay off only if other people join. This is something I was aware of before getting Liip involved in the CMF initiative but its served as a reminder. I have to admit I was hoping for it to be different this time around mainly because we got quite a number of community people together to nod of the direction before we started to invest heavily 2 years ago. Anyway, do what you think will benefit you directly, if other people join along the way, all the better. But if you think your own investments will only pay off if other people join, you are in for a rude awakening unless you get really lucky.
Second people like to hear the truth, but they don't necessarily want to hear the full truth. With that I mean the peculiar reaction Jackalope with Jackrabbit and Doctrine DBAL generates. I wasn't surprised that many in the PHP community are concerned over running Java code in production. But what did confuse me is that people expected feature parity with the Doctrine DBAL implementation. Instead of comparing our pure PHP implementation with other pure PHP implementations of a content repository, the benchmark was Jackrabbit. Since we are far from being at the same level, people concluded that it is not worth a look. In other words: it of course makes sense to speak the truth, but it was counter productive to promote Jackrabbit as a "get there early" solution for the masses if it was clear that the masses wouldn't get on board with a Java solution. The Java option is going to be a niche solution for the PHP community and even in the long wrong only a niche will even need the scalability of Jackrabbit anyway.
Third is that criticism of "complexity" might very well be true. However they might also be very misleading. Many people who are not really interested in tinkering in low level detail use this term interchangeably with "unproven" or "lacking support". As these people are not interested to tinker in the low level stuff they need to know that a large number of people are using the technology before adopting it as a validation that the technology is sane and more importantly that there will be people around to help them. This is conservative thinking is of course a very sensible basis for decision. Just don't get confused by the terminology used to describe it. Until you have a large array of real world use cases from different companies, do not spend much time on getting these people on board as you will be wasting the time of both you and the people you are trying to convince. Instead focus on the people that are indeed interested in the low level stuff as these are the only people that can help you get the real world use cases. Unfortunately there are of course fewer people in this group. The good news is that these people can largely teach themselves and if they do like what they see will quickly be able to move things forward in big ways.
So in summary: All investments have to bring a sufficiently large payoff by themselves, make it easy for your audience to think positively about your product and focus your time on those people able to help you create real world use cases as those are a prerequisite to mass adoption.