Create vision.md

[andrej-schreiner]

Proposed changes

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[TheNeikos]

Overall I think that the document is going in the right direction. I think some points are under-specified:

What tradeoffs does thin-edge promise? You can't have tight security and 'no knowledge, easy to use, low touch provisioning' while also being 'highly extensible'. What are the limits?

I know this is not necessarily user-facing, but even for contributors I think answering these questions is paramount. How would one judge if a component should be added to a release with conflicting 'soft' requirements? Is it 'highly extensible' but requires expertise to wield? Or is it low touch but not that extensible? In between sounds messy but potentially useful?

These are IMO the most important aspects to nail down for the project, as this is what will make or break it for end-users.

[TheNeikos]

I would not use passive voice here -> "The aim of thin-edge.io is to provide"...

I also think that saying "Unlike other solutions" is not that interesting to potential readers. What other solutions? Why is not being a single-purpose agent a good thing?

What about: "thin-edge.io is a flexible platform focused on bridging the gap between IT and OT users. It achieves this using re-usable components and without any vendor lock-in!"

[andrej-schreiner]

@TheNeikos "Why is not being a single-purpose agent a good thing?"
Answer: this is one of the reasons we started thin-edge.io, because we have collected evidence that:

• single purpose agents are hard to maintain and do not offer the flexibility needed for iot solutions
• single purpose agents are often bound to a specific device
• single purpose agents have usually only few people who can develop them , and those embedded devlopers are hard to find

--> I like your suggestion

[andrej-schreiner]

thin-edge.io is a flexible platform focused on bridging the gap between IT and OT users. It achieves this by using reusable components and without any vendor lock-in. - that's what we agreed to replace it with

[matthiasbeyer]

I found that the DCO trailer on the commit is missing.

[itsroshan]

Seems like we are a bit too narrowly focusing on manufacturing here.

[nneuerburg]

A few comments on the vision dock from my point of view.

[nneuerburg]

I don't like the word platform but prefer framework and propose to be more specific than IoT project teams, hence the following proposal:

The aim of creating thin-edge.io is to make it easy for IoT device integrators to enable resource constrained devices for IoT. Unlike other solutions, we are not just another single-purpose agent but a
flexible framework with re-usable components without any vendor lock-in, focused
on addressing the needs of both IT and OT users.

[andrej-schreiner]

proposal incorporated below

[nneuerburg]

We believe that the IoT is the driving force ...

[itsroshan]

I would add machine learning to the set ( data analytics doesnt explicitly capture it)

[nneuerburg]

Previously, we mention that thin-edge.io should also allow to integrate with existing projects / device software. I believe that this is important for each device manufacturer who has already significantly invested in device software and does not want to start from scratch. Is this a requirement we should add here?

[andrej-schreiner]

I belive the extensibiliy and openness for integration with other compoenents is a key need agree, I tried to include this in the capabilities and reference to the design pricniples later

[andrej-schreiner]

Suggested change

	We believe that IoT (edge/device management, middleware, data analytics) are the
	driving forces of the fourth industrial revolution: companies are forced to
	leverage IoT solutions to stay competitive. In the past a large amount of
	companies have suffered from failed IoT projects and initiatives, where a lot of
	time and money was spent on device enablement: connectivity, security, device
	management, etc...
	Thats why we are creating thin-edge.io. It provides an easy and flexible way for
	IoT project teams and device manufactures to make their devices IoT-ready
	without having to re-invent the wheel with costly and time-consuming,
	potentially embedded, development projects and without having to reevaluate
	existing projects or applications to enable them with thin-edge.io.
	We believe that IoT (edge/device management, middleware, data analytics) is the
	driving force of the fourth industrial revolution: companies are forced to
	leverage IoT solutions to stay competitive. In most IoT initiatives a lot of
	time and money was spent on device enablement in areas such as device connectivity, security, software, firmware, or configuration management.
	This motivated us to create thin-edge.io. It provides an easy and flexible way for IoT project teams and device manufacturers to make their devices IoT-ready. This saves them time as they do not have to reinvent the wheel with costly and time-consuming, potentially embedded, development projects. Our modular architecture does not force IoT project teams to start from scratch but instead enables existing projects or applications to be enhanced or integrated with thin-edge.io functionalities.

[didier-wenzek]

I think this document can be made stronger by moving some sections elsewhere (notably the requirements, but also the detailed description of the business targets) and by adding more insights on the design principles we believe as key enablers for IoT project success.

[didier-wenzek]

I find this introduction not strong enough. "make IoT easy" can be a mission but is a bit too vague to be a vision that guides decisions, aligns contributions and tells the users where we plan to go. I'm missing a direction of work. What are the challenges and our approach to tackle them? How do we plan to address ease of use, flexibility, re-usability, freedom of choice, IO/OT needs?

[andrej-schreiner]

any counterproposals? I believe your open questions are addressed below

[andrej-schreiner]

@didier-wenzek I realized you question realte to questions you ask in prodcut strategy and not prodcut vision, while there are some indications of answers to them below I do not think they fit into this document

[itsroshan]

I like the short vision summary. Few changes I would recommend -
a) Changing "flexible" to "flexible and extensible"
b) Though its important to qualify that we work on resource constraint devices, but at the same time most use cases we see are Pi kind of gateways. It would be good to make it clear that thin-edge.io will work on all of them too.

[didier-wenzek]

I would really avoid the word "game changer". The future will tell.

[andrej-schreiner]

proposal incorporated below

[andrej-schreiner]

any counterproposals? I believe your open questions are addressed below

[andrej-schreiner]

I belive the extensibiliy and openness for integration with other compoenents is a key need agree, I tried to include this in the capabilities and reference to the design pricniples later

Review is stale and taking the pragmatic approach and merging the PR. If there are any further changes please submit a new PR. Thanks

[didier-wenzek]

Approved.

[reubenmiller]

Approved. Merging this long-lived PR. Any changes should be submitted via the normal PR process (from forks).