Open-source projects take a lot of time and effort to do well. They're kind of like startups in themselves, actually. And in this kind of situation, you're committing to publicly maintaining the thing that you're trying to shut down.
If there isn't enough interest at the start, it's just prolonging the pain of failure. It's better to rip the bandage off and move forward with your life.
I totally agree that maintaining it as open source will take a lot of time and effort.
What platform is Omniref written in? I'm interested in exploring adding it as a feature of our GitLab. But there has to be enough interest and the tooling should match (we use Ruby, Go, and elastic search).
We can pay for the effort required. And the lessons you learned will live on. Although I would totally understand if your priorities are different.
If gitlab.com had something like this as a paid tier and I could do annotations on basically everything in the repo (directories etc). I'd pay for my team to use it. I say gitlab.com because I just don't want to deal with hosting right now.
Not sure if this is the right issue tracker, but GitLab has an organization issue tracker[1]. Creating an issue there would also enhance discussion because of notifications etc.
>Open-source projects take a lot of time and effort to do well.
This might sound mean, but I don't intend it that way: you've already "failed" as a business, so there's no reason to hold yourself to a high standard in the open-source department.
You can totally just drop a code blob on Github and let folks fork it and start organizing to maintain it themselves--it's not like you have anything to lose, and somebody might even find it useful some day.
It's weird to me that people have that hangup about releasing code...if people don't like it, they just won't use it.
Have you done this yourself? I'm curious whether it's something that sounds good in theory until you've been up against the decision yourself, or if it's just a "different strokes for different folks" situation.
It isn't weird to me at all. I would much rather move on with my life than constantly feel bad about the unusable state of a blob of yucky never-designed-to-be-open-source code I just dumped on GitHub.
Almost all the code I write is up on my Github with an appropriate license. Almost all of it nobody really cares about, barring a couple of projects with forks and even some pull requests which I get to as I have time.
The thing is that, for products, abandoned code is strictly better than no code. We see this all the time with games--classic games only get supported once their source is released. The same is true for non-game software.
People who turn up their nose at "yucky" code that works or shipped are not worth considering in the same league as the folks that actually built something. Real artists ship, everything else is just people wanking about best practices.
I don't understand why. Strip credentials from your source, dump it on GitHub. It may or may not get picked up by someone else, but this in itself is already better than having the project die. It also doesn't make you committed to anything.
So honest question - even if you don't feel like maintaining it later, why not open source anyway?
I shut my startup and open-sourced our code. But it was hard, very hard.
It takes a significant effort at a time when you've just expended all the effort you have in trying to get funding or a future.
First you need to go through your entire code and ask: What code or assets were acquired under a license that prohibits open-sourcing or re-licensing? This may be a library, or it may be a paid-for webfont, or it may be licensed photos or UI packages. For every one identified, you now need to find an alternative that can be used and implement it before you can open source and remove reference to the old before you open source.
Then there is the documentation, whilst you have a small team of a couple of people who intimately know the code you probably focused more on shipping than documenting. To open source really asks for the documentation more than the shipping... the ability to survive as an open source project isn't just about providing value it is to deliver that value in a way that people can access which means documentation.
Then there is the structure and organisation of the code. The finest example of this is that you probably aimed at the sky and have built a multi-tenant SaaS platform in which most components can scale independently of the others. This stuff is complex to deploy and run, but that's OK as you're probably running only 1 to 3 instances in total. But someone who is a user of your software cares not about this, and just wants it to work for a single tenant with a super-simple deploy process to get started. It is really hard to take a "built for SaaS in a single environment (AWS)" and make it a "built for someone to deploy wherever" thing.
All of the above add up to months worth of time and effort. Time when you're looking at your bank balance and realising that you need a job to avoid being homeless. Time that you simply don't have, and effort that is best focused on finding a job.
When your startup dies, there is certainly a lot that could be open-sourced, but unless you spent the last few months of the startup life working towards that... it is the lowest priority thing you can do.
What you should do when your startup fails:
#1 Focus on you, your health and state of mind. See friends, eat well, exercise, get out of the city if you can.
#2 Get a job. You're super valuable right now and you're in demand. You can build product, manage a team, probably code, and you really should get money in so that you have security and stability you probably haven't had for a while.
Take time, recover.
Worry about open-sourcing, or starting the next new thing, in the future. When your startup fails, now is for you to recover.
Edit: And open-sourcing makes a huge assumption that your investors (who own the rights to a chunk of this stuff) even agree that you can just give away what they invested in.
Apart from stripping licensed code, none of that is necessary it's just nice. Nor does it have to be finished before you release the code, so there's no reason you can't go back and clean it up later.
The code dump may not be usable without significant effort, but having it available is still better than not having it.
Even just throwing it out there with things stripped and it not working is not an end.
Then come the emails asking how to get it working, why certain things are as they are.
Most founders and creators care, so these emails are hard to ignore, and you want it be a success (otherwise you wouldn't have worked on it or then opened it) and so now you're shackled to having to document piecemeal, to many individuals, most of whom are not serious about doing anything as they are just kicking tyres.
Most interested parties in open-source projects are companies that could have been customers but didn't want to pay, and now it's free they want it without paying, and also won't invest in the time to get it working.
It's a huge burden to open source a whole project rather than just a library.
And as the OP said:
> If there isn't enough interest at the start, it's just prolonging the pain of failure. It's better to rip the bandage off and move forward with your life.
> It's a huge burden to open source a whole project rather than just a library.
None of that is a burden. There is no responsibility and this INCESSANT claim, is everywhere (used across all manner of projects for decades, specifically by MS or MS acquisitions) without basis.
> so now you're shackled to having to document piecemeal
That just sounds like you cant trust yourself to make good decisions, again? JUST DONT. You ripped off the band-aid. PROBLEM SOLVED. But that doesn't happen, traditionally we just get these nods about how "tough" OS projects are which makes no sense, since you are already washing your hands of it somehow the OS project you HAVE to handle? Instead, it's much more likely that people are afraid of criticism, which has never been borne out in the wild..."but we don't want to be compared to DOOM's sourcecode quality".
> won't invest in the time to get it working.
That's a personal choice. Reading how software works and looking at design, is part of the value. Getting it to "work" is ancillary. SMH
Except for the licenses (and in a perfect world, most of the work about them should have been done already while the project was private), you don't have to do any of these things, they are just bonuses. What do you think many open-source projects look like? and most of those personal but open-source projects which are on Github?
> Edit: And open-sourcing makes a huge assumption that your investors (who own the rights to a chunk of this stuff) even agree that you can just give away what they invested in.
Interesting point. Is it really accurate? I mean, if investors to a company literally have partial ownership of the company's IP, does it also mean that the company cannot decide to open-source part of its code (i.e., license away part of the company's IP rights), or license code to a third party, without the approval of its investors?
(Not a rhetorical question, but a legitimate question.)
Shareholders own the assets at the time the company is wound-up, those assets include the code and IP.
It may be that as a founder and at an early stage, that you own the majority of those assets but you are still exposing yourself to a bit of a legal nightmare if you assume that majority ownership gives you the right to dispose of it as you see fit. If any investor could argue that you can sell the IP for any price that would offer them a return, it's going to be risky.
In my case, my seed investors were users of the software we created. They wanted the software to be available and so it was all fairly easy, but I was well aware that there was a huge risk there. I probably would not have opened anything if they had said no.
I totally agree with your posts here (and thank you for writing up so many details on this!), but you probably have to do due-diligence on selling the IP for some return for your investors anyway, so I think we're really talking about the situation where that has already come up zeros.
Disposing of the property of a company requires management, then board, then shareholder consent. According to provisions set out in a company's bylaws or operating agreement. Or maybe a court order in a bankruptcy proceeding.
Think of it this way...
Setup: An investor bought 20% of the shares of your company. You and a co-founder have 30% each and the employees have 20% in semi-vested stock options. You have $10,000 in vendor-related debt, a lease on your space, some computers, some software, and $2500 in the bank. You are not going to make another payroll.
Under no circumstances can you, as the founder, with all these people who have various claims on the company can go give that $2500 in the bank to a homeless person you just met on the street. Or to a church. Or, if you already know you are hitting the wall, throwing a big going-away party for the employees.
Software is the same. It's a company asset. You are not a solo flier. It belongs to the company - not to you. You are only one of the several (or many) stakeholders -- including the landlord!
> They're kind of like startups in themselves, actually
Not necessarily - just mention that the project is abandonware/looking for a new maintainer. Having access to the code will be helpful to anyone looking to move forward or build on it without tying you down, and anyone who finds a workable model can benefit from your fork.
Just want to throw in some support for what nebabyte said here. The community can be super kind towards this kind of thing. Also, I'm guessing you already have documentation on usage a plenty that you created via the original site so it wouldn't be unusable.
I know this also might be too soon to think about so do take your time to come to a better place mentally before considering it :). Good luck with whatever the future holds! I sincerely hope things get better for you
Similar to sytse, I'd be interested in an open source release as well, especially if it's in Python (with an eye toward possibly integrating it into the open source annotation server http://hypothes.is), though unlike sytse I don't have any funds to spend on it, so would be satisfied with a clean code release.
If there isn't enough interest at the start, it's just prolonging the pain of failure. It's better to rip the bandage off and move forward with your life.