Possibility of organizing a “fundraising” committee for Open Source Swift?

Evolution Discussion
1

i was originally going to post this as a reply to @xwu ’s reply over at Extension methods for non-nominal types - #36 by xwu , but halfway through i realized it’s a distinct enough topic to merit its own thread:

throughout the history of Swift Evolution we’ve tended to push people towards Option #1, with Option #2 a distant second (e.g. GSoC). we haven’t really done a lot with the other two Options, which kind of leaves us in a situation where Apple funds the vast majority of Swift compiler and “fundamental” library development (e.g. SwiftNIO), and unpaid volunteers fill in the gaps in their free time where they can.

this has some benefits to the language and its ecosystem:

  • the very core components of the Swift toolchain are well-maintained, as Apple pays people directly to do this.
  • language features that are central to the ‘big visions’ being spearheaded by Apple (e.g., Concurrency, ~Copyable, etc.) are well-supported, as Apple pays people directly to work on them.
  • libraries that do very specific tasks that are central to a particular company’s business are well supported, as the third party invests in the library for their own use, and occasionally the companies decide to open-source the libraries.

but it also has some weaknesses:

  • features that have niche constituencies but don’t fit into a ‘big vision’ fall by the wayside.
  • “middle ring” infrastructure - the kind of stuff that is not Foundational but also not specific enough to a single company’s business for them to justify fronting the entire cost themselves is neglected, so this work falls to unpaid volunteers.
  • these volunteers have little financial support so there is a frequent pattern of volunteers releasing a version 1.0 of a library and then abandoning 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.

today, we leave it to the individual volunteers to manage their own fundraising, e.g. through GitHub Sponsors. but Fundraising is Hard, especially as an individual, and isn’t really something that can be done as an afterthought - it requires a lot of planning, coordination, follow-up, and marketing skills, and a lot of it is about leveraging connections built up over time, and cultivating these relationships continuously.

which leads me to wonder if there is a space for an official “Fundraising Committee” to fill, which would

  • enshrine raising funding from non-Apple sources as an official Community Goal,
  • establish a stable and long-lived counterparty for sponsors to engage with, and
  • coordinate ways to incentivize financial contributions to Swift, for example, by “badging” donors, displaying their logo on Swift.org, or connecting them with advertising space on community websites such as Swiftinit or Swift Package Index.
37 Likes
2

This is desperately needed in today's day and age of software. Unpaid active contributors and projects innovating, maintaining code and helping solve problems that benefit everyone, especially in open source, should be rewarded and acknowledged.

It is a no-brainer that the benefits outweigh the drawbacks. Swift is perfect for this type of investment, all things considered.In my opinion

3 Likes
3

I was using Tuist recently, and I noticed that they use a bounty platform for such things.

I wonder if that could be an option here. I can't really estimate how much it would cost to sponsor somebody for the issue that you mentioned - but depending on the feature, I think it's realistic that you could find 5 small companies willing to contribute $2K each (or a mix of companies and some individuals). Bounties are easier to sign-off on because it's a one-time payment only if the work is done, and a $10K bounty might be enough for some smaller compiler features.

For example, if there were a bounty to add enum case-paths to the language, I think you could find a handful of companies interested in putting some funds towards that. The kind of companies who maybe can’t go out and hire full-time compiler engineers, but are also not opposed to investing in their engineering infrastructure.

It might be worth looking in to other communities that have adopted similar platforms and what the effects have been.

I don't think it would be against the forum rules if you wanted to look for contributors to the pot, or if you were to advertise the bounty here looking for developers to claim it. Perhaps mods can confirm?

13 Likes
4

I believe something like this is sorely needed for the Swift ecosystem (or any OSS ecosystem, for that matter) to succeed in the long run. It can't be, as security challenges mount, that we all rely on the efforts of a few skilled volunteers and, let's be honest, a large dose of luck for stuff to work.

One thing I'd love to see being sponsored in particular is simply maintenance. Of course, every bit helps, but speccing out features and then tracking and delivering them can be quite tedious. Moreover, it leads to seeing valuable work through the lens of features alone/mainly when often all mature packages need is hands on deck/eyes on issues. You can't start a funding process to fix a CVE.

In a recent podcast episode we spoke about Filippo Valsorda's interesting Geomys project. I wonder if something like this could also work for the Swift ecosystem.

4 Likes
5

Good idea, along the lines of what I previously broached for a platform workgroup to do. There are many ways this can be set up, the most common for large OSS projects these days is to set up a non-profit foundation to act as that counterparty: the Zig foundation claims to have raised half a million dollars last year and there are many others.

I don't think Swift needs a foundation quite yet, and there are many lighter-weight ways to start off, like the Open Collective option I mentioned a couple years ago or one of the many bug bounty websites that seem to be out there.

I think all we need is for some trusted members of the community to set something up, and I'm sure I and others would be happy to contribute both money and code.

5 Likes
6

Different take: remove the $100 fee for the developer program. This is way easier to implement than any funding/scholarship/award. And it benefits more people.

They are already taking a sizable cut of the app revenue. There are other stores that do not require any payment, and Apple is the words richest company (or at least in the top 5).

At the same time, rdars and issues are ignored, and every time you ask for some fix on this forum, it will be marked as "off-topic". Then it's gets "liked" by other Apple employees (and ex-employees). Another Apple response is: "use the search function" (a good old RTFM). This means reading 30 threads from the last 10 years (~10h). Instead they could just quickly summarize the discussion or add an entry in the FAQ. And very often you get a silent treatment where nobody responds.

During WWDC Tim Cook boast how Apple is making coding more accessible to everyone. Nothing speaks “we want to empower people to learn to code” as much as a $100 fee. This can be a substantial amount of money in certain regions, or for some people.

As for your idea: :dollar: is a problem; it makes everything much more complicated:

  • External contributors are not reliable. Unless it is done under a contract, which becomes an entirely different relationship.
  • Sponsor changes their mind, in which case the worker just wasted a lot of their time without getting paid. This happened on this from multiple times: Apple started the topic, the community devoted time, and then Apple abandoned the whole thing. Money was not exchanged, but time is still a resource. Same with PR to swift projects by non-Apple developers, they get ignored even if they only add test cases.
  • Sponsor will probably need to devote some resources to the project. Either to help the volunteer or to steer the direction. This becomes waste if nothing gets delivered. It is much more economically feasible to just employ the person.

My experience tells me that anything “yet to be delivered” has to happen under a written contract to protect BOTH sides.

As for projects that already exist:

  • Wordpress drama - imagine being connected to something like that. Even on a smaller scale (for example: projects violates patent or "steals" code) this can do more harm than good. I actually saw a PR where someone tried to contribute MY code to one of the Apple open source projects. The PR was ignored anyway with no comment from Apple.
  • Open source projects can be quite unstable. Look at ffmpeg, they had a few splits where some people left the project. What happens then? Sponsors have to pick a side.

At the same time, Apple does not need to grow the Swift ecosystem. They have enough person-power to re-write everything by themselves, it happened a few times already. They even do this with the whole apps (sherlocking). And just like any other big company, they recognize that using 3rd party packages is a security risk. They do not even use swiftlint, at least it is not their standard tool.

Btw. Apple does the (free?) training camps. This is not the kind of community contribution you mentioned, but it is something. The participants sign contracts for protection, but those are training opportunities, not an employment contracts. It is a good PR (Tim Cook mentions it often during WWDC) for a very small price.

TLDR; They can throw :dollar: to get a good PR, but realistically this is nothing. At the same time, removing the $100 developer program fee would help more people.

2 Likes
7

Btw. Swift Package Index is not owned by Apple but it is sponsored by them ("Corporate Supporters"), so there is already a precedent to the @taylorswift idea.

1 Like
8

You raise some good points about the problems with this idea, which I'm sure many of us have observed with OSS projects in the past, ie you'd probably want some kind of standardized, lightweight contracts drawn up for all OSS contributors who get paid, to protect both sides to the transaction. However, many of these are managerial issues that affect all projects, from those closed-source inside companies to the other end of the OSS spectrum.

And all your Apple-specific complaints are beside the point, as the OP is about "raising funding from non-Apple sources as an official Community Goal." Apple employees and funding may or may not choose to get involved, but their involvement is irrelevant to this effort.

6 Likes
9

We’d definitely consider bounty/sponsorship for certain issues.

4 Likes
10

It might make sense to differentiate between work on the language itself (maybe including Foundation) and supporting useful Swift packages. The committee style might work well for the first, while for the second interest groups and direct support might be more appropriate.

11

I have a hard time with the idea of "fundraising" to support development of a language that was made primarily to benefit Apple (to broaden the app developer base and make apps less buggy for its iPhone users), an incredibly profitable corporation.

What I'd love to see is Apple directly fund engineers to work on the parts of Swift that are less exciting but more critical to your every day app developers. Broadly, general app developers weren't asking for advanced features like non-copyable and move-only types, but rather to finally address the littler things like enums with associated case comparisons or protocol extension overrides.

And it seems these quality-of-life low-hanging fruit type things are only ever fixed by the community and not Apple after years of suffering through them (e.g. Allow Protocols to be Nested in Non-Generic Contexts).

1 Like
12

although i expect that everyone eventually involved in this effort will have slightly different focus areas, i personally would like to see more funding channeled towards the infrastructure and libraries for server-side use cases, and Swift on Linux more generally.

these are areas that Apple does not invest nearly as much as is needed for the ecosystem to keep pace with competitors like Rust and Go, and these are also areas that are distant from Apple’s core businesses, so in my mind it makes a lot of sense to raise funding from alternative sources.

7 Likes
13

Inline with @taylorswift we would also consider sponsoring Linux specific support work - e g. Issues like these:

3 Likes
14

Happy New Year everyone! I’m the creator of Algora, the open source bounties platform used by Tuist - thanks for the mention Karl! Algora has helped award $335k+ to 559 developers from 68 countries, using open source bounties and tips on GitHub. It’s used by major (commercial) open source projects and even one of the GitHub cofounders awarded a bounty with Algora!

I spent the holidays preparing a new platform after following closely the conversation in this thread. This is the POC for your feedback: swift.algora.io

swift.algora.io
swift.algora.io1500×787 177 KB

In a nutshell, you can create bounties and tip developers across Swift repositories on GitHub by commenting the following commands on issues and pull requests - give it a try!

  • Bounty command: /bounty $1000
  • Tip command: /tip $500 @username

Bounties are paid after pull requests are merged, while tips are paid instantly. Both use Stripe for payments, with invoices coming from Algora. Contributors & maintainers receive payments within a few days.

Bounties, tips, sponsors and community members will be displayed on the page above.

Next week I’ll release the contracts feature, it’s like bounties with prepayments. I think these are ideal for maintainer sponsorship and more complex work. I’m also open sourcing the entire platform (built in Elixir) later this month, you’ll find the repo link on the page.

I am eager for your feedback to iterate on the solution and hopefully arrive at something that benefits the community, cheers!

20 Likes