Ricoh policy on feedback to community feature requests and firmware updates

Ricoh Hardware and Software
1

I would like to raise some general points for the attention of Ricoh development teams.

I realize roadmaps are always sensitive and I do not expect public visibility of upcoming new product releases. However setting expectations on the scope of upcoming firmware releases (bug fixes and feature adds) in existing product is perfectly reasonable I think.

So, when a feature request is raised (e.g. BT audio input), after Ricoh consideration and decision to address, a simple acknowledgement note as feedback to the community would go a long way. Something like: “We acknowledge this is a relevant feature and are currently investigating/developing for an upcoming firmware release. More details will follow in due course.” The same applies for identified bugs/bug fixes.

Failure to do this leaves people hanging and in the dark without knowing if it is on the Ricoh development list or not. Worse still, some may spend their own development efforts to add the feature themselves in a plugin, only for this to be made redundant when suddenly a new firmware update is released adding the feature.

Related to the above is the matter of beta releases for developers. Mature platform owners provide firmware update pre-release betas to their developer community. This allows developers to test their own existing apps/plugins against the new firmware to ensure nothing is broken. If problems are found, it allows a development/test window where both parties have the opportunity to adjust software to maximise interoperability. Without such beta releases, there is a real risk that commercial customers see broken software and services or performance impacts. I am aware of a specific case where this has happened with a Ricoh plugin.

The above are established ways to help build community, engagement and trust. I would welcome more transparency to the community on such matters. Many thanks Ricoh for your consideration.

1 Like
2

@gthomas thanks for taking the time to start up this discussion.

I’ll work with @jcasman to raise this discussion with managers at RICOH.

One thing that we can do is find examples of how other companies are communicating regarding feature requests, beta releases and bug fixes.

If there are examples on the process followed by other large companies, then we can post them here.

3

https://beta.apple.com/sp/betaprogram

1 Like
4

@gthomas , thank you for your research and posting these three links.

@jcasman , let’s aim to read through the information and summarize the main points for discussion with your contact at ricoh.

1 Like
5

@gthomas and @craig I’m doing this now, intend to share with RICOH this week. Thanks, Gavin.

6

As Android is a huge developer community, it would be good to find some other examples where the developer community is smaller.

Maybe like a Garmin watch?

Matterport

7

Ok, but lets not lose sight of the points I raised initially. Fundamentally what I am stressing is…Ricoh lets hear some more from you :wink:

1 Like
8

@jcasman I believe that the main point was summarized in this section.

Related to the above is the matter of beta releases for developers. Mature platform owners provide firmware update pre-release betas to their developer community. This allows developers to test their own existing apps/plugins against the new firmware to ensure nothing is broken. If problems are found, it allows a development/test window where both parties have the opportunity to adjust software to maximise interoperability. Without such beta releases, there is a real risk that commercial customers see broken software and services or performance impacts. I am aware of a specific case where this has happened with a Ricoh plugin.

@jcasman , also remember that there is no way for developers to install beta firmware on their own. There’s no way to just make it available through the desktop app. In addition to the legal work on beta licenses and beta program agreement, there would also need to be a modification to the upgrade utility or a new utility would have be created.

Basically, even if we recommend that beta firmware be shared with developers in a “beta” program, we would still need to make achievable recommendations on the distribution process.

See this information on a beta software release for the SC2.

See the process here:

Note that the SC2 is running a different internal OS from the X and Z1. Thus, I don’t know if the beta upgrade process would be the same.

9

@craig , @jcasman one more notice on my end: there was an earlier firmware for Ricoh Theta Z1, that was actually performing better with my live streaming plugin. In same environment it was streaming much longer than this latest firmware. So it would be really important if could try and revert a firmware upgrade as it can really cause some plugins work less efficiently. So in my plugin i could highlight which firmware works better and not recommend certain upgrades to some users who would like to live stream for longer time. Any way restoring an earlier firmware could be also very important to some use cases…

10

@jcasman if you want to pursue this discussion, you should also consider organizing the feedback from other developers regarding communication around firmware. I believe you have other requests with 1:1 email and meetings.