Introducing the Swift Fundraising Cooperative

Community Showcase
1

Hi Swifties!

Recently, there has been growing interest in a centralized Fundraising Organization to support projects that benefit the Swift Ecosystem, and I am thrilled to announce the launch of the Swift Fundraising Cooperative (SFC), an organization explicitly dedicated to securing commitments from Ecosystem Stakeholders, and allocating it towards work on areas of the Swift Ecosystem not adequately supported by existing sponsors today.

Why a Fundraising Cooperative?

In the nine years since the launch of the Swift Project, the language has grown significantly beyond Apple and its platforms, and there are many components and technologies people rely on today that cater to unique use cases and suffer from a lack of Serious Financial Investment. Such components might include:

  • Features with niche constituencies, but don’t fit into a ‘Big Vision’ currently being spearheaded by the Core Team.
  • Middle Ring Infrastructure that is not Universally Foundational but also not specific enough to a single company’s business for them to justify developing internally from scratch.
  • Written Documentation that synthesizes technologies that cut across the individual Areas of Responsibility of existing teams of paid contributors.

Today, there is broad recognition that the existing unpaid, volunteer-driven contribution model for this infrastructure is woefully insufficient to meet the needs of the Swift Community.

  • Volunteers without financial support frequently release a version 1.0 of a library, and then abandon the project for lack of funding.
  • High quality third-party-backed libraries are often tailored specifically to that company’s needs, which makes them less useful to others.
  • Self-managed fundraising, e.g. through GitHub Sponsors, is exceptionally challenging as an individual, and requires a lot of planning, coordination, follow-up, and marketing diligence that subtracts from time that can actually be spent on development.
  • Unpaid volunteers are highly vulnerable to Social Manipulation, or even Outright Bribery, which weakens the security of the Swift Ecosystem.

What do we Hope to Achieve?

Prior to the launch of the SFC, we identified a handful of concrete axes, which we think pose excellent opportunities for investment.

  • Platform support. We believe that platforms — such as Android, WebAssembly, Windows, or even “Server” — constitute a natural stakeholder boundary, which defines a set of potential Sponsors who would benefit from a particular investment.
  • Industries. We believe that certain technological stacks — such as 3D Animation, Game Development, or Algorithmic Trading — form natural constituencies that would benefit from coordinated investment.
  • Training. We believe that the lack of decent-quality cross-domain Documentation is severely hindering the adoption of Swift within large organizations, and that coordinated investment would enable the creation of training materials that synthesize topics that can’t be covered by existing paid teams who can only document the single technology they are working on.

The overarching goal of the SFC is to establish a stable and long-lived counterparty for potential Sponsors to engage with, regardless of their particular areas of interest, and to work with them to allocate resources to the solutions they need. Put another way, when no existing organizations are paying attention to a Problem You Have, us folks at the Swift Fundraising Cooperative are the People To Call.

What Benefits Do Sponsors Receive?

Our ultimate goal is to upstream all of our work to Open Source Swift, for the benefit of the entire community. That said, we understand that Open Source development has historically suffered from the widespread Free-rider Problem, and therefore we expect that certain contributions, particularly platform-specific investments, will be made available under a delayed-licensing model in order to incentivize First Mover investments. However, it is our utmost hope that potential Sponsors will be willing to share the work they have funded immediately to the Community, without delay.

Who is Part of the SFC?

The SFC will have three Founding Members, who will serve as Fundraising Chairs.

Fundraising Chairs are responsible for discussing needs with potential Sponsors, matching them with Implementers, and helping manage the work being funded in order to provide some measure of confidence in Open Source Swift investments.

Fundraising Chairs will additionally function as Reliable Intermediaries, who will respond to messages in a timely fashion and forward it to a desired recipient, if possible. We encourage everyone to participate in the all-important goal of funding investments in the Swift Ecosystem, regardless of membership.

How Can I Get Involved?

We want everyone to get involved with the SFC, even if you are unable to make a direct financial commitment of your own. Do you know somebody who may be able to fund work of interest to you? Do you yourself have expertise that might make you an attractive recipient for a grant? Or do you even just want to talk about the future direction of the Swift Ecosystem? Please don’t hesitate to reach out! The mission of the SFC is to function as an active, responsive counterparty to field these types of queries.

48 Likes
2

Congrats! I can’t wait to see what you can accomplish.

You mention that there are four founding members, but list three. Typo or more to come?

2 Likes
3

oops, that was a typo! thanks

4

There was a fourth founding member who had to drop out because he got too busy with work. Maybe he will join us again later. :grinning_cat:

4 Likes
5

I would be willing to put a good amount of money towards two specific goals because I do not have time to implement it myself (nor the expertise). If I saw someone taking on the project, I would immediately start sponsoring it.

  1. MOST IMPORTANT: Objective-C interop (gnustep/libobjc2) on non-Apple platforms (I know the community generally does not want to see this, but I actually need it).
  2. LEAST IMPORTANT (FOR NOW): Modern Swift on FreeBSD, OpenBSD, NetBSD (PPC, Intel, ARM)
7 Likes
6

No idea on the first one, but good news on the OpenBSD front, as @3405691582 just got some long-delayed OpenBSD pulls in. :grinning_face:

@3405691582, any plans to put together an openports package finally, like Rust has now?

2 Likes
7

Yes.

There are still some rather stubborn bugs to work out, but I'm making slow progress.

3 Likes
8

I have a feeling it is going to be hard to fulfill my first one. But if anyone is willing to take a crack at it and set up even just a GitHub sponsorship, let me know!

I think it would be an excellent open source project that would allow us to easily use GNUStep project (and build our Obj-C projects on Linux). I stated working on a sort of bridge for it, but I had no idea how to take care of the objects crossing Swift->ObjC boundaries (and back) and keeping reference counting right and not allocating a lot of wrappers -- which lead me to conclude that we really just need the support built into the gnustep/libobjc2 version of the runtime.

If anyone has any thoughts lmk.

9

I would like to see Swift on NetBSD. I may be able to provide some
material support, too.

David

1 Like
10

This sounds really cool. Kudos for the effort!

What are your next steps, and where can one find out more, esp. about how to participate in the cooperative, and whether there'll be any legal implications (like the cooperative pooling resources, but also ownership of code bases like a real-world cooperative for physical assets/capital might)?

2 Likes
11

How can we apply for funding? Or pitch ideas? I would love to help create a full Swift Firebase Studio alternative instead of the many fragmented tools and projects we currently have. We can holistically align and support the many good OSS initiatives but have a hosted Postgres (like Supabase) + swift edge functions (vapor / hummingbird) as a service, + AI with deep context (like Cursor or AlexCodes etc.) + swift multi platform UI. The sum of the parts becomes 10x. I don't know if we fork Supabase or work with them. Generated revenue should go back to this fund, so by using the hosted service the user is also supporting future swift development.

Imagine having the AI trained on all these things, so with a few prompts we get a fully deployed backend and clients along apple, android, windows, linux, wasm, IoT, all in Swift. I would think this would radically transform software development and drastically increase swift's adoption and influence.

SwiftBase = Storage + edge functions + auth + push + multi-platform + AI

And of course eventually SwiftBase should run on... SwiftOS!

Thoughts?

1 Like
12

Thanks, we hope it produces results. :smiley:

Right now, we're just an intermediary with no infrastructure of our own. We discussed various different possibilities, but initially Diana and Tyler felt most comfortable simply helping interested companies find open-source devs they want to sponsor/contract.

Therefore, the only way to participate right now is by helping either side of that, whether by telling us publicly or privately, either by presenting ideas that you think need to be worked on by available open-source devs with those skills or by bringing companies that want to fund those ideas.

Depending on how well that goes, we'll look at other approaches, like crowdfunding or whatever.

I asked Diana last week to answer this question since she chose the name, but she appears to be busy. I highly doubt we will ever apply such legal tactics, ie it is only a cooperative in an informal sense.

You message us, whether publicly or privately, as you're doing here. :wink:

I've never heard of Supabase, but this seems like a massive effort more suited to an investor or large crowd-funding campaign than our efforts to match companies with individual open-source devs on smaller projects.

We're not aiming to start such large projects right now, but if some company wants to fund such an effort, we're happy to facilitate in whatever way we can.

4 Likes
13

ideally, all work funded through the Cooperative would be immediately released to the public under a permissive license such as Apache 2.0. however, we expect that in rare cases, entities funding work may want to adopt a delayed licensing model in order to avoid fronting the cost for work that everyone else would be able to immediately access for free. we don’t have a hard policy for this yet, i feel that a maximum duration of 12 months “exclusivity” would likely be where we draw the line.

facilitating arrangements where source code would never be released under a free license are out-of-scope for the Cooperative.

3 Likes
14

I see! thanks for these details. Wish the swift community could come together on bigger ambitious projects like these, but I totally understand limited resources and risk assessment favors smaller tasks and immediate needs.

A few notes just to add,

All of Supabase is already open source, so much of the heavy lifting is done for us, we just need to improve the server swift component and fine tune a open LLM model on that stack to create a Lovable / bolt.new experience for swift full stack applications. I think this would be big to promote swift in mainstream mindshare and platforms outside apple.

I understand this is a big task, which is why I'm also approaching venture capital as well as others in the swift community. If there's anyone you know who you think might be interested I'd love to be connected.

And SwiftOS I recognize is a moonshot, just seeing how it develops and who might know the right people to move it forward.

15

Apportable ported the Apple runtime to Android some years ago, I looked at porting this to Linux, it was a bit tricky because you really need notifications from the dynamic linker whenever a shared object is loaded to register the ObjC metadata. Might be worth looking into again though and would certainly avoid as many changes to Swift (at the expense potentially of requiring more changes to GNUstep).

16

I (on behalf of flowkey) offered financial support for maintaining Swift‘s Android support some time ago on these forums and didn’t find any resonance at the time – maybe I formulated the pitch badly.

In any case, that offer still stands.

3 Likes
17

I’m sure @Finagolfin would be interested.

OT Flowkey looks great.

18

I went back and looked at that 2021 offer now: you wanted some bugs fixed for armv7 or older Android and the community Android CI kept green. I responded there at the time that Daniel was keeping the Android CI green and that I didn't know who could fix such legacy Android bugs, but that I'd be happy to coordinate more with you and the community on the Android port. I never heard from you or anyone else on the matter again.

If you'd like to sponsor our renewed work on the Android port now, feel free to lay out what you'd like to see done, either publicly in one of the forum threads here or by privately messaging one of the community Android workgroup members. We're always looking for direction from long-time Android users like Flowkey, which is why I pinged you in that Android workgroup thread a couple months ago, but didn't get a response.

1 Like
19

FWIW: If someone wants to hand me a bucket of money to turn Elementary into a batteries-included web framework for running Swift apps in the browser, I'd probably find the time. ; )

20

I had no idea that Apple's objc runtime was completely open sourced. With that said, I would love to see it ported to FreeBSD/*BSD and Linux. At the minimum, I searched through the source code for "swift" just to see what I'd find, and it seems like a lot of that could be implemented on gnustep's runtime. Thanks for the pointer.

I have no idea what amount of money would motivate someone to make this happen, I know the talent is all there, but I am willing to find out if it is possible on both ends. Of course Swift would then need to be forked to support working with objc on other platforms so this is a huge undertaking and since the community generally (I gathered) did not want to see that as a part of Swift, so I think it would have to be maintained as a separate fork -- which is also problematic for longevity.

Ultimately, I just want to build some (large) apps against GNUSteps frameworks.

I have also considered rewriting a version of AppKit and UIKit in Swift for Linux (that's a LOT) , but it is just a pity that a lot of that work has already been done in GNUStep. I would love to just continue on with the work they did.

Thank you for the tip! If you (or anyone) is interested in getting some funding to do this let me know, I would love to contribute.