A Sad Announcement
omniref.com
omniref.com
According to Crunchbase they had exactly 1 seed round (https://www.crunchbase.com/organization/omniref#/entity) and their project provides a really nice feature for github which is better than githubs existing feature. So I'm perplexed why someone like Github doesn't acquihire them, give them a nice bonus for their work over the last couple of years and add their biological distinctiveness to Github[1]. Or Atlassian integrating it with Jira so that your kanban notes can be attached to code as you're developing a sprint.
[1] Yes that is an old Borg reference.
I wasn't expecting this to be on HN (was kind of hoping for the opposite, actually; I'm not in a mental place where I can write a big, Medium-style, "why my startup failed" missive just yet), so I didn't go into any of this sort of stuff.
The short answer to your question is that companies are bought, not sold. They may seem common, but acquihires are statistically pretty rare, and they usually come with...terms. Which may or may not be good. There's also no guarantee that an acquired product will continue to exist post-acquisition.
Anyway, if enough people are interested, we're considering open-sourcing the annotation tool. I'd like to see that live on.
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.
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.
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.
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.
So honest question - even if you don't feel like maintaining it later, why not open source anyway?
+ 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.
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.
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
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.)
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.
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!
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.
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
More importantly, that was just one feature in a pile of other "must have" features that people said they needed. It was on the roadmap, but we never got around to it.
--
[1] Well, other than perhaps and upload to bitbucket or github and slapping a LICENSE file on it, probably. It shouldn't involve any maintenance or development work, is what I mean.
I did find out about Git notes through this thread, which seems interesting.
My use case isn't anything fancy. I just want to understand what tail is doing behind the scenes with inotify so that I can implement it in another language but I haven't found a rigorous enough outline of tail in pseudo-code to translate it. So now I'm just fighting with it in Vim and VSCode to strip away all the baggage that C forces onto a problem to get to the meat of the actual solution.
I think we all gain when code is more understandable and don't have to individually reverse engineer things to transport the lessons from one code base into another. I thought crowd sourcing the annotation process was an interesting take by Omniref. Maybe it was ahead of its time.
[1] https://www.kernel.org/pub/software/scm/git/docs/git-notes.h...
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 use their obviosuly outstanding work.
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 software tools company is the unwillingness of developers to use hosted tools, particularly if those tools are new and/or different.
When you're a small team, you can only do so many things at once. Supporting hosted users, even in the best-case scenario, takes a lot of time and effort. It's (sometimes) worth it if you can land bigger clients who are willing to pay a premium for that effort, but often those bigger clients won't pay until you have a reputation with smaller teams, or they require lots of custom development that takes even more of your time. So you have a chicken-and-egg problem. It's not impossible to make it work, but it's harder than it should be.
If you're running a small/medium team, try to realize that innovation can only exist in this area if we're willing to support startups when they're younger. I've personally used lots of startups' services over the years for my dev work. Some succeeded, others failed, but trust has never been an issue.
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.
Rather than see this as a fault with developers, perhaps this is an indication that hosted services aren't the best model for development tools. (or really any tools that are "mission critical" to someone's daily operations, whatever they may be.)
For that reason, when I choose dev tools I strongly prefer to stick with open source when it exists, or if purchasing something, a product that is perpetually licensed and runs locally. There are occasional exceptions, but they have to provide some notable benefit from being a service. (Github is a good example)
I get why SaaS is nice from a startup's perspective (not to mention being the trendy thing, and probably what investors expect to see), but if it doesn't work for your customers, maybe it's time to look at other approaches.
This stuff isn't a "trend". It's rational. People who use your software but don't pay you money are not your customers. They're your users. Customers are the users who pay the bills and make you a business.
GitHub is definitely an interesting example. I remember hosting my own SVN and Git servers at companies. It wasn't fun, and GitHub offered an easy-to-use alternative with a nice UI. That's why teams paid for GitHub. But now you can provision a data center with a mouseclick. The market has changed, and with a number of free clones out there, code hosting is becoming a commodity. It's a race to the bottom.
The "notable benefit from being a service" that made GitHub a compelling purchase (i.e. backups, stability, availability etc.) is the same core benefit that any SAAS product offers. But in a world of cheap virtual hosts, it's harder and harder to make that sale. Especially when your closest competitor is your own open-source code.
My point is, it isn't surprising that you'd choose the cheapest tool you can find that does the job. That's what everyone does. But it doesn't make a great business to be offering your source to the world and hoping to differentiate on features. That's why people are trying to thread the needle with "self-hosted" offerings...which cost a lot of money.
Price isn't my main requirement, I'm perfectly willing to invest some cash in a better tool when it exists. I do have some ideological and practical leanings towards open source, but I'm also pragmatic about it and willing to purchase commercial software that provides enough value.
My concern here is about my ongoing right and ability to continue using a tool. Beyond any price I might pay to license it, I am also going to invest time and effort incorporating it into my development process, and would incur significant switching costs to undo, replace, and repeat that when a service provider goes out of business, pivots to a new product, removes features I depend on, raises prices to a point I can't afford, etc...
Open source avoids some of those concerns, and provides me with another option if the others happen; So does a commercial product that I operate myself; But with a hosted service any one of those things can become a "my way or the highway" decision that is forced on me, often with little warning or planning.
"GitHub offered an easy-to-use alternative with a nice UI. That's why teams paid for GitHub....The "notable benefit from being a service" that made GitHub a compelling purchase (i.e. backups, stability, availability etc.) is the same core benefit that any SAAS product offers."
It's an interesting take on our different perspectives that those weren't the things I had in mind at all when I brought up GitHub. I agree those were the draws that got users initially, but as you mention, they have been devalued by technical improvements in their competitors and infrastructure in general. I see GitHub's value now in their huge base of users and "social" features, and the network effects that creates. You can't easily replicate that in a free alternative, even if you were to perfectly clone (or even improve) GitHub's features.
1. Install JVM 8
2. Install GIT
3. Run
The self-hosted model works but it only works for extremely... not simple... but "refined?" setup and deployment procedures. Well bugtested and thoughtout releases. (This includes backups, auto migration, user prompts at startup of dangerious proceedures).
I think that due to this forced side effect of host-your-own that it makes the option preferable. It's harder to do but it proves higher quality control standards and allows for a much much more fail-tolerant archatecture.
I get the feeling that the number of not-so-competent DIY'ers far outweighs the competent ones.
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.
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.
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.
We detached this comment from https://news.ycombinator.com/item?id=13281887 and marked it off-topic.
Edit: the comment was https://news.ycombinator.com/item?id=13282118. My mistake; undetached.
Please keep up the good work forever.