2024 Fundraising matcher interview with Patrick Masson

by Daniel Takamori on December 5, 2024

CC-BY-NA 4.0 Patrick Masson

We're so happy to feature our incredible matchers this year! Thanks to all of them for contributing to our largest match goal yet. Today we're talking with Patrick Masson, Executive Director of the Apereo Foundation.

SFC: Tell us a bit about yourself! Where are you from, what are some of your hobbies? Social media?

Patrick: I am currently the Executive Director of the Apereo Foundation. Apereo was established in 2012 as a non-profit organization and works to support and develop open source software for higher education. The foundation's mission is to assist academia in developing, adopting, and maintaining open source software for teaching, learning, and research. Before Apereo, I was the General Manager of the Open Source Initiative. I have also worked in higher education as a CIO of The State University of New York, Delhi, and CTO at the University of Massachusetts, Office of the President. I started my career as a Scientific Illustrator, moving from pen and ink to computer-generated imaging, thus leading to my later roles in academic computing and free and open-source software.

I live in Albany, New York, moving here from southern California (San Diego and Santa Monica) about 20 years ago. I am on Mastodon at @massonpj@fosstodon.org. I have a Twitter account, but it is dormant and redirects to Mastodon. I'm on LinkedIn but rarely participate. In addition to working at Apereo, I am an adjunct professor at The University at Albany, teaching "Open Source Princinples and Practices" in the College of Computing & Information. I also served on my local school board for four years, 2014-2018. I enjoy playing hockey and biking (slow touring, nothing serious) with my wife, Jamie. We have two sons--and despite all my tutelage and advocacy, one works for Microsoft as a software engineer developing very proprietary video games--Thanksgiving is tough ;-).

SFC: Why do you care about software freedom? How long have you been involved?

Patrick: I first discovered Free Software in the early 90s while working at UCLA. My work focused on medical and scientific visualization. Many of the tools we used from academic and research initiatives were readily shared. The idea of "software freedom" was not well established (or perhaps known to me) then. Rather, universities worked under traditional, collaborative models where peers created cohorts of practice around shared research interests and efforts. The software was just another output of research to be peer-reviewed, edited, built upon, and used by researchers as needed (That sounds like "software freedom"). While we did use software that today carries an OSI Approved License (remember this is before the OSI was founded), including Linux, NCSA HTTPd, some FTP servers, etc., most of the software was community-built, where collaboration, cooperation, and co-creation, were the drivers. No one thought about this beyond the software-specific use cases driving development at an institution or across research efforts. While not labeled as such, the ideals or ethos, practices, and benefits of software freedom took root with me then.

SFC: How do you use free software in your life?

Patrick: I use free and open source software daily and emphasize its use, from my home computing (mobile phone, laptop, and desktops) to professionally at the Apereo Foundation. Working for an organization advocating and supporting free and open source software, I feel it is essential that "we eat our own dogfood." As such, my work computer runs Linux and only FOSS tools/applications, and we strive to deploy FOSS for our business and administrative computing, e.g., Drupal for our website, CiviCRM for our constituent management, BigBlueButton for web conferencing, XWiki for our document management, etc. Truth be told, a few legacy systems are in place, but as opportunities arise to migrate, I expect to do so. How can we convince the institutions we reach out to that FOSS is a viable option if we've not also selected that option?

SFC: On the spectrum on developer to end user, where do you lie? And how do you think we could do better bridging that divide?

Patrick: Like many in our industry, "career advancement" often requires moving away from developer to administrative roles. So, while I am--and always will be--an end user personally and an advocate for free and open source software within the organizations I work with, I do not do any significant development (coding) of software these days. I suppose it could be said that my "development" efforts today are focused on developing organizations that create and maintain free and open-source software and the communities of practice that make it all possible. My efforts (building awareness, fostering adoption, and promoting contributions) include developing an authentic ecosystem beyond software communities were free and open source software--and even the ideals/ethos--can thrive throughout industries and institutoins.

SFC: Tell us about how Apereo is forwarding software freedom and about your role in the org.

Patrick: I joined Apereo just over two years ago. At the time, Apereo primarily served as a fiscal sponsor for open source software developed by academic and research institutions. As free and open source software has become operational on campuses and fundamental to research activities, Apereo is extending its role in supporting educational, administrative, and research computing through software freedom. Many campuses have opportunities through grant funders and consortia initiatives to adopt and even develop their own free and open source software. Campuses, too, rely on open source software created internally or even developed and deployed by trusted third-party service providers. In response, Apereo offers "OSPO as a Service" and "Foundation as a Service." support models where campuses can access Apereo expertise and services to manage their own internal open source software projects locally or outsource their initiatives to the Apereo Foundation. Despite the long history of the practice, especially in higher education where many free and open source projects began, software freedom is still poorly understood by many outside technology fields (i.e., faculty, researchers, administrators). Apereo is working to foster authentic engagement to realize the maximum benefits of software freedom.

Institutions of higher education have an inherent understanding and an appreciation for software freedom as it aligns with and supports academic freedom. Guiding principles include the open exchange of ideas and the pursuit of knowledge. Both prioritize transparency, collaboration, and the freedom to explore, modify, and share work without undue restrictions. In higher education, academic freedom empowers scholars to research and teach freely, fostering innovation and critical thinking. Similarly, software freedom enables developers to study, adapt, and improve code, driving technological progress and accessibility. Together, these principles create an ecosystem that values intellectual curiosity, shared learning, and the democratization of knowledge. Apereo's vision is for an academy where both flourish and mutual support creates a thriving environment for education and technology to grow together.

SFC: What's got you most excited from the past year of our work?

Patrick: FOSSY, FOSSY, FOSSY!!! While there are several activities SFC undertook this year (and has undertaken for many years, hosting several important projects, Outreachy, license protection, general advocacy etc. etc., etc.), organizing and delivering a software freedom-focused conference was for Apereo (and me personally) a highlight. It is not simply because it provides a forum for peer communities of practice to meet after such a dearth of opportunities (due to COVID, OSCON shutting down, etc.), but because the event so well aligns with Apereo's direction and strategy.

For Apereo, the event is a perfect opportunity to work with the free and open source community--projects, foundations, industry, experts, advocates--to introduce the higher education community--institutions, faculty, researchers, administrators--through shared interests and activities. Rarely do these two groups interact, and Apereo--because of FOSSY and SFC--has another touch point to facilitate greater engagement and productivity; we were thrilled to run the FOSS for Education track and are excited to submit a proposal again for the track in 2025. SFC's work to grow and mature the event is phenomenal and inspiring. I am sure FOSSY will continue to grow in size and impact, and Apereo is dedicated to supporting it as best we can through community and contributions.

SFC: What issues happened this past year that you were happy we spoke about?

Patrick: While the history and activities undertaken by SFC related to AI and LLMs extend back to 2020, the recent announcement, "Aspirational Statement on LLM-backed generative AI for Programming," was uniquely prominent for Apereo and higher education. While there are many issues related to AI, two fundamental concerns among institutions of higher education are bias and reproducibility. AI is taking higher ed by storm--if you attended the recent EDUCAUSE Annual Conference, you know what I am talking about. However, real concerns should be evident considering how and where AI "solutions" are being marketed.

A core tenet of research is reproducibility. Research reproducibility suffers significantly when AI models, particularly LLMs, and the datasets used to train them are closed-source or proprietary; transparency, black box algorithms, independent verification/validation, accessibility/equity, etc., are all issues that may impact research and hinder discovery. The same applies to administrative systems where bias, ethical concerns, and a general lack of accountability can impact student and faculty affairs.

I was also delighted to see SFC's response was "aspirational" and delivered in a tone to help and contribute.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?

Patrick: I think SFC--like other organizations working with shared values and a common vision, like Apereo--is in a tough spot. Despite the 30 years of history, many organizations are either unaware or unengaged with free and open source software. Gone are the early days (2004-2012?) where open source was the hot topic, marketing magic, and investors' and industry's funding choice. While the adoption and dependency on FOSS are greater than ever (especially in higher education), actual support and participation by those who most rely on sustainable communities and the projects they produce are declining (disappearing?).

Reaching a wider audience is a real challenge, considering reaching the current audience- which should already be engaging- is so difficult (and frustrating). I honestly believe organizations will come to appreciate the importance of supporting the FOSS core to their business and operations, especially with growing external pressures (e.g., the Cyber Resiliency Act, Software Bill of Materials) combined with new opportunities (e.g., increased funding from granting organizations). While several new organizations are popping up--which, in my opinion, are simply chasing the latest money and buzz--those like SFC, with years of services, credibility with the community, and authenticity in practice, will emerge as fundamental resources and valuable services for organizations that choose to best leverage FOSS for their benefit and the benefit of others.

SFC: Have you been involved with any of our member projects in the past?

Patrick: While most of my involvement has been as an end-user (e.g., I have several scientific illustrations created in Inkscape and published in medical and dental textbooks and journals), I have been most active with the Teaching Open Source project run by Heidi Ellis and Greg Hislop. Considering the project's focus on using open source software and technologies to teach computer science and other disiplines, it's probably obvious why I am involved.

SFC: How do you see our role amongst the various FLOSS organizations?

Patrick: "Supporting the supporters." I rely on SFC as a resource for Apereo's foundational work, which extends Apereo's capacity and capabilities in service to our constituents in higher education. Examples include policy analysis and advocacy, copyleft compliance, the aforementioned "Statement on LLM-backed generative AI," etc. In this sense, SFC serves a similar role to the OSI, where organizations like Apereo, whose focus is "FOSS outward facing," i.e., connecting with end-users, benefit from SFC's "FOSS inward facing," i.e., connecting with FOSS organizations on broader issues impacting their constituent communities.

SFC: Do you think we do a good job standing up to the organizations with more corporate funding?

Patrick: Times are tough for FOSS foundations, and funding from all sources should be pursued. I think SFC does a good job with corporate sponsorship- everyone knows what SFC is all about, and SFC has stayed true to its mission and is authentic in its practices. I do not feel SFC has compromised its credibility or shied away from issues based on corporate support.

SFC: What other organizations are you supporting this year?

Patrick: I am committed to supporting the FOSS projects and foundations I use (rely on) personally or professionally. I consider this no different than those who pay annually for proprietary software. Both models need funding to develop software, but FOSS is a better deal for the consumer: lower TCO, funds that support development--not profits, the ability to help shape the project (features and functions), etc. It is simply a better/smarter business decision for organizations (and individuals) to pay for FOSS than proprietary software.

[permalink]

Tags: conservancy, fundraiser

Is Tesla open source? Roadster certainly isn't...

by Denver Gingerich on December 21, 2023

There appears to be some debate over whether a certain billionaire said on November 22 that "Tesla Roadster is now fully open source", or maybe that "All design & engineering of the original @Tesla Roadster is now fully open source". In any case, as the people who work every day on whether or not what companies say is FOSS really is FOSS, we reviewed the materials Tesla provided on the Tesla Roadster Service Information page. We found no source code — and last time we reviewed the Open Source Definition, providing source code was mandatory to meet it. But this situation is worse than that. Tesla did include several copies of the Linux kernel in only binary form, with no offer for source whatsoever. That's a GPL violation. We immediately emailed Tesla to ask them where the source code was but (now 3 weeks later) we have still heard nothing back.

Tesla's violation is not surprising, given their past behavior. We've written before about Tesla's prior inabilities to provide complete source code. But now Tesla has completely backslid from incomplete source code all the way to "no source or offer". Instead of learning from its past mistakes, Tesla has increased its erratic behavior to make even more mistakes of the same type.

Now you may wonder why we care about a company that is decidedly not open source, and about code that is relatively old at this point. Well, we believe that people should have the right and ability to repair their software, no matter how old, and that this applies to everything that contains software, including TVs, wireless routers, and (in this case) cars.

The need for being able to repair here is not hypothetical. The dangers of Tesla drivers' inability to fix the software in their cars is palpable. After discussing safety concerns in the software on its cars with the NHTSA, Tesla recently did a voluntary recall on all cars it has produced in the past 10 years. This recall is *due to faulty software*, which was only discovered to be faulty after many drivers died. Neither NHTSA nor the public has the right to review Tesla's actual software for safety. If Tesla at least complied with the GPL, regulatory bodies and the public could review those portions for safety. (Of course, we think Tesla should be required to make the source for even those parts of the software not governed by GPL available to the public for security audits and review.)

Tesla has taken a strong and disturbing position: they'd rather keep their source code secret than increase safety for software in cars. Furthermore, rather than letting car owners fix their cars, they were forced to wait for Tesla to both agree that there was a problem, and then work on Tesla's own schedule to release a fix for the problem. If owners had the source code, the owners (and the press, who uncovered the systematic problems in this case) could more quickly identify that there was a problem to begin with, and then implement a fix right away, instead of waiting for Tesla to decide they wanted to do something about it.

By refusing to comply with the GPL agreements, Tesla is not only violating licenses - it is making its cars more dangerous, and removing the ability of owners to fix problems when they arise. This cannot continue, and we again call on Tesla today to give all its customers the complete source code for all copylefted software Tesla has distributed to them. This is common sense, and is merely what the agreements require.

Of course, we're just as concerned as anyone that owners might make software modifications to their car that decrease safety. We support certification requirements for any software that is installed to drive on the road. Just as it is completely legal for a consumer to build their own car from parts, and be subject to safety inspection before driving it on public roads, so too should that apply to software. Tesla, sadly, continues to maintain the fiction that they know better than everyone what's safe for software in cars to do — even after it's been shown that Tesla's software is killing people. As a for-profit automaker, in this regard Tesla is actually held to a lower burden than a hobbyist who built their own car.

We hope you will stand with us in calling on all companies to follow the terms of the copyleft agreements they are bound by. Violating the GPL and using proprietary software is not, as Tesla claims, the only way to keep drivers safe, instead it's downright dangerous.

[permalink]

Tags: conservancy

A Note from Our Executive Director: 2023 and my personal quest for software freedom

by Karen Sandler on December 19, 2023

Just when I think that I've really grokked the implications of the technology I have woven into my life, I find that life throws completely new challenges my way that make me realize the extent of the work that we have ahead of us for software freedom.

Front of hospital in Brussels CC-BY-SA 4.0 Karen Sandler

Early this year, in February, as I readied myself for the excitement of receiving an honorary doctorate at KU Leuven, I felt my heart beating strangely. An already scheduled visit to the cardiologist revealed that my inherited heart condition had caused an irregular rhythm. I struggled to walk up even shallow inclines.

I have a heart condition I was born with, called Hypertrophic Cardiomyopathy (HCM). It's a condition that generally causes me no discernible symptoms, but I am at much higher risk of what they call "sudden death" than people without this condition (sudden death is what they call it when your heart ceases its function, for HCM patients, it's often because your heart is beating so fast that it's just fluttering instead of efficiently pumping). This is why I've had, for many years, an implanted pacemaker/defibrillator.

Irregular heart rhythms are common for HCM patients over time but need to be either reverted or treated with medication to live a normal life. The longer one is in an irregular rhythm, the more likely that irregular rhythm will stay and be non-revertable. Facing these new symptoms in early in the year, I needed to determine what I needed to do and whether my travel was still safe. To figure out how best to proceed, my electrophysiologist wanted to know about the history of my irregular rhythms. Luckily, I have my implanted pacemaker/defibrillator — designed to record that important information. Ostensibly, this is one of the purposes of having an implanted medical device: to collect such data to inform my treatment.

Years before, I'd decided to have this device implanted with the greatest of trepidation. Many of the key and important features of this device are implemented in software, not hardware. This is my second device (the previous one eventually had battery failure), So, twice, I've had to decide to make an unfair moral choice: do I maximize my chance of surviving with my heart condition, or do I allow installation of proprietary software in my body?

After I decided to have the device installed, I made serious efforts to actually verify the safety and efficacy of the software in the device myself. I filed Freedom of Information Act (FOIA) requests to review the FDA's approval process of this device. What I discovered horrified me: no one — not the FDA, not the patients, not the doctors, not the public — has ever reviewed the source code of the device, or even done direct testing of the software itself. Only the manufacturer does this, and the FDA reviews their reports.

This is a problem that will take a lifetime of many activists working for patient's rights to solve. In the meantime, I had to make the difficult moral choice whether to allow the device in my body, and ultimately I did - it was simply too dangerous to go without (doctors estimated a 25% chance of suddenly dying before I reached the age of 40). I tried to reduced the harm by choosing a device manufacturer that allowed the radio telemetry to be disabled for security reasons. This was a huge benefit, but ultimately it meant I picked a device made by a company that has a large presence in Europe, but a very small one in the United States. Little did I know that this choice would lead me to another difficult decision, which would again only be difficult because the software in the device is proprietary.

In February 2023, while I scrambled to have data in my device extracted before my trip, I discovered that due to the proprietary nature of the device, no one but a company representative could help me. The only one who worked In my city (a major city!) had gone on vacation to visit family overseas. The company had no other representatives available to help me. After much calling to different numbers of the company, I was able to get a list of hospitals and offices across the city that might have had a machine (oddly, they call them “programmers”) that could interface with (or “interrogate”) my device. Upon calling those locations, only a few actually had the programmers and none of those were able to give me an appointment before I left for Europe.

The helplessness that I felt was a powerful echo of how I felt years ago when I realized that my defibrillator was shocking me unnecessarily when I was pregnant. The only way to stop it was to take (otherwise unnecessary) medication to slow my heart rate down. Proprietary software, installed in my body, led me to no choice but to accept medical treatment that I didn't even need.

This time, even though I live in a major city, just one employee's vacation schedule meant my doctors could not diagnosis my urgent health problem. These heart devices are all locked down. Equipment between companies and also among newer models are *not* interoperable. I and my doctors could not access the critical information in my own body when I needed it most.

Ultimately, I made the difficult and potentially dangerous decision to go to KU Leuven anyway to receive the honorary doctorate. It was an incredible honor and I would have missed a once-in-a-lifetime opportunity. Outraged and frustrated again that I was forced to make a life-or-death decision that would have been much easier to evaluate were it not for proprietary software being the only option for heart devices, I nevertheless went.

Thanks to a fellow software freedom activist who helped me navigate the Belgian medical system, I was able to get my device interrogated there. I confirmed there was not immediate danger, and I used that information to come up with a plan for the rest of my trip and for my healthcare in the coming months. While the trip was a wonderful experience, I'm haunted by that helplessness that comes from having no control over technology I rely on so deeply.

When I returned my cardiologist insisted that I get a wearable device to monitor my heart rate. Knowing my feelings about proprietary software (from all of the times I advocated for software freedom in the doctors office!), he told me “you're not going to like the recommendation I have”: the doctor suggested I get an Apple Watch. As soon as I got home I researched all of the alternatives. I found an FDA approved device that has reliable heart rate monitoring but does not require constant contact with a proprietary mobile device or continuous connection to a centralized, proprietary service. The device is unfortunately proprietary itself, but fortunately has no GPS or other similar tracking, and doesn't mandate additional use of third-party proprietary software. This was still a painful compromise for me. I wish every day that I had access to its source code and the ability to modify its software to better suit my unique heart-monitoring needs. But this is my life and my health, and I'm grateful that I found a solution that I can use while I wait for (and advocate for and support) free solutions to catch up so I can use them instead.

Karen finally getting her device "interrogated" in Brussels. Note the various "programmers" in the background for each different manufacturer's devices. CC-BY-SA 4.0 Bert Van de Poel

Happily, since that happened, surgery has returned my heart to a normal heart rhythm, but my cardiologists have said that my need for the tracking device remains. I hate that I've had to incorporate more proprietary software into my life, but I'm so grateful for the treatment I receive and the years of life I am hopefully gaining.

The ways we rely on our software are not theoretical. They pervade every aspect of our lives, and we must make our decisions carefully — knowing that there will be immediate and long term consequences of those choices.

We should stand strongly for our principles but we must also live. At Software Freedom Conservancy we have the philosophy that it's not enough to just talk about our values, it's all about actually doing work that will move the needle towards achieving software freedom for everyone.

There is at least one, and perhaps a few, rather famous FOSS activists who are fond of declaring that they live their life without using any proprietary software. I am in awe of the luck that their privilege affords them. I had to make a really tough choice: put myself at risk of an untimely death, or put proprietary software in my body. I chose to live — and continue my work advocating against proprietary software.

This year, at SFC, we focused on our partnerships with right to repair organizations to ensure that the software right to repair (which could have helped me to get the information off of my proprietary device) is an important part of the previously hardware-focused conversations. We raised the alarm about John Deere's GPL violations after years of work on the matter. We stayed in regular contact with other organizations to support them and we worked on concrete action items, like the amicus brief we recently co-signed.

Waffles for sale in a Belgian hospital CC-BY-SA 4.0 Karen Sandler

We stood up for the consumer and user rights that are baked into the GPLs and continued to push forward our lawsuit against Vizio — to make sure that everyone must be taken seriously when they ask for source code they are entitled to by the GPLs.

We know that users face real difficulty and often feel like they have few choices. We don't blame anyone who uses proprietary software; instead, we empathize with you because we live in the real world too and face difficult choices. We have campaigns such as Exit Zoom and Give Up GitHub to help you find alternatives to the proprietary software that you're using every day that you'd rather liberate yourselves from.

I do hope that (after you donate to SFC, of course!) each of you will do something to help improve the state of software freedom for yourself or someone you know, even if the solutions aren't 100% perfect, because they make a real difference in people's lives and demonstrate that we can do things differently. Help someone flash their phone with a free build, even though it has some proprietary components to remain functional (keeping it out of the landfill). Introduce someone to a free software app. Put Debian (or another free distro) on some old equipment to give it new life, even though it may remain a secondary device. Start collaborating with someone using a pad instead of centralized cloud services. I for one am looking forward to rooting a robot vacuum this holiday season to be able to control it with a free app that removes the need for centralized connectivity in order to operate at all. Maybe you'll do the same with a garage door opener? Sky's the limit when we work on it together. Let's keep it going bit by bit until all of our software is free.

Happy holidays.

[permalink]

Tags: conservancy

Sourceware thanks Conservancy for their support and urges the community to support Conservancy

by Sourceware PLC on November 27, 2023

Sourceware is maintained by volunteers, but hardware, bandwidth and servers are provided by sponsors. It is our goal to offer a worry-free, friendly home for Free Software projects. Because Free Software needs Free Infrastructure.

We have only been a Conservancy member project for 6 months, but we started the search for a fiscal sponsor about two years ago. Although we probably didn't really know or understand why we needed one at first or the services they provide.

Sourceware has been a Free Software hosting platform since 1998. As a developer platform for developers getting consensus on technical roadmaps has always been easy. But the discussion on governance took some time. In particular how much influence corporations should get was at times contentious. Sourceware may be volunteer managed, but wouldn't be possible without the hardware, network resources and services provided by some corporate sponsors. The Sourceware community values their independence and the strong community which it manages.

After nine months of discussion we finally settled on joining the Software Freedom Conservancy with a Project Leadership Committee of eight members (Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni). Our Fiscal Sponsorship Agreement with the Conservancy states that there cannot be a majority of people affiliated with the same organization (max two members can be employed by the same entity at once). The agreement also states that for projects Sourceware hosts everything will be distributed solely as Free Software and that we will publish all services as Free Software. There is also a conflict of interest policy for the PLC.

Joining the Software Freedom Conservancy as a member project made Sourceware more structured. We have monthly Open Office hours now to learn from the community about any infrastructure issues and then the Sourceware Project Leadership Committee meets to discuss these, set priorities and decide how to spend any funds and/or negotiate with hardware and service partners together with the Software Freedom Conservancy staff.

Projects hosted by Sourceware are part of the core toolchain for GNU/Linux distros, embedded systems, the cloud and, through Cygwin, Windows. Years ago Ken Thompson laid out the roadmap for attacking an operating system via the compiler and other code generation tools. These days these are known as supply chain attacks. The Free Software community should reasonably insist that they be defended against these kinds of attacks with mechanisms for prevention, detection and restoration. We have been encouraging hosted project to write up a security policy which we support with technical infrastructure. Sourceware now offers different ways to attest a patch or email is valid. Using the Sourceware public-inbox instance you can use b4 for patch attestation using dkim, gpg-signed emails or patatt. Projects concerned with source code integrity now have various options to use signed git commits, signed git pushes, or use gitsigur for protecting git repo integrity. And new services, like our snapshots server https://snapshots.sourceware.org/ are run in containers, on separate VMs or servers (thanks to our hardware partners). Sourceware also leverages Conservancy's advisory role in how community projects are impacted by and can comply with recent regulations like the USA Cyber Security Directives and the EU Cyber Resilience Act.

Conservancy staff has been attending conferences to discuss with the Sourceware community, first virtual, then in person. Without having a formal fundraising program we already collected more than $6000 in just 6 months for Sourceware. We got even more support from hardware partners, who provided us with extra servers for our buildbot and to setup new services. We wrote up a Roadmap looking backwards to the last 25 years and looking forwards to the next 25 years. All this resulted in more volunteers showing up helping out.

Having been part of Conservancy for just 6 months has given the community and volunteers running the Sourceware infrastructure confidence in the future. We hope the community will support the Software Freedom Conservancy 2023 Fundraiser and become a Conservancy Sustainer so Conservancy can support more Software Freedom communities like Sourceware.

[permalink]

Tags: conservancy, sourceware, fundraiser