Open source is becoming very prevalent in the software world, even if it’s not obvious. Your phone, your television, your smart speaker, and even your car is likely to use open source libraries and applications. In fact, a recent Tidelift survey showed that 92% of applications use open source libraries.
One thing I’ve seen over my many many years in open source leadership is that using open source is one thing, but it’s often done inefficiently. To illustrate, let’s take a look at two theoretical developers — Alice and Bob. Both Alice and Bob use Asterisk as part of a larger communications service that they offer. Before we get too far into the stories of Alice and Bob though, let me define a couple of terms I’ll be using in the blog post. I tend to think of open source software as a stream — think of a stream of water — which starts at a spring (the authorship of the software itself) and flows towards the users of the software. Using this metaphor, when I talk about “upstream”, I’m referring to those involved with the production of the software, and when I talk about “downstream”, I’m referring to the end users of the software. In our little example, Alice and Bob are somewhere in the middle of the stream… they’re taking the Asterisk releases produced upstream, adding some sort of value through configuration and integration work, and sending it downstream to their users or customers.
Now let’s compare and contrast how Alice and Bob work with the upstream community. Bob doesn’t really engage with the upstream community much. He built his software on Asterisk 13 (because it was an LTS release) soon after Asterisk 13 was released. He’s written a few custom patches for Asterisk, but hasn’t bothered to push them back upstream. Also, he hasn’t really bothered to keep up with Asterisk updates, except for when he runs into a bug that has been fixed in a newer Asterisk 13 update. Then he begrudgingly updates to a newer version of Asterisk 13, rewrites his patches for the updated version, and continues on his merry way. Bob also hasn’t bothered to try chan_pjsip, and keeps delaying the move.
Alice, on the other hand, is more engaged with the upstream Asterisk community. She is active on the Asterisk forums and mailing lists. She asks questions. She helps answer questions for other people. She reports bugs when she finds them. She shares her opinion about upcoming features in newer versions of Asterisk. Even though she also initially built her software on top of Asterisk 13, she has since moved her software to work with Asterisk 16. And even though she too has written a couple of custom patches for Asterisk, she has pushed them upstream whenever appropriate. When a new version of Asterisk 16 comes out, she tests it with her software to ensure that there are no problems. Alice has actively embraced the change from chan_sip to chan_pjsip, and is comfortable with the new channel driver.
So, at this point you might be asking yourself, “Self, it seems like Alice is going to a lot of extra trouble? Is it really worth all that effort?” Up until this point in the story, Alice certainly has done a lot more work with the upstream community than Bob has. Will that effort pay off?
Now, to continue our story, we look at the present day. Bob stumbles across the Asterisk Versions wiki page and realizes that Asterisk 13 will go into “security fix only” mode in October of 2020. Now he’s faced with the task of moving his software to a newer version of Asterisk. His lack of engagement with upstream has come back to bite him. Alice, on the other hand, smiles knowing that her investment to stay engaged with the upstream community has paid off, because she knows that by staying actively engaged that she doesn’t have to do massive shifts when a particular version goes end of life.
Now, even though the story above is fictitious (and I hope none of you thought I was basing Bob’s character off of you), I can state that I’ve seen this pattern play out time and time and time again not only with open source projects like Asterisk and FreePBX, but also with dozens of other open source platforms. People often start using open source as a “quick win” to get something started, but they don’t think about the longer-term ramifications of how they choose to keep up with changes.
So how can we change this? If you’re building a solution based on Asterisk or FreePBX, we at Sangoma make it easy for you to stay engaged with our open source projects. On the Asterisk side, we have mailing lists, forums, IRC channels, and blogs where you can keep up with not only the latest changes, but also with development discussions as well. On the FreePBX side, we also offer forums, IRC channels, and blogs. See us at a conference? Stop by and tell us what you’re doing with Asterisk and/or FreePBX. Or, if those options overwhelm you, reach out to me at email@example.com and I’ll try to guide you in the right direction. I’ve spent more than 20 years in open source software communities, and I am happy to share my experiences with you.
Sangoma cares deeply about open source, and we make it a priority to engage with those in our open source communities who use Asterisk or FreePBX as part of their own projects. We can’t do it alone, however. We welcome and encourage you to reach out to us and share your successes and your concerns.
My recommendation to you is to stay engaged with the open software communities which serve as the upstream for your software and services. By doing so, it will save you a lot of time, effort, and headaches down the road. It’s through building effective communities of software enthusiasts that the rising tide of open source benefits us all.