So it's been how long since we made the announcement?
A bit over a week, right?
And the response has been extremely positive.
From what I've seen, I think people are delighted to see that,
first of all, the package index is on a steadier footing when it comes to being around for the long term,
but also that Apple are supporting this project, along with a whole load of other companies.
And I think that's worth just talking about for a second.
They were keen to join that set of sponsors rather than replace them.
them. So our GitHub sponsorship is still really important to us, the sponsorship
of Stream and Emerge tools is really important to us, and of course the
infrastructure sponsorship of Microsoft and Mac Stadium remains completely
integral to how we keep this project running. What we've done is expanded the
amount of companies that are supporting the project rather than replaced
everybody with Apple. Yeah absolutely, feedback has been really great, just
great to have that in place and take some of our concerns away.
When we were planning out the project, we sort of had some early timelines
where we thought, how long can we run this given what support we had at the
time, and it's really a great relief to have this additional support by Apple
to give us that long-term trajectory and giving us the assurance that we can
keep running this site and also growing it.
And that's actually probably something we should also mention.
The site growth just over the last week has been tremendous.
The influx of unique users on the day alone was a record, but also since then,
the levels of unique visitors and page views has been a lot higher than previously.
And that's just really great to see.
And package submissions as well.
Oh yes.
We've woken up lots of people who were sitting on their packages, probably just
waiting to see if we're going to be around or what's the status of that project.
And then they all clicked on that button, just submit their packages.
And it's been absolutely wild.
But seriously, though, I say this to everybody who, whenever I talk about
marketing, you cannot talk about your project enough, like you may get sick
of hearing yourself talk about it, but, but it's impossible to, you know, I
would say that we were running a fairly successful project already, and yet the
number of people who had no idea it existed.
We were both on a Slack where somebody was talking about the announcement and
we were on that thread in the Slack.
And I think there were a couple of people in that thread who didn't know about
packageindex.com before, before this announcement.
Inconceivable.
And also they actually only saw the announcement through that thread in the
Slack, like you can't talk about it enough.
Yeah.
You can't talk about it enough.
Even an official post on swift.org is only part of the story.
And of course it was also nice to see.
It's a nice moment of recognition to have any post on a swift.org.
Have your name against it, but it was nice to see both of our
names up there on the swift.org too.
Yeah, that was really great.
So we asked whether the community had any questions about the
announcement or about the funding.
And we had a few people get in touch with questions.
Actually, mainly the questions come from contributors and people who are quite
close to the project, which of course you would expect.
And so I think we should go through some of these questions.
So the first question is from James Sherlock, who is a regular
contributor to the project.
Thank you, James, for all of your contributions.
Um, his first question is aside from improved financial safety, what else,
if anything, are you hoping to get out of the relationship?
So I think a big part of that is something I just touched upon, it's more visibility and more reach as the place to go for packages.
So as I just mentioned, we already have seen that effect straight away that we got a lot more visibility and I think people like the assurance that we're closely associated with Swift.org and are the place to go for packages.
packages. And it also validates our work. It's just great to see that this is seen,
the project has been seen as a component in the Swift ecosystem. I think that's just great.
It also gives us a line of communication into Apple, which we now have with the Swift team.
And that in itself is very valuable.
The second question is by Marin Todorov. And it is, how did the process happen? Who initiated
it? What was it like?
We talked to Tom Doran years ago now when package collections were being
put into the package manager.
And if you might remember that Swift package index was featured in a WWDC
video, I think in 2021, if I remember rightly, and that was the year
the package collections came out.
And we knew package collections were coming out in the Swift package manager
because that's all open source.
And we launched our support for package collections on day one or around day one.
So we were right there.
What we didn't know of course, was that package collections would
also be supported in Xcode.
I've already gone down a rabbit hole here.
So anyway, so we've been having conversations with Tom around package
collections, but that was nothing to do with funding or anything like that.
But that was the beginning of that relationship where we actually started
to talk to, to Apple.
We then initiated the conversation around funding.
I think it's no secret.
We've written on our blog many times that this project demands much more than
your average open source project, which is just code.
So the fact that there is a website to maintain, the fact that there is an
entire build system on the backend means that as an open source project, it
definitely it requires constant attention and constant maintenance.
Whereas with a code-based open source project, you might be able to
take some time away from it.
That's not something we're able to do.
And so, yeah, we reached out and said, look, we, we wonder if you have any
interest in, in helping support the project.
Yeah.
And maybe we should add it.
It almost felt like we were running into an open door because the feedback we got
is we were aware of what you're doing and really interested in, in having that
discussion.
The other thing I want to say here is that the support that we received from Ted Kremenek and Tom Doran was incredible.
They were nothing but helpful at every stage of the conversation and I want to thank them personally for all of their help to get to the fact that Apple now supports the project.
Yeah. And at every point it was really important or is still is very clear that open source
and the swift aspect of open source and the ecosystem is really important to them. I think
that can't be overstated. And I think that reflects also in this support for the index.
Yeah, that comes across very clearly every time we talked. Back to James Sherlock for
the next question. And in fact, the next several questions are from James. James asks, is the
agreement time-bound or is there some other limit on the agreement? Without
going into specifics, any agreement of this kind would be time-bound. I think
that's very clear that this isn't... Are you trying to tell me Sven that they
haven't promised to support this project until the end of the internet? Well I'm
I'm hoping you tell me about a clause that I didn't see where it says that, but unfortunately I think that's not the case.
No, but it's a good question. It is a good question, but it's clear an agreement like
this has a period, but it also has the opportunity to be renewed and we're not expecting this
to be a short-term relationship.
And the surrounding circumstances change, right? I mean, whenever that comes up for
renewal, that sort of thing, the packet index might have very different usage, for instance,
then require different kind of time investments or hosting investments and that sort of thing.
And that's something you can't lock in at the moment for however many years down the
line.
That's just the nature of things.
You need to keep that in mind when you set this sort of thing up.
All right.
So the next question by James is, this is the first agreement of its kind that I've
seen.
What barriers did you have to break down?
What level in the business did it reach?
Timothy get involved.
Timothy being Tim Cook here.
I can confidently say that Tim Cook was not involved in this.
Although, of course, we have no idea.
I'm pretty sure he was not involved in this.
I would hope Tim Cook was not involved with this.
I'm confident that Tim would value the work that we did
for this fifth ecosystem greatly.
But I am almost certain he was not involved.
So dealing with a company of apple size
naturally a complex process and you can imagine a number of people would be involved in signing
that off. Throughout the process, effectively, our chief weapon was patience because it just
takes very long to have these sorts of discussions.
You're right that patience was definitely needed, but also this project felt important
to Ted and Tom as well. And without them fighting our cause, I think you're right that this
is an unusual agreement for any large company to support an open source
project like this. It's going to be no secret to anyone listening that you need
somebody inside the company who believes in what you're doing and those people in
this instance were Ted and Tom.
The next question by James is, do you think your partnership has opened
doors for other open source projects to achieve similar levels of support?
That's a great question.
And I would say, I hope so.
It's not our place to speak for Apple here, but I think any big company supporting an
open source project that benefits both the project and the company is a wonderful thing
to see.
And I personally hope that all big companies look at what we have arranged here with Apple
and decide that they can do similar things in whatever ecosystem they're working in.
Yeah.
I mean, it's a recurring theme that you see on social networks where open source projects are looking for support and often complaining that it's really hard to keep running.
And often it's just a labor of love that isn't financially viable.
People do it anyway often because they hope for some future support or employment, that sort of thing.
But it is very common for open source projects to be struggling.
And some people succeed, but it's often around the person
and their particular skills that make that succeed
or the avenues they choose to find that support.
So I think there's a problem to be solved.
And I'm not saying that we found that solution,
but it is a path.
And hopefully there are more instances where that works out
because just so much is built on open source and the value of the open source
projects are reaped by these big companies that it feels like it should
be easier for big companies to, to turn that around and also support these
open source projects.
There's been plenty of examples of open source projects that were very
important to very large companies that, that were not being supported in
anywhere near appropriate levels.
like for example there was the log4j
vulnerability that when obviously the
vulnerability is a separate issue and all
projects have vulnerabilities and that
wasn't the problem but what came out of
that was that log4j project was not
receiving enough support and it was at
the heart of every big tech company's
infrastructure. Next question is again by
James. Has Apple applied any restrictions
to what can be done by the Swift
package index or what contributions can be made. Is this the real reason for CLAs,
CLA being contributor license agreements, that we have in place on our GitHub project?
This is a very easy question to answer. In fact, there's a couple of
questions here. The first part, have they applied any restrictions? Absolutely not.
No, nothing changes on the open source side of this project. I don't think that
topic even came up. And then your question about the CLA is also no. So the CLA has happened,
so just to actually give a little bit of background there for people who are not familiar with this,
a good couple of years ago now, we changed the licensing of the package index open source
project. It was originally licensed, I think, as MIT. And I think as with many open source projects,
Not enough thought is given to licensing at the point where you start the project.
Like we definitely knew it was open source.
We'd both liked the MIT license.
I generally, MIT would be my, my, my default license to go to when
I want to open source something.
But actually it didn't fit particularly well with what we were
trying to do with the project.
And when we realized that we needed a little bit more structure
to our open source licensing, I did have a look at what the Swift project used,
But that was only part of the decision to choose Apache 2 and the Apache 2 CLA.
So a CLA is a contributor license agreement.
And really the reason that we put these CLAs in place is that what we wanted to
make sure is that anybody who contributed to the project had the permission
to contribute to the project.
So if you contribute to the Swift package index open source project, your
contributions remain your own.
They are still yours, even with a contributor license agreement.
A lot of people think that contributor license agreements assign the IP of
the contribution to the project.
That's actually not the case.
What they do as I understand, I'm not a lawyer, but as I understand it, the
main thing that they do in this instance is they give us the confidence that you
had the permission to make that contribution.
So for example, if you work for a big company, let's say Google.
I'm not picking Google for any specific reason, but they're just a big, a large
tech company and you use a Google laptop and you're being paid by Google as you
make a contribution to the Swiss package index, the contributor license agreement
is your declaration that you basically didn't do that.
And it makes sure that the IP is clean to go into the project rather than
assigning us the IP, but that was really just part of this project becoming more
serious and part of us putting a few protections in to the project.
And it was nothing to do with Apple.
Nothing to do with them.
Okay.
I think the last question we have is from Joe Heck, who is also
a contributor to the project.
He says, I don't know how much support by Apple intermix is interbound by
the same rules as Apple employees, but I'd love to hear a bit on your opinion
of how the famously closed source only company is growing to embrace more
community and open source aspects of development and how package index fits
into that expansion. I think we've touched on this a couple of times how
very clear it's been in our discussions that the open source aspects are core to
what Apple and Swift.org are doing and I think that's very clearly reflected in
just how many open-source packages Apple have created. If you look at the Swift
package index, there are currently 57 packages by Apple in the index. Apple are the
most prolific open-source Swift package authors according to our tracking. I
think all of this speaks to the strategy and that's actually, if you think about it,
a very familiar strategy by Apple. If you look at built-in apps on the iPhone,
Apple's signature move is to provide the foundation, like weather, notes, reminders,
like foundational features and apps, but then also leave lots of room for third parties
to add on top of that.
And it's very clear that the same is happening here in the open source space, like the very
foundational libraries and services like Swift itself, Swift Package Manager, Neo driving
all of the server-side Swift ecosystem, the package registry,
and the index is sort of naturally falling into this space.
I think this all lines up very, very nicely and very clearly
what the plans are here and what the expansion space really is.
I think that rounds out our questions, doesn't it?
It does.
We are definitely running long today.
I can see by the time on the clock
that we're not going to hit our length target today.
So let's maybe keep the package recommendations a little shorter today.
Do you want to kick us off with your first one?
Yes.
So the first one is called Crayon and it's by David Walter.
And that's a really nice package for dealing with colors and color aspects.
It is very similar in API to the color from SwiftUI and then has extensions on
it, like is dark, is light, contrast.
So you can get contrast values out of it and like a Boolean, whether you have
enough contrast, like for accessibility, that sort of thing, and also gives you
extensions to do color manipulation, like negative, inverted, saturated,
desaturated, that sort of thing.
So that's a really nice package for colors and it's called Crayon by David Walter.
I would love to have this package in CSS.
Darkening and lightening the colors.
You can do it in SAS, which is the pre-process of a CSS, but the way that
we do colors on the package index, we're doing our colors in pure CSS.
And I would love a library like this.
Okay.
My first package this week is a package that is called with, and
it's by Slip Douglas Thompson.
So this package reminded me of a language feature of C#.
I, this has been a very long time since I did any C# development, but I was
at one point a C# developer, and there was a statement in the language called
with, that basically says you can declare a variable and say with this newly
declared variable, do something with it before you complete the initialization
of this object or this variable.
And it's a really nice technique.
And you can do this already in Swift.
You can say let X equals and then open up an inline closure and return
something from that closure and that's your initiated object, but you have
to do that with thing where you do the kind of braces and then the round brackets
at the end to make it into a closure.
And what this does is it's not a with statement like it was in C#, but it's
a with function where you get a closure that you can do something with.
and whatever comes out of that closure gets returned as the value.
And I found that a useful tool 15, 20 years ago in C#,
and I find it a useful tool with inline closures in Swift,
and this just gives a little bit more structure to that.
Yeah, what I really like about that pattern is that it scopes,
like configuration you might have to do on an object,
it really scopes it together and it's easy to see,
and I'll group it together and not have a variable leaking around
that you really just use temporarily to set something up.
- It's not a big library.
In fact, it even describes itself as a micro library.
So it does one thing and that's all it does.
It has documentation, it has a good readme file.
It's been in development for three years
and only has seven stars.
In fact, I'm gonna go right now and give it a star.
- Excellent, live starring.
- Done.
- Excellent.
So my second package is a package you also mentioned on iOS Dev Weekly last week,
but I will say I actually had it in my list before that.
You were using it before it was cool, right?
Exactly.
I'm always on the fence with this sort of stuff.
Everything is about chat GPT and I am ambivalent about that whole AI.
We had an episode where we talked about this a little bit,
but there is clearly something there.
I mean, this is not cryptocurrencies.
I don't want to open up that kind of worms, but there is clearly something there.
There's already use cases that you can see.
I don't think they are the ones that are commonly thrown around.
Well, we're not going to talk about it this week, but we actually have been discussing
whether there is a usage for the chat GPC API within Swift Package Index.
And I'll leave that as a little teaser.
We didn't look for a reason to use chat VPC like a lot of like a lot of projects
are looking for reasons to do it. But actually, there's something that, and like I say, we'll
tease this for a future episode, but there's something that we could legitimately use it for,
and it's already, from our little experimentation with it, it's doing a really good job at what
we wanted it to do. Yeah, and I think that that area is summarization, because that steps around
a lot of the problems with AI. But back to the packages I wanted to recommend, and that's called
DocCGPT, it's by Gonzalo Nunes, and it is a tool to generate documentation for your package.
It's not a library, it's an executable that you run on your package, and it will
stub out documentation on your properties, methods, functions, classes, structs,
everything really. And the really nice thing about that is, and I've tried this with a Swift
package index it does a really good job, an initial pass to give you something
and even if you might have to edit the preamble more, the thing that I can see
this help with is just dealing with the parameters and the return values but a
lot of times when I actually start documenting something and I'm happy to
write that one-liner that explains what this does but I get really annoyed
having to then pick out all the parameters that often have very obvious names already.
So I almost think like, leave me alone, the parameter speaks for itself as does the return.
Well, you just let me write that one line and then be done with it. But you can't really do that.
If you try to document it properly, you can't really leave those blank. And I can see this
being really powerful and giving, at the very least, giving you those stubs. But actually,
I found the one line is to be really good as well. So I think you can get, you can go a really long
way taking the tedium out of documentation and actually allowing to use the edge cases,
the special things about functions that you might actually, that's the strongest reason to document
something. Because it's not the return types or the input and parameter types, because those are
often documented by the Swift language types already.
It's about why you might want to use a function
or why you might not want to use a function.
When is it good or bad?
What are the special things about that?
And I think tools like this free your time
to deal with those kinds of things.
And I think that's where a lot of the power of AI lies,
to take the tedium away.
And I'll get off my soapbox now.
- I agree.
And I also, like you said,
I linked to this in IOSWP. I think this is a great package that will give you a really solid
starting point for documentation and take away some of that tedium. You might ask, what's the
value in documentation that is so obvious that it could be derived? But actually, there is value in
it. My second recommendation this week is TrustKit by, I presume this is a company, Data Theorem.
TrustKit is an open source framework that basically helps you with SSL public key pinning.
This is a technique that prevents man-in-the-middle attacks. You basically verify the identity of the
SSL certificate that you are expecting to be on the server that you're communicating with,
with a network request, and you can guarantee then that you're talking to the correct server
and not somebody pretending to be the server that you think you're talking to.
This has been possible for a long time, and in fact this package has been in development for
eight years. So it's a well-established package and it makes that process of pinning SSL keys
or verifying that you're talking to the right server much easier than it would be. You define
the hashes that you are expecting to find in your info.plist, and then you're given a method to then
basically be able to say, "Verify this." So this is the kind of package that solves a problem
that you might be tempted to skip if you are rushing through to a first release. Whereas
you might think, "Well, yes, I know I should pin my SSL certificates, but I'll do that later."
Here's a package that makes it relatively trivial to do that.
Well, you had me at "makes it easier to work with SSL"
because that always gives me nightmares.
My third and last pick is called Polykit by Anton Hestand.
And that package is very easy to talk about
because what it does, it gives you rounded polygons in SwiftUI.
Just look at the readme, it draws out a few shapes and it's really nice.
You get rounded triangles, squares, that sort of thing, hexagons.
Very easy to use, very painless, and it saves you from a lot of pixel math,
and it looks really nice.
- That is an extremely targeted package,
but I can't imagine an easier way to make that kind of shape.
- That's great.
All right, that's Polykit by Anton Hestand.
- I know we said that we were only going to do a couple each,
but my last one for this week is nothing more than a comical package name, so I'm going to sneak it in.
My last package for this week is a package called Mork & Middy,
which, if you have any recollection of the 70s TV show Mork & Mindy, Brad Howes, who is the author
of this package, has obviously got a fondness for that TV show and called his Middy library
Mork & Middy. And I'm not even going to tell you what it does. If you're interested in Middy,
Go and have a look at it, but we'll leave it there because we are trying to keep today's episode
under an hour. So with that, I think we should wrap it up. Thanks so much to everyone who submitted
questions for the opening section of today's episode. And thank you so much for all of our
supporters, including Apple, for making what we do here possible. Yeah, absolutely. Thanks everyone,
and see you next time. Bye bye. See you next time. All right, bye bye.