Recently, E Hashman of the OSI board asked for feedback from communities that traditionally don’t have ties with the Open Source Initiative, particularly the JS, Ruby and Rust communities. As I was heavily involved in the latter two, I decided to answer, received a questionnaire and answered it. It was a very pleasing exchange, thank you!
I don’t want to repeat the questionnaire or my answers here, but the central question “What’s stopping you from becoming a member of the OSI?” stuck with me and I want to write down my personal (biased, incomplete) view of the OSI and particularly why I never spend a passing thought on it, unless inquired.
Note: since writing this article in 2020, there has been leadership changes at the OSI, including hiring full time staff. Their new executive director set up a number of programs. I appreciate the changes and they are a start towards fixing the issues laid out here. As mentioned in the end of this post, while I would still stand by some of the criticism, I think it’s also important to support the current OSI staff in addressing it in their own way and give them the space to do it.
I’m biased here, but I believe that the JavaScript, Ruby and Python communities were responsible for the dominant cultural shift in programming from 2010 on. I would even go as far as saying that Rust isn’t even particularly innovative, but applied practices from those communities well. These communities were effective at building new structures, bringing coding to the masses and thinking new ways. The Ruby Community invented the (Rails)Bridges and Rails Girls and a very distributed network of small conferences and non-profits, such as Ruby Central, Ruby Berlin and RubyTogether. The Python community built a highly effective foundation and the PyCons, which are still a reference model for e.g. effective abuse handling and public documentation of procedures. The JavaScript community has shown an extremely good hand at scaling wide and broad, showing community prowess and being very nimble at addressing technical problems.
Together, they have understood that the way to scale your communities is bringing new people in and understood using the hypergrowth of the tech sectors in their years to their success. Although Ruby ends the clear third after a decade, Ruby would be irrelevant nowadays without those approaches.
In summary, I would say that these 3 communities aggressively pushed the needle of what’s practice in open source. Especially in my local area, in Berlin, this can be seen through the success of non-profits like OpenTechSchool, which is technology-independent, but driven by members of those 3 communities.
I am along for that ride - first RailsConf Europe attendance in 2008, first organisational work in 2010, with germany.rb, the German Ruby meetup, then eurucamp in 2012, the Rust Meetup under OTS since 2014 and RustFest since 2016. I started contributing to the Padrino webframework in 2011, and to Rust in 2014. Present tense, because this is a great ride.
All of these environments can easily be called “Open Source”. For example, Ruby on Rails was a driver for the popularisation of the MIT license as the default license in the Ruby world, despite Ruby’s inventor, Yukihiro Matsumoto, being a recognised free software advocate. Yet, their detachment from the OSI is a curious matter. One would imagine that the sudden success of not one, but three ecosystems would make the stewards of open source interested! No such thing happened. I can only speculate on reasons from the OSI side, but I can give my personal reasons for the other way around.
The last decade or so has seen a huge uptake in both open source productivity and in creation of new community structures. Especially, it saw the formation of structures beyond code and beyond the old ones. To give an example here: OpenTechSchool (OTS) was created to teach people coding - more than 10000 people have used that offer in over 1000 events in the first 5 years since its inception. And this is just the tip of the iceberg of a new meetup and conference culture in FOSS. The groups organising OTS events are a new generation of community and project organisers, who have a mission that goes beyond making code free: actually democratizing coding by destroying barriers and giving marginalised people a spot in an environment that should be accessible, but isn’t. Those structures have an interesting property: a desire for independence.
But the software side also started to struggle: a lot more software started popping up and the production of open source software has accellerated extremely. And facing the high additional amount of labor necessary to deal with a much bigger community and much bigger competition, the same issue popped up: independence.
In both of these contexts, independence is often discussed as a money issue, usually in two variants. The raw one: how do I even get money for my work? And the hidden one: If I receive large amounts of money, e.g. by being employed, how does my project stay independent?
There’s again three ways out of this:
The first: Ruby on Rails has indeed answered the question by stepping off and just not taking money, finding other ways of getting their infrastructure cost paid. This still means that Rails production costs money and someone foots the bill, but it’s essentially a big barter deal. This leads to a number of weird issues, like the actual cost of a project not being calculatable and funds not being shiftable. Cost-savings don’t work to your benefit, but the donors.
The second is blunt: just not play the game anymore. I remember a quote from alicetragedy at a conference where I inquired how a project was doing: “It’s successful, so I may have to shut it down”. Retract your labour.
The third is also rather upfront: build a funding structure, which means additional labour overhead, especially around distributing funds and paying the people distributing the funds. Also, tons of conversations with potential sponsors.
You may look for the fourth, “getting people employed”, but that doesn’t give you independence, as those people are clearly bound to their employer’s direction. This is not a theoretical case, FOSS developers getting hired into companies and at some point moving up the career ladder is a cause of maintainer drain.
But this article is about the OSI, or, rather, about the absence of the OSI. And I think that is the crux of the issue: this transformation has happened without the proclaimed stewards of the Open Source Definition. And this isn’t unsurprising, because OSIs focus is different: OSI is about promoting Open Source in the industry.
This does, for example, show in their education material, which (except a course for kids) is often aimed at the interaction of businesses with the Open Source world. Only the GitHub material is aimed at non-corporate Open Source maintainers, but obviously biased towards GHs services they provide to the community. The other linked guide by TODO Group uses multiple huge entities like Uber or Microsoft as case studies. The third one is the Google open source documentation, which is mainly aimed at Googlers. My general conclusion is that individual maintainers are not the main target group of the OSI, especially not in practice teaching.
They do provide useful resources to maintainers, like the OSI license list and the license discussion mailing list, but these are only a fragment of the issues we are facing today.
Case studies, investigations and similar around popular, indepent Open Source projects are suspisciusly missing. The only writing I could find that does touch on the issues I mentioned above is this one, which pretty much argues the status quo.
And this is the reason why I never think about the OSI, except when I want to check whether a license is considered open source. Because it has, by itself, been very absent. Beyond the utility value of defining what “Open Source” is1, OSI is not helpful to me.
It didn’t pick up interesting threads and didn’t try to get in touch with communities that didn’t naturally gravitate towards them. One of their co-founders being extremely aggressive towards progressive causes, which were an underlying thread of many of the changes mentioned above, did add some negative feelings in the mix. I say some because I appreciate that ESR is not the OSI and many of the current OSI leadership don’t hold his views, but this hampered the organisation on growing a new community.
But my main issue with the OSI is how little positive and forward-thinking I get out of it. Studies on Open Source issues like Roads and Bridges (and its follow-up book Working in Public), or things like the Maintainerati Report would have been home-runs for the OSI to produce or at least promote. Mozilla’s Open Leadership Resources and trainings are also to be mentioned. All of these are much more useful to me as a maintainer and project lead striving for independence than anything the OSI produces. Their leadership is also mainly consisting of people employed at a number of companies, shielding them from the issues mentioned above.
I find OSI’s current public behaviour disconcerting. Or, rather, the absence of public behaviour, replaced by vocal chair-people. All the issues mentioned above have increased, even culminating in the current drift of “ethical source”, which adds an additional layer of morality on top. It’s a subject for another post, I do actually believe this issue would be less hot if the previous ones were addressed earlier.
The Ethical Source and Open Code (payment involved) movements is a direct attack on the values of the OSI (and, incidentally, the FSF), from a direction that I believe those organisations did not see it coming: from maintainers and developers. I believe that this is the first fundamental value shift on that front since the Open Source movement split from the Free Software Movement. This puts especially the OSI on the defense. And this defense is weakened, as they have missed building ties to major community drifts. The inability to see and address those drifts and reorient towards maintainer issues has left the OSI out in the open.
This is sad, because the OSI is uniquely positioned to guide these discussions: it is an old organisation with many ties to companies. Losing the OSI would be losing a lot of ties that have taken years to build. I have yet to see relevant changes to their mode of working, though, finding their own, practical answers and guidance to the issues mentioned above.
I remain to be convinced otherwise, but I see the OSI on the way to irrelevance. I’m personally very conflicted around it, because I still see value in fully liberal Open Source, but also value the current drifts that eschew harmony and hegemonism in favor of more solutions, centered around individual wishes and developers, not the ease of use for multinational companies.
Thanks to Steve Klabnik, Don Goodman-Wilson and Jan-Erik Rediger for crossreading and corrections.
top