Live data from Hacker News

A Sad Announcement

omniref.com

41–50 of 78 posts

Re: A Sad Announcement

#41
post #16

Earlier quoted context omitted.

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 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?

+ Licenses

+ Documentation

+ Structure and organisation

+ Time and effort

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.

Re: A Sad Announcement

#42
post #41

Earlier quoted context omitted.

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?

+ Licenses + Documentation + Structure and organisation + Time and effort 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-licen…

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.

Re: A Sad Announcement

#43
post #41

Earlier quoted context omitted.

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?

+ Licenses + Documentation + Structure and organisation + Time and effort 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-licen…

> 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.)

Re: A Sad Announcement

#44
post #7

This is why I think no one should trust companies that sell you software, that you can't host yourself, for something as critical as documentation and source control. I feel really bad for all the companies that have to jump through hoops to get their data rescued from this company. It also sucks to loose such a smart company. I wish they had built their solutions as a self hosted system so that people could still us…

The reason why you see startups avoiding this model is because supporting self hosted solutions is extremely difficult as a small team and only impedes the ability to evolve your product. It's a shame, but companies shouldn't adopt products if they lack a feature requirement (data migration).

It's really not that difficult, many of us have been developing applications that customers download and install themselves for years.

Re: A Sad Announcement

#45
post #43
post #41

Earlier quoted context omitted.

+ Licenses + Documentation + Structure and organisation + Time and effort 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-licen…

> 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…

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.

Re: A Sad Announcement

#46
post #41

Earlier quoted context omitted.

+ Licenses + Documentation + Structure and organisation + Time and effort 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-licen…

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.

Open sourcing is a burden.

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.

Re: A Sad Announcement

#47
Stupid question: what does Omniref do that can't be done with source code comments? Comments are readable by anyone in any editor and do not require external tools. They are co-located to the relevant lines of code by being part of the source, and are as portable as the code itself. My first impression is that it is a solution seeking a problem.

Re: A Sad Announcement

#48

Earlier quoted context omitted.

This is only the case for complicated deployment proceedures. One of my favorite pieces of software that I love updating is a project called GitBucket. It's a GitHub/BitBucket-esq site. It's simple to host and easy to use without much overhead. The deployment procedures go as follow: 1. Install JVM 8 2. Install GIT 3. Run If you aren't running a database it defaults to the internal one. All the defaults are sane. It…

All this quality control comes with a cost. If you for example start supporting external databases you probably need to support at least few of those to cover what customers are likely already running. For each database there's no single version that everybody is using, instead you have at least two versions running. 3 databases with 2 versions each means already 6 different combinations to test on. And not just the…

> For each database there's no single version that everybody is using, instead you have at least two versions running. 3 databases with 2 versions each means already 6 different combinations to test on. And not just the application logic, but the update procedures

So... use an ORM? That's what we should have been doing in the first place.

> One big problem is that if something goes wrong in the customer side, debugging those issues is really time consuming. And things do go wrong. Most of the time you are probably solving issues that are not really your problems at all. Customer don't follow the installation instructions, the environment is not like it is supposed to be, customers tinker with things they are not supposed to tinker with. How do you handle this support in practise. Are your software engineers willing to spend the time on the phone, maybe with customers in different time zones. Do they have the administration expertise for those operating systems and databases the application supports so that they feel comfortable guiding customers over the phone.

Provide it as an enterprise feature. Charge 100$/hr of debugging or provide the hosting yourself. The option to self host has to be there just in case you die so you'd only switch over to self-hosted (in most cases) if the company did die but you still needed the tooling.

Also, with docker this isn't as much of an issue. Just write a docker file and boom it's up and running.

> Then there is the question that do you get good enough compensation for all this compared to just offering the SaaS solution. Just the additional hands-on support given to customer quickly eats your profits from the monthly fees charged from customer. All the time spend on creating installation and update procedures, testing those and giving support to customers is away from putting up new great features. On the other hand, being able to offer the on-site version can be of course a great competitive advantage.

If you charge 100$/hr for setup, support, and maitnence yes it's very profitable. Look at the DBA world.

Re: A Sad Announcement

#49
post #12
post #7

This is why I think no one should trust companies that sell you software, that you can't host yourself, for something as critical as documentation and source control. I feel really bad for all the companies that have to jump through hoops to get their data rescued from this company. It also sucks to loose such a smart company. I wish they had built their solutions as a self hosted system so that people could still us…

"This is why I think no one should trust companies that sell you software, that you can't host yourself, for something as critical as documentation and source control." Omniref founder here. Please try not to think this way, particularly if you're a small team. I realize that this is kind of an impossible request (especially given the source), but one of the things that makes it immensely difficult to start a softwar…

What format will the data be in? Will it be given in a format usable as the way your service provided? That either speaks to the fact that the service wasn't needed (which doesn't sound right) or that the users will need to do a lot of sword sharpening to fix the gap in their tooling now that you are gone.

In effect, people are going to miss you.

Also, for the kind of work that some people do it's impossible to use any outbound network stuff that looks at the source code. That's off the table. That's also a huge client base.

Post reply on HN