Hands-on experience with an Open Source project

#wordpress #go #pushnotifications #opensource

After a reflection about my past experiences building side projects, I decided that all my new personal projects would be Open Source, and right after that I created Perfecty Push Notifications, a plugin for WordPress that is a self-hosted alternative to OneSignal or WonderPush for sending Web Push Notifications for free.

Perfecty Push Notification was launched in December 2020. It is a self-hosted Web Push server written in PHP for WordPress websites. So far, it has reached around 3,713 installations with more than 400 websites using it actively. The latest version is 1.3.3, and the next release will include a performance improvement that sends 10.000 notifications/minute in a basic server with 2GB RAM and 1 vCPU.

In this post I'll share my experience with this Open Source project and the things I've learnt from it.

Running lean

When you build a side project with an idea in mind you have two options: build it privately to launch it whenever you're done, or make it public since the beginning. I got inspired by the Running Lean book by Ash Maurya, and I was aware of the potential pitfalls of not closing the feedback loop with your end users from the beginning. You face the risk of not completing the project or launching something that nobody needs.

Building an Open Source project that is open from the beginning helps you exactly in the Problem/Solution fit: the feedback loop is closed as soon as you get the first installs and you're enabled to do continuos iterations using your users' feedback. Of course, for this, you need to follow CI/CD practices, do constant deployments, have good automated tests, an so on... however the details about Running Lean I won't describe them here but you can found them in Mauryas' book. Also, please note that the book is not about Open Source projects but can be applied to them too.

Picture taken from Leanstack

Community traction and support

One of the biggest differences with creating a personal project that only you have access to, is that an Open Source project can be public by design and everything will be under the public scrutiny. Of course this can be seen as a pitfall because it adds you some pressure, but that's exactly what you need to get the things done with your project, and as a side effect the reward is incredible.

In my case, right after publishing Perfecty Push to the WordPress plugin directory, the project gained community traction and I received tens of private messages from many people around the globe asking for more information, quoting the development of something similar, etc. Those messages I cannot share them, but here are some of the public comments the plugin received:

I cannot enjoy more the excitement of this guy talking about Perfecty Push (I loved it!)

However, the most powerful effect is that many people believe in your project and get involved in its development, and that speeds the things up, but at the same time you're now in charge of providing guidance and ultimately deciding on important matters for the project. This gives you a great power, and a great responsibility.

Great powers

You have great powers starting with the first user that decides to install your plugin, and with the first Open Source contributor that wants to join your adventure.

With your users, you have the freedom to define the path of the product features and how it will handle the users' information. You're now in charge of defining how their system will behave with the data they own. This might sound scary, but at the same time demonstrates that your users believe in your idea, and that at the end of the day you were not 100% crazy (maybe 99.999%).

With the contributors you have the ultimate voice in important matters. When no consensus is achieved, you have the power to say if something makes it to reality or not. It doesn't mean that you're the ruler of a tyranny, but it means that when there's not a clear path, you need to take one of the pills, either red or blue, because at this stage you're the one who takes the decision. I imagine in more mature projects this doesn't happen because they require a more complex structure to operate.

Great responsibility

Imagine you're the creator of a JS library that is distributed through npm and is used by hundreds of projects. What happens if by mistake you introduce a serious bug that could take down an app? Those bugs could make their way to production and affect real websites that are run by real businesses. Well, the consequences are similar if by mistake you introduce a serious bug in a WordPress plugin. You can literally take down thousands of websites by mistake.

You have a special responsibility to take care of your end user's platforms, they decided to trust you and believed in your project. They have great expectations from you now. As we're humans, we're error prone, and we need to mitigate these errors with a good testing strategy and extra attention when we publish a new version of our plugin: add automated tests, test it locally, test it in a real production scenario yourself, test it twice, check your email to see if there's something strange around your project, pray, etc.

Disclosure

As of today, I've caused two disruptions that I caught early myself and corrected even before getting any support ticket:

One source file was not included during the build stage in the pipeline and thus, it created an unrecoverable error. Fortunately, WordPress detects these situations and reverts the plugin upgrade in your user's websites. I corrected this almost immediately and the rest is a happy story.
The minified JS SDK version had a mismatched reference in the main project after migrating the repos from my personal Github account to a .org account. This was corrected and didn't have any major consequences, except the users couldn't enjoy the new features included in that version.

Again, this demonstrates that we and the systems we build are error prone, and we need to be humble and do our best to mitigate them.

Ideas, ideas everywhere

One of the most enjoyable parts that can be also stressful, is that everyone wants their opinion to be heard. Everybody wants to influence on the project features, and because you get a massive audience, and maybe you were not prepared for this, you have now the challenge to achieve a balance between hearing the user's voice and making reasonable decisions for the project. This might put you in some difficult situations where you have to say no to a stubborn user, but at the same time you need to find the right words to do it so that he can come back to you afterwards.

It's also important that you take care of your project and make your best effort to answer your users' tickets or emails (they love to receive an answer from you!) Watch out: At the end of the day, in the Problem/Solution fit, this is one of the most important parts because it's the instantiation of the feedback loop abstract.

Conclusion

I really recommend taking the Open Source approach for side projects that have a business idea in mind. If you've created more than three projects in a row that didn't make it to reality, please consider this model and let me know your thoughts!