UniAudio Development

This document is used to collect ideas about what has to change to start with UniAudio development again. This is by no means a complete document, so please help to finish it!

Very valid comments
Development, after all, must be done by developers. Funding is only for the purpose of furthering development, and not the end in itself. My concern is designing a payment/voting system too complicated and rigid to promote and invite open development. This project is sufficiently different from OO.org that a copy of its model isn't necessarily a good fit.

Remember that the solution isn't just to substitute for Adrian's money but to also free it from the constraints of the single-paid-developer-only model.

How to improve development

 * Always try to make the audio hardware available to the developer or have a tester you can trust
 * Usually, it does not cost that much to purchase a sound card
 * Especially compared to the actual money that was spend on the developer!
 * If the card is not onboard, we should try to make it available to the developer
 * If not, we have to find a tester that helps the developer
 * If there is no tester, and the developer has no hardware, than we should not work on that
 * Create a document that describes in full detail what a tester has to do and how
 * There are various ways in which UniAudio outputs usefull information, those have to be listed and explained
 * Record user and tester reports in an "experience database" so the developer(s) can relate changes to effects more easily--also at later points for previous versions
 * We need clear milestones
 * Have a test plan for every major release
 * This can only work if we have a number of testers for UniAudio
 * It would be nice to have a list of "tested" vs. "untested" hardware, not just a list of what should work
 * It would be beneficial to have a database where the hardware can be listed and a set of tests defined, this would help take care of the plan for testing as well as the list of "tested" vs. "untested" hardware. Then the testers can mark the tests they have performed (I have never tried to record on this machine for instance and don't have a mic but could sign off on other tests).
 * Standardize the build environment with the help of Christian Langanke
 * Make it easier for testers and users to find appropriate versions
 * Follow a strict version numbering scheme
 * Record changes, preferably in "non-developer speak"
 * Document the Uniaud API so other developers can put it to use
 * have more then one developer on the project (less dependency, multiple eyes on the same problems, fall back, knowledge exchange)

Suggestions for Milestones

 * building a new release from the current svn repository
 * closing all old bugreports (no-one knows the status of the old bugs)
 * applying ALSA patches to be in sync
 * test HDA support
 * test APM support (including APM in ACPI)
 * create an easy to use PM mixer, maybe based on LBMix
 * create an up-to-date list of supported chips

How to raise money

 * from the os2world.com thread
 * Collect up front $5000 to $6000 by $20 per subscription for 1 year. This means 200 to 300 people must subscribe to this project. Make 5 milestones. Subscribers vote as to whether the milestone has been reached and the programmer is paid $1000 per milestone.
 * A Subscription based model
 * Before all this can start, netlabs.org proposes a small number of milestones for the project and finds a developer that would be interested to work on the project (the latter would be nice, but is not a must)
 * People are paying up front a subscription for one year, say $15
 * This is required to have access to the voting procedure and all other privileges for sponsors
 * In addition, they can (but don't have to!) vote for milestones with $1 per vote or they can create a new milestone for $1
 * The amount of money must be small enough, to not having to argue with users if the milestone is not fulfilled!
 * It must clearly be stated that voting for a milestone does NOT guarantee that this milestone will be reached in a given time!
 * After all, it may be that developers find out later that the feature cannot be implemented or something the like
 * And then I really don't want to get into the situation of having to pay back amounts of $1 to a couple of users!
 * However, proposing a new milestone also means they have to describe it in more than 1 sentence!!!
 * This will create a list of milestones, ordered by importance for the users
 * The total money that is collected will then be distributed over the milestones, weighted by the priority
 * this needs some more thinking :-)
 * Sponsors get
 * access to release binaries (and the source together with build instructions)
 * access to test binaries (and the source together with build instructions)
 * access to beta version binaries (and the source together with build instructions)
 * access to a support forum to post questions and bug reports
 * we would have to find out how to verify the subscription for the forum (without adding too much work!)
 * a way to ask for hardware support - via creating a new milestone
 * a way to steer development (now I am getting abstract :-) ) - again via purchasing a milestone ?!
 * Normal users get
 * access to release binaries (and the source together with build instructions)
 * access to a page where they can learn what they will have access to when they pay ;-)
 * Get SSI/Mensys involved. After all, this audio driver is an essential component of future eComStation releases. You cannot sell an OS that doesn't have basic sound support. Basic sound means: stereo play and record, a GUI mixer. Multichannel 3D stuff is not required.