paying-the-piper
paying-the-piper copied to clipboard
beeware
What's the cost?
Was just thinking, does anyone have an idea of an approximate cost (in time) of maintaining an open source project. Perhaps per GitHub star per year? Maybe that's not the best number-- suggestions welcome.
It doesn't have to be a perfect number but it would be nice to know how much these projects need to support themselves in a sustainable (ie, non burnouty) way.
As you mentioned, stars can build up over time and make no difference. impress.js, for example, is a top 30 and gets 400 organic unique visits per day which is 1/3 comparing to js-cookie for example, and they have an astonishing difference in stars.
Number of unique hits might be the best unit of measurement IMHO, the cost can be somehow derived from that.
Sounds fair. Hits also no doubt scale with bugs that need solving so its a good metric.
Perhaps a better question (than asking people to pull numbers out of the air) would be, could we get some tracking in place around a range of project maintainers who aren't working themselves to death, on reasonably sized projects so we can generate a (reasonably) scientific number that we can work with. Anyone know any projects / maintainers who would be interested? Some kind of open source project timesheeting.
If you set it up right, you could re-run the project with a new sample set each year to account for changes in project landscape etc...
From there we'd be able to start understanding the basic question of what effect is required for one of these projects needs to be stable, which gives us a starting point for building out a solid funding model stack and implementation guidelines for projects of different traits using both current and novel funding models (and it'll be more obvious what the gap is so we can explore funding models that will REALLY fill this gap).
You can get in contact with folks like @zenorocha (clipboard), @jonathantneal (normalize.css), @paulirish (h5bp), @cvrebert (bootstrap), @QuincyLarson (FreeCodeCamp).
I can help with data from impress.js, js-cookie and jquery-cookie, maybe one of them is keen to help too?
(I just didn't pinged here because I don't want to spam, maybe contact on Twitter or e-mail?)
One thing that might help out here is, depending on if the GitHub API supports it, if someone were to make a small web app that maintainers could just sign into, and publicize their metrics in a friendly format to run calculations on. That makes it a lot easier on those with less time, and also opens it up to more people.
Okay.. maybe we can get an "Hours I spent maintaining this week" app up, and then ping out over twitter etc. Keep it simple...
- User can sign up with a Github login, mark projects that they maintain with some other details about the project for classification purposes (License, Language, Other?)
- Each week they get pinged through their email to key in an estimate of how many hours they've spent actively maintaining.
- Front page has some kind of analysis of the average effort cost of maintaining a project based on the supplied data.
- Maybe host a little badge people can put on their repo with the median time spent maintaining the project or something :p.
Am I missing any requirements for a MVP?
Am I missing any requirements for a MVP?
For an MVP I guess that is it. We can improve later anyway.
If you're building this can you make the development public with small commits and PRs so that we can help if necessary with review or something?
Of course! I don't know if I'm building it, but I'll have a think about it this arvo.
I mean... If I build it I might have to maintain the damn thing, and I can't really quantify how much time that's going to cost me ;).
I mean... If I build it I might have to maintain the damn thing, and I can't really quantify how much time that's going to cost me ;).
If it's small and with a strict scope then it wouldn't be necessary a lot of changes besides the initial implementation. As I said I can help with reviewing it if using JavaScript/node. It is much easier to maintain a prototype than an application a lot of folks rely on.
Looking forward to it.