Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Difference between revisions of "Open Source ROI Model"

From eLinux.org
Jump to: navigation, search
(more ideas for factors)
Line 1: Line 1:
 
Here are some loose thoughts on Open Source contribution Return On Investment (ROI):
 
Here are some loose thoughts on Open Source contribution Return On Investment (ROI):
  
I once created a game called TuxBucks which tried to model the dynamics of open source ROI.
+
I ([[User:TimBird|Tim Bird]]) once created a game called TuxBucks which tried to model the dynamics of open source ROI.
  
 
Below is a list of some factors affecting open source ROI, which I think would be good to model.
 
Below is a list of some factors affecting open source ROI, which I think would be good to model.
Line 27: Line 27:
 
*** Adaptation costs increase as hardware is customized, and decrease as commodity hardware is used
 
*** Adaptation costs increase as hardware is customized, and decrease as commodity hardware is used
 
*** Adaptation costs likely decrease when older hardware is used (due to software "showing up" for hardware over time)
 
*** Adaptation costs likely decrease when older hardware is used (due to software "showing up" for hardware over time)
 +
 +
== Relevant code dynamics ==
 +
* the amount of relevant code depends on the total size of the available code, and the uniqueness of your hardware
 +
** total size of available code depends on the contribution amount and contribution value (and contribution rate, over time)
 +
** contribution amount depends on size of contributor pool
 +
** percentage of relevant code depends on amount of contributors in your market area (this is what CELF tries to affect)
 +
* Can code areas be isolated and analyzed independently?
 +
** eg. Can you look at just processor-specific or board-specific contributions, and measure these separately from the main code base?
 +
* size of relevant code depends on network size (and network quality)?
 +
** maybe network size should not be measured in people, but by contribution rate?
 +
  
 
== Effect of mainlining code ==
 
== Effect of mainlining code ==
Line 61: Line 72:
 
** mainlinging cost is reduced
 
** mainlinging cost is reduced
 
** integration cost is reduced??
 
** integration cost is reduced??
 +
 +
== Miscellaneous ==
 +
* What about "quantum effects"?
 +
** a single developer or single company may significantly affect the outcome

Revision as of 18:08, 31 May 2007

Here are some loose thoughts on Open Source contribution Return On Investment (ROI):

I (Tim Bird) once created a game called TuxBucks which tried to model the dynamics of open source ROI.

Below is a list of some factors affecting open source ROI, which I think would be good to model. I have no idea, for most of these, how to come up with realistic values for these factors.

Overview

  • Total return from open source = amount of code that is relevant to your product, minus acquisition and integration cost, minus participation cost
    • Let RP = amount of code relevant to your product
    • Let AC = acquisition cost
    • Let IC = integration cost
    • Let PC = participation cost
  • the formula becomes ROI = RP - AC - IC - PC
  • Acquisition cost = license fees plus subscription fees plus downloading costs
    • downloading costs = cost to train inexperienced engineers in downloading plus cost to download
    • Integration cost = finding cost plus conflict resolution cost plus adaptation cost plus quality assurance cost
      • Integration cost also includes integration with 3rd-party software (not modeled yet, above is integration of non-mainlined patches)
    • Finding cost = cost to train inexperienced engineers in finding plus search time plus downloading cost plus evaluation cost
    • conflict resolution cost = cost to resolve patch conflicts
      • Conflict resolution depends on patch series breadth (patch locality), and magnitude of version gap (among other things)
    • Adaptation cost = engineering cost to adapt existing code to current situation
      • Adaptation may involve re-writing existing code, or developing new code (drivers) where they don't exist
      • Adaptation is the programming companies have to do to fill in the gaps left by open source code
      • Adaptation costs increase as hardware is customized, and decrease as commodity hardware is used
      • Adaptation costs likely decrease when older hardware is used (due to software "showing up" for hardware over time)

Relevant code dynamics

  • the amount of relevant code depends on the total size of the available code, and the uniqueness of your hardware
    • total size of available code depends on the contribution amount and contribution value (and contribution rate, over time)
    • contribution amount depends on size of contributor pool
    • percentage of relevant code depends on amount of contributors in your market area (this is what CELF tries to affect)
  • Can code areas be isolated and analyzed independently?
    • eg. Can you look at just processor-specific or board-specific contributions, and measure these separately from the main code base?
  • size of relevant code depends on network size (and network quality)?
    • maybe network size should not be measured in people, but by contribution rate?


Effect of mainlining code

  • what costs go up in order to mainline code?
    • cost to generalize code (very hard to gauge?)
    • cost to convert code to submission standards
    • cost to forward-port code to the latest project version
      • may be unavoidable if your code is dependent on other items (especially board support or architecture code)
      • could factor in cost to forward-port the board support or architecture code
  • what costs go down as a result of mainlined code?

Effect of not being current with your source code version

  • What is effect of not being current?
    • raises mainlining cost (see mainlining code costs)

Effect of experience with open source

  • What are switching costs for developers entering open source work?
    • How expensive is it to learn diff+patches or git, for example?
    • What is the magnitude of the learning curve for participating?
    • Does the learning curve increase over time (I believe it does, as complexity of code bases grow)
  • Can this be measured by examining

Dynamics of network effects

  • What number of contributors is needed before open source becomes useful?
    • number of contributors affects amount of contributions
    • skill of contributors affects value of contributions
    • amount and value of contributions affects the total code base size
    • total code base value affects likelihood of code relevance to product (really?)
  • Can this be modeled, realistically?

Dynamics of participation costs

  • as participation increasing, training cost go down
    • finding cost is reduced
    • mainlinging cost is reduced
    • integration cost is reduced??

Miscellaneous

  • What about "quantum effects"?
    • a single developer or single company may significantly affect the outcome