A couple of weeks ago, I made the move to Overcast as my primary podcast application on my phone. I absolutely dig it, but one of the things that I respect most comes in the FAQ of the application:

There’s a very basic web app. An iPad app is planned. A Mac app might happen someday.

I have no plans for other platforms at this time. It’s nothing personal: they’re just not for me.

Overcast was clearly built for a specific purpose – on that was largely personal – and there’s no intent to grow it beyond that specific purpose.

I love that.

Overcast

And when it comes to our own work, there’s something to be said for building tools that help you do whatever it is that you want to do, and if you’re looking to market it great, and if you’re looking to keep it only on your machine or as a tool for your own project, then that’s great, too.

But in a segment of the industry that praises open source and the advantages that come with it, it can be somewhat of a challenge to have tools that you build only for yourself and have them maintained for that single purpose.

Open Source Challenges (You and Your Software)

Although I love much of what comes with open source – code reviews, contributions, improvements, bug fixes, and so on – I also believe that features are what give software its identity and if an application or project ends up taking on too many features or too many things “just because” or without any specific reason other than “because someone wants it,” then it becomes less of what it was.

Some will call it scope creep, some will call it bloat, but whatever the case may be, whenever you’re working on a project – especially if it’s a personal project – then you know if a given feature request fits within the scope of the project or not.

And this is where I think there is tension in open source: Sometimes, those who are maintaining an open source project get irritated if an open source project becomes inflated with features (or even loses features) that they once believed were core to the project.

But when this happens, it’s no fault of the people who are issuing pull requests. It’s the fault of the developer. If you’re creating a project that you that fits a specific purpose, then you have the responsibility to maintain the project as you see fit.

You need to have a mission, vision, and scope for your work. You stand as gatekeeper to that code.

You Shall Not Commit

You Shall Not Commit

If someone issues a pull request for a feature that you don’t want, then reject it. If someone reports a bug that isn’t really a bug but more of a lack of functionality, close the issue – it’s a non-issue.

Whatever the case, open source does not imply that the original codebase has to be tampered with. Sure, it can be forked and modified, and built out for other purposes by other people, but the original codebase can stay true to whatever purpose you’ve originally intended it.

So whether or not it’s you or others who critique open source as a way for a project to “belong to the masses,” make sure that you’re viewing it in the proper context. It belongs to the masses in that others can take the code and do what they will with it, but the original code and identity of the software can always be yours.

Category:
Articles

    Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.