Cetin,

Your idea is a very good one -- I certainly don't perceive it as a negative comment at all! I actually suggested as much to Samuel at eTecnologia at some point. I think the Linux model has worked quite well: You have a small core group of people that decides what goes into the next release and what stays out. This decision is usually made after a lively community discussion, with (mostly civilized) arguments for both inclusion and exclusion. But in the end somebody (or some body) must make the final decision, lest the whole effort turn into a "software by ultrademocratic committee" type of deal, which generally sooner or later dissolves into a free-for-all mayhem.

Since at least for the time being this is not an open source product in the traditional sense, these decision mechanisms might need to be a bit different. In some ways it may make it even easier to have a few people making the final decisions, because this software is not "pure communal property".

Anyhow, a Wiki might be a good way to go about it, no doubt. There would need to be some kind of check-in-check-out procedure, so that "approved and completed" code gets locked out of further development, at least for the current version cycle. Functions "up-for-grabs" would need to be checked out but not necessarily locked, so that other developers would know who else is working on a given function/feature and communicate with them to see if they could help with some part of it, or whatever. However, "unlocked" features would need to be basically open for anybody to take a crack at co-operatively or on their own if they so wish, so that somebody dragging their feet on a checked-out feature wouldn't create a drag on the whole project. People working on a given feature could also always look back on the wiki to see who else, if anyone, is working on the same feature, which in turn could be a strong impetus for them to get cracking. The way I see this check-out system could work is the following:

1. OPEN: Not-yet implemented -- anyone can check out a feature and start working on it

2. SEMI_LOCKED: In QA -- new submittals for the feature are no longer accepted, pending QA results. A Badly Behaving Feature would be demoted back to Open status, a complete and stable feature would be elevated to a "version x locked" status. Automatic status change -email goes to any developers possibly working on the same feature.

3. LOCKED: Complete -- no more submittals for the feature are accepted, at least for the current version. Automatic status change -email goes to other developers possibly working on the same feature.


This would allow the "loosely coupled community work" to progress in an organized way, with people occupying the following three (Romanesque) roles:

1. The Second Triumvirate: Compiles and publishes the not-yet-implemented function/feature list for the next version; accepts/rejects the QA'd functions/features to the current version core.

2. The Gladiators: Check out available features; do the battle; submit the loot to the Tribunal

3. The Tribunal: Does QA for submitted entries, accepts or rejects (thumbs up or down) them based on completeness, stability and elegance (!). Alternatively hands them back to the Gladiators for more work, or sends them to the Second Triumvirate for the final, official acceptance.

How's that for Applied History Lessons!

(By the way, is Izmir far from Istanbul? I visited Istanbul a few years back and absolutely loved the city -- the Mosques, the Turkish baths, the Bazaars, the wonderful, friendly people and the FOOD! I'm going back for seconds as soon as I can...)


Pertti



>Pertti,
>(Please do not take my comments as a negative act. I don't have such an intention and actually already talked with my biz manager to buy the product for supporting whether or not we use it).
>
>I am somewhat worried about open-source style write/test and send. Instead each function implementaion could be placed somewhere (like wiki or anyhting similar) to be edited and perfected by academic level discussions (here I do not really mean to discuss it at academies, but as sometimes we all do, discuss on the code to find the best implementation - we do it here too much to find a better performing code sample for example). Honestly at this moment Fabio comes to mind as a perfect QA manager:)
>For example I'd at least add m. in your code:) We all have timing problems but we all would give a hand to such a thing I think.
>(and I wonder if we could also write implementation from .Net direction too, ending an enhanced version of functions etc. - I don't know yet if that is possible with eTechnologia.xxx and has any legal problems).
>Cetin
>