I wanted to write a blog post about everything that has happened with AudioKit in its first-year available as an open-source project, but I realized that all that is well-documented by looking at the blog, or by looking at the Release log. So instead of going over it all again in detail, I want to write about a few of the lessons learned along the way.
But first, it’s good to take a moment to reflect on the stats from the last year.
There have also been 8 major releases, 4 versions of 1.x and 4 versions of 2.x. We have made 2402 code commits and 498 web site commits since 1.0. That’s a 300% increase from all of the commits that led up to our launch!
Every major release had something really important in it: Tests, Sensible Defaults, Xcode Templates, Rate-Agnosticism, CocoaPods Support, Example Projects, Live-Coding with Playgrounds, Syntax Refinements, Dynamic Tables, Static or Dynamic Dependencies, Switching to the MIT License, Travis Continuous-Integration, Embedded UI Tools, Plots, Sensible Presets, SoundFont Support, tVOS Support, and New Operations. Phew!
Thankfully this was not all on my shoulders, AudioKit got 12 new contributors this year, most notably Stephane Peter who as of March really has been a primary force in AudioKit development, quickly earning him a place on AudioKit’s core team.
Okay, okay, let’s get to the fun part, the lessons learned along the way!
Lesson 1) Open-sourcing a large private project is not easy
With AudioKit 1.0 we learned a lot about what it really means to open-source a piece of code and get things working and well-documented enough for public consumption. Although this work didn’t technically happen in the last year, it is worth noting the monumental effort that Nick Arner put in to make this happen.
Additionally, building a web site for an open-source project can be harder than writing the code.You have to put yourself in the shoes of someone who has never heard of your project and that is challenging for a developer whose deep into the code.
Lesson 1a) Even after launch it doesn’t get much easier
You might think that once you release your work is done for a while, but actually now that eyes are on you and people are trying to use your code, you’re about to learn about all the things that you didn’t even know were broken. Here’s Github’s timeline for my last year (it’s 99% AudioKit):
Lesson 2) If you build it they may not come
This is not me complaining about how many users AudioKit has. I am actually really surprised by how big our community has become. We have 1,190 stars on Github, with 158 forks. We’ve had countless demo apps created, 5 apps released on the App Store, and quite a few schools have adopted AudioKit to teach audio programming to high-school students all the way up to graduate students. So, while the adoption rate is great, I’ve learned that even though I might think a feature is amazing, I really never got much feedback from people after that feature is released. The lesson however is to not be daunted by this fact and not rely on positive feedback to make positive improvements to the code. A good example of this is Testing and Travis Continuous Integration. These were huge undertakings that in general no one is ever going to care about. But they are so important to the future development of AudioKit! Being able to accept/reject code based on tests and having that automatically happen behind the scenes on Travis is one of my favorite accomplishments of this last year.
Lesson 3) Open-source with the right license…
When we first released AudioKit, it was under the LGPL license. We had to do this because of our libsndfile dependency is licensed under the LGPL. However, we received lots of questions and comments about how the LGPL was not appropriate for closed-source iOS apps on the App Store. With the addition of a dynamic framework, we were able to re-license AudioKit under the MIT license. Ideally, we would have done this work before we first released AudioKit and we probably would have had more initial users.
Lesson 4) Love everyone, because they might become your core team
When I look at the core team of AudioKit developers, I am struck by the fact that I still remember when they were completely new to AudioKit. I could have been dismissive of their interest or abilities, but if I had been a jerk like that they would never have wanted to work with me and make the contributions that I value so much now. I’ll mention Nick again because literally, AudioKit might still be in procrastination mode if it were not for him. Stephane has made improvements to AudioKit that I just would have not thought of or been able to implement on my own. But, the best example of this lesson is Simon Gladman. His first project using AudioKit may not have been all that great, but since then every AudioKit project he has built has been better and more interesting than the last. His latest AudioKit-powered Metal Particles project is absolutely gorgeous and this trajectory has no sign of decreasing either, so I can’t wait to see what comes next.
Goals going forward
Perhaps the main lesson learned is that you can’t really predict the future of an open-source project, you just have to be ready to react to whatever happens next. That being said, we do have a lot of work planned and improvements in the works. Thanks to everyone for the great year we had, and here’s to another great year ahead.
