What is sustainable open source? #65
Comments
|
I sense two different branches right now in the "sustainability" effort for open source:
Upstream we have the problem of ongoing maintainers with no compensation, downstream we have the problem of compensation with no ongoing maintainers. I believe that our current state of company-backed open source appearing to be more sustainable is merely an accidental side-effect of our craft letting VC-backed companies set the agenda of what we consider best practices/tools and success. I think we can make that go away. Traditional open source didn't go anywhere, we just stopped seeing its outcomes as success somewhere along the way. |
|
First of all thanks @vsoch for that awesome soundcloud audio-essay - nicely done. I've been chewing on this all weekend, and one of the things that struck me in my experience in academia, non-profits and in my consulting work, is the necessity for everyone to "come to terms with" and "agree upon" what is meant by the words we are using in order for dialogue to make sense and afford real decision-making power. So before I can answer your question about what is sustainable, I think we can all agree that it is pretty important to agree upon what WE mean when we judge something to be (or not to be) sustainable. So that's what this response is about - an etymological teardown of this term and then the application of what we've uncovered in the context of the question you posed in the title of this issue. PIEI really enjoy the journey of looking at common meaning in the sounds of the words we use, and Proto-Indo-European is a fun place to start. This is the shared heritage of language - like Interlingua but on a much more scientific and less political level. *upoThe first Proto-Indo-European root within sustainability is *ten-The second Proto-Indo-European root within sustainability is SUSTAINThis word undoubtedly comes from the Latin sustinere "hold up, hold upright; furnish with means of support; bear, undergo, endure." To sustain something means to keep it "around", or "alive". As a verb it implies that there is an action, an effort involved. There is no moral prejudice here, because commonly accepted "bad things" can also be sustained - such as the chewing of one's fingernails.
SUSTENANCEThe things that a houseplant needs for its "sustenance" are regular access to water, having access to a pot big enough for its roots to grow and that its leaves get the right amount and type of light to enable photosynthesis. The classical meaning of this word is literally "means of living, subsistence, livelihood" and has survived to this day - even if it is not terribly common. SUSTENTATIONSUSTENTATION is the act of providing SUSTENANCE in order to SUSTAIN. And here is where I think it gets really interesting from a semantic standpoint. Because the thing that really needs to be "sustained" is not the code per sé - but the attention that SOMEONE actively puts into using, developing and maintaining code. And these PEOPLE doing this stuff NEED sustenance. SUSTAINABLENow that we know what it means to sustain and what sustenance is, we are in fact at the crossroads here and potentially where we need to really differentiate. It is clear that ANYTHING is sustainable, because sustaining something is "merely" giving it what it doesn't (inherently) have but needs to survive in order for it to continue being what it is.
The diagram above shows the duality we are faced with, and now I need to pass the ball back to you. Are we concerned with the sustenance of CODE or are we concerned with the PEOPLE first so they can be concerned with the CODE?
|
There is a rather lengthy discussion going on at the sfosc repo about what sustainable open source is, and I think that showing our users that we really are invested in open source is a good thing to do. Here is some background information. sfosc/sfosc#65 https://github.com/good-labs/greater-good-affirmation
|
@themightychris this is very insightful:
If I can summarize with some of the phrasing that I've used, traditional open source success is out there, but it's hard to see among the artificial (VC-backed) success stories. My worry is that those aren't mutually exclusive - that the second can hurt the first. It's like having a small town with a bustling coffee shop, and then 4 Starbucks move in. Perhaps the coffee isn't better, but it's hard to tell when you visit the town and don't have history because you've seen those special red cups on TV. @nothingismagick how can we sustain code without people? Here is what (my understanding) of closed source would look like: A small team of developers is sustained (salaries) to maintain a code base. In the simplest of scenarios, opening up the code increases the size of the developer base, and other contributors show up (error reports, documentation fixes) so the "to attend to" error gets stronger. And if you are a company, then you realize this is working really great for you, but what if you could strategize to get more back than code? The code feeds into a service, of course! And then the equation is fairly straight forward - put more strength in any of those arrows and the profits increase. That's what the model looks like. But from the standpoint of the contributor? He or she might still see this: So to answer your question - for traditional open source, we are concerned with sustenance of code. But that actually means being concerned about the people maintaining it. For artificial open source, what troubles me is that the emphasis isn't on code or people, it's on the last step there - the $$$. Sustenance of people and code are just the stepping stones to get to that. This isn't something any large VC funded project would ever admit. It would ruin the feel-goodness for being open source, and turn people away so that their pipeline would eventually dry out. Yet it is fundamentally different than the traditional model. So - how do we distinguish these two things? How do we encourage and highlight the more traditional project success stories that are in the shadow of a coffee conglomerate? :P |
Not that I do not agree that this is something that should be done, but what does this have to do with sfosc.org? |
|
There is no sustainable open source community if projects die out being in the shadow of something that looks like traditional open source, but isn't. |
|
IMHO the only thing that can make open-source "fake"/"artificial" is a lack of work put into making the realization of FOSS rights economically achievable for intended users. What motivates someone to invest funds in developing it can be irrelevant if users are empowered to know what to look for. To me the most obvious way that SFOSC could help with this problem is by helping define what qualities can make a project sustainable -- can someone redeploy it without being a core dev? Can someone move it to new hosting without being a core dev? Can someone upgrade its dependencies without being a core dev? Can someone make common surface-level changes and go through a test->deploy workflow without being a core dev? Can someone fork it and know exactly what to do to avoid IP liabilities without hiring a lawyer? etc If a project goes beyond slapping a FOSS license on the repo and puts in the work to check all these sustainability boxes, it doesn't matter what the economic model is/was/will be--the user has rights they can count on for sustaining their use, and more importantly in many cases their organizations' use beyond their own tenure If SFOSC can cultivate a community consensus around what sustainable FOSS looks like, and promote tools/practices to make more FOSS sustainable, than users will have a better chance of knowing what will be sustainable at the outset |
|
This is a really good idea! I can give a quick example for relatively prominent projects that I'm not sure would fit these criteria. Specifically, looking at the question "Can someone redeploy it without being a core dev?" What comes to mind is Kubernetes. It's a beast that is somewhat reasonable to use when it's hosted, but almost impossible to roll your own. You need pretty substantial infrastructure to deploy on, plus a substantial team with a lot of expertise. That along creates huge barriers to being able to use it, and so the incentive to pay for it as a service is fairly strong. It gets stronger when other OSS encourages using it. Users get invested, and then they either invest or go elsewhere. But on the other hand, what if there is some function that is inherently complicated, and there is no way to get around the complexity. How is that line drawn? |
|
I feel it's important to avoid trying to bucket projects as being in or out as some permanent essence of their being--I don't think we should be drawing lines. Each quality that makes a project more sustainable is a spectrum that projects should constantly moving forward on. We need to be painting the path to being more sustainable and exerting pressure to move the whole ecosystem forward on every quality. Everything is relative anyway. With the kubernetes example, if we define the target user as someone who wants to host an application--yeah it's very difficult to roll your own. But if we define the target user of kubernetes as someone already rolling their own way to host fleets of applications without kubernete...that totally flips that evaluation |
|
It's kind of interesting that when you look at this exact same discussion from an academic standpoint, nobody is really thinking about industry involvement. It's more about scientific reproducibility than "this software is going to go away entirely because the license would change / we couldn't deploy it" etc., but for the last point, not being able to deploy it because there isn't enough information, not being able to deploy it likely because funding / resources have run out. How do you guys group / think about sustainability in academia vs. industry, are they the same? |
|
Yeah I totally agree @themightychris. |
|
Another community which asked this question: |
|
Very interesting discussion, thanks @vsoch . Sustainability implies two periods of time: today, and the future. An unsustainable FOSS community meets its members' needs today, but cannot in the future. So, maybe we define sustainable in our sense by drilling down on community flaws that would make the future community "not viable" / needs not met. This paragraph from @themightychris is great:
Perhaps we should come up with a whitelist of things a community would have to be able to do in any time period that if not met, would reduce or eliminate that future community's viability? We could then break down the kind of sustenance each of those items needs (devs, money, effort, documentation & training, legal protection, etc). |
|
Yes, I keep enjoying this idea. #59's cost of forking. And the "can you" list of questions. It works similar to the CII badge, with a Q&A format to get a good grasp on where you're at in terms of qualities and best practices. The way you're describing it now @NickKellett, not only can they be used for projects directly to figure out their own sustainability pain points. It could be a template for evaluating models / contracts too. We should be very clear though on what SFOSC means by sustainable exactly. One non-obvious aspect I think is in the https://sfosc.org/sfosc-book/motivations/. Having the right incentives to create more FOSS, not less. Isn't necessarily the same as keeping a single community afloat. I think it may also be part of what https://github.com/good-labs/greater-good-affirmation is getting at. Though I'm not well versed enough on it yet, so I could be wrong on that. But there is definitely an element of not defining sustainable as a self-serving kind of sustainable. But sustainable in creating more good things for the commons. @NickKellett @themightychris could you help make an issue to move this idea of list of qualities forward? |
"Open source" is thrown around rather casually, and it's come to mean everything from a small, homegrown project, to a company supported behemoth with an advertising department and paid developers. The issue I have is that projects that previously might have been valued based on their utility (that don't have company backing) are now being hidden behind the corporate open source. It's also the case that companies can (in a way) hijack the open source culture for branding. You know, the label "open source" says good things. It looks good! want to bring up discussion here about this - how do we group these different things? Is "traditional" open source now better labeled as relating to academia, or science, or something else? Is traditional open source just... going away, because it wasn't sustainable to begin with? If companies have an easier time with sustainability, is that fair? What I think is a compelling different are incentives - whether the project exists "for the greater good" or to encourage users to deploy a service and make a company money. I've been trying to come up with some criteria that might be able to distinguish these groups, and am interested in feedback:
https://github.com/good-labs/greater-good-affirmation
It started as a pledge (where participation meant clicking a button to open an "edit" link on a participants.csv file, and then adding a project or community) but feedback from some communities I work with said that it was too much of a promise they didn't want to take. It's since been adopted to just be an affirmation - a project or community can read it, affirm they are for the greater good, and add a badge to their repo. Regardless of who reads it, it will help to make them think about "Is my project incentive structure transparent?" and possibly improve.
Another idea I had for definition was less about incentives, and more about levels. For example, I'd say that the communities that the "Greater Good Affirmation" wants to support are somewhere less than non-profit:
And within those groups, it's usually the case that academic/science are to the left of non-profit, and industry to the right. Whether the definition is based on incentives, and/or definition of the entity itself, I'm very interested in creating some definition that supports / honors the traditional model, the one "for the greater good." Thoughts?
The text was updated successfully, but these errors were encountered: