Just a thought: If you give a task to somebody and "lock it up", then you have to wait (and possibly wait and wait and wait and... well, you get the picture) for that guy to either finish it or turn the task back in unfinished. This could seriously slow down the overall development. How about letting programmers choose from the list of uncompleted tasks, make a note on that item on that list that they are working on it, but let others work on the same unfinished tasks if they want to. Now these guys can co-operate if they want, or race to the finish on their own. First to complete the task wins, but most likely some esoteric options get left out and the others can then offer their own code to patch the first one, and all active participants get their names on the "wall of fame".
Pertti
>Hi Thomas
>
>I agree that we need to ship, shipping is a feature, so we are working hard for this. We are willing to give the helper developers discounts or Free copies of our product, according to their effort. We are looking for a nice proposition to the developers.
>
>I agree that releasing in stages, could make sense, but I'm afraid some people could think we are not going to deliver a true VFP Compatible product. So I guess We'll have to be careful with the naming of every release to let the people now the level of functionality included. I guess something like Compiler-Table Edition -Level 1, to let know the Data Layer is completed. Compiler-GUI Edition - Level II, or something like that.
>
>We already know the effort required for most of the functions / commands, We'll publish the guidelines to let the community start working on the implementation. We'll be asigning the functions, and letting the people know about the status of every function implementation: Not implemented, Assigned, Testing, Completed.
>
>So this is a nice effort to work, I hope you'll also lend us a hand programing VFP in VFP. You'll be surprised the easy is this if you can build on top of the .NET Framework.
>
>Thanks,
>
>Samuel David
>
>
>>Hi David,
>>>
>>>Could you believe that what we get asked more is about the GUI part. I really thought this could be the last item to implement in our road, but now I guess We'll have to change our plans...
>>
>>The only context where this would make sense to me is that the person asking about that is concerned that you'll also go the last mile. As perhaps the most distinguishing factor of the vfp GUI is the tight coupling to datasources, manipulating those datasources via vfp language must be done before a GUI can be considered...
>>
>>>BTW, did you read our secret plans? some of the other things you mention, are already implemented or being actively worked.
>>
>>Naawh, I never read those - I sometimes visit that nice girl from third floor after they removed my permit for clairvoyance. Seriously, to me most of that is "just logical" if I visualize myself in your situation. At start I also had some doubts on you guys appearing out of nowhere with no track record and a very ambitous plan. But
>>
>>
you are not promising a pie in the sky
>>you are open about the technical problem you encounter
>>you are listening to some of the hints here - I saw the list of things implemented before you posted<g>
>>you show the level reached with your compiler
>>and your answers mostly fit my mental map / take on things
>>
>>so I am quite willing to try out the first release making business sense for me. Before you entered the scene I had eyed IronPython as my next step. Now I am hoping for you to finish your first release. Open sourcing or releasing the code to customers might help settle much of the current fear in others, but the main thing is shipping a working product helpful for your customers.
>>
>>Quickly getting more developers from the vfp pool might help - and in my best case scenrios you will still make a profit on your compiler. My personal belief on the value you will be providing is not [only] in prefinancing development, but mainly in establishing a rigorous test system for the compiler. vfp is/was a very stable and compatible environment, and the developers are used to that level. Testing effort will rise exponentially with more of vfp implemented, and for you to try to get to the level of the latest and greatest vfp in one step might overtax ETec capabilities.
>>
>>On the pro side you can reuse existing "plumbing" and already have a target to test against (only very few desgin meetings needed), but during the years the gifted vfp team has implemented quite a lot of features. As shipping definitely would be a feature, you might consider to give permanent discounts to developers writing some of the functions complete with a unit test for it - if you already have a scale for the difficulty of each functions implementation (Occurs() should get a smaller bonus than a complete SQL Select <bg>) and a "locking" schema to make sure each function is only being worked on by a single developer and each developer can only lock one task at a time. Such a move might lift some of the necessary grunt work without too much of a pre-financing problem. Something in-between an unpaid open source effort and a profit oriented endeavour.
>>
>>Also let me reiterate: releasing different parts at different times could make *business* sense to me to become a customer as early as the language and backend capabilities are solid at a non-GUI level similar to FPW/FPD capabilities - but make each implemented part compatible with todays level. But the discussions in the last days markedly showed quite a large spectrum of opinions amongst us fox developers<bg>, so perhaps not too many agree with me on this topic perhaps others can chime in and give you their opinion.
>>
>>Again, I think you should charge your customers for the effort of testing, fixing and so on so that the high level vfp has reached can be maintained for future releases (plural!) while acknowledging the effort some people went to to help you come to market early by charging them markedly less - as there are "only" about 400 steps missing the number of people actually delivering parts will not cut too greatly into your potential revenue.
>>
>>Much more difficult will be to determine when an implementation of the dreaded foundation read or DDE can be cosidered error free, if you plan to implement them at all.
>>
>>But coming to market sooner than later probably means a higher potential customer base - before too many are comfortable with different/new tools: especially as those willing to switch now/only recently are probably the people easiest to compel to try your compiler!
>>
>>my 0.02 EUR
>>
>>thomas
