home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,258 of 264,096   
   Dan Cross to arne@vajhoej.dk   
   Re: Staying on OpenVMS or Migrating to L   
   07 Sep 25 13:05:33   
   
   From: cross@spitfire.i.gajendra.net   
      
   In article <109fa1s$2hamk$2@dont-email.me>,   
   Arne Vajhøj   wrote:   
   >On 9/5/2025 11:00 AM, Dan Cross wrote:   
   >> In article <109em8t$2dg49$1@dont-email.me>,   
   >> Arne Vajhøj   wrote:   
   >>> On 9/5/2025 7:37 AM, Dan Cross wrote:   
   >>>> In article <109d9l6$2298n$2@dont-email.me>,   
   >>>> Arne Vajhøj   wrote:   
   >>>>> On 9/4/2025 11:53 AM, Dan Cross wrote:   
   >>>>>> In article <109c9pn$1r966$1@dont-email.me>,   
   >>>>>> Dave Froble   wrote:   
   >>>>>>> On 8/29/2025 2:59 PM, Simon Clubley wrote:   
   >>>>>>>> This assumes of course that VSI does not go bust and that you now   
   >>>>>>>> have to port away from VMS before your time-limited production   
   >>>>>>>> licences expire.   
   >>>>>>>>   
   >>>>>>>> That possibility may become the major factor in whether you stay   
   >>>>>>>> on VMS or not.   
   >>>>>>>   
   >>>>>>> Simon, if the world ran on "what ifs" and such, nothing would ever get   
   done.   
   >>>>>>   
   >>>>>> Risk analysis is a common and essential part of running a   
   >>>>>> business.  Responsible folks across many different fields   
   >>>>>> reasonably ask "what if?" questions all the time as part of   
   >>>>>> doing their job, and plenty of stuff still gets done,   
   >>>>>> regardless.   
   >>>>>   
   >>>>>>> Yes, there are possibilities, and VSI isn't the most secure   
   >>>>>>> choice, but what is?  Hate to break it to you, but you are spreading   
   FUD.   
   >>>>>>>   
   >>>>>>> Perhaps deal with "what is", and if that changes, then just "handle   
   it".   
   >>>>>>   
   >>>>>> It is not only reasonable to evaluate the risk tradeoffs   
   >>>>>> involved, I would argue that it is madatory for a responsible   
   >>>>>> professional.  The best response   
   >>>>>>   
   >>>>>> Reflexively shutting someone down by accusing them of spreading   
   >>>>>> FUD isn't useful when people raise legitimate concerns about the   
   >>>>>> future of VMS, and Simon raised a very legitimate concern: the   
   >>>>>> probability that VSI would go under and VMS disappear in a   
   >>>>>> flurry of lawsuits is much, much higher than the probability   
   >>>>>> that Linux is going to disappear any time in the next century.   
   >>>>>>   
   >>>>>> Surely this must weigh on the minds of folks in charge of making   
   >>>>>> technology and purchasing decisions, and so dismissing those   
   >>>>>> concerns out of hand is not helpful.  Instead, lobbying VSI to   
   >>>>>> address them and put in place assurances would be a more useful   
   >>>>>> response if one wants to keep seeing VMS available.   
   >>>>>   
   >>>>> But at this point in time there really is no reason to believe   
   >>>>> that VSI would go bust as described.   
   >>>>>   
   >>>>> It has a revenue stream.   
   >>>>   
   >>>> That's true, but that's not the point.  As Simon pointed out, it   
   >>>> is the perception that matters, not just the reality.   
   >>>>   
   >>>> And further, we're talking about relative risk here: while it   
   >>>> may not feel particularly risky at present to rely on VSI, it is   
   >>>> undeniable that it is _more_ risky than the alternatives.   
   >>>>   
   >>>>> VMS x86-64 and compilers and almost all layered products are   
   >>>>> available for VMS x86-64. VMS does not have any huge "must have"   
   >>>>> cost items lined up.   
   >>>>>   
   >>>>> That means that just mediocre business abilities will   
   >>>>> prevent VSI from going bust.   
   >>>>>   
   >>>>> Just adjust development level to what the revenue stream   
   >>>>> can support.   
   >>>>   
   >>>> While VSI _does_ have a revenue stream, it's very small, and it   
   >>>> is unclear how it is spread across customers: it could be one or   
   >>>> two large customers that are subsidizing the rest; if one of   
   >>>> those large customers migrates off of VMS, that could be   
   >>>> catastrophic for the organization.  Caveat that I don't know   
   >>>> whether that's the case or not, but that's also part of the   
   >>>> point: it's unclear, and therefore, the risk is greater.  That   
   >>>> is, having some metric of revenue diversification for a vendor   
   >>>> is an essential part of doing adequate risk analysis.   
   >>>>   
   >>>>> Of course VSI management could do something totally   
   >>>>> crazy - borrow 100 million and invest in an unknown   
   >>>>> crypto currency or hire 200 engineers to make systemd   
   >>>>> run on VMS or whatever.   
   >>>>>   
   >>>>> But most companies would go bust if management do   
   >>>>> sufficiently crazy stuff.   
   >>>>   
   >>>> I don't think anyone is worried about VSI making a bad pivot.   
   >>>>   
   >>>> In fact, I don't think anyone is particularly worried about   
   >>>> _VSI_ doing anything to screw things up themselves.  It's rather   
   >>>> worry that the market around them can change subtly but in ways   
   >>>> that are significant vis VMS's customer base, and thus VSI's   
   >>>> overall health.   
   >>>>   
   >>>>> Bottom line is that at this time the risk of VSI   
   >>>>> going bust is similar to most other companies.   
   >>>>   
   >>>> Absolutely not.  VSI is a small company with a small revenue   
   >>>> stream and a small (and ultimately decreasing) number of   
   >>>> customers.  This is qualitatively and quantitatively different   
   >>>> than a large organization with a large and diverse revenue   
   >>>> stream spread across many customers.  The VMS market is not   
   >>>> growing; we have no idea how diverse the existing customer   
   >>>> portfolio is.  To assert that the risk profile is the same as   
   >>>> "most other companies" is simply untrue.   
   >>>   
   >>> I think this is exactly what Dave was talking about.   
   >>   
   >> I think you should let Dave speak for himself.   
   >   
   >I did not speak for David. I was speaking for myself.   
   >   
   >*I* think that what you wrote matches what David described.   
      
   Ok.   
      
   >>> Very generic, "something could happen", lots of   
   >>> handwaving.   
   >>>   
   >>> Instead of looking at specifics, what risks there are   
   >>> and whether VSI management can handle those if they   
   >>> materialize.   
   >>>   
   >>> Given that those topics are already covered in detail   
   >>> in the thread then the generic something could happen   
   >>> is indeed FUD.   
   >>   
   >> Please point to the place where these concerns are "covered in   
   >> detail in the thread".  I submit that they were not.   
   >>   
   >> The closest I can find is when you wrote something along the   
   >> lines of, "number employees < annual revenue / average employee   
   >> cost will keep them over water."  But this fails to account for   
   >> how "annual revenue" can change and how quickly, and there is   
   >> insufficient data publicly available to make _any_ assumption   
   >> about that.  "number of employees < annual revenue / average   
   >> employee cost" is what's really generic handwaving.   
   >   
   >No that is a very simple business model that will prevent   
   >VSI from going bust.   
      
   s/simple/simplistic/   
      
   So where were "those topics [are] already covered in detail in   
   the thread"?  There are no details there.   
      
   >And VMS revenue stream is not that uncertain. We have   
   >seen the decline rate over a couple of decades when   
   >it was on a doomed platform. Now it is on a platform   
   >with a future.   
   >   
   >I consider it a reasonable assumption that attrition rate   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca