4 ms·

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 co

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 use their obviosuly outstanding work.

jzelinskie 10y ago
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).
- gravypod 10y ago
  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 also supports transfering the internal DB to other systems. 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.
  - dceddia 10y ago
    I think part of the problem is that for every person like you (competent DIY'er) there are N people who don't really know how to do those 3 steps, but for whatever reason (budget, fear of SaaS, etc) decide to host the thing in-house. Those are the ones that become a support nightmare. I get the feeling that the number of not-so-competent DIY'ers far outweighs the competent ones.
  - jpalomaki 10y ago
    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 application logic, but the update procedures. 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.
    - gravypod 10y ago
      > 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.
- tonyedgecombe 10y ago
  It's really not that difficult, many of us have been developing applications that customers download and install themselves for years.
timr 10y ago
"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 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.
- Sanddancer 10y ago
  Yes, because tools hosted elsewhere have the problem your shutdown is exemplifying. A definite expiration date /sucks/. Even if it is a month out, that means having to do a lot of retooling to pull out all the bits and pieces that have been built in that rely on the third party. Were it a hosted solution, a transition plan could be made that isn't a mad rush to make sure all the data that's in those annotations is saved once the lights go out.
  - deleted 10y ago
    [deleted]
- gravypod 10y ago
  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.

jzelinskie 10y ago

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

gravypod 10y ago
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 also supports transfering the internal DB to other systems. 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.
- dceddia 10y ago
  I think part of the problem is that for every person like you (competent DIY'er) there are N people who don't really know how to do those 3 steps, but for whatever reason (budget, fear of SaaS, etc) decide to host the thing in-house. Those are the ones that become a support nightmare. I get the feeling that the number of not-so-competent DIY'ers far outweighs the competent ones.
- jpalomaki 10y ago
  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 application logic, but the update procedures. 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.
  - gravypod 10y ago
    > 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.
tonyedgecombe 10y ago
It's really not that difficult, many of us have been developing applications that customers download and install themselves for years.

timr 10y ago

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

Sanddancer 10y ago
Yes, because tools hosted elsewhere have the problem your shutdown is exemplifying. A definite expiration date /sucks/. Even if it is a month out, that means having to do a lot of retooling to pull out all the bits and pieces that have been built in that rely on the third party. Were it a hosted solution, a transition plan could be made that isn't a mad rush to make sure all the data that's in those annotations is saved once the lights go out.
- deleted 10y ago
  [deleted]
gravypod 10y ago
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.