only a few words I want say about my conditions of work which induce the constraints of how I can use things like Pharo. I'm pretty shure that some ideas may be useful also for people doing Buisness about Pharo itself.
0) general remark: all preople in the context of Pharo do a great job. Critism is always easy, doing it a complete different thing. But this is the only thing I can provide at the moment: give ideas for answering the question what is needed to put Pharo into business
1) I'm a user. I take Pharo to create tools for my Safety work, for example graph based Hazard analysis. Moose Suite provide some interesting opportunities for this. In general the strong point of Pharo would be to get some data, do simple processing with it and put it on the screen an printer with a few lines of instructions
2) Pharo as a powerful but easy to use to script solutions. But the way to come to this solutions should be unique. The more possibilities I have to draw a line, the more I have to look which possibility is the best and where is the difference. For my time budget I would prefer to take one maybe not so optimal solution and can just do my work than first starting a research about to best library or API to do it. That's for me the real potential of Smalltalk and Pharo consortium: All are objects, they can be mixed - guided by the expert knowledge of the consortium - to form a powerful but clear set of objects for every main aspect of programming and processing. Don't es libraries, see objects. See the Processing environment and the Wolfram products for this
3) how can I do it ? If you are in time pressure, it is important to find out in a few minutes how to do what you what. The old philosophy of "howto" is still necessary and powerful. Right examples, step by step tutorials can help a lot. You want to do this - here is how to do that. of course, as an old Smalltaker an "softie" I'm used to look into the code - this is fine if software is my main job. But not if I want to use such powerful things like Moose. My suggestion: only develop what also can be documented. There is an old wording for Quality and Safety people : things not documented doesn't exist ;)
4) put it on the screen: one way, easy and in every browser. If you work in a company, you have many constraints of applications and ports. But web browser always works! I'm personally not interested in rich OpenGL frameworks or special graphic APIs: HTML 5 CSS and WebGL X3DOM can do all what I need for visualizations . It's known or has to be learned only once. And even better, like Processing, having an abstract DSL for graphics or like the commands of wolfram products their for complexed diagrams which put their results in a browser - hey, a dream :)
5) data fetching is the start of all. Connecting to any database, excel file or other files, lightweight mapping of data with a few (and unique and well documented ) commands would help a lot to just script down the tool needed.
As I said: just thoughts, I'm aware of that the progress of Pharo is amazing and all people do a lot - I just vote for the fact to do a little bit product management with the commercial user in mind which has time pressure, is officially not supported using weird Pharo instead of good old Java and has to argue every time to the boss what he does.