Introduction to Wasabi Development

First of all, This is not Winamp3, Wasabi.player, or any other piece of software. Wasabi is a coding platform. So far this Wasabi tree is a more or less a class toolkit within a platform that facilitates interaction between classes & plugability. This tree is a fork of the (partly open, partly closed source) platform that was used to build Winamp3 and now gen_ff.dll (Winamp 5.x's freeform skinning). at this time it does not (i repeat, does not) have a gui. There are thoughts about taking chunks of the (open source) Winamp3 sdk and backport it to this fork, but this hasn't been done.

Preliminary roadmap

Total time before completion of the project is expected to be as long as 2.5 year (6m mostly design, 2y dev).
As a preliminary roadmap, the idea is :

• Planning, r&d and testing until Jan, 1 2005 using the current source tree
  
• Development / refactoring into a new source tree starts no later than Jan, 1 2005
  
  • At this date, all core specs should have been defined and understood by the core developers
    
  • At this date, all critical proofs of concept should have been completed and tested on the major target OS
    
  • After this date, changes in the specs should be limited to the strict necessity (ideally, no change happens, but of course this is not an ideal world)

note: the first phase (design) also includes coding, for instance, the TUI needs to be working asap for us to start using it as a test platform, and everybody should feel comfortable working on actual code. The idea however is that code developped during this phase will require (at least a few) changes once we jump on the final dev.

Types of contributors

• Core developpers
  
• Developpers
  
• Skinners
  
• Documentalists
  

Obviously, this is rather reductive, a core developper will very often work at the same level as that of a regular developper, and (just as a regular developper) will usually also be a documentalist and sometimes a skinner, but this is the idea... each contribution type then has sub categories, there isn't a master architect but several core developpers architecturing their assigned part(s) and ensuring cohesion of the whole, and there are regular contributors who use the core infrastructure to create more object and more leverage for specific parts of the code (ie, the media core developper architects the media pipeline and implements its core functionality, a media developper implements a specific DSP, input or ourput object, same for UI core vs widgets, and so on). (see Contributing? for more)

Quickies (ToDo?)

- An efficient breakdown of the project into componnents, where developers can be as autonomous as possible