I'm going to contribute some thoughts for discussion, from the viewpoint of someone looking in from the periphery of the project. I think that one factor in the recurrence of people coming forth offering their services as a project manager type may stem from the appearance that the project doesn't have a sense of direction. Some end users might see some of the threads in the forums, and the resultant activities in Trac and SVN, as a sign that the project is simply a bunch of people throwing code they like into a domotics system, and that the project is a barely contained anarchy, ruled by a Darwinistic approach of "he who writes the code wins".
Now, some may find that offensive, but it's not intended to be; it's intended to portray the possible viewpoints of someone who's seen the various YouTube videos, have come on by the community and started looking around. I've been following the project for couple of years now, so I've seen more of an evolution of the project and the dynamics involved, and I know things are more complex than that, but I'm trying to convey the views of newbies coming across the project. If someone is going to commit their time to rolling out LMCE to control their home, their safe and comfortable castle, they may feel more comfortable knowing that it's going somewhere, and is going to be around for the foreseeable future. So, if they're excited enough about the system and the project, they volunteer their services so that they can guarantee that both will be around.
Because of this perception that the project lacks direction, it appears that there may be a deficiency in the project's communication plans, one that can be easily remedied by the same refresh activities going on with the wiki and the website. Maybe an "officially documented" steering committee and processes can be put into the wiki, detailing who's governing the project, and what the goals are for the next release. This may exist informally already, like discussions in IRC, but if it were to be put into the wiki with some kind of roadmap, that may also help those who wish to contribute. Something along the lines of pain points, features intended to be incorporated into the next release, platform and infrastructure changes or directions, that kind of thing. That way, those who wish to contribute can work in the same direction as the core devs, rather than working on code which may be at odds with the planned directions of the project.
My other concern is a process concern, which may help with the perception that the project is a barely contained anarchy, ruled by a Darwinistic approach of "he who writes the code wins". For example, right now there's a somewhat animated thread in the feature request forum on the topic of monitoring. This has been repeated in the past in other threads, where animated and heated discussions about what technology/projects/code should be implemented, and he who writes the code wins. While it's obviously necessary to have code written to get features implemented, my concern is less of the "what" and more of the "how" things make it into the project. I, like many others, have my favorite projects/tools, etc., which I will defend and debate vigorously. My concern, and recommendation, is that there be a process for getting code or functionality into LMCE, one that takes into account a requirements analysis for the immediate need, consideration for how it can be extended upon or repurposed for other needs, and a wholistic approach to how it fits into the overall LMCE architecture. Thom's concerns about duct-taping on code and hacks are valid, and should extend to other modules/frameworks that go into the architecture.
Thom's made comments in the past about the huge size of the LMCE codebase, and all the challenges that have been faced since LMCE came about from PlutoHome. I've had similar issues at my workplace, re-platforming other group's "lost turds" where some project had engineered a solution carte blanche, without giving due consideration to existing infrastructure, supportability or lifecycle management. It's not a fun place to be in, and I expect that the devs don't want a repeat of the PlutoHome re-platforming experience some time down the road. That's why I am suggesting a steering committee and a process for vetting new and current code/functionality, plus an organizational approach that seems to work well...
Maybe some or all of the core devs can take a similar approach to that of the kernel dev team (given that LMCE is in some ways as complex as the Kernel!). I'm suggesting subsystem maintainers... Those devs, deeply knowledgeable about the subsystems under their purview, can shepherd those of us who wish to contribute code or functionality to the project, as they would know all the aspects of those subsystems, and can recommend ways to implement new code and functionality without duplicating effort or technology. This would also give new contributors a contact with whom they could learn from (think mentoring), and eventually spread the development load across a broader base of developers, all working towards a common set of goals. It may also take some of the pressure off of Thom and some of the others who have carried the weight of LMCE on their shoulders, freeing them up to look at the bigger architecture and feature sets.
None of this is meant to ruffle feathers or be construed as criticism. Rather, take it as an indicator of your success, of a job well done in showing people what a domotic system can be capable of. People want to contribute; the challenge is communicating where the help is most needed, and harnessing people's enthusiasm and skills.
Speaking for myself, I'm not a programmer; I couldn't C++ my way out of a wet paper bag, so I won't be coding any wonderful new features anytime soon. That doesn't mean I don't plan to contribute to the project. My day job has me sys-admining Linux systems running on pizza boxes to mainframes, and a variety of hypervisors to boot. So, I'm going to bring the mentality of someone charged with maintaing a highly-available, secure, stable, and supportable hosting environment to any contributions I make to LMCE. If there are pain points that are taxing the core devs, I'd need to know what they are before I could even hope to help. I'll post to that effect in a separate thread on the dev forum.
Hopefully this provides some food for thought as LMCE goes through it's growing pains approaching 8.10 gold...
/Mike
