What 10 Years of Maintaining an Open Source Package Actually Taught Me
I built it so a client would stop copying and pasting.
That was the entire reason. I had a freelance project where the team published blog content, then opened Telegram, then X, then Facebook, and posted the same thing three more times by hand. So I wrote a small Laravel package that pushed content to all of them from one call. I released it publicly mostly so a few colleagues could use it too.
That was about ten years ago. Since then, a stranger has stopped me on a street in Mashhad to thank me for it, someone in Bushehr messaged me about it out of nowhere, and a US startup offered me a job because of it. It is now the foundation of a product I am building.
None of that was the plan. This is what actually happened in between.
TL;DR
- I published the package for a handful of colleagues. I had no idea an open source community would form around it.
- Renaming a package is a real migration for everyone who depends on it. I have done it twice, and communicating it properly is most of the work.
- Maintenance lapsed for a long stretch while I was relocating from Iran to Turkey. Users sent pull requests and kept it alive.
- Being recognized in person by someone who uses your code is a strange and specific feeling.
- Ten years on, the package still had demand, which is why it became a business rather than a finished thing.
The first version solved one problem badly enough to be useful
The original package did three platforms: Telegram, X, and Facebook. Its API was a static call, SendTo::telegram($message), and that was roughly the whole design.
It worked. Not because the code was good, but because the problem was real and nobody wanted to solve it themselves. Every Laravel developer running a content site had the same copy-paste routine, and none of them wanted to read three separate API docs to stop doing it.
I wrote an article about the package after releasing it. That was the moment it stopped being a private tool. People found the article, tried the package, and started opening issues. The install count grew without me doing anything else to promote it.
The lesson I would not have predicted: the code was not the hard part, and it was not the valuable part either. Packaging a boring, repetitive problem so somebody else can skip it turned out to be worth more than anything clever in the implementation.
What renaming a package actually costs
The package has moved namespace twice. First from toolkito/larasap to alihesari/larasap, then to owlstack/owlstack-laravel.
Each move meant the same work: publish under the new name, mark the old package as abandoned, point it at the replacement, and let every existing user know the address they installed from is no longer maintained. People emailed me. People messaged me. Some had the package pinned in production and wanted to know exactly what would change.
The moves were deliberate. The first consolidated the package under my own namespace, and the second reflected a genuine rewrite into a larger project. Most users followed, and the 442 stars came across both times.
What made that work was treating the rename as communication, not configuration. I expired the old package so installs would surface the notice, linked the replacement directly so the path forward was one click away, and answered the messages that came anyway. Users follow a rename when following is easy and the reason is visible.
Even done properly, some of the cost lands on other people, and it is worth pricing before you decide:
- Every dependent has to act. A rename is not transparent. Someone has to edit
composer.json, run an update, and verify nothing broke. - Search results lag for years. Old articles, Stack Overflow answers, and tutorials keep pointing at the previous name long after you have moved on.
- You will answer the same question repeatedly, in issues, in email, and in DMs, for months.
- Abandoned-package notices help, but only for people who look. Some developers discover the move only when an install fails.
If you are weighing a rename, the practical version is: do it when the package is genuinely becoming something different, do it as early as you can, and communicate it in more places than feels necessary. The technical part takes an afternoon. The migration you are asking your users to perform is the real expense, and making that migration easy is what determines whether they come with you.
The maintenance gap, and the people who covered it
The upgrade work itself was never heavy. Laravel ships a major version every year, dependency constraints need widening, and that is a small predictable job.
Then I moved from Iran to Turkey, and the small predictable job stopped happening.
Relocating consumed everything. New country, new work, new logistics, and no spare attention for a package I maintained for free. Issues accumulated. Compatibility complaints piled up for Laravel versions I had not tested. For a long stretch, the package was effectively unmaintained.
What kept it alive was users sending pull requests. People who depended on the package fixed it themselves and offered the fixes back, and they did that without any commitment from me that I would ever merge them.
When I eventually had time, I went through them, reviewed what each one did, and merged or rejected them. That review was slower than writing the changes myself would have been. Understanding someone else's fix to your own code, months later, is genuinely harder than fixing it fresh.
Two things I took from that period:
A permissive license and a public repository are a form of insurance. Because the code was MIT and the repo was open, users could keep the package working without me. If it had been locked down, it would simply have died while I was busy.
Unmaintained does not mean unused. Downloads continued the entire time I was absent. People were depending on code I was not watching, which is an uncomfortable thing to sit with and a good argument for saying so publicly when you go quiet.
Being recognized for code you barely remember writing
Two years after I left Iran, I went back to visit. I was in Mashhad with friends when a man I did not know walked up and greeted me by name.
I had no idea who he was. He explained that he recognized me because he used the package, and he wanted to thank me for it.
I still find this hard to describe. Software you write mostly disappears into other people's systems. You see download counts, which are abstract, and issues, which are usually complaints. You almost never meet the people on the other end. Having someone approach you in a city you no longer live in, because of a few hundred lines of PHP you wrote years earlier for a freelance client, collapses that distance in a way a statistics page cannot.
It happened again later, in a Telegram group for developers planning to emigrate. Someone from Bushehr said he recognized my name, used the package across several projects, and thanked me. Different person, different city, same experience.
Neither of these changed anything practical. But if you are wondering whether publishing your side project is worth it, this is the part nobody mentions. Not the stars. The fact that real people, in places you have never worked, are quietly building on something you made.
Where it actually led
About a year ago, a startup approached me about working with them. The manager was based in Turkey, the company was in the US, and they had found me through the package.
I did not take it, because by then I was building my own product around the same problem. But the offer made something clear: the package had been functioning as a professional credential for years without my noticing. Nobody asked for my CV. The code was the CV.
That is the concrete, unromantic career argument for open source. A maintained public package is evidence that you ship, that you handle other people's problems, and that you keep something alive over time. It works while you sleep, and it works in markets you have no connections in.
Ten years later, it became a business
Last year I looked at the package properly and noticed something: demand had not faded. Ten years on, people were still installing a tool for a problem that had, if anything, become more common. Everyone publishes to more platforms now, not fewer.
So I rebuilt it. The current version splits into two packages: owlstack/owlstack-core, a framework-agnostic PHP engine, and owlstack/owlstack-laravel, a thin Laravel wrapper around it. The rewrite replaced static calls with dependency injection, returns structured results instead of raw arrays, and dispatches events on success and failure.
Platform support went from three to eleven: Telegram, X, Facebook, LinkedIn, Instagram, Discord, Slack, Reddit, Pinterest, WhatsApp, and Tumblr.
The core/wrapper split is the structural decision I would defend most. The original package tangled Laravel specifics with platform API logic, which meant every Laravel upgrade touched code that had nothing to do with Laravel. Separating them means the engine can be tested independently and reused outside Laravel entirely, and the wrapper stays small enough to update quickly.
That package is now the foundation of Owlstack, the product I am building around it.
Would I do it again?
Yes, but not for the reasons I would have given ten years ago.
I did not publish this package expecting a community, a job offer, or a business. I published it so a few colleagues could use it, and everything else followed from the fact that it stayed public, stayed licensed permissively, and stayed alive long enough to matter.
If you are deciding whether to open source a side project, the honest version is this. Most of it is unglamorous: dependency bumps, compatibility issues, and questions you have answered before. You will have periods where you cannot keep up and you will feel bad about it. The rewards are real but unpredictable and slow, and none of them arrive on a schedule you control.
But the code keeps working while you do other things. It reaches people you will never meet, in countries you have never worked in, and occasionally one of them walks up to you on a street and says thank you.
Frequently Asked Questions
Should I rename my open source package?
Only when the package is genuinely becoming something different, and preferably early, before many people depend on it. A rename forces every dependent developer to act, leaves search results pointing at the previous name for years, and generates the same support question for months. Mark the old package abandoned, link the replacement directly, and announce it in more places than feels necessary. Users follow a rename when following is easy.
What happens if I stop maintaining a package people depend on?
Downloads continue regardless. If the license is permissive and the repository is public, users can patch it themselves, and some will send those fixes back as pull requests. That is what kept my package alive through a long gap. The most useful thing you can do when you go quiet is say so publicly, so people can decide whether to depend on you.
Does open source actually help your career?
It functioned as a credential I did not know I had. A US startup approached me about a role because of the package, without ever asking for a CV. A maintained public project shows that you ship and that you sustain something over years, and it does that continuously in markets where you have no personal network.
Is it worth open sourcing a small utility?
Mine was small, and the value came from the problem being common and boring rather than from the code being impressive. If a repetitive task annoys you enough to automate it, it probably annoys other people the same way. That is a better predictor of adoption than technical sophistication.
How much time does maintaining a package take?
For a small package, the recurring work is light and predictable: widening dependency constraints when the framework ships a new major, and answering compatibility issues. The problem is not the volume, it is that the work arrives whether or not you have the capacity that month. Mine lapsed entirely during an international move.