<div class="markdown">
<p dir="auto">Recently I polled many active members of the Swift dev community. I<br>
asked 4 questions:</p>

<ol>
<li value=1>What are you working on in Swift or the Swift ecosystem?</li>
<li value=2>Of the things you know about that people are working on, what's
 the most important?</li>
<li value=3>What are you excited about in Swift?</li>
<li value=4>What are you worried about in Swift?</li>
</ol>

<p dir="auto">Swift has a fantastic community. Right now, we’re at a global max of<br>
active contributors[1]. Our contributor community is growing, and<br>
we’ve got a large number of people who are consistently active. Our<br>
upcoming hackathon in Bristol looks to be one of the largest we’ve<br>
had, by number of registered attendees.</p>

<p dir="auto">Not only is the size of our contributor community growing, but we see<br>
more and more Swift clusters being deployed. One survey response that<br>
came up several times is being excited about seeing 10+PB clusters in<br>
production. Swift is growing in the number of deployments, the size of<br>
those deployments, and the level of contributor participation. It’s<br>
all very very exciting to see and be a part of.</p>

<p dir="auto">No question, there is a lot to do in Swift and a lot going on.<br>
Interestingly, regardless of what an individual was working on at the<br>
moment, there were several things that came to the surface as commonly<br>
mentioned "important things". These most-mentioned topics are:</p>

<ul>
<li>container sharding</li>
<li>fast-POST</li>
<li>encryption.</li>
</ul>

<p dir="auto">All three of these topics are long, ongoing things. Interestingly, all<br>
add end-user benefit without actually requiring any changes from the<br>
end user. These aren’t features that are adding new (externally<br>
visible) functionality; they are making the current system more<br>
capable for the way users already want to use Swift today.</p>

<p dir="auto">There is a <em>lot</em> of concern in the community about supporting the<br>
interaction of different features. For example, understanding what<br>
happens when you overwrite a versioned *LO via a COPY using an<br>
encrypted EC policy (and with the different config options possible<br>
for each of those) is hard to reason about. This makes it hard to<br>
support, hard to test, hard to document, hard to review new code, and<br>
hard for users to understand. Of course this is somewhat balanced by<br>
the praise Swift gets for being flexible and adding features that<br>
enable complex enterprise deployments. Unfortunately, the cost of<br>
these complex interactions make it difficult to support the codebase,<br>
add new things, and review patches.</p>

<p dir="auto">Speaking of patch reviews...</p>

<p dir="auto">There's also quite a bit of community concern about slow reviews. Some<br>
of this is related to the concern around complex feature interaction.<br>
Some of this is the ratio of cores to stuff-going-on. This issue is<br>
exacerbated in swiftclient, where there is an obvious gap in the<br>
contributor community.</p>

<p dir="auto">On the positive side, there's a huge amount of praise for the<br>
community itself. People find the community welcoming and pleasant to<br>
work with. Even those who work in more remote time zones find it<br>
enjoyable (paraphrased: "Before I worked on Swift, I didn't expect we<br>
would work well together because the community is so spread out across<br>
the world. But it's absolutely awesome."). There's one comment from a<br>
relative new contributor about it being hard to get involved (learning<br>
the code and community via IRC). Having an easy onramp to community<br>
participation is very important for the health of the project.</p>

<p dir="auto">So what are the plans moving forward? I’ve got some ideas, but<br>
improving Swift is something we all can work together on. If you’ve got<br>
an idea, let’s try it out!</p>

<p dir="auto">Here’s some thoughts I have about how to improve</p>

<p dir="auto">Goals we need to keep in mind:</p>

<ul>
<li>Reduce complexity by reducing modes of operation (eg fast-POST only)</li>
<li>Remove extraneous features, modes of operation, and deprecated things</li>
<li>Add "magic" in the right places to make complex things simple and hard
things easy</li>
<li>Respond to patch submitters quickly</li>
<li>Remember that new community members are always joining, and we must
provide them with an easy way to get involved technically and socially.</li>
</ul>

<p dir="auto">Specific action item ideas:</p>

<ul>
<li>Re-introduce the automatic config pipeline generator.
This reduces errors around one of the most confusing parts of Swift.
Our feature interaction matrix is exacerbated by the amount of
middleware that is used/recommended by default. This makes it hard
to add new middleware, and if we the active contributors are confused
by it, then deployers have no hope. An automatic pipeline generator
removes confusion and puts the magic in just one place.</li>
<li>Describe and test complex feature interaction (especially things
that aren't an atomic operation). Document the feature matrix.</li>
<li>Update "getting started" docs and install guides on a recurring
schedule. Challenge active contributors to rebuild their SAIOs from
scratch (without an automation script) once a month.</li>
</ul>

<p dir="auto">[1] <a href="http://d.not.mn/active_contribs.png">http://d.not.mn/active_contribs.png</a></p>

</div>