Julius:
Been working so these comments may be a bit late.
Some things to think about with your model.
1) If the contract is for application development, you need to have a mechanism for finding both the architects and worker bees. Too many architects or folks that think they should be architects can result in a system with excellent components, but when taken as a whole is a mess.
2) The company will need to be able to understand quality not just pricing. This can't always be gleaned from customer surveys.
3) If all the folks working are independents, how are you going to ensure:
- They don't try to cut you out and simply go direct -- contracts can help, but often not prevent such things from happening if both the contractor and the client want that arrangement.
- That there is a flow-down of client contract conditions for all your subs (insurance, non-disclosure, other behavioral restrictions.
- That your subcontractors fit within the budgetary scope of your project. Dollar per hour contractors often try to find as much work as they can on an account to maximize their billable hours. This can play havoc with your budget.
- That they play well together. Open source programmers are often very good programmers. Very good programmers can be more opinionated, stubborn and hard to manage than your worker bees.
The inherent competition between contractors in your model will actually hinder you from delivering a quality solution to your customer as a "team" will not be easily formed. For my part, when I do such work, I pay as much as I can and let everyone understand the economics. Things still don't always turn out as I'd hope.
All I can say in my short time away from work.
Good luck. I'd like to hear about lessons you learn as you progress through this. As a previous writer mentioned, I'm still learning every day.
Regards,
Scott Behnke
Principal
Elemental Solutions
[email protected]
571-212-7114 (phone)
------------------------------------------------
On Mon, 28 Apr 2003 15:21:31 +0100, "Julius Steyn" <[email protected]> wrote:
> Hallo gentlemen,
>
> You may recall my debut under the above subject heading on this mailing list
> during late March. Again thank you for the constructive feedback received
> from members of the list. I have since collated all the findings of several
> months' research and joined forces with other members on this mailing list.
> Our focus was simple:
>
> "How to leverage the advantages, culture and experience of Open Source and
> to integrate these with the demands of business customers to such a degree
> that Open Source can become a better provider of business critical
> software - with lasting benefits to both developers and business customers"
>
> We developed an Operating Model and business strategy based on the feedback,
> research and challenges discussed in the summary essay that followed. Many
> existing and past business models were investigated each have their own
> unique characteristics, benefits and advantages. Some of the 13 business
> models that we investigated included; Sourceforge, SourceXchange, Collabnet,
> Elance, sologig, rent-a-coder, experts exchange, free agent, asynchrony,
> etc. Although we are confident about our strategies and the proposed
> business model we are at a stage that we respectfully seek your advice and
> input. I have summarised the basics of the Operating Model at the location
> below and will provide a detail strategy and business solution during the
> latter part of this week, your feedback is critical to finalise some of the
> key aspects of the business solution.
> http://www.devcity.org/opsmodel/
> I look forward to your constructive response, criticism, comments and
> discussion about some/all of the initiatives mentioned in the above essay.
>
> With kind regards
> Julius Steyn
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.