First of all, thank you for the transition from svn to git repository. After steep learning curve, I've come to like git for the ability to have own hacks in own repository and ability to easily create patches for community.
As a new contributor, I have some ideas about things that could be done better. I'd like to hear your opinions about them:
There are a half-dozen dev mailing lists and weekly dev calls, but we've made them invitation only so far for a few reasons:
1) The volume of email is huge just with the existing dev teams and we're not sure we can handle more traffic through that method. That's what this social network is for.
2) We discuss upcoming hardware in those lists, and because that has commercial implications we need to keep it in a closed group until we're ready to release. Huge investment goes into hardware products and progress is unpredictable. Sharing that sausage-making would both confuse and probably kill the market.
That said, we are moving towards a process that makes it easier for people to contribute. We've moved to the Git version control system, so people can work on code in a local repository and contribute patches in a way that's easy for the dev team to evaluate and integrate.
We're also going to open some of the dev lists, at least to in a read-only form. We just need to clense them of all hardware discussion, which is big job given the volume of the archives.
Back to your points:
--MAVlink is indeed changing (we're part of that, so we'll be ready on day one). The MAVLink dev team is here.
--We have published roadmaps in the past, and we should probably do it more regularly. Just another one of those jobs we don't have enough time for, but I take your point and will try to get one out soon.
--Everyone has access to the Issue Tracker already.
--The way most people come to be invited to the dev team is by proposing to add/fix something in particular and showing that they are competent to do it. One great method is to pick off some bug report in the Issue Tracker and either fix it or prove that it's invalid. That's a great demonstration of a good fit in the project, and we can integrate that person more easily into the existing dev team structure.
Overall, I very much take your point and we're working on ways to make it easier for people to contribute. Moving to Git was for exactly this reason, but we've got a lot of work still to do. The cost of bringing in people in the wrong way is high (everything from time spent bringing them up to speed to the risk that they'll mess up the code), so we have to be thoughtful about how best to do it.
Maybe you can join the project as our New Developer Ninja and help us with this ;-)
Thank you for very thorough reply. I did not realize that for open source project like this there exists commercial interest, other that maybe for using the end product.
About the mailing list, if you don't want to open development lists for public, you could start new public list as a place for occasional contributors to submit bug fixes and get feedback about them.
About the issue tracker. Having one is great and it's good that everyone can browse and file new issues. My problem is that general users can't take ownership of bugs. I submitted patches for bugs 412 and 415 and noticed soon after that user DrZiplok had committed almost the same fix to bug 415 and the bug is still in new state. Double work there =)
Thank you all for the code so far. I'll be glad to help. As a day job, I work as MeeGo developer and we have had to solve similar kind of problems in partially community run and partially closed source environment.
Yes, that's the difference between open source software and open source hardware. The hardware part costs money, so it's typically made by companies with the usual large sums invested in parts and inventory to ensure sufficient supply to meet demand. At the scale we're now operating, the investment required is too large for individuals, to say nothing of the need for legal compliance and liability insurance that goes with hardware.
There are now quite a few companies producing the hardware the open source software developed by this community runs on: 3D Robotics, Jdrones and Udrones, to say nothing of all the retailers out there selling these products. The cost of pre-announcing a product too soon or missing a promised release date can be crippling, to say nothing of disruptive to the community, so we're careful about only announcing hardware when we know when it will ship in volume.
That's a good idea for a open maillist on bug fixes. I'll set that up now. In the meantime, please PM me your email address and I can get you repository access and we can talk about implementing some of the process improvements you've suggested.