Raising money turns a marathon into a sprint.
Raising money turns a marathon into a sprint.
In short, I wanted to accelerate the pace of learning, because if I didn't, I would always kick myself for not stepping on the gas pedal.
I don't regret my decision either TBH.
Another is that I've randomly put credentials in the source code that I don't want leaked (again, my code is an ugly mess full of shortcuts and hacks). Yet another is that it would be impossible for someone to host themselves because I don't even understand it myself.
However, when you're closing shop dumping the code out there for others to figure out how to run, even if you can't help them set up an env from scratch still helps. I also think we need more spaghetti code out there, would help teach new developers how to maintain and refactor "legacy" code.
The credentials in source code thing, I thought by this time would have been a "solved" issue, but I guess some people still yolo it :). Credentials in source code, are the equivalent of password on post it notes ;)
While not the best security, post it notes are immune to hacking and really hard to leak without a home intrusion.
Credentials in source that won't be shared is a pretty efficient hack. Often it happens by mistake - eg. when you hard-code that credential into a bash script during testing when you're trying to curl a new API and then push it by mistake after a coworker asks for you to share your progress on a new branch for review.
I'd love to hear about these "non-obvious" reasons, because I can't say "I'm embarrassed by my code" sounds like a good excuse after convincing people to move to your platform, charging them a subscription for it, then kicking them off with only 60 days notice.
And "I don't think others could figure out how to host it" isn't a reason not to release. It costs nothing but a pretty insignificant amount of time to publish it, so even if it's "impossible" to re-host (and history would say it's not), I really don't see a reason not to let people try.
Sorry again for the confusion
I wish you no ill will, but goodness, talk about an anti-ad for your products.
Creds should be outside the SCM, and there are varying levels of "best practice" - vaults, environment variables of CI servers, text files with strict permissions outside the SCM, etc.
Your tips are true but not very helpful. I know it's bad or I wouldn't call it an ugly mess. I have better practices nowadays regarding credentials but all my projects always spiral out of control some way or another. If it's not this it's something else but I'm never proud of my code.
Freelance projects are bounded by NDA. And my personal projects are bounded by shame.
If I am worrying about credentials, code cleanliness, documentation etc I wouldn't have any time or energy to turn my stream of free flowing ideas into code.
The goal of OSS is not to show off your skills as some elite programmer.
I think the quality/bugginess isn't as much of a factor as the fact that the codebase was not written with the intention of becoming OSS. Things like lack of documentation, hard-coded secrets, inflexible hosting/deployment, etc. are difficult to account for after the fact. And if you ignore these things and just "throw code over the wall", then virtually no one will even look at your code, let alone use it. Kind of a waste of time just to indulge a few self-righteous commenters on some message board, if you ask me.
A lot of OSS software was written with the intention of being open-sourced, so many of the things that make open-sourcing a previously-closed repo difficult are considered upfront.
What's the goal? You make it sound like I have an obligation to do it for some utilitarian reasons, while in reality maybe one or two previous customers would use it while migrating to something else. It's crap software with much better OSS alternatives already.
It either dies with me or dies as an abandoned repo I need to be ashamed of.
Reimplementation saps alot of productivity from the economy.
Ethically, however, it doesn't really check out for me. If the software is a core part of your business and the (or one of the) primary reasons an investor has joined your business then it's at the very least a bait and switch to make such a decision without their involvement. To a big VC or private equity firm this may infuriate some but have little monetary impact; at a much smaller firm this could be highly damaging.
I'm also fairly certain that whatever harm comes from this decision would put the CEO in personal liability, potentially all the way up the decision chain.
Would it? Don't owners of companies general cede day-to-day business decisions to those running the company (i.e. the CEO)?
The issue is that shareholders literally own the property owned by the company, that's what it means to be a shareholder. Including intellectual property.
Announcing you are shutting down a company, and then, without board approval, the CEO giving away what assets remain... is super sketchy and probably illegal, probably stealing from the shareholders (or even more likely other creditors, if they exist), who would probably like to partially recoup their losses from sales of any remaining assets. What those assets are you are giving away are, say, a fleet of cars, or the intellectual property of source code, legally the same.
Imagine if a car service company announced it was shutting down, and then gave away all it's cars, instead of selling them in an orderly fashion and distributing profits to anyone who was owed money, including creditors and shareholders.
Given that with a company going out of business a lot of people are going to be losing money and wanting to get what they can out of any assets... the time to release as open source is really before you go out of business.
A noble thought, but then what? skeleton crew the business at a snails pace while still being unclear how to actually make money?