[HN Gopher] Dyalog: Escrow
___________________________________________________________________
Dyalog: Escrow
Author : tosh
Score : 62 points
Date : 2022-10-26 13:30 UTC (9 hours ago)
(HTM) web link (www.dyalog.com)
(TXT) w3m dump (www.dyalog.com)
| hoosieree wrote:
| That's pretty neat. Like a will to specify who gets your stuff
| after you die, but for a company/customer relationship instead.
| jbirer wrote:
| You need to set up a working HTTPS certificate, if you want to
| estabilish any sort of trust or credibility.
| abrudz wrote:
| Not sure why topic link isn't https://www.dyalog.com/escrow.htm
| (which does have a working certificate).
| tyho wrote:
| Because Dyalog have failed to implement a HTTP->HTTPS
| redirect. Without this you rely on all your users
| understanding the difference between HTTP and HTTPS. Most
| don't and links to the HTTP version of your site will
| proliferate.
| travisjungroth wrote:
| Pretty sure there are people out there trusting Dyalog.
| Dave3of5 wrote:
| Isn't working for me anymore, hug of death ?
| GNOMES wrote:
| Is this just an Escrow Live rebrand?
| lemax wrote:
| These are a nice way to show larger companies you want to work
| with that you've made long term considerations for the
| sustainability of your software. We've brought this sort of thing
| up later in deal cycles if prospects have concerns over company
| future. We have contract clauses ready if they want to
| participate in the code escrow and many are happy to pay to join
| on as a beneficiary if we shut doors or discontinue our product.
|
| In practice though, code escrows are kind of fraught with issues
| -- deposited source code that doesn't compile, out of date, etc.
| It's up to vendors to deposit working materials, as there isn't
| usually any kind of audit process. I can't imagine the costs and
| time it would take to pick up a vendor's source code, staff some
| maintainers, and get them efficient. Enterprise customers are
| usually shopping by requirements, not underlying tech, so they
| are likely not even aware of the tech they would need to hire
| for.
| abrudz wrote:
| I don't know how others do it, but Dyalog puts _everything_
| necessary to build a fully functioning product on each escrow
| hard disk. So the only other thing necessary is a computer that
| can connect to the disk. Source: I work at Dyalog.
| jxy wrote:
| Does it include a fully bootable OS? Or does it include a
| libc? Or does it include a compiler and necessary libraries?
| Does the disk need a specific OS to read it?
|
| I guess I'm asking what happens when you "connect" "a
| computer" to "the disk".
| szundi wrote:
| What if the computer is an Amiga? Or the Apollo 13
| computer?
| binarymax wrote:
| This used to be somewhat common, before opensource really took
| off. I worked for 2 different companies in the late 90's early
| 00's that had everything in escrow as certain customers demanded
| it.
| thewellis2 wrote:
| I recall working on a project a few years ago that had it in
| place. The end client was a hundred year old company, with
| bricks and mortar stores, that needed a boring, stable solution
| that had several key features. They would take only the older
| version that we built for the escrow, so that if things went
| sour they had a workign solution that they would have the
| source-code for that could be given to another company.
|
| On the one hand it was a pain to work towards, as the
| requirements had little immediate value (new features needed
| lengthy documentation, lots of features had to be stripped out,
| long (manual) test checklists, etc) but on the other hand, it
| got you thinking about how to build software that would need to
| last longer than the company you're in. Made me realise that
| feature creep/bloat was what was holding the product back, not
| the Next Big Thing(tm).
| nivertech wrote:
| Can you imagine putting a modern
| JS/react/node/npm/webpack/bun/etc. based software in escrow like
| this?
|
| There is so much software rot in this ecosystem that in a several
| months it will be practically useless.
| igrekel wrote:
| Yes of course. An escrow is required for many contracts,
| especially for government subsidiaries. We have a SaaS service
| (a complex environment including a react front end) and still
| use an escrow service. A lot of it relies on docker images.
| nivertech wrote:
| Do you build this docker images by yourself, or they're pre-
| built/fetched from container registry? What about public npm
| packages?
| superjan wrote:
| Maybe it is no longer safe to put in production but it would
| still be useful to start with something that works.
| sramam wrote:
| This was my first thought as well.
|
| I think the use-case for this is when the customer has not or
| is unwilling to upgrade from a "working version".
|
| Having the ability to take ownership of that "working version"
| for their business continuity reasons can be invaluable.
|
| Not sure how reliable this statistic[1] is, but a quick search
| yielded jQuery still has 11% of the market share.
| Interestingly, "websites added" > "websites dropped"!!!
|
| [1] https://www.slintel.com/tech/programming-framework/jquery-
| ma...
|
| PS: I have nothing but praise for jQuery and it's positive
| impact in the web world. However, given its age, seemed like a
| good example to illustrate the point.
| owgevub wrote:
| I inherited a library's source code via an escrow process back in
| the 90s when the vendor went out of business. It was written in C
| and came with no documentation. It took a while to get the thing
| to build and understand where all the pieces were, but it wasn't
| too bad after that initial ramp up. I ended up maintaining that
| code for many years, doing everything from porting from x.25 to
| tcp/ip to making changes to the application layer protocol to
| keep up with industry changes.
|
| My favorite memory was a comment I found buried in an exception
| handling section of code: /* We would like to think that this
| would work well */
|
| All in all, the escrow process was worth it for us as it was a
| critical piece of functionality that would have been difficult to
| replace otherwise.
| cryptonector wrote:
| I also inherited (as developer and maintainer at the customer
| that actually inherited it) a product via source code escrow.
|
| Source code escrow is a very good idea for a startup selling
| proprietary software.
| dannyw wrote:
| https://web.archive.org/web/20221026133106/www.dyalog.com/es...
| travisjungroth wrote:
| I wonder if there's a way to do something similar but with a
| deadman's switch. Escrow is a great solution, but kind of
| expensive.
|
| On another point:
|
| > in the unlikely event that we become unable to continue to
| service our customers
|
| Maybe there's a second condition I'm missing here, but becoming
| unable to continue to service your customers is an incredibly
| _likely_ event. The only alternatives are losing every single
| customer or existing as a business until the end of time. I 'd
| put the probability of losing every customer as < 1/100 and of
| continuing until the end of time at 0. So 99% that this is the
| outcome. Again, maybe some alternative I'm missing.
| electroly wrote:
| "Losing every single customer" doesn't have to be as dramatic
| or unlikely as you make it sound. Consider the possibility that
| they could introduce a new product that supersedes the current
| one and they stop adding new features to the old product, and
| all customers eventually switch over. The old product has lost
| all of its customers, but it's just because they switched
| products. The escrow deal here is for the specific product,
| Dyalog APL. It wouldn't cover Dyalog NewThing. In this
| situation, the escrow never pays out.
| travisjungroth wrote:
| I wasn't talking about the payout, but about the quote.
| throwoutway wrote:
| Apparently NCC Group does this a lot. What does something like
| this cost?
| lemax wrote:
| Around $4k to $10k depending on the number of beneficiaries.
| Each beneficiary enters into their own agreement with your
| company and NCC group, and then there is an overarching
| agreement between your company and NCC. There is a cost
| associated with initial setup between you and NCC, and then
| each beneficiary pays a bit too (you can pass on this cost to
| them if you like).
|
| Source: just worked with them
| iffycan wrote:
| I'm not finding it on their website. Do they have a "release
| as open source" option?
| lemax wrote:
| I'm referring to NCC group's pricing, not Dyalog
| webmobdev wrote:
| There should be should be a legislation for this - when a closed
| source software reaches EOL or is abandoned or the company that
| created it shuts down, the source code of the application should
| be made public.
| TeMPOraL wrote:
| The unfortunate counter to that is, "we can't release the
| source code as significant parts of it are still [used in / IP
| relevant to] the [maintained / new / upcoming] product".
|
| This is why the third party 'pasc1878 suggests isn't enough -
| changes to standard practice, and likely to IP laws themselves,
| are needed too, which are unlikely to happen without regulatory
| pressure.
| webmobdev wrote:
| Yes, copyright laws for code will need to be tweaked. There's
| also the issue that some countries don't recognise software
| patents.
| pasc1878 wrote:
| How do you implement this. When a company dies you can't access
| its servewrs etc.
|
| Which is why in the contract you have with the software company
| you include having them put the code in escrow with a third
| party.
|
| The third party is necessary
| webmobdev wrote:
| Sure, a third-party is required. What I meant is that there
| should be a law forcing software companies to commit their
| source code to such kind of third-party services (government
| or private run) so that closed source code can be open
| sourced after certain conditions are fulfilled.
| nudpiedo wrote:
| it solves one of the biggest fears against closed software,
| however nowadays also companies want engineers already to be
| pretrained in the exactly same area of the topic.
| pelagicAustral wrote:
| I like this option a lot, although, Most companies would unlikely
| be able to implement something like this, solely on account of
| third-party dependencies.
___________________________________________________________________
(page generated 2022-10-26 23:01 UTC)