Im willing to convert my site to use bitshares payment gateway to accept bitassets and auction off real goods.. if i had a delegate i cam create non reserve auctions which will almost gaurantee new users coming in .. current site is http://devcoinauctions.com... ive already added bitshares payment gateway to it to buy bids or sell bids.. its uses websockets to update order status
so can handle many more users with the same server than conpetitors.

The cost? 1 delegate.. the payoff? new users every month! i cam track new users which must buy into bitshares to use it so we can see weekly trends on how successful it is.

You illustrate what i start to think might be a problem with bitshares: no one wants to do something for bitshares for free. BM mentioned being managed as a startup is an advantage, but it seems to have a cost. People want to develop and help bitshares, but the pre condition is to be a delegate.... it is a problem because enthousiasm, conviction and grass root movement could be the key to success for bitcoin's successor. Linux'devs didn't develop linux to get paid, but because they liked it! They didn't think about user acquisition, they just did their thing. And look what has come out of it!

I've read multiple times that some companies are waiting for a 1.0 release to integrate bitshares. If hat's true, shouldn't the focus be on a 1.0 release?

Also, there are some initiatives that are presented as game changing, but get lost. An example: the cart integration. It has been done, but in the website I do not see references of that.

Finally, I feel like the focus is always changing. At times it's bitassets,then it's the 1.0,  now it's user acquisition while as many said, the pain to become a user is still too high...

Take this as constructive feedback, I do not pretend I would do better ;-)

Publishing and maintaining the current focus would already make a lot to avoid irrelevant distractions like the bingo in client stuff.

Thinking out loudly, here's what I think could on the "focus" page (development oriented):
- Strategic goals we want to reach until may 2015, september 2015, december 2015. Eg: popularise bitUSD, develiver light client, ....
- List what feature/software is currently developed with an roughly expected delivery date
- List of features/software to develop afterwards.
- Possibly list what we postpone for now
- Possibly list the things we do not want and clearly reject.

This page could be reviewed monthly, but between those revisions, new proposals
would be assessed based on this list. This would prevent loosing time and
energy in discussions of items not aligning with our current objectives.

In may 2015, we evaluate what was done, try to learn and optimise the process, and publish objectives for may 2016.
This page could be simply an ASCII text document kept in a git repo, so that the history is kept, and published on github.

I'm a developed myself, and of course the goal should not be to make it a heavy
procedure or cumbersome project management methodology. But this kind of light
structuration approach has already worked for me and my teams.

Take this as a constructive post, written in the hope the developers can get something out of it to help them deliver
all the potential of Bitshares. The goal is certainly not to impose anything!

BTS: rba

BTSX5xF4bPjtQWMXqLnkqKrZQFPXabgiCMnJ9zbJfWpA797onSMHuL

thx!

BTSX5BrfyL988ZDo65w5czJiLxgDnKY5ukb4hB6bbQZDHzbHXR8LTA

thx!

I've found instructions on how to get the PTS in the paperwallet:
https://en.bitcoin.it/wiki/How_to_import_private_keys_v7+