Why I Didn't Open-Source My Second SaaS
panelbear.com
panelbear.com
The difference I see is traduora looks like a project, not a company. Sell support! Don't give it away for free. If someone asks me for a bugfix, I show them the ticket in our open backlog & tell them if they want it done faster, they have to pay. Seeing their concern turned in to a ticket shows them that I care, but telling them I prioritize paid fixes tells them it's not a charity. Don't let them feel entitled.
I've always been a little annoyed at this model, because with so many companies it comes down to "I paid you $120,000/year for this support contract and you're telling me you've been able to track down this bug I reported, but you're not going to fix it because it's not on the project your developers are currently working on." And then they get really miffed if you drop the support contract next year, telling us how we'll be locked out of security and feature updates, even though there were zero releases in the past calendar year. If I'm playing for the equivalent of a full time junior developer I expect at least some action on my bug reports.
At the same time, maybe for some rare & "really big" features, it could be worth the extra administrative work, to pay for that particular feature
Support subscriptions could even include an annual/monthly/whatever number of credits to vote for issues, possibly at a discount compared to a la carte.
I wonder if there's any SaaS that specializes in this. Like, Kickstarter but for new features, preferably on the company's own sub domain? So as not to distract people with unrelated projects, when they visit the "features crowdfunding" page. And the audience would come from the company's website (but not from the "Kickstarter for features" company's website).
Or I wonder if Gumroad would think this sounded interesting.
> with some expiration so customers don't end up paying for a bug that isn't fixed until years later
Good point
> If I'm playing [sic] for the equivalent of a full time junior developer ...
Equating $120,000/year with a junior developer salary is exactly the kind of tone deaf I see too much of on here[0], but in this instance it plays in favour of your argument.
Depending on exactly where you are in the world - even within the US - $120k might be a much more senior salary, or several developers worth of salaries. It then becomes perhaps even more galling that you're seeing zero service for that outlay.
[0] Yes: I know junior devs in SV might get this but SV is not the world.
$60k base salary is definitely junior developer territory.
I give you 1/5 because the app doesn't do what I want and you don't kiss my ass nice enough. You don't know how to treat your customers right, how childish of you to ask money to fix my particular problem!!
For some reason a lot of people believe that leaving a review with bad rating for a free and opensource app will motivate the developers fix the issue asap, in hope that the user will change the rating to 2/5.
Why not? There's successful projects selling or based around extensions.
- $100k with a browser extension: https://www.indiehackers.com/post/css-scan-made-over-100k-d6...
- $38k/month with a browser extension: https://www.indiehackers.com/podcast/187-jordan-oconnor-of-c...
- $3.1k/month with a browser extension: https://www.indiehackers.com/product/night-eye
- $2.5k/month with a browser extension: https://www.indiehackers.com/interview/weather-extension-ad9...
In the same vein, I have a bully, he both writes me on my professional email (to ask me for reparations), AND writes me on public forums 12hrs later asking why I didn’t answer him yet. So it is not only free users who expect premium service, nowadays even bullies expect 12-hrs response ;)
(For all I’m concerned, he can go to court if he really believes I owe him something, I give it 0% chance, but he’s clinging to his illusions).
Just lowerclass problems.
Hmm. What percentage of claims in sworn testimony are intentional lies?
The amount of people that personally attack you and accuse you of horrible things should be zero.
I've also seen users personally using our forums to try to get the software for free and complaining it costs too much money.
As soon as it's clear that one of the developers is listening they go quiet but it's super disheartening when your community, which should be supporting you, feels so entitled.
Interestingly enough I used to have a customer facing job in a completely different industry and it was exactly the same situation there. 90-95% of customers were great; they were pleasant and easy to deal with. But man, the bad ones took up sooo much time and energy, it was ridiculous.
My second favorite (would be first if not for the slightly snarky style) is "Please, go read the License". This is to say that the License typically states that "this software is provided AS-IS with no guarantees at all", but in a very indirect way that most people won't understand when told to them... but I still like that answer, FWIW :-)
"Pull requests are always welcome :)"
Sounds like he was too focused in one area of his project, and needed to take a step back to get a broader view of the state of things. I'm not convinced the closed/open source nature of his code is responsible for that.
From the post:
> In the past, when it came to running a business as a solo-founder, having it open source created too much maintenance burden for very specific feature requests. In particular from non-paying users, who sometimes sent me emails directly, demanding I look at their issue, or help them fix things “as soon as possible”.
This lack of interaction is both a feature (lets you focus, you have time to take care of paying users) and a bug (less interaction means you could build the wrong thing, the source is no longer a marketing mechanism for you).
> It sounds like having the code open sourced took too much of his time away since it allowed people to make requests for things. But I don't see why that means he necessarily has to take time to fulfill the requests.
The existence of the interactions doesn't necessitate engaging with them. If engaging with interactions is taking too much time away, one could simply, not engage with them.
Sure, I get it, everyone needs to prioritize. But if you are ignoring interactions on your OSS project, you can expect more, oh, I'll call it 'heat'. I have seen those github issue threads, where people get frustrated because someone hasn't engaged.
So if you aren't going to engage, why open source it? Sure, there are other reasons, but the community feedback loop is a crucial part of the value of OSS for building a business.
Also, I get there's nuance and you can choose to engage when there's been a certain level of commitment from the community (a number of upvotes is what my current company uses to help prioritize efforts), but for a solo founder it can be really hard to prioritize, and the author apparently found all the requests a distraction. His choice, but I sympathize.
Companies selling non-OSS products get slammed with requests on a large scale and they have to deal with them somehow. Todoist immediately comes to mind. I mean, sure, it's possible that some users of a paid product will conclude you don't know what you're doing and take their business elsewhere, but that's kind of like boasting about fixing your broken finger by cutting off your arm.
I'd argue engagement is only a medium part of open source: plenty of projects publish code and never accept requests/issues, and are very popular. It is always nice to open source even if you don't accept PR's/review issues, because it gives me more trust.
I'm sure there are plenty of blog posts out there, but I can see the following benefits:
* marketing halo ("we do open source")
* community feedback, both bugs and features
* community contributions
* trust in the company
* trust in continuity of the product (even if the company fails, I can continue to run this product)
* cost
Apple, for example, publishes a ton of stuff over at opensource.apple.com. But the majority of it is stuff thrown over the wall, and not attached to a community that has to be actively managed.
The insistence on confusing these things for other people is perhaps one of the biggest threats to open source.
That's a great distinction as there are companies out there doing open development who may have a closed source product.
This choice isn't always as simple as it sounds. There is, strange as it is, a real reputational risk to be known as a disengaged open source maintainer.
It's a real PR risk to have a demanding open source user who personally emails you then takes to Twitter to denounce the project if you don't engage. It's also definitely a risk for a paid, proprietary project too, but for some reason it doesn't seem to happen as often.
> Sounds like he was too focused in one area of his project, and needed to take a step back to get a broader view of the state of things. I'm not convinced the closed/open source nature of his code is responsible for that.
It's not that the author was overly focused on one thing. It was just that he didn't want to pay the cost.
Again I think this is an unfair characterization of the author's point.
All that being said, I think your original point, that you can have open source without engagement and minimal PR risk, is doable on reflection, you just need to break away from the usual open source mould. So e.g. that means not using GitHub, GitLab, Sourcehut, etc. to host your code. Instead just provide a contact method that customers can use to request code on demand such as an email address or mailing address.
Minimize any other contact surface area and enforce trademark heavily so that any users re-uploading the code to other sites must change the name.
Basically make sure to hide the official open source channel away from non-paying users.
At that point it's another interesting question whether it's still worth it to the author to go open source (since you're giving up most of the stated commercial benefits of open source, especially those surrounding reputation), but it's a way of minimizing the reputational risk of non-engagement.
And of course sometimes you may judge the reputational risk to be acceptable.
> I was too focused on developing every feature, trying to give support to every single ticket, and I completely ignored the marketing aspects of it as I had no time for it.
Saying the author was overly prioritizing responding to the communications that open sourcing the code allowed to come through shouldn't be controversial. He himself is admitting to it.
My main point is that the author hasn't convinced me that blame should be placed on open sourcing the code. To me that's akin to blaming the messenger. He should instead be looking to why he felt obligated to spend the time supporting "every single ticket", when he himself knew that he was neglecting other aspects of the business side of things.
Your contention as I understand it is that this was effectively the author's choice and that he conflating two concerns. There is the choice of whether to open source code and whether to support the code. Nobody was holding a gun to his head and forcing him to support code. Hence his misprioritization is of his own doing.
The author's implied contention is that the two concerns are not independent. That while it may not have been a gun to his head, there are a variety of factors that link the two together.
I'm expanding on that contention and saying that there is valid reason, if you have code on GitHub, to feel a need to support it. It's a trade-off. You can decide the risk is small enough to ignore which is fine, but it's still there.
>This choice isn't always as simple as it sounds. There is, strange as it is, a real reputational risk to be known as a disengaged open source maintainer.
IMO there is middle ground. One can engage with a canned response stating support for non paying customers is provided on a "Best effort" basis and current high commercial demand doesn't allow the maintainer to offer as much time as she/he would like to for free...
Reasonable people will understand, perhaps some of them will even convert to paying customers. Bad PR from unreasonable people will happen regardless.
When a user opens an issue, sometimes it can be very time-consuming just to determine whether the user is encountering a legitimate edge-case bug, vs the user doing something wrong and not reporting it accurately. This type of issue can't be ignored entirely, because if it's a legit bug, then it's present in the paid SaaS product as well.
Also consider that many GitHub accounts don't mention real names or company affiliations. It can be hard to tell whether an issue submitter is some rando or a loyal paying customer. Even if you have a separate bug tracker or support system for paying customers, some of them will submit issues to the open source project by mistake.
I've seen many maintainers whinging about the demands of communities on their time. But it's all 'choose-your-level-of-involvement'. Those people clamoring for attention may be annoyed and frustrated with you, but that doesn't answer the question as to why that's a problem unless you choose for it to be.
If the maintainer is a solopreneur, whose source of income is a paid SaaS version of the open source project, then no they typically cannot ignore critical bugs.
> Those people clamoring for attention may be annoyed and frustrated with you, but that doesn't answer the question as to why that's a problem unless you choose for it to be.
Out of curiosity have you ever maintained a decently popular single-primary-maintainer open source project? How about one with a SaaS or commercial version?
Frequent frustrating interactions with users isn't exactly beneficial to one's sense of motivation, at least in my experience (which mirrors the original article quite closely).
Maintainers may have a degree of involvement necessitated by their business needs. However, the loudest people screaming for support are very rarely even the same niche as those funding a project. So ignore the whining; listen to the constructive bits if they're there. Delete messages en masse and move on with your life.
YMMV. We can agree to disagree.
I find your tone to be uncivil and I do not wish to continue this discussion with you.
Open source doesn't mean that you need to provide hours of free support to someone who couldn't even bother to write a proper issue description. For a matter of fact, you don't even need to provide free support to anyone, no matter how nice they are and no matter how well they written the issue You can help them, but you don't have to.
You also don't need to accept pull requests: if you think that the feature doesn't make sense or the code quality is terrible, or it's just not important to you, you don't need to accept pull requests.
You also don't need to bend over backwards to maintain a stabile API.
It makes your life easier if you communicate this in the README of the package, tell people that it's the early days of the product, you develop in the open, but you aren't going to abide by other people's unrealistic expectations about your open source work.
"Misunderstand" implies there's some authoritative definition on "open source" means here. I remember people considering Dasura "not open source" even though it was GPLv2, simply because they didn't accept patches and only threw code over the wall.
To a lot of people, open source means engaging on Github. You can say "they're wrong", but that's just disagreement.
No pesky user requests or stars.
Accepting pull requests on smaller projects seems strange. If I wrote this why do I want someone else sharing credit.
Still I agree that it's probably possible to open-source without these problems and that this is not a complete compelling argument for every case. For me personally at least not open-sourcing at the beginning (like the author did) would probably be preferred as well for a solo-founded project.
I think so too. There's personality trait that I wonder if it is related to this: Agreeable vs Assertive, in the Big 5 personality traits,
(Actually I wrote a sibling reply (sibling to yours) and mentioned this, here: https://news.ycombinator.com/item?id=26433328 hmm maybe it'd been better if I had replied to you instead :- ) didn't see your reply until now though.)
I have code I could open source (e.g. some very useful Postgres extensions created for a company) but I value my time more, and I know many others that view the calculus similarly. There is value in open sourcing code but we should be honest about the associated costs and not pretend they don't exist.
Could that depend on the personality traits of the solo founder? What if it's in some people's nature, to feel bad about rejecting make-sense feature request and bug fixes, in order to instead focus on money making things? (Even if logically it'd be the long term good thing to do.) Whilst someone else might have felt just fine, doing that?
If you know about the Big 5 personality traits, maybe this is related to where you are, in the Agreeable vs Assertive dimension.
For someone who is more Agreeable, then, keeping the SaaS closed source, might be the way to go — so there simply won't be any unsupported platform installation problems to ignore but feel bad about.
When we looked at the other solutions out there, we saw that a lot of them offer a self-hosted version for free. Giving away whole products for free has become a trend I don't anticipate. You can be sure there is an open-source, free as in free beer replacement for almost anything, which makes it really hard to build a sustainable business. While you can generate some traction off of it, you also have to deal with people asking for free support, new features, bug fixes, and so on. I have quite a lot of open-source projects, one of them is a game server management web UI [2]. It breaks my heard every time I have to tell someone that I can't support their request. There are cases where it makes sense to have the product fully open-source of course, like an operating system, or anything that can be considered "infrastructure".
Writing software is difficult and it takes countless hours to build something useful that is non-trivial. If it's something a lot of people rely on, think about charging for it, instead of giving it away for free. But in the end it's your time after all.
When it's coming from OSS developers who are not making money themselves, it's indeed head scratching.
Sad, but true. Everyone wants good software but very few users are willing to contribute anything. Even if it's just to test an unreleased version.
I think open source projects need to think more about their "funnel" that turns users into contributors. Even if it's just for minor tasks, like docs, translation or testing.
This isn't too fancy - quite commonly corps and startups alike offer some generic libraries. One can take that pattern to greater degrees.
This allows to scratch the itch of sharing something with the community, while still guaranteeing a livelihood.
Of course, it's mostly an incompatible approach for those favoring a strict monorepo- and microservice-based architecture.
In the future, I would love to open source it. But for now, all I see in other B2C/consumer OSS projects is a lot of complaining, frustration, and extra work without a benefit to my paying customers.
It seems extremely commoditized at this point with multiple competitors who have strong positioning (I.e. privacy focused, open source, etc).
Eventually one day I want to do email forwarding, I was thinking open source or not and pretty much chooese to go with close-source for now.
I can see myself open source in the future when I get enough customers and I have more time to cleanup the private stuff in our mono repository right now.
But for an early self-bootstrap self-funded I feel like focus too much on Open Source and I don't have time to focus on the growth or marketing.
I finally release my first SaaS this year, make $78/month right now(don't laugh at me). https://hanami.run
I would say I'm not against opensource and it definetely work for others, but for me, by not going open source I can focus on the business itself. With that being, I contributed back such as a mail parser https://github.com/yeo/parsemail https://github.com/yeo/pix
I can imagine myself release a lite-version(our early prototype) where we can forward email using a config file, instead of a database with all the user, membership stuff that no one care about if you want to self-hosted my SaaS.
Does anyone why housing everywhere seems to be going nuts? This can't be a good sign.
It will depend on the location, but usually a mix of more people in the big cities, inflation, low interest rates ( so low mortgage rates), physical constraints ( most cities can't sprawl forever), sometimes regulations ( like zoning).
It's mostly in big cities though, go to a small one without any obvious geographic advantage ( like being on the seaside), and prices are usually much lower and stagnating.
Also depending on location, IMHO the pandemic has shown to a lot of people that remote work is possible and can be productive, so there will be some moves towards smaller cities and villages + remote working for big city businesses.
- Populations are growing.
- Younger folks would rather live in the city.
- Sets of homeowners and voters heavily overlap.
- Government supports homeowners via tax policy, all housing is already taken.
- Existing homeowners prevent new construction.
- Some portion of renters enjoying rent control also support NIMBY policies.
A perfect recipe for housing scarcity and therefore high prices.
This is why I'm mystified as to what's driving prices up, I've heard things like increasing tourism making owning a home a good investment, foreigners buying homes to get citizenship (a "golden passport"), and foreigners trying to spend their unlaundered fortunes abroad.
More recently, pent-up demands after a covid induced slow down, temporary government incentives, increased risk of currency devaluation, markets, gold (heck, even cryptocurrencies) at all time highs.
Once the economic damage of the pandemic is factored in, small businesses die and the middle class start being taxed even more, I'd expect the market to react negatively as people with money flee.
Probably at some point after lockdowns are over (if they will be over at some point) and governments start taxing real estate purchases again (some countries reduced taxation to push the housing market up).
These are billion-dollar companies that can buy dozens of buildings at a time.
So while before the rental housing busioness was much more decentralized and more locally owned (with exceptions obviously), now we're seeing big organized international corporate operations coming in and buying up stock and optimizing operations to maximize profits to the maximum extent of local laws, and running things arm's length and without any real thought to the fact that these are people's homes, and probably shouldn't be treated with "maximum efficiency".
Popular tactics such as "renovictions" are used to get rid of rent-protected legacy tenants, and a (literal) fresh coat of paint is applied to old buildings to then rent at "market rates" which just means the maximum the market can bear.
Don't get me wrong, having companies do OSS is much better than having unpaid developers ruining their sleep and coding 4 more hours after their daily shift.
Still, I don't think it's a great reason to not do OSS. I can name soo many projects open sourced by companies where nobody bothered to merge my PRs or answer issues.
The reason I wouldn't open source my business is for a later stage, when I actually have a profitable business and AWS/other giants will clone it and sell it instead of me.
Let anyone read the code and run it but only for testing and hobby purposes.
This would be like offering a trial version with the advantage that people can easily offer tiny fixes and letting people make changes for their particular use cases.
and maybe: https://www.cockroachlabs.com/blog/oss-relicensing-cockroach... "Why We're Relicensing CockroachDB [under the Business Source License]"
Also, the Fair Source license: https://fair.io