Project Life Cycles in Open-Source Software Sanjiv R. Das, Andrii Ieroshenko, Piyush Jain, David Qiu, Michael Chin, Brian E. Granger
arXiv:2605.12738v1 [cs.SE] 12 May 2026
{sanjivda, aieroshe, pijain, dlq, chnmch, brgrange}@amazon.com
Abstract—Using methods previously applied to product life cycles, this paper models developer engagement through the project life cycle for open-source projects, and detects similar dynamics in a cross section of projects. Endogenous growth theory is used to model growth dynamics in open-source software engineering, while incorporating the interactions between growth levels and developer activity over time using systems of differential equations. The solution to this model calibrates well to many open-source projects. The model generates an estimate of the lifetime developer engagement and growth, which supports estimating a lifetime production value of open-source projects. Index Terms—open-source; growth, developers, endogenous growth theory
I. I NTRODUCTION Changes in productivity in modern economies have been greatly ascribed to technological change, prompting the modeling of the path of technological advancement. In this paper, we model how growth levels (in open-source software) dynamically interact with the number of developers in the project. This interaction is important—as an open-source software (OSS) project grows and finds interest in the user community, a developer community also springs up around it. This accelerates the activity level of the project, which we measure as the total commits (additions and deletions) of lines of code in the software repository housed on platforms such as GitHub. As activity increases, it attracts more developers who wish to tweak and enhance the open-source project for their own use. This flywheel persists until the project matures and the level of activity slows down and the number of developers stabilizes (and often declines). These dynamics are similar to those considered in endogenous growth theory developed in Romer (1990). A management framework for this interaction between developers and open-source project growth is highlighted in Dey et al. (2024)—their CROSS model provides a foundation for understanding and enhancing the sustainability of OSS projects with a view to practical application. The term “open source” was coined on February 3, 1998, see Peterson (2018). Open-source software (OSS) has achieved amazing strides and its role in the economy is undervalued and uncounted in GDP as it is free. The Synopsis Report (Bals, 2024) calls OSS everything, everywhere, all at once. It notes that the percentage of commercial code bases containing OSS is huge, on average 96%. And 84% of codebases contain at least one open-source vulnerability. There are two views on the value of open-source software. (i) The supply-side view that looks at the cost to create OSS, also known as the cost-based valuation. (ii) A demand-side view, i.e., the value created for the users of OSS, who do not have to build the software for themselves or pay for it.
Hoffmann et al. (2024) estimate the supply-side value to be $4.15 BN, and the demand-side value to be $8.8 TN (which says that demand-side value is 2120x of supply-side value!). Developer time and cost can be measured from activity on OS repositories, but time and cost are extremely variable. Imputing labor costs to rewrite existing OSS arrives at estimates of $38 BN in 2019 for the US (Robbins et al., 2021) and Euro 1 BN in 2021 (Blind et al., 2021; Blind and Schubert, 2024). Assessments of value can be highly user-specific, and an interesting study reported in Chesbrough (2023) brings out the various features and value of usage of OSS, noting that most firms find that cost savings and faster development are the main drivers of usage1 (Wladawsky-Berger, 2022, 2024). We examine each commit to any chosen library over time and count the number of edited lines of code (added and removed) as a measure of technology progress in the repository. To illustrate, take the example of a popular open-source library, pandas, released in 2009. pandas is a powerful Python library for data manipulation and analysis. It offers fast and flexible data structures, easy handling of labeled and relational data, a high-level tool for practical data analysis in Python, with an ambitious goal of becoming the most comprehensive data analysis tool across programming languages. The library is designed to make data processing intuitive and efficient, serving as a crucial component for data scientists and analysts working with Python. Counting the changes over time to the repository, the cumulative growth in the project, A(t), is shown in the top panel in Figure 1, and the number of contributors L(t) per month is shown in the bottom plot. The models in this paper calibrate dynamical equations that represent these growth and contributor patterns, which may then be used to model the future path of any repository. These dynamical models may be relevant in answering many questions: (1) Can we understand developer engagement and is there are pattern across open-source projects? (Yes, the evidence shows the same S-curve as seen with product lifecycles). (2) How does developer engagement interact with project growth? (We find that some projects’ growth elasticity with developer engagement is positive and for others it is negative, leading to two different trajectories). (3) Is project growth endogenous and conforming to a version of Romer (1990)’s growth model? (Yes). (4) Can we use the models for developer engagement and growth to project time to maturation of the project when it does not need additional 1 https://www.prnewswire.com/news-releases/ linux-foundation-research-shows-economic-value-of-open-source-software\ \-rising-in-terms-of-benefits-vs-costs-301761106.html
generated from analyzing the project life cycle may be used to arrive at lifetime value. And Section VI provides closing comments. II. T HE E NDOGENOUS G ROWTH M ODEL
Fig. 1. Plot of the cumulative lines of code changed (top plot) and
the number of contributors (bottom plot) since the inception of the pandas library in 2009. Lines added and deleted are counted as work done on the repository. The dots represent the effect of each commit. A second-order polynomial trend line was fitted to the code changes data, resulting in the following best-fit equation: A(t) = 1.79 × 10−2 t + 8.26 × 102 t − 2.71 × 105 , R2 = 0.9879. The fit of the number of contributors over time is represented as the following best fit polynomial trend of order two: L(t) = −4.35 × 10−6 t2 + 3.59 × 10−2 t − 1.49 × 10, R2 = 0.6968.
resources than just a developer? (Yes). (5) Can this lifecycle information help in judging lifetime OS project value? (Yes, though it depends on valuation assumptions). (6) Is there a constant ratio of project success (downloads) to developer effort? (No, there is wide cross-sectional variation in project success relative to developer). The rest of the paper proceeds as follows. In Section II, we describe an initial dynamical equation used to model lines of code committed (added and deleted) to a repository. Section III models the life cycle of developer engagement, which feeds into project growth. Section IV calibrates the model to actual data for popular open-source projects. It also shows how to make lifetime projections and assesses stability of these forecasts at different stages in the project’s life. Section V makes speculative suggestions about how the information
This model presumes that technological progress is not exogenous but driven by intentional investment decisions of agents (in our case, the developer ecosystem). Technology is treated as a non-rival good. Non-rival means that it can be used by multiple actors simultaneously. Further, in the opensource setting, goods are non-excludable, i.e., the owner does not exclude others from using it. In the open-source world the community owns the software and engagement is seamless. Most technologies tend to be excludable and often rival, which sets open-source software apart from other avenues of technological progress. We use these ideas to present a framework for understanding how decentralized growth can drive technological progress. Romer (1994) offers a good review of endogenous growth models. We introduce an adaptation of an endogenous growth model here with a basic model for developer engagement, which is refined later in Section III. As noted previously, we define cumulative growth over time as variable A(t) and developers (contributors) as labor L(t). We use the Cobb-Douglas production functional form for changes in project growth.2 This version of the model defines the rate of change in OSS growth as a function of current growth levels and the number of developers working on the project. We assume that the rate of change in developers is a simple function of the current engagement in the project (the model in the ensuing sections is more elaborate and will be used for the empirical work in this paper, but here, we introduce ideas with a much simpler model for developer engagement). With this assumption, the model admits a closed-form solution, shown below. (Later, we will enhance the developer model to include an independent propensity to contribute.) Let the dynamics of growth level A be described by the following function of labor L (contributors). Changes in A are also a function of the level of A itself. This is what is known as the “standing on the shoulders of giants” effect (Isaac Newton, 1675), i.e., previous technological advancements drive new ones. dA = γLλ Aϕ (1) Ȧ = dt where • γ > 0 is a constant “efficiency” parameter; • λ is elasticity of labor; if λ = 1 doubling L doubles the growth rate. If λ < 1, there are diminishing returns to adding more contributors. If λ > 1, there are increasing returns to adding contributors. • ϕ is growth spillover. If ϕ < 0, growth makes new growth harder (the “fishing out” effect). If ϕ = 0, new growth is not a function of past growth. If 0 < ϕ < 1, there are positive but diminishing returns to existing growth. If 2 https://en.wikipedia.org/wiki/CobbDouglas production function
ϕ = 1, new growth is linear in existing growth. And if ϕ > 0, growth is explosive. • Scale effects: If λ + ϕ > 1, there are increasing returns to scale. If λ + ϕ = 1, there are constant returns to scale. If λ + ϕ < 1, there are decreasing returns to scale. Labor L: A simplistic model for labor dynamics is the following: dL L̇ = = nL (2) dt With initial conditions: L(0) = L0 ,
A(0) = A0
The closed-form solution for both processes is (derivation details are in the Appendix): L(t)
=
A(t)
=
L0 ent (3) 1 1−ϕ λ λ (1 − ϕ)γL0 (1 − ϕ)γL0 λnt − (4) e + A1−ϕ 0 λn λn
This solution is valid for ϕ ̸= 1, n > 0. If ϕ = 1, the equation would need to be solved differently. Also, for n = 0, the solution is shown in equation (20). To check the solution by differentiation, set equation (24) to A(t) = u(t)1/(1−ϕ) . ϕ 1 1−ϕ · du , and then proceed to recover so that dA dt = 1−ϕ · u dt equation (1) in a few steps of algebra. The overall solution shows that: (a) Labor grows exponentially at rate n (this is by assumption, of course). (b) The growth level A grows as a function of both the initial conditions and the parameters γ, λ, ϕ, and n. This is a simple model where L is modeled as an exponential growth process independent of A. As we can see, for example, in Figure 1, the number of contributors (labor level L) does not grow exponentially forever, so the ordinary differential equation for L will need modification. We extend the model for L in the next subsection, and this will also admit a closed-form solution for the model of developer engagement. III. A N ENGAGEMENT MODEL FOR THE NUMBER OF DEVELOPERS
We model the number of developers per month engaging with a project using the Bass (1969) and Bass et al. (1994) models, which are used for product life cycles. This approach has so far not been applied to software project life cycles. The main idea of the model is that the developer engagement rate per month of a project comes from two sources: 1) The propensity of developers to work on the software project in any month because it is apt for their use case or from other motivations, independent of the other contributors propensity to engage in any month. 2) The additional propensity to work on the software in any month because others have adopted or are engaged with the project. Hence, at some point in the life cycle of a good open-source software project, social contagion, i.e., the influence of the early contributors becomes sufficiently strong so as to drive many others to work on developing the software as well. This is a network effect.
We note that this definition of engagement deviates from the original specification in product adaption models where adoption is assumed to happen just once in a person’s lifetime, whereas in our model, we are more interested in modeling repeated engagement of any developer. Therefore, we define engagement (or re-engagement) propensity per month using the model described below. The unit of developer engagement in an open-source project is taken to be a “developer-month” – and the total number of developer-months over the lifetime of the project is denoted as m, which is latent, PT i.e., unknown until the project ends. Note also that m = t=1 L(t). Once a project is underway and has seen some traction, engagement statistics may be used to develop a forecast of future engagement. This will enable an estimation of total engagement m and its distribution over the life cycle of the project. Define the fraction of a developer engagement in an OS project in month t as f (t). Hence, the number of developers engaging in month t is simply L(t) = f (t) · m. (Note that R this implies f (t)dt = 1, and we may think of f (t) as a probability.) So, the probability of engagement at time t is the density function f (t) = F ′ (t), where F (t) is the cumulative probability or fraction of engagement up to time t. We can re-express this as a rate, conditional on remaining f (t) total engagement thus far, i.e., 1−F (t) . A functional form for this rate is the diffusion equation f (t) = p + q · F (t) 1 − F (t)
(5)
where p is the independent rate of engagement (the coefficient of independent engagement) and q modulates the network effect (the coefficient of imitation). The idea is that engagement is driven by a developer’s independent need for the software package and also driven by awareness from engagement by other developers. We may rewrite this equation as: f (t) = [p + q · F (t)][1 − F (t)]
(6)
The right-hand side shows that the fraction f (t) may be expressed as the product of two components; the first p + q F (t) may be interpreted as the current intensity of engagement, and the second is the remaining engagement fraction. The goal here is to fit this equation to software developer engagement data to ascertain p, q and the lifetime engagement in developer months (denoted m). We rewrite the equation above as dF/dt = p + q · F, F (0) = 0 (7) 1−F which is a differential equation with an initial condition, which we can solve for F (t), provided here: F (t) =
p[e(p+q)t − 1] pe(p+q)t + q
(8)
Differentiating, we get the engagement probability density at time t: e(p+q)t p(p + q)2 dF f (t) = = (9) dt [pe(p+q)t + q]2
Denoting the lifetime engagement as m, then expected engagement at time t is L(t) = m · f (t). Using data, we want to estimate {p, q, m}. Cumulative engagement up to time t is defined as L(t) = m·F (t). Substituting these into the diffusion equation (5) above we have L(t)/m = p + q · U (t)/m 1 − L(t)/m
(10)
Re-arranging we have =
[p + q L(t)/m][m − L(t)]
=
β0 + β1 L(t) + β2 L(t)2
(11)
β0
=
pm
(12)
β1
=
q−p
(13)
β2
=
−q/m
(14)
L(t)
If we have data on periodic engagement L(t) and cumulative engagement L(t) we can fit a regression to the data to get coefficients β0 , β1 , β2 . We can then solve for p, q, m as follows. Given that β1 = q − p = −m β2 − β0 /m,
(15)
we re-arrange to get a quadratic equation β2 m2 + β1 m + β0 = 0 with solution for lifetime engagement m: p −β1 ± β12 − 4β0 β2 m= 2β2
(16)
(17)
The positive root of m may then be used to solve for p = β0 /m,
q = −mβ2
(18)
Next, we model how growth (lines of code) changes dynamically over time. Models of growth have been used to value open-source projects (Horowitz et al., 2001; Hoffmann et al., 2024) and obtaining lifetime value begins with estimating lifetime growth. A. Rescaling 1 If we rescale time by t0 = p+q ln(q/p) and f by f0 =
(p+q)2 4q
(these are the time and height of peak developer engagement) we get normalized developer engagement: α f ′ = f /f0 = sech2 (1 − t′ ) 2 where α = ln(q/p) and t′ = t/t0 . Developer engagement is scaled and shifted by the function sech(·)2 . Since α indicates that just the ratio q/p matters, this is effectively a single parameter model, modulated by the ratio of the coefficients of the network effect and the independent effect.
Plot of the developer engagement since the inception of the pandas library in 2009. The fitted line uses the solution in the equations above where it is determined that p = 0.00084, q = 0.02686, and m = 9448. Fig. 2.
IV. C ALIBRATING D EVELOPER E NGAGEMENT AND G ROWTH TO DATA We download all commits in a project from GitHub and count the number of lines added and deleted in each commit, from the inception of the project. We use the contributor information from these commits to count the number of unique developers contributing to a project in every month. First, we fit the data to the model for developer engagement. Second, we fit the dynamics of the growth model to the data on commits and the data on developer engagement. The code for this project is available here: https://github.com/srdas/oss-lifecycle. A. Fitting developer data As an example, the model for developer engagement is fit to the data for the pandas library using the closed-form solution above. Figure 2 shows the monthly engagement data, and the bottom panel shows the engagement rate. The best-fit parameters are p = 0.00084, q = 0.02686, and m = 9448. This calibration is straightforward because of the availability of the closed-form solution in Section III. Estimates for a collection of popular open-source projects are presented as examples in Table II. We also note here that the parameters p, q have the same scale as those in the original Bass (1969) paper (see Table I there). B. Fitting growth data The behavior of the endogenous growth system will be a function of the three growth parameters {γ, λ, ϕ} in equation (1), which is an ordinary differential equation (ODE). Using the solution to the ODE with a given set of these parameters enables tracing out the estimated function Â(t) over time using the data for both, commits and developer engagement. While γ is a scaling constant the parameters λ, ϕ are elasticities with
TABLE I
C ALIBRATED PARAMETERS FOR THE GROWTH MODEL , dA = A · Lλ · Aϕ . γ IS A CONSTANT, λ IS THE ELASTICITY OF dt GROWTH WITH RESPECT TO DEVELOPER ENGAGEMENT, AND ϕ IS THE ELASTICITY OF GROWTH WITH RESPECT TO CURRENT GROWTH .
Project dask-dask huggingface-transformers jupyterlab-jupyterlab kubernetes-kubernetes langchain-ai-langchain microsoft-DeepSpeed numpy-numpy pandas-dev-pandas pytorch-pytorch vllm-project-vllm
Fig. 3. For the pandas library, the plot shows the fit against the raw
data after calibrating the ODE of the Cobb-Douglas model to the data. Best-fit parameters: γ = 601657.05, λ = 1.301, ϕ = −0.552. Time periods are months.
respect to developer engagement and project growth levels. The sign of these parameters informs us about how the project responds to infusions of each resource. For calibration, we minimize the root mean squared error between the data and estimated functions from solving the ODEs. The calibration objective function is: T
2 1 X Â(t, L̂(t)) − A(t) {γ,λ,ϕ} T t=1 min
(19)
where T is the number of months in the data and Â(t, L̂(t)) comes from the solution to the ODE for A and uses the solution for the ODE for L to estimate L̂(t). Numerically, each iteration of the minimizer calls the ODE solver internally to generate an estimated dynamical path for growth Â, which is then compared to the true path A by the optimizer. The ODE parameters are updated and the objective function is refined until parameters are found that minimize it. The solution is obtained in a few seconds and converges to the minimum. Once the optimal parameters are determined, these are used to plot the estimated functions against the actual commits data to assess the fit. For the pandas library, see Figure 3. We see a very good fit. Labor elasticity (λ) is positive and growth elasticity (ϕ) is negative. Adding more contributors brings more growth, but growth eventually saturates as seen from the negative elasticity for growth. For ten example projects shown in Table I we see that a majority of the projects have a positive elasticity with developer engagement, where λ > 0 and also a positive one with growth level, ϕ > 0. This means that, over time, projects get a stable pool of contributors who improve their skills in the project and are able to accelerate growth (λ > 0). This is good because over time, developer engagement peaks and
γ
λ
ϕ
13255.95 292.79 11300.14 0.01 1431.86 649.79 370.42 601657.05 21.03 13.30
-0.3811 -0.4171 1.4304 12.9150 0.7093 -0.6623 -0.3206 1.3005 0.4524 0.1723
0.0111 0.5017 -0.2231 -1.1730 0.0916 0.3490 0.3318 -0.5523 0.4228 0.5940
then declines. Because ϕ > 0, as the project matures and cumulative growth level A grows, the pace at which lines of code are added also increases. A similar pattern has been noticed by venture capitalists (Droesch et al., 2020). C. Extrapolation In order to assess the future trajectory of the project the ODE solutions may be projected further for additional months. The three projection plots for the pandas project are shown in Figure 4. The phase diagram shows the interaction between L and A, and we can see that as the project matures, growth continues without the need for a large number of additional contributors, consistent with the increasing returns and the long-run growth model in Romer (1986). We can also ask when developer engagement will taper off and stabilize, as it inevitably must for all projects. Bessemer Venures denoted this point as the “steady-state maturity” of the project (Droesch et al., 2020). We implement this by solving for the value of t that sets f (t) · m = 0.5 in equation (9). That is, engagement has dropped to a half-developer per month (no full time developer activity). Figure 4 (middle plot) shows the start and end of developer engagement in addition to its life cycle forecast for the pandas project. We conducted this analysis for other example projects and found the remaining life to maturation to be as follows, assuming no significant changes to the project: pandas has 12.7 years remaining to maturation, and others, for example, are jupyterlab 7.9 years, langchain 1.82 years. Table II shows the model parameters and life expectancy of each project. We see that the coefficients are similar to that obtained in work on product life cycles. More importantly, the p and q parameters are of similar size and scale across all projects, suggesting that the model applies well in the cross-section of open-source repositories. (For some projects p or q is negative, in which case the developer engagement data does not fit the model well.) D. Forecast Stability Since the model may be calibrated to data at different points in the life of the project, and then used to forecast the future
Fig. 4. Extrapolation of the solution for the pandas repository till its maturation, which is defined as engagement dropping to half a
developer per month. The phase diagram shows the interaction between L and A, and we can see that as the project matures, growth grows without the need for a large number of additional contributors. TABLE II
F ITTED PARAMETERS OF THE DEVELOPER MODEL IN SECTION III. T HE START DATE AND END DATE OF THE DATA USED FOR EACH PROJECT IS SHOWN . T HE COLUMNS IN THE TABLE ARE AS FOLLOWS : 1. p: COEFFICIENT OF INDEPENDENT PROPENSITY ( PROBABILITY ) TO JOIN THE PROJECT IN ANY MONTH . 2. q: COEFFICIENT OF NETWORK INTENSITY ( PROBABILITY ) TO JOIN THE PROJECT IN ANY MONTH . 3. m: CALIBRATED DEVELOPER - MONTHS EXPECTED OVER THE PROJECT ’ S LIFETIME . 4. t: CURRENT LIFE OF PROJECT IN MONTHS . 5. T : EXPECTED LIFETIME OF PROJECT IN MONTHS . 6. yrs: AT THE CURRENT RATE , EXPECTED REMAINING TIME TO 2 MATURATION OF A PROJECT IN YEARS AFTER THE E ND DATE OF THE PROJECT. A LL PROJECT FITS SHOWED HIGH R VALUES WITH ALL T- STATISTICS FOR PARAMETERS p, q, m SHOWING STATISTICAL SIGNIFICANCE AT THE 99% LEVEL . Project
Start Date
End Date
p
q
m
t
T
yrs
dask-dask huggingface-transformers ipython-ipython jax-ml-jax jupyter-server-jupyter-scheduler jupyterlab-jupyter-ai jupyterlab-jupyterlab kubeflow-kubeflow kubernetes-kubernetes kubernetes-sigs-kueue langchain-ai-langchain langchain-ai-langchain-aws langchain-ai-langchain-google microsoft-DeepSpeed mlflow-mlflow numpy-numpy pandas-dev-pandas pytorch-pytorch ray-project-ray run-llama-llama index scikit-learn-scikit-learn tensorflow-tensorflow vllm-project-vllm
2014-12-31 2018-10-31 2005-07-31 2018-11-30 2022-09-30 2023-02-28 2015-07-31 2017-11-30 2014-06-30 2021-11-30 2022-10-31 2024-03-31 2024-02-29 2020-01-31 2018-06-30 2001-12-31 2009-07-31 2012-01-31 2016-02-29 2022-11-30 2010-01-31 2015-11-30 2023-02-28
2026-01-31 2026-01-31 2026-01-31 2026-01-31 2025-12-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31 2026-01-31
0.00210 0.00230 0.00149 -0.01448 0.04236 0.01421 0.00358 0.02221 0.00464 0.00191 0.01343 0.00867 0.02816 0.00197 0.00150 0.00018 0.00084 0.00064 0.00126 0.00770 0.00163 0.00387 0.00121
0.03855 0.03078 0.02430 0.00058 -0.06855 0.11660 0.03007 0.02332 0.02233 0.04751 0.14676 0.06620 0.05942 0.07003 0.01044 0.01735 0.02686 0.02930 0.02749 0.13915 0.01677 0.02769 0.11101
2173.64627 12940.35495 2817.00050 -1360.19200 189.77015 240.70389 2820.22037 897.26940 23872.21258 2854.25959 5263.69827 540.68494 499.36713 1496.74400 11476.56955 9769.60912 9448.61510 34554.29690 10234.99818 3014.88442 10026.76782 28138.49944 12331.92116
134 88 247 87 40 36 127 99 140 51 40 23 24 73 92 290 199 169 120 39 193 123 36
199.97683 284.67205 303.19720 -258.61177 47.53731 48.41652 222.22246 112.18981 330.63036 179.90429 61.84962 87.18043 63.82810 124.48289 643.39112 593.24927 352.18475 383.43603 330.39570 66.27020 452.60215 303.58833 110.96520
5.49807 16.38934 4.68310 -28.80098 0.62811 1.03471 7.93520 1.09915 15.88586 10.74202 1.82080 5.34837 3.31901 4.29024 45.94926 25.27077 12.76540 17.86967 17.53298 2.27252 21.63351 15.04903 6.24710
life of the project till its demise, it is useful to examine how stable these forecasts are for the time of maturation. Of course, as the time moves on, we gather more information about a project, which will mean making adjustments to the forecast of both developer engagement and growth levels. In order to assess how these forecasts change, we examined ten well-known open-source projects as follows. First, we calibrated the model using all the data about the project from its inception until the current time (end January 2026 at the time of data collection). Second, we plotted the fitted developer
engagement and fitted cumulative growth and compared these to the actual data. As shown in Figures 6 and 7, the fit of both the developer engagement model and the cumulative growth model is very good across most projects. Third, we then used only data for the first 75% of the project’s current life. For a project like pandas, which began in 2009, this would mean dropping the most recent four years to get estimates. In the third row of Figure 7, we see that the fitted developer engagement model (left plot) is almost the same when calibration uses full data (red line) versus
Fig. 5. Developer engagement on open-source projects over time, see also Table II. Engagement is measured as the number of developers who
commit code each month. The engagement plots have a dashed line that starts end January 2025 and shows the projected future trajectory of developers engaging until the maturation of the project. The bottom plot shows the same data normalized using the mathematical results in Section III-A. The x-axis is normalized to show the time of peak developer engagement to be 1, and the y-axis is normalized so that the peak height is 1 for each project. Projects with greater overall lifespan are wider than others with lesser lifespans.
when only the first 75% of the project’s lifetime data is used (green line). When considering the cumulative growth fit (right plot) the two lines are almost identical. Examining both figures 6 and 7 reveals that the future projections for the project are robust to the timing of calibration. Even for projects with a short life so far, this does not matter for estimating growth dynamics, as they seem to fit very well regardless of when the calibration is done. However, for estimating developer engagement, sometimes the calibrations do lead to different fitted dynamics as in the case of pytorch, though for most of the other projects, even for developer engagement the calibrations at different times lead to similar developer
engagement plots. Researchers may use these forecasts to support valuation of these projects, so the fact that robust estimates of lifetime dynamics are available early in a project’s life is encouraging. In Section V we will use these dynamic models for developer engagement and growth to suggest methods for valuation of OSS projects, though we surmise that these would vary based on assumptions made by the valuer. E. Adaptation to Closed Source Software These interactions in the open-source ecosystem may be used to estimate headcount needed to develop closed-source
Fig. 6. Model calibration I: The plots show the fitted values to developer engagement data (left) and cumulative growth (right). The actual
data is shown alongside the fitted data when the fit is undertaken using both, the entire data sample and the first 75% of the data available for each project.
Fig. 7. Model calibration II: The plots show the fitted values to developer engagement data (left) and cumulative growth (right). The actual
data is shown alongside the fitted data when the fit is undertaken using both, the entire data sample and the first 75% of the data available for each project.
software using a simpler model with only equation (1), given that developer labor will be set to a constant L. The solution is 1 " !# 1−ϕ A1−ϕ λ 0 A(t) = (1 − ϕ) γL · t + (20) 1−ϕ This equation can be calibrated to the data for project growth by modulating the parameters γ, λ, and ϕ for a fixed level of L using the same solution approach from the previous subsection. This is simpler than modeling the dynamics of open-source software projects. Extensions to the model for how developers are added to the closed-source project would be internal to and vary by organization. V. VALUATION A PPROACHES Table III reports lifetime developer engagement and growth, as well as illustrative (under assumptions) supply-side costs for valuation of the ten projects portrayed in Figures 6 and 7. The current life of the project and forecast full life are shown. The project life is assumed to “mature” when developer engagement drops to half a developer a month. For many projects this is shown in Figure 5 (top, the bottom plot shows the normalized version of the top plot). We note that the project does not stop being downloaded and used, just that developer maintenance becomes minimal and reaches a low steady-state. The number of developer months currently invested in the project is shown in Table III. This is the sum of the number of developers each month for all months. Current cumulative growth is the total number of lines of committed code (additions and deletions) until current time and lifetime growth as forecast by the dynamic model is shown as well. Growth per developer month in the table is a useful statistic that will be used for valuation of the projects and it varies widely across projects. This is calculated based on data up to current time. A. Supply-side value The valuations shown in the last two columns of Table III are calculated as follows. Growth is divided by the Innov/Dev Ratio and then multiplied by 0.5 (by making an assumption that a developer spends about half their time on the project. This quantity is then multiplied by $10,000 (assuming this to be the global average salary for a developer per month3 ). By using projected lifetime growth, this approach also gives the lifetime builder cost of the project. It is also known as the “supply-side” value of the project. These costs vary significantly across the selected projects. The analysis is here is intended to be illustrative, showing how an understanding of the project life cycle is the first step in assessing lifetime costs and value generation. B. Demand-side value Next, we evaluate the “demand-side” value of the project, i.e., what is the project worth to the users of the open-source software? To assess this value, we can use downloads as a 3 https://aijobs.net/salaries/developer-salary-in-2025/
proxy and if we can determine a value per download, then knowing the lifetime downloads enables an assessment of this value. However, demand-side valuation is complicated and subjective and these difficulties and a new approach to understanding the value of OSS is documented in Chesbrough (2023). The growth model (lines added and deleted) offers a lifetime forecast, as shown in Table III. If we have an estimate of the number of downloads per lines edited for each project from existing data, we can estimate lifetime downloads. The ratio of PyPi downloads to lines of code changed varies across projects, with the popular projects having very high values compared to the less popular ones as shown in Figure 8. This information may be used to estimate the demand-side value. For example, the ratio for Pandas is 30462 (Figure 8). Since this project has a lifetime growth in code of 5.24 million lines edited (Table III), the lifetime downloads are expected to be 160 billion. Put a value on each download to determine what the project is worth. Another simpler calculation may be as follows. We know that Pandas has 2,772,426,479 downloads in six months (Figure 8), and we can extrapolate this over the remaining life of the project, which is 153 months (III)), i.e., 2772426479 × 153/6 = 70, 696, 875, 215 downloads to go. The devil is in the assumptions, and whatever these may be, they should be consistently applied across time and projects. To be clear, these are only suggested approaches to lifetime project value based on first estimating lifetime developer engagement and projected endogenous growth. The number of lines of code committed by a developer per month can vary widely depending on various factors, but typical ranges may vary depending on which types of coders are being considered. Anecdotal estimates suggest that professional developers tend to commit between 10-50 lines of code per day.4 5 This translates to roughly 200–1000 lines of code per month, assuming 20 working days.6 Then of course, several factors influence the number of lines of code committed, such as project complexity, development phase, individual coding style, team size and collaboration, and code review processes. Admittedly, lines of code amended is a fuzzy measure of productivity because some days may involve writing hundreds of lines of code, while others might focus on debugging or refactoring with minimal new code. Experienced developers often write fewer, more efficient lines of code. Impact may also be measured in other ways such as code quality and the impact on project goals, which may vary a lot across projects, and are quite subjective. VI. C ONCLUDING D ISCUSSION The paper adapts the endogenous growth model of Romer (1990) to the dynamic evolution of code growth levels and 4 https://softwareengineering.stackexchange.com/questions/40100/ how-many-lines-of-code-can-a-c-developer-produce-per-month 5 https://stackoverflow.com/questions/966800/ mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects 6 https://news.ycombinator.com/item?id=37040552
Fig. 8. The ratio of PyPi downloads to lines of code changed (additions and deletions). These ratios are determined by dividing the total
downloads over the past 6 months by the total lines of code added and deleted over the same time frame. These ratios offer insight into the usefulness of projects to the community around them for the degree of effort invested by developers.
Project
Repo
PyPi package
Dask HuggingFace IPython Jax JupyterScheduler Jupyter-AI JupyterLab KubeFlow Kubernetes Kueue LangchainAWS Langchain LangChainGoogle MLFlow NumPy Pandas PyTorch Ray ScikitLearn TensorFlow vLLM
dask/dask huggingface/transformers ipython/ipython jax-ml/jax jupyter-server/jupyter-scheduler jupyterlab/jupyter-ai jupyterlab/jupyterlab kubeflow/kubeflow kubernetes/kubernetes kubernetes-sigs/kueue langchain-ai/langchain-aws langchain-ai/langchain langchain-ai/langchain-google mlflow/mlflow numpy/numpy pandas-dev/pandas pytorch/pytorch ray-project/ray scikit-learn/scikit-learn tensorflow/tensorflow vllm-project/vllm
dask transformers ipython jax jupyter-scheduler jupyter-ai jupyterlab kubeflow kubernetes kueue langchain-aws langchain langchain-google mlflow numpy pandas pytorch ray scikit-learn tensorflow vllm
6mo downloads
6mo changes
Ratio
137036942 615182150 524949513 75853043 121521 897504 254384699 379218 519803832 753 38771056 597444237 22629 150869506 3549725144 2772426479 1179989 203893216 898376562 148662915 23646706
7457 1146859 8033 311112 55 48572 157009 383298 786672 677285 120580 980693 107567 1200227 110329 91014 1473048 1122592 53140 1939560 1184765
18376.95 536.41 65349.12 243.81 2209.47 18.48 1620.19 0.99 660.76 0.00 321.54 609.21 0.21 125.70 32174.00 30461.54 0.80 181.63 16905.84 76.65 19.96
TABLE III LIFETIME STATISTICS AND ESTIMATED VALUATIONS FOR TEN KEY OPEN - SOURCE PROJECTS . P ROJECT LIFE ( TIME TO MATURATION ) IS MEASURED IN MONTHS . “D EV M ONTHS ” IS DEVELOPER MONTHS . G ROWTH IS IN MILLIONS OF LINES OF CODE COMMITTED . T HE “I NNOV /D EV R ATIO ” IS THE CUMULATIVE LINES OF CODE COMMITTED ( BOTH ADDITIONS AND DELETIONS ) DIVIDED BY THE CUMULATIVE NUMBER OF DEVELOPER MONTHS UP TO CURRENT LIFE . T HE PROJECT VALUE IS CALCULATED AS G ROWTH DIVIDED BY THE I NNOV /D EV R ATIO MULTIPLIED BY THE COST PER MONTH PER DEVELOPER , ASSUMED TO BE $10,000, MULTIPLIED BY 0.5, ASSUMING THAT OPEN - SOURCE DEVELOPERS SPEND 50% OF THEIR WORK TIME ON ANY PROJECT. VALUATION HERE RELATES TO THE PRODUCTION COST OF THE PROJECT, ALSO KNOWN AS ITS SUPPLY- SIDE VALUE .
Project
dask-dask huggingface-transformers jupyterlab-jupyterlab kubernetes-kubernetes langchain-ai-langchain microsoft-DeepSpeed numpy-numpy pandas-dev-pandas pytorch-pytorch vllm-project-vllm
Current Life (months)
Full Life (months)
Current Cum Developer Months
Current Cum Growth (MM)
Lifetime Growth (MM)
Innov/ Dev-Month (Ratio)
Supply-side Valuation Current To Maturation ($MM) ($MM)
134 88 127 140 40 73 290 199 169 36
200 285 222 331 62 124 593 352 383 111
1938 6990 2426 20949 5168 1213 5939 8214 26430 4465
0.78 5.25 4.15 46.41 6.60 0.62 5.91 4.96 26.93 2.99
1.58 250.80 4.39 46.41 6.97 3.37 21.57 5.24 56.88 35.49
403.98 750.41 1710.05 2215.58 1277.78 513.22 995.03 603.77 1018.82 669.48
9.69 34.95 12.13 104.75 25.84 6.07 29.70 41.07 132.15 22.32
developer involvement in open-source software projects. Developer engagement is modeled using the Bass (1969) model, which fits the data well, suggesting that a product life cycle model is adaptable to modeling open-source project life cycles. This paper’s system of dual ODEs for growth and developer engagement is solved and calibrated to data from GitHub repositories. Phase diagrams enable an assessment of the maturity of the project, its future trajectory, and the elasticities of growth and contributors on these dynamics. We are able to speculate when developer engagement will drop below a single developer-month, without any further exogenous changes, signaling a point of low usage and activity. We applied this to some popular projects with interesting results. To the extent that these life cycle projections are within acceptable levels of accuracy, they may be used to forecast how long we may expect growth in and depend upon an opensource project (see Figures 5, 6, and 7). This complements the idea of underproduction risk noted in Champion and Hill (2021), Gaughan et al. (2024). Experimentation across a few different systems of ODEs suggest some regularities, namely that growth feeds on itself, like a flywheel, and once this is in motion, additional developers do not matter as much and efficiency and downloads per unit of developer effort improves. This explains why open-source projects are maintained by a small group of core developers, noted in Droesch et al. (2020). As projects mature and taper off in developer engagement as shown in Figure 8, we may detect successful mature projects as those that have a high download to developer effort ratio. Finally, we are able to use the dynamical equations for developer engagement and cumulative growth to support illustrative valuation models for open-source projects. Supplyside valuation for 10 chosen projects ranged from the tens of millions to the hundreds of millions. Demand-side valuation can be imputed from lifetime growth using the ratio of downloads to lines of code changed. These are initial approaches to
19.57 1671.09 12.83 104.75 27.27 32.85 108.40 43.42 279.15 265.08
understanding the life cycle of open-source software projects. Future work will expand the number of projects analyzed. The analysis of strategic investments by tech companies in these projects and its benefits may be possible with minor additions to this model. R EFERENCES Bals, F. (2024). 2024 Open Source Security and Risk Analysis Report (OSSRA) | Synopsys. Technical report, Blackduck, Inc. Bass, F. M. (1969). A New Product Growth for Model Consumer Durables. Management Science 15(5), 215–227. Publisher: INFORMS. Bass, F. M., T. V. Krishnan, and D. C. Jain (1994). Why the Bass Model Fits without Decision Variables. Marketing Science 13(3), 203–223. Publisher: INFORMS. Blind, K., S. Pätsch, S. Muto, M. Böhm, T. Schubert, P. Grzegorzewska, and A. Katz (2021). The impact of open source software and hardware on technological independence, competitiveness and innovation in the EU economy: final study report. Publications Office of the European Union. Blind, K. and T. Schubert (2024, April). Estimating the GDP effect of Open Source Software and its complementarities with R&D and patents: evidence and policy implications. The Journal of Technology Transfer 49(2), 466–491. Champion, K. and B. M. Hill (2021, March). Underproduction: An Approach for Measuring Risk in Open Source Software. In 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 388–399. arXiv:2103.00352 [cs]. Chesbrough, H. (2023, March). Measuring the Economic Value of Open Source: A Survey and a Preliminary Analysis. Technical report, The Linux Foundation. Dey, T., B. Fitzgerald, and S. Daniel (2024, September). CROSS: A Contributor-Project Interaction Lifecycle Model for Open Source Software. arXiv:2409.08267 [cs].
Droesch, M., A. Karp, A. Sterman, and E. Kurzweil (2020, October). Measuring the engagement of an open source software community, https://www.bvp.com/atlas/measuringthe-engagement-of-an-open-source-software-community. Gaughan, M., K. Champion, and S. Hwang (2024, April). Engineering Formality and Software Risk in Debian Python Packages. arXiv:2403.05728 [cs]. Hoffmann, M., F. Nagle, and Y. Zhou (2024). The Value of Open Source Software. SSRN Electronic Journal. Horowitz, E., R. Madachy, D. Reifer, B. Steece, and B. K. Clark (2001, January). Software Cost Estimation With Cocomo II (HAR/CDR edition, Editor: Barry W. Boehm ed.). Upper Saddle River, NJ: Prentice Hall. Peterson, C. (2018). How I coined the term ’open source’ | Opensource.com. Robbins, C. A., G. Korkmaz, L. Guci, J. B. S. Calderón, and B. L. Kramer (2021). A First Look at Open Source Software Investment in the United States and in Other Countries, 2009-2019. In IARIW-ESCoE Conference “Measuring Intangible Assets and Their Contribution to Growth”, London. Romer, P. M. (1986). Increasing Returns and Long-Run Growth. Journal of Political Economy 94(5), 1002–1037. Publisher: University of Chicago Press. Romer, P. M. (1990). Endogenous Technological Change. Journal of Political Economy 98(5), S71–S102. Publisher: University of Chicago Press. Romer, P. M. (1994). The Origins of Endogenous Growth. The Journal of Economic Perspectives 8(1), 3–22. Publisher: American Economic Association. Wladawsky-Berger, I. (2022, March). The Impact of Open Source on the EU Economy. Wladawsky-Berger, I. (2024, April). What’s the Value of Open Source Software Based on Actual Usage Data?
dL = n dt L Z Z dL = n dt L ln |L| = n · t + C Using the initial condition L(0) = L0 : L(t) = L0 ent 2) Now we can substitute this solution into the equation for A: Ȧ = γ(L0 ent )λ Aϕ This is a Bernoulli differential equation in A: dA = γLλ0 eλnt Aϕ dt 3) To solve this, let’s use the substitution u = A1−ϕ : du dA = (1 − ϕ)A−ϕ dt dt Substituting: du = (1 − ϕ)γLλ0 eλnt dt 4) Integrating both sides: u=
5) Substituting back u = A1−ϕ : (1 − ϕ)γLλ0 λnt e +C λn 6) Using the initial condition A(0) = A0 : A1−ϕ =
A1−ϕ = 0
A PPENDIX Solving the initial differential equations for project growth and developer engagement. See Section II. The dynamics of growth level A are described by equation (1), reproduced here. dA = γLλ Aϕ (21) Ȧ = dt The equation for developer engagement (labor) is reproduced here as well: dL L̇ = = nL (22) dt With initial conditions: L(0) = L0 ,
A(0) = A0
The solution to this system of equations is as follows: 1) First, let’s solve the equation for Labor (L) since it’s independent of A: L̇ = nL This is a simple separable differential equation: dL = nL dt
(1 − ϕ)γLλ0 λnt e +C λn
(1 − ϕ)γLλ0 +C λn
(1 − ϕ)γLλ0 λn 7) Therefore, the complete solution for both processes is: C = A1−ϕ − 0
L(t)
=
A(t)
=
L0 ent (23) 1 1−ϕ λ λ (1 − ϕ)γL0 λnt (1 − ϕ)γL0 e + A1−ϕ − (24) 0 λn λn
This solution is valid for ϕ ̸= 1, n > 0. If ϕ = 1, the equation would need to be solved differently. Also, for n = 0, the solution is shown in equation (20). To check the solution by differentiation, set equation (24) ϕ 1 1−ϕ · du , to A(t) = u(t)1/(1−ϕ) . so that dA dt = 1−ϕ · u dt and then proceed to recover equation (1) in a few steps of algebra. The overall solution shows that: (a) Labor grows exponentially at rate n. (b) The growth level A grows as a function of both the initial conditions and the parameters γ, λ, ϕ, and n.