"Don't reinvent the wheel, just realign it." ~ Anthony J. D'Angelo

If you're building some open-source project, there are two key aspects to consider:

You see the loop! 🔁

Let's take each point one by one and understand.

This point does not apply to projects created solely for learning purposes.

Keep in mind that when building a project, your goal is to solve a specific problem, not just to write code. As a result, your focus should be on integrating various "unit features" to solve that problem efficiently.

You should always check if these "unit features" are already implemented by some other project, because -

But what if I am not able to properly integrate the existing project with my project? And yes, sadly that happens many times. 😔

And that's because the project authors don't think enough about the extensibility of the project, which brings us to our next point.

To prevent other developers from encountering the same issues with your project, consider all the ways it can be extended. However, keep in mind that not all projects are designed for extensibility. When you do see potential for growth, aim to keep it flexible and open for being extended.

Let's take an example to understand it better.

I have been recently developing a WordPress plugin named "WP Messaging". And the motto of the plugin is to provide a complete messaging solution for WordPress.

Do you think email marketing plugins like "MailPoet", "Newsletter", etc. should not be responsible for the "email sending" part? Shouldn't these just be responsible for managing email schedules, subscribers, etc? They already have a lot to do!

And here comes my plugin into play! Its target is to handle just the message transaction part efficiently.

(Here I am just focusing on the email part of the plugin, it also handles SMS and push notifications)

It overrides the default wp_mail's behavior and instead send the mail through your desired provider. So, wherever wp_mail is used, it will just hijack the call and send the mail through the provider. Therefore the email marketing plugins can just go on and use plain and simple wp_mail and the rest will be managed by this plugin. There is a "default mail" option in these plugins, you can go ahead and select that one and see the magic!

But there are some other plugins also which do this right? So, what's special about this? Here comes the awesome library I have used to handle the email-sending architecture - Utopia Messaging.

The awesome part about this plugin is that it doesn't provide you a long list of providers that are available, rather gives you the ability to extend it to add your own providers using a simple boilerplate code! And that's what I was talking about in the second point. You can read more over here.

And there was an example of how to follow the second point, and now here's an example which is violating the second point -

You remember the part where I said - There is a "default mail" option in these plugins, you can go ahead and select that one and see the magic!, it's true for most except one. 😔

Mailpoet - It has this "default mail" option, but guess what does it do! Instead of just using wp_mail function, it generates its own PHPMailer object and uses that and gives us no option to override that.

Therefore what they are indirectly telling us is - "Either use one of our available providers or use PHPMailer only, which is highly unreliable. We will not give you the option to use any other message routing tools.". Why in the world will you do that?! 😣

And that's it! Following these hopefully, we will be able to make projects which will not only be useful to a user but also to a developer! 😉