Comepetion run by Sellafield: Standardised robotic control architecture for Sellafield

While I don’t like it either, over the years I’ve come to understand this: consider having a need (whether your own or a client’s) and analysing potential technology to cover that requirement/fill the need.

If you’re looking to acquire technology or base your product on something for the long term, a traditional matrix based evaluation approach typically doesn’t have a column for “could be used if we spend 6 months developing base feature X”, nor a column for “might get this depending on community contributions and/or time in the schedule of the maintainer/developer”.

With quite a few alternative (competing?) technology stacks on the commercial/closed source side (perhaps not for this particular set of requirements, or with a hefty price-tag), and a bunch of other non-functional-requirements (such as the ones mentioned by @mrobinson (ie: licensing, maintenance, operator UX, deployment, integration with existing infrastructure/technology)), is it so strange for companies to make the choice to not use ROS?

IMO, the main difference between commercial software and open-source software in this sort of context:

  • in OSS, a missing feature presents an opportunity to contribute
  • in any other case, a missing feature is reason for dismissal/looking for alternatives

If, as a company, I’m not looking to contribute or become part of an OSS community, why would I consider missing features a feature?

1 Like