Jalcide
the premise of this thread seems to be well-meaning, but is flawed and impractical.
in software development, you can't just throw money -- especially temporary for hire money -- at the problem.
it has to be built-in, planned, architected, scaled, and provisioned for, for the the long run. a company can't run a yearly development cycle and business based on the hope they may or may not get donations.
the hire would have to be mentored in to a decades-old codebase.
no developer of this caliber would do this on a six month or year-long stint. it's a major career choice.
there are not many software developers in the world that have this kind of experience. this is the kind of thing where someone from, say, steinberg leaves and joins presonus (a real example of the two founding presonus engineers). is someone like that going to take a 3 month donation fund? no way. they've got families to feed, probably.
so, are you really proposing coming up with a six figure salary x 3 years minimum? cuz that's what it would take -- for just one developer of the kind of caliber they require.
all this is moot, anyway, the person best suited to fix the bugs is the engineer that created them. you hire outside help to add self-contained, product-ized new features, not to try to dig through someone else's code to fix their bugs.
you should forget about this, apply for a beta test position, and if accepted, actively contribute to it.
there are no more or less bugs in Sonar than any DAW. not being a Sonar fanboi -- i've mostly switched to Studio One, actually. :blush:
As an Software Engineer, I'd say you'd need a senior level developer, preferably one who understands music, but a senior level developer more than anything. No .Net, no Java, no Web guys, no Agile guys, no script kiddies. C/C++ developers need only apply, in Sonar's case - heavy MS experience.
Most of the bugs being mentioned here are quite solvable by a seasoned developer. Software development may seem like magic to some, but then again so is music to others. (Everybody go pat themselves on the back...)
BTW, the best person to fix a bug is generally anybody
but the guy who created it. This is because people have blinders when looking at their own code. This isn't to say that the guy who created a piece of code isn't the quickest to navigate within that code.... however, proper architecture, design, and coding conventions do a lot to let other coders understand what is happening within a product's code. When looking at design issues - two heads are better than one.