That's my peeve with marketing advice this day. Describing what the product will do for user in emotional/vague terms carries zero information relevant to evaluate the product and make a use/purchase decision. It's either treating the customer as a generic unsophisticated idiot, that can't understand what the product actually does, and just needs to be told it'll make them happy, or it's a pure manipulative play. Either way, this is not the style OSS projects should pick up.
to me it means - you will be able to write code that allows you to save and retrieve data from various online services that offer data storage without having to know the particulars of each one of those services apis.
Is this what it does? And if so I wouldn't think that was useless information, at least it is useful enough for me to determine should I Read on?
It is accurate but not concise. The explanation should start with the purpose of the project described in about one sentence, then elaborate by adding context that may or may not be known to the reader.
I linked the overview page because the image on it explains the project better than any description I could find.
One of the issues I see is mixing "what" and "why".
The "what": an abstraction for accessing object storage services, implemented as client libraries in multiple languages plus utilities built on top.
The "why", the problem to be solved: there are many services that provide key-value storage with values being possibly very large; it is reasonable to want to write code that works with any of these services but there is no common interface to write this code against.
Caveat, I may very well be misunderstanding the project.
Questions I have:
- how does it compare to object_store
- what is the philosophy of the project; in what way is it opinionated about the design of object storage services
That's my peeve with marketing advice this day. Describing what the product will do for user in emotional/vague terms carries zero information relevant to evaluate the product and make a use/purchase decision. It's either treating the customer as a generic unsophisticated idiot, that can't understand what the product actually does, and just needs to be told it'll make them happy, or it's a pure manipulative play. Either way, this is not the style OSS projects should pick up.