Anecdotally, most Open Source software is produced by people working on company time. Some is produced by non-corporate-affiliated maintainers. How do you see this distinction? Does it matter? Does and should OSI have a role in balancing the two?
1 Like
I think it might be more important to look at project governance. How do changes in the code base get decided? Can influence on the projectâs roadmap be purchased? Perhaps the OSI might recommend some best practices for community-driven project governance?
1 Like
In my mind, this is essentially the difference between âopen source softwareâ and an âopen source software project/communityâ. There have been many discussions over the past years about this, including public statements by some people who believe that a piece of software should not be called âopen sourceâ based solely on its license, but only if its license plus its governance plus other attributes constitute an acceptable âprojectâ.
I, for one, donât think the OSI should dive into this end of the pool at all; the licenses that are the primary focus of the OSIâs work donât make any attempt to describe, control, or place requirements on governance, and I donât think they should. There is certainly a place for an arbiter of âgood communityâ versus ânot good communityâ, and some projects might choose to participate and get some sort of badge/label to demonstrate that their governance meets that bar. I suspect it would be incredibly challenging to get consensus on something like the OSD, but for governance.
Whether or not a piece of software comes from a âgood communityâ or not is a risk-management decision for the person deciding to consume that software, just like the license is.
(As an example, one person who very strongly believes that the âopen sourceâ label should only be applied to projects/communities, not software, actually told me that my personal projects would not be considered âopen sourceâ in his mind because in spite of their OSI-approved licenses, they donât have any governance model or community aspects. I find that to be counter-productive.)
3 Likes
Yes. For a recent example, here is Andrew Lilley Brinker proposing an Open Governance Definition:
The Open Source Definition has been around for decades, but it only addresses the requirements of the terms under which the software is licensed to the public. This is a laudable achievement, but it does not ensure community access to the levers of power in the production of that software.
Just as the Open Source Definition set the minimum requirements for user freedoms which must be preserved for a project to qualify as open source, an Open Governance Definition would set the minimum requirements for user power which must be available for a project to quality as open governance.
It would not need to specify the governance rules under which projects must operate. Instead, it could focus on ensuring that users, regardless of their background, have equitable access to power in open source projects which want to call themselves âopen governance.â The combination of open source plus open governance would become the highest signal of user freedom and equitable access a project could pursue, and would help incentivize developer investment in projects which meet this standard.
I agree. Who is a better candidate than OSI to take this on? An existing foundation? Which one? A new entity? Why?
It would certainly be challenging. Whoever takes it on should learn from OSIâs experience conducting the OSAID process, to see if it could be done more smoothly.
To me OSI is the natural candidate for this role, because we have a mandate at the highest level of Open Source in a way that no other org does. Just because itâs challenging doesnât mean we arenât the right ones to do it.
Why âmore importantâ? To me, non-corporate-affiliated maintainers are the heart and soul of Open Source. If the only way to feasibly participate in Open Sourceâeven with vendor-neutral governanceâis as a representative of a corporation, I think something essential is lost.
1 Like
I feel that corporate and independent open source can play distinct yet complementary roles in the open source ecosystem â it doesnât need to be one against the other. Both have their strengths and challenges, and both can help drive innovation, collaboration, and adoption.
Some corporate strengths include resources, funding, infrastructure, and engineering talent to large scale projects, and long-term maintenance; this can lead to adoption and enterprise ready consumption. The flip side is possible steering of projects and restrictive license practices.
Independent strengths include innovation without corporate constraints and perhaps more neutral governance, and wider adoption. But, there can be resource and sustainability challenges, too.
I feel thereâs room for both approaches - together, their strengths can create a diverse, thriving ecosystem that benefits the global open source community.
Opinions are my own and not of my employer
3 Likes
I am not a candidate, but I feel the need to interject here.
This anecdotal data does not seems to fit with the (limited) data we have from studies of the opensource body of work.
Tideliftâs 2023 State of the OpenSource Maintainers report point that
60% of maintainers describe themselves as unpaid hobbyists, while only
13% describe themselves as professional maintainers earning most or all of their income from maintaining projects.
23% of maintainers describe themselves as semi-professionals, earning some of their income from maintaining projects.
Note that the report is mostly done by contacting maintainers working with Tidelift, which skews the data toward maintainers that are paid or spend a lot of time on their opensource.
This would mean that the real life data is probably even more skewed toward unpaid hobbyists. This lines up really well with what we know from analysis of the sheer size of opensource, see this report from my friend Josh Bresser
Even if we accept that corporate/paid opensource maintainers may write a lot more code per month, due to them being paid (which is not that obvious, when we know how inefficient the modern corporate environment for software engineering is), the only possible conclusion is that corporate/paid opensource is, by far, the minority part of opensource code out there. If not negligible in size. It may be larger in impact, this is an open question for research.
But I think it paint that question in a far different color.
2 Likes
(I am not a candidate. 
)
Within the Linux kernel development community specifically, itâs true that most maintainers and contributors are currently employed by large corporations. This makes sense because itâs those big companies that need new features in the Linux kernel. However, even if the Linux Foundation were to disappear, Linus would presumably continue developing the Linux kernel as usual.
Also, as Diana-san wrote, across the broader Open Source community, it remains a fact that the majority of contributors are still individuals who are not employed by corporations. This has been the case for decades.
Companies will hire Open Source developers if it benefits their business, and many people will continue to produce open source code regardless of those corporate movements. At the global community level, there doesnât seem to be any compelling reason to worry about that ratio. (That said, in countries like Japan, where traditional corporate practices may hinder the employment of Open Source developers, the situation could be somewhat different.)
If there is a concern, itâs the potential burnout of unpaid maintainers who get swamped by demands from people working at those companies. For decades, Iâve been saying, âIf youâre not feeling up to it, you have no obligation to fulfill usersâ requests. If they truly need that feature, they have the freedom to fork.â In the end, there may simply be no fundamental remedy for this issue.
Perhaps a more pressing concern is the possible onslaught of AI-generated code, which may already be underway.
I think itâs best to keep open-source as it is. However, like Wikipedia has successfully done for years, we should actively promote donations to support independent maintainers and ensure sustainability.
Well, there are also lots of contributors who are employed by nonprofits and many coders who are paid in the academic field. But if what weâre lamenting is the loss of hobbyists who could afford to contribute on their own time, thatâs different. That luxury of time and access to educational opportunities hasnât always been available to a very diverse set of contributors. Even though we are now seeing some progress in the widening of that privilege, it feels like what we might really be lamenting is longer work weeks and lagging pay rates in a lot of fields that arenât âwriting code at a company.â (I donât think those are topics that the OSI can affect, btw.)
FYI Iâve been discussing opengovernance for over 6 years now, I helped create GitHub - opengovernance/opengovernance.dev: opengovernance.dev which a basic checklist of things when I ran into some issues explaining the downside of certain open source projects controlled by single vendors.
I do think the OSI should consider putting out advisory guidelines or education around open governance. There are a lot of people out there that were confused with the Wordpress fiasco that open source doesnât necessarily mean that your marketplace or distribution channel is also openly governed along with all aspects of the code.
Anyways, thanks for sharing the resource 
1 Like
Thanks for chiming in, @Diana. I was hoping someone would bring some data to the table.
The Tidelift study is a good one to have in view. The other one I had in mind when kicking off this discussion is GitHub, LF, and Harvardâs 2024 Open Source Software Funding Report, which finds that companies contribute $7.7 B per year to Open Source, of which 86% is employee labor. Of course, this says nothing about the non-corporate-affiliated contributions. Is there a way to relate the two studies? 
skews the data toward maintainers that are paid or spend a lot of time on their opensource.
This would mean that the real life data is probably even more skewed toward unpaid hobbyists
corporate/paid opensource is, by far, the minority part of opensource
I donât see it this way. If the Tidelift data is skewed towards non-corporate-affiliated maintainers, then the 60% figure would probably be reduced significantly were the base to include corporate-affiliated maintainers, such as are represented in the Funding Report.
what we know from analysis of the sheer size of opensource
Josh observed that there were â727,986 unique NPM maintainersâ at time of writing, while also acknowledging that âthe vast majority of NPM packages will never see widespread use.â His 95%/5% split is consistent with a finding in âThe Value of Open Source Software,â from Frank Nagle, et al. (source of the infamous â$8.8 trillionâ fantasy), that the number of Open Source maintainers when weighted by impact is a few thousand. Andrew Nesbitt reported similar results a year ago:
So around 4,000 developers are responsible for packages that make up 80% of downloads for those 9 registries of 4.2m packages, totalling 870 billion downloads, the 0.1% if you will!
Still, the distribution of those few thousand between corporate-affiliated and non-corporate-affiliated is unspecified, so I agree: more research required!
Yes! 
How do we address this concern? What strategic role can and should OSI play?
Iâm inclined to lump these with âcorporate-affiliatedââbasically, paid by oneâs day job to work on Open Source. Probably worth dialing in clearer terms.
what weâre lamenting is the loss of hobbyists
Or at least, the threat of loss, the burnout that @shujisado identifies (and yes, this impacts diversity). Per previous comments, I think we have a pretty clear view that most Open Source is maintained by a few thousand people, but we donât have a clear picture of how many of those are âhobbyists,â though I donât think this is actually the best term. Who here wants to call PHK or Sindre Sorhus or Josh Goldberg a hobbyist? Hmm ⌠clearer terms.
Wikimediaâs shift to a broad individual donor base was highly intentional and a lot of work to pull off. Would you see OSI taking on this strategic role on behalf of non-corporate-affiliated Open Source maintainers?
Yyyyaaaasssss. 
Thanks for the links!
OSI should consider putting out advisory guidelines or education around open governance.
Weaker than a Definitionâ:trade_mark:, could be a good first step. Possibly even a learning from the OSAID experience.
confused with the Wordpress fiasco
Facts.
(It feels odd to see a thread in the âElectionsâ category where voters are answering questions posed by the candidates. )
Regarding the issue of unpaid maintainers burning out, my personal take is: âItâs not something OSI should be tackling directly.â If someone stops working on a personal project, and the code is still needed, then someone else will just take over. That cycle has continued for decades and shows no sign of ending anytime soon.
Last year, I investigated which individuals or organizations effectively maintained 1,000 Open Source software components used within a certain company. Then I categorized those components into three groupsâSingle-Vendor Open Source projects, projects under Nonprofit management, and projects maintained by Individuals or small collectives. Interestingly, the number of projects in each of those three categories was roughly the same. While the big projects people typically talk about are often under the Linux Foundation umbrella or run by well-known companies, smaller projects that get less attention tend even now to be personal projects.
If a personal projectâs founder burns out, yet thereâs still demand for it, someone else will take it over. Projects managed by nonprofits typicallyâby necessity, as Chris-san pointed outâhave clearer governance in place. Many of the âopen-washâ issues weâve been seeing in recent years ultimately occur in Single-Vendor-owned projects, so there may be something OSI can do in that area.
That said, Open Source is a concept that treats both âgoodâ and âbadâ actors equally. While OSI can recommend good governance practices, it canâtâand shouldnâtâtry to force them.
2 Likes
I agree. Candidates should pretend to have all the answers and not listen to the community. 
If someone stops working on a personal project, and the code is still needed, then someone else will just take over. That cycle has continued for decades and shows no sign of ending anytime soon.
Anyone is freeâand should be encouragedâto stop working on a project whenever they want for any reason. If the reason is that the rest of us burned them out, and this is a systemic issue for decades throughout Open Source, that seems to me worth addressing at the OSI level.
Last year, I investigated which individuals or organizations effectively maintained 1,000 Open Source software components used within a certain company. Then I categorized those components [âŚ]
Oooh ⌠did you publish about this? Can you share the link?
That said, Open Source is a concept that treats both âgoodâ and âbadâ actors equally. While OSI can recommend good governance practices, it canâtâand shouldnâtâtry to force them.
Hmm ⌠this depends on frame of reference. With respect to the Open Source Definition (OSD), we do have concepts of âgoodâ and âbadâ (doesnât attribute, doesnât share-alike, open-washes, etc.). Other possible concerns are undefined, as OSD doesnât address governance, field of endeavor, etc. It also doesnât address AI directly, hence OSAID, which now carries its own related-but-distinct âgoodâ and âbad.â An Open Source Governance Definition (OSGD) would do likewise.