![[RSS]](/static/img/feed-icon-14x14.png)
Conservancy Blog
Displaying posts tagged FOSS Sustainability
How we all develop and support free software
by on November 29, 2022
Today is Giving Tuesday, and I'd like to share part of my story that brought me to Software Freedom Conservancy. Having started as a donor over 5 years ago, I find myself now with even more passion for our mission as an employee.
I've been using software for close to 30 years; I wrote my first program around 25 years ago, and I've been working in non-profit free software for over a decade. Over all that time the thing that keeps bringing me back is that software is for people. Made by and for people.
Having worked in technical roles as a systems administrator, site reliability engineer and CIengineer, the last year and a half at Software Freedom Conservancy is the first non-technical role I've had. Stepping into the Community Organizer role has allowed me to reinvigorate my passion for FOSS by working directly with people. There have been the usual differences that have cropped up: feedback cycles with people are much longer than just pushing a new patch to see if the tests pass, prose is a lot harder to write than even the more esoteric programming languages (different people use different compilers!). I certainly never thought I'd have to help wih fundraising! But it turns out as a developer I often felt disconnected and distant from the people my code was supposed to support. So while stressful and juggling many things at once, it's a grounding activity that really drives home how connected our mission is to the people who help support us.
There are a few differences between non-technical and technical roles in free software development that I have noticed.
The first is bugs. There are bugs you learn to live with (screen sharing with Wayland and free software video conferencing is still a pain), and some that need the highest priority attention (it's been just over a year since the Log4J incident). Unlike debugging code, in community building spaces we don't have the luxury of thinking of problems as bottlenecks, with absolute solutions. With people, there are often no right or wrong answers. We work cooperatively over a long period of time to build a shared history that informs how we deal with issues that arise.
While in the technical context, I would often think of community building in terms of making it easier to get code upstream, or work with developers of an adjacent library. Community building itself has an intrinsic value, which is something we don't get when writing abstract code. The time scale for human interaction and relations is longer than the half life of an arbitrary patch and can thus use a bit more nuance and care when dealing with each other. Especially in the volunteer context of FOSS projects, understanding each others lives and timelines removes the ambiguity that text based communication often leaves.
Most starkly, the thing I never truly had to worry about in other jobs was fundraising. I thought I could dodge this aspect of my career by not continuing as an academic mathematician, but real work needs real resources. The technology field is an interesting one, we often have large amounts of money floating through what is often touted as a meritocracy. So in my mind if we could just talk about all the great work we do as a non-profit, by the meritocratic principles, we should have money flowing out our gills! Alas, the investors don't flock to non-profits as much as they do to startups.
So how can we work around the absence of a meritocracy to fund our work? I think it all comes back to finding the people who believe in software freedom as much as we do. And extending open arms to those people who haven't heard about it, but are equally affected by the encroaching proprietary software corporations. By sticking to our mission and actively creating a more equitable world in which software freedom is the default (and not an alternative we have to fight for) is how we'll gain momentum and win people over. Our dedication to software freedom speaks for itself through the projects we host, the diversity and inclusion efforts we sustain and by being the only organization in the world doing widespread license compliance.
The human side of open source is complex and requires deliberate, relationship-driven work. That deliberate work can be slow and doesn’t fit neatly under the profit and efficiency models that the tech industry often revolves around. The same mindset that coders apply to “bugs” doesn’t work for conflict resolution in communities, because people’s values and interests are multi-faceted. SFC works to sustain a thriving community around technology that works for people’s needs.
We at SFC do this work with your help. We are able to pursue a more just world, not just through code, but through relationship building with sustainers like you. Our community is incredible and I wouldn't trade writing unit tests for the joy and passion I feel working alongside contributors from all over the world. Please consider becoming a sustainer and helping us all year, or donating to us so we can work together to create a more just future for all.
Give Up GitHub: The Time Has Come!
by on June 30, 2022
Those who forget history often inadvertently repeat it. Some of us recall that twenty-one years ago, the most popular code hosting site, a fully Free and Open Source (FOSS) site called SourceForge, proprietarized all their code — never to make it FOSS again. Major FOSS projects slowly left SourceForge since it was now, itself, a proprietary system, and antithetical to FOSS. FOSS communities learned that it was a mistake to allow a for-profit, proprietary software company to become the dominant FOSS collaborative development site. SourceForge slowly collapsed after the DotCom crash, and today, SourceForge still refuses to solve these problems0. We learned a valuable lesson that was a bit too easy to forget — especially when corporate involvement manipulates FOSS communities to its own ends. We now must learn the SourceForge lesson again with Microsoft's GitHub.
GitHub has, in the last ten years, risen to dominate FOSS development. They did this by building a user interface and adding social interaction features to the existing Git technology. (For its part, Git was designed specifically to make software development distributed without a centralized site.) In the central irony, GitHub succeeded where SourceForge failed: they have convinced us to promote and even aid in the creation of a proprietary system that exploits FOSS. GitHub profits from those proprietary products (sometimes from customers who use it for problematic activities). Specifically, GitHub profits primarily from those who wish to use GitHub tools for in-house proprietary software development. Yet, GitHub comes out again and again seeming like a good actor — because they point to their largess in providing services to so many FOSS endeavors. But we've learned from the many gratis offerings in Big Tech: if you aren't the customer, you're the product. The FOSS development methodology is GitHub's product, which they've proprietarized and repackaged with our active (if often unwitting) help.
FOSS developers have been for too long the proverbial frog in slowly boiling water. GitHub's behavior has gotten progressively worse, and we've excused, ignored, or otherwise acquiesced to cognitive dissonance. We at Software Freedom Conservancy have ourselves been part of the problem; until recently, even we'd become too comfortable, complacent, and complicit with GitHub. Giving up GitHub will require work, sacrifice and may take a long time, even for us: we at Software Freedom Conservancy historically self-hosted our primary Git repositories, but we did use GitHub as a mirror. We urged our member projects and community members to avoid GitHub (and all proprietary software development services and infrastructure), but this was not enough. Today, we take a stronger stance. We are ending all our own uses of GitHub, and announcing a long-term plan to assist FOSS projects to migrate away from GitHub. While we will not mandate our existing member projects to move at this time, we will no longer accept new member projects that do not have a long-term plan to migrate away from GitHub. We will provide resources to support any of our member projects that choose to migrate, and help them however we can.
There are so many good reasons to give up on GitHub, and we list the major ones on our Give Up On GitHub site. We were already considering this action ourselves for some time, but last week's event showed that this action is overdue.
Specifically, we at Software Freedom Conservancy have been actively communicating with Microsoft and their GitHub subsidiary about our concerns with “Copilot” since they first launched it almost exactly a year ago. Our initial video chat call (in July 2021) with Microsoft and GitHub representatives resulted in several questions which they said they could not answer at that time, but would “answer soon”. After six months of no response, Bradley published his essay, If Software is My Copilot, Who Programmed My Software? — which raised these questions publicly. Still, GitHub did not answer our questions. Three weeks later, we launched a committee of experts to consider the moral implications of AI-assisted software, along with a parallel public discussion. We invited Microsoft and GitHub representives to the public discussion, and they ignored our invitation. Last week, after we reminded GitHub of (a) the pending questions that we'd waited a year for them to answer and (b) of their refusal to join public discussion on the topic, they responded a week later, saying they would not join any public nor private discussion on this matter because “a broader conversation [about the ethics of AI-assisted software] seemed unlikely to alter your [SFC's] stance, which is why we [GitHub] have not responded to your [SFC's] detailed questions”. In other words, GitHub's final position on Copilot is: if you disagree with GitHub about policy matters related to Copilot, then you don't deserve a reply from Microsoft or GitHub. They only will bother to reply if they think they can immediately change your policy position to theirs. But, Microsoft and GitHub will leave you hanging for a year before they'll tell you that!
Nevertheless, we were previously content to leave all this low on the priority list — after all, for its first year of existence, Copilot appeared to be more research prototype than product. Facts changed last week when GitHub announced Copilot as a commercial, for-profit product. Launching a for-profit product that disrespects the FOSS community in the way Copilot does simply makes the weight of GitHub's bad behavior too much to bear.
Our three primary questions for Microsoft/GitHub (i.e., the questions they had been promising answers to us for a year, and that they now formally refused to answer) regarding Copilot were:
-
What case law, if any, did you rely on in Microsoft & GitHub's public claim, stated by GitHub's (then) CEO, that: “(1) training ML systems on public data is fair use, (2) the output belongs to the operator, just like with a compiler”? In the interest of transparency and respect to the FOSS community, please also provide the community with your full legal analysis on why you believe that these statements are true.
We think that we can now take Microsoft and GitHub's refusal to answer as an answer of its own: they obviously stand by their former CEO's statement (the only one they've made on the subject), and simply refuse to justify their unsupported legal theory to the community with actual legal analysis.
-
If it is, as you claim, permissible to train the model (and allow users to generate code based on that model) on any code whatsoever and not be bound by any licensing terms, why did you choose to only train Copilot's model on FOSS? For example, why are your Microsoft Windows and Office codebases not in your training set?
Microsoft and GitHub's refusal to answer also hints at the real answer to this question, too: While GitHub gladly exploits FOSS inappropriately, they value their own “intellectual property” much more highly than FOSS, and are content to ignore and erode the rights of FOSS users but not their own.
-
Can you provide a list of licenses, including names of copyright holders and/or names of Git repositories, that were in the training set used for Copilot? If not, why are you withholding this information from the community?
We can only wildly speculate as to why they refuse to answer this question. However, good science practices would mean that they could answer that question in any event. (Good scientists take careful notes about the exact inputs to their experiments.) Since GitHub refuses to answer, our best guess is that they don't have the ability to carefully reproduce their resulting model, so they don't actually know the answer to whose copyrights they infringed and when and how.
As a result of GitHub's bad actions, today we call on all FOSS developers to leave GitHub. We acknowledge that answering that call requires sacrifice and great inconvenience, and will take much time to accomplish. Yet, refusing GitHub's services is the primary power developers have to send a strong message to GitHub and Microsoft about their bad behavior. GitHub's business model has always been “proprietary vendor lock-in”. That's the very behavior FOSS was founded to curtail, and it's why quitting incumbent proprietary software in favor of a FOSS solution is often difficult. But remember: GitHub needs FOSS projects to use their proprietary infrastructure more than we need their proprietary infrastructure. Alternatives exist, albeit with less familiar interfaces and on less popular websites — but we can also help improve those alternatives. And, if you join us, you will not be alone. We've launched a website, GiveUpGitHub.org, where we'll provide tips, ideas, methods, tools and support to those that wish to leave GitHub with us. Watch that site and our blog throughout 2022 (and beyond!) for more.
Most importantly, we are committed to offering alternatives to projects that don't yet have another place to go. We will be announcing more hosting instance options, and a guide for replacing GitHub services in the coming weeks. If you're ready to take on the challenge now and give up GitHub today, we note that CodeBerg, which is based on Gitea implements many (although not all) of GitHub. Thus, we're also going to work on even more solutions, continue to vet other FOSS options, and publish and/or curate guides on (for example) how to deploy a self-hosted instance of the GitLab Community Edition.
Meanwhile, the work of our committee continues to carefully study the general question of AI-assisted software development tools. One recent preliminary finding was that AI-assisted software development tools can be constructed in a way that by-default respects FOSS licenses. We will continue to support the committee as they explore that idea further, and, with their help, we are actively monitoring this novel area of research. While Microsoft's GitHub was the first mover in this area, by way of comparison, early reports suggest that Amazon's new CodeWhisperer system (also launched last week) seeks to provide proper attribution and licensing information for code suggestions1.
This harkens to long-standing problems with GitHub, and the central reason why we must together give up on GitHub. We've seen with Copilot, with GitHub's core hosting service, and in nearly every area of endeavor, GitHub's behavior is substantially worse than that of their peers. We don't believe Amazon, Atlassian, GitLab, or any other for-profit hoster are perfect actors. However, a relative comparison of GitHub's behavior to those of its peers shows that GitHub's behavior is much worse. GitHub also has a record of ignoring, dismissing and/or belittling community complaints on so many issues, that we must urge all FOSS developers to leave GitHub as soon as they can. Please, join us in our efforts to return to a world where FOSS is developed using FOSS.
We expect this particular blog post will generate a lot of discussion. We welcome you to interact with SFC staff on our public mailing list about this effort.
Footnotes
0SourceForge is now built as a (apparently proprietary) fork of a different FOSS system (called Allura). SourceForge's CEO ignored our multiple inquiries asking if SourceForge really is running upstream Allura (i.e., has no proprietary modifications), and our repeated requests for a link that explains how a project can leave SourceForge for self-hosted Allura. The responses from SourceForge management were quite similar to those received since 2001 — when they first went proprietary.
1However, we have not analyzed CodeWhisperer in depth so we cannot say for sure if Amazon's implementation is compliant with the respective licenses. Nevertheless, Amazon's behavior here shows sharp contrast with Microsoft's GitHub: Amazon acknowledges the obvious fact that there are license obligations that deserve attention and care when building AI-assisted programming solutions.
Asking Microsoft to resign from the RIAA over youtube-dl takedown demand
by on October 26, 2020
We learned on Friday that GitHub removed youtube-dl's primary collaboration forum and code repository from their site, which had been hosted at https://github.com/ytdl-org/youtube-dl. The action was in response to a DMCA Section 512 notice that the RIAA sent demanding removal of youtube-dl, which was released and distributed via GitHub under a liberal FOSS license. In the notice, the RIAA cites DMCA Section 1201 (the removing digital restrictions section) as justification for youtube-dl's removal.
We believe that youtube-dl has substantial non-infringing uses. There are many, but to name a few, youtube-dl has the following important features:
- enable users to watch YouTube videos without installing any non-free software
- watch YouTube at different speeds (including speeds YouTube does not offer) — an important feature for accessibility!
- view YouTube videos at their highest quality on low-bandwidth connections
- ability to download (and then, with other software, modify and reuse) freely licensed videos, such as those licensed under CC-BY
- various aids for journalists, including fact-checking, video analysis, and bandwidth saving
We realize Microsoft, a paying member of the RIAA, has left themselves stuck between their industry association's abuses of the law and the needs of FOSS projects for which they provide infrastructure. While under current law (which we object to), complying with the takedown notice is admittedly the fastest way to limit Microsoft's liability, we view Microsoft's membership in the RIAA as a much bigger liability to our community, now that Microsoft controls GitHub. We call on Microsoft to resign from the RIAA and remove their conflict of interest in this matter. This is an important opportunity for Microsoft to stand up for the values of software freedom.
If you work at Microsoft (including for its GitHub subsidiary), we call on you to petition your employer to resign immediately from the RIAA. We suggest that you raise these concerns directly with your manager or other management, or (even better) by starting an internal email petition with other employees.
To build a strong community of FOSS developers, we need confidence that our software hosting platforms will fight for our rights. While we'd prefer that Microsoft would simply refuse to kowtow to institutions like the RIAA and reject their DMCA requests, we believe in the alternative Microsoft can take the easy first step of resigning from RIAA in protest. We similarly call on all RIAA members who value FOSS to also resign.
Some Work-At-Home Tips for FOSS Contributors
by on June 23, 2020
The global COVID-19 pandemic has changed everyone's lives, and taken the lives of so many of our family members and friends. For those of us that have been spared, our lives must continue, and this is particularly true for those who work in Free and Open Source Software (FOSS), since so many of us already worked from home. Doing so when our world faces so many simultaneous crises is undoubtedly difficult. I share below a few ideas that I've had that might be able to help my fellow FOSS contributors.
We have a weekly meetup of FOSS contributors where I live, which once upon
a time met at a restaurant for late breakfast, but now meets weekly on a
Jitsi instance installed by one of the members. During a recent session,
one contributor complained about a real problem she faced, as she put
it: All my non-FOSS friends keep asking me ‘Teach me how you work
from home; I'm doing it for the first time and failing’
. The
answer she gave them was that what is happening now is not the
“working from home” that she had trained herself for all this
time.
Specifically, she meant that most of us who already work from home have built quite easy routines of having the home to ourselves. Roommates, children, life partners, and family who live in the house often have at least some of their day when they're away. Now, everyone is staying at home, so the personal procedures and systems that those of us who stay while the others go have simply evaporated.
My colleague's observation was quite salient. I've seen plenty of articles talking about how to work from home, but few have tips for how to handle the unique situation where everyone in the house and must all work from home together. I have a few ideas that I thought might help in this regard. Admittedly, some of these tips are likely FOSS-specific, but if you've found this article and don't work in FOSS, there might still be a hint or two that helps. Here's a list of changes that I've made that have really worked for me:
Hour-shift if you can. If you're able to, attempt to try new times of day. For me, I've been attempting to wake up earlier than everyone else in the house and get a few hours of work before others in the home start their day. Our Executive Director, Karen Sandler, has been working late in the evening after her children are in bed. Of course, shifting to inconvenient times is difficult and annoying, but we've found it can help to fit in a few hours of focused work during these difficult times.
Reorganize rote tasks for right time of day. When lots of people are around the house, some times of the day are inherently going to be louder and more chaotic than others. Keeping that in mind, I often try to plan out a day so that tasks that require serious concentration are scheduled for the most quiet moments and rote tasks are saved for those moments when it feels like nothing else can be done. For example, if I have to write complex correspondence with FOSS project leaders, I try to do that early in the morning, and save the Git repository reorganization project — which is mostly waiting for long rebases to finish and cherry-picking changes from other branches — for those times when my quarantined neighbor is power-washing his driveway.
Mix housework with conference calls. My colleagues at Conservancy already know this, but for those of you who have been on the phone with me now may be in for a shock: if you've had a conference call with me recently, I was probably loading or unloading my dishwasher, cleaning the kitchen, or doing laundry while I spoke with you. The amount of housework for all of us has gone up now that we're all going nowhere else, and it's tough for all of us to fit it in. Most of our work in FOSS is at a keyboard, but for those moments when I don't need the keyboard and screen in front of me, I look for tasks that need attention that I can easily do while wearing a headset. Of course, I recommend the double-mute button solution to really ensure that your colleagues don't hear the kitchen sink spigot on the line!
Not everything needs a video chat. Video chat is now mainstream and everyone seems to want to use it. Of course, I (and all of us at Conservancy) encourage use of FOSS solutions, such as Jitsi and Big Blue Button. However, not every meeting needs a video chat, and, fitting with the previous point, being tied to your desk for a long video chat at a time when you're in a crowded house can be difficult. Encourage your colleagues to use a simple phone call when it will do for a meeting. Use a mobile or cordless phone so you can take a walk while talking, even if it's just wandering around the house. Furthermore, being cognizant to the increased noise levels in all our homes — be it from children playing, or that power washer next door that I mentioned — consider meetings on IRC, XMPP or other forms of FOSS online chat. This also allows folks the flexibility to step away for an emergency and come back to catch up.
Keep working on context switching skills. I admit that I envy people who can truly multitask and keep clear attention on two complicated things at once. It's a skill that I've never been able to develop, but there's another skill that can be equally valuable: the ability to switch between two tasks quickly. Those of us that program know that speeding up context switches on a computer speeds just about everything up on the computer. It's also (at least a bit) true with a person. If you can handle a surprise issue that someone in your house is asking you about, and quickly return to work without losing too much time to re-acclimate yourself, it really helps to keep work efficient during these tough times. Like any skill, it requires practice to develop. I find the best way to practice is be very mindful about what I'm working on at any moment and why, and when a distraction comes along, I evaluate it carefully by sub-vocalizing, and then note down something about where I was with the task I'm on before switching. I find that even the briefest of notes (3-5 words) makes a huge difference when I attempt to swap the task back into my mind.
Finally, keep in mind that one good fact in the sea of bad things in our world is that all of humanity is facing COVID-19 together. Those of us who are fortunate enough to do our jobs from relative safety in our home owe it to do our best to work efficiently and keep going, while the essential workers who are caring for the sick, searching for a vaccine and shelving our grocery stores take risks on our behalf to help our society survive the pandemic. I try to have empathy for all the others facing challenges that are greater than mine during the pandemic, and do the best I can in my own work to honor their sacrifices.
