Functions need to be better delegated, maybe, 3-5 guy team to handle the web sites, make them pretty and updated with info. This includes the wiki page, infographics, videos, etc

Another team to write articles, do interviews, marketing stuff, etc

then delagate Y and X with side projects like minebitshares, bunkershares, limewallet, etc

and the rest developing the client.

That way we don't have the same people doing multiple stuff at the same time, loosing time and resources. Meaning we should optimize development. I don't know if that's what happens but I'm under the idea it does. People loose too much time with stuff that don't matter or stuff that someone else could be doing and ends up consuming his time. I trust the devs, I'm just under the idea that things are not that organized.

For this, we should have like Ken suggested, a table of all 101 delegates, links to their proposals and updates and what each one of them is up to.

I am aware that BitShares is still in the startup stage itself and that the delegate system may be sufficient to perform these tasks if the market cap increases but I'm not sure access to information is easy enough and at the very least I think the delegate system should have an 'about me', 'here's what I'm doing' and for unelected delegates an official client based platform for pitching themselves to the shareholders.

====================================================================
TL;DR:
Shareholders can't be relied upon to donate to development funds but they need control over how much development funding the blockchain provides and who receives it.
Separation of community/company maintenance (Delegates) and core development.
Delegates compete to act as maintainers of the blockchain and as the human element to DAC decision making.
Core development could be funded by contracts between the shareholders and developers.
Devs propose development and a pay schedule. Shareholders pay into proposal-specific funds as they see fit and development starts once a given pledge-threshold is met.
These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.


Here is a hypothetical scenario I hope will illustrate how this could work.

I unlock my bitshares wallet and see that I have 500 cds (core-dev-shares) and navigate to the 'Development Proposals' tab. 1 cds = 1 bts but can only be spent per the terms of a core development contract. These core-dev-shares are perhaps the dilutionary funds that used to go to just Delegates.
I see that Invictus Innovations has a proposal for bitAssets 2.0. The team claim it will take 2 months and are asking for 200k bts and $2k bitUSD upfront with a 5M bts completion-'bounty'. Of this 5M bts, 2.5M will be held in escrow for 1 year and 2.5M will be converted to bitUSD on a weekly basis from the start of development until depleted. The team promises to provide proof of progress to
the community and expects Delegates to scrutinise the details.
Underneath this proposal I see that two delegates I trust have evaluated the proposal and interviewed Invictus Innovations and conclude that they think it is a proposal worthy of investment. One delegate has provided an .mp3 file to his 'town hall' interview and another has convinced me that the economic reasoning holds up. The proposal also has a 90% Delegate recommendation rating.
I am now a reassured and confident shareholder so pledge 60% of my 500 cds to this proposal.
I see Moonstone is nearly funded so I send another 20% there.
But I also notice that ByteMaster has another great proposal but doesn't have the time to implement it right now. It's a minor feature not worth the time yet. He has requested an exorbitant fee to prioritise this work over his spare time but I'm sure he expects someone else to pitch for a much lower cost.
I see underneath that 'script.kiddie' has already offered to whip up the code for just $500 bitUSD with a 5k bts royalty fee to be paid to bytemaster. I pledge some more of my 500 cds and see it is instantly converted to bitUSD at market price.

A month later I come back to my wallet to check my cds balance. Script.kiddie has the new feature running smoothly but I see that another project he proposed didn't get funded within the time-window and the 50 cds that I pledged has been refunded to me to allocate to other projects.

I think that trying to merge the two distinct 'departments' of core development and efficient company maintenance stifles innovation and diversity in both departments.
Delegates should get paid for being delegates and core development teams should pitch and get paid solely for contracted tasks completed.

In order to ensure max decentralization of our DAC the shareholders need to actively participate in all aspects of the DAC.
As we are all humans with short attention spans these decisions need to be spoon-fed to us. The easier it is to participate, the more shareholders we get to take part.
If anything is complicated or hard to evaluate, participation will drop off sharply.

Groups of humans are known for witch hunts so we should make sure that when these happen they do not spill over into unrelated areas of the DAC.
For example; if a mob gets stirred up to oust a delegate providing a slow price feed then we need to be certain that there won't be any collateral damage. So delegates cannot also be responsible for funding core development.

Taulant and Moonstone have stated that they aim to demonstrate their worth by taking on risk and offering the shareholders the opportunity to invest by buying their product (their code) and having them open-source it. Could core devs take a similar approach?

Data and necessary info needs to be compiled by the DAC for presentation to the shareholders so they can make informed decisions.

Delegates need to be easily evaluated with a quick look at a list of statistics. Delegate pay should pay for the efficient running of delegate tasks only.
Core development needs to be pitched to the shareholders in a modular fashion and opened up to the free market – I propose by way of a crowd sale system.
Dev teams need to show their goals and code needs to be written in a way that allows numerous parties to add to the codebase over time. A clear list of tasks to be completed allows separate dev teams to pitch separate projects. The shareholders can then fund development as quickly or as gradually as they wish. Projects won't overlap so less time is wasted, and potential dev teams know that they will get paid for the work they do.

Startups who want to set up businesses directly on the BitShares blockchain could also share this coredev proposal system to get funding. Bts shareholders could be encouraged to direct their core-dev-shares to their proposal by getting voting rights in the business and a share of future profits proportional to their stake or perhaps even as loan repayments.
The proposals that get funded would reflect the views of the shareholders. The proportion of core development vs. start-up 'VC funding' style proposals that get funded will most likely change over time as the ecosystem develops.

Shareholders who are delegates could also pitch for core development tasks if they are so inclined but shareholders need to be able to quickly see who is doing the job for which they are specifically being paid for.

For delegates this should mean that shareholders can view a list of hard stats that accurately tell them who is performing well and who isn't.
These stats include:
Uptime
Block propagation
Average time per price feed (possibly broken down per asset – this could be displayed next to a measure of volatility of the specified asset for a fair assessment.)
Other clear cut and useful stats.
A percentage of how many successfully funded core-dev proposals the delegate reviewed and advised on.
Delegates should also be responsible for being oracles on contracts between the shareholders/DAC and core development teams. They are the human element of the DAC so should evaluate the viability of core development proposals and also check-in on project progress.  Delegates would have no authority to stop shareholders funding unrealistic proposals but should use their reputation to serve the shareholders in an advisory capacity.


Instead of funding core dev with dilution, those block rewards could be sent proportionally to each account by their holdings. The funds could be held in some kind of multisig account that allows them to only be spent by contributing to core dev project proposal crowd sales.

Proposals for core development could be published in a separate section of the core wallet in a way that acts to 'crowd sale' the proposed project.
It costs a nominal fee to publish these ideas to avoid bloat and make it easier for shareholders to assess less options. These proposals are contracts to complete a given task within a stated timeframe for a price acceptable to the shareholders.

Core Dev Proposals contain:
A summary of the problems aiming to be solved, what the finished product will look like/do and why/how it will work
a timeline
A fee structure. Perhaps an upfront fee and a recurring payment schedule or an on-completion bounty.
Proposals can also be published with the expectation that someone other than the author will bid to actually compete the task.  Devs who wish the implement someone else's idea can include a royalty payment in their proposal. 'Fund us and we'll pay 10kbts to the author as a royalty.'
This 'royalty' is voluntary but encourages 'ideas people' to promote their ideas to establish themselves in the community to increase the likelihood they'll get a royalty and as a consequence more people hear about the best proposals.
The author of a proposal may also be a large stakeholder with lots of funds to pledge to a developer team to implement their idea, so devs may want to attract this 'VC money' and so offer a symbolic/generous royalty.

The party can then pitch themselves to the shareholders on why they should get this contract. For example:

'We propose to implement BM's proposal for bitAssets 2.0. Upfront we require: 10kbts, £2kbitUSD, 5M bts to be held in escrow until completion except each month 0.5 bitGold is paid out from the fund.'

These proposals accomplish:
Separation of DAC maintenance and DAC development
Open-sourcing of ideas for core development. If a proposal contains a good idea but asks for too much funding, other parties are able to promise the same project for an alternative payment schedule.
A direct relationship between the shareholders and core development incorporated into the DAC itself.
An opportunity for projects willing to build businesses around bts to get access to donations or loans.
The ability for development and businesses working around BitShares to increase as fast as shareholders are willing to pay.

there are a lot of encrypted messaging apps on the market already. NXTTY comes to mind. even whatsapp is working on their end-to-end encryption. the market is saturated in my opinion.

Liondani, I would like to have a bit more contact with you about business because i tend to lose my confidence, and have difficulties to make decissions on my own. Let*s skype again soon. Or should i post that in the forum so we dont have this pm thing and so that people know what we communicate? Ok i will post this text now.
What i wrote in skype:

Hi! I didn+t want to spam the delegate section with my updates. But maybe it+s about time to make a little zusammenfassung (summary), of what i did in a short clip and post it there. The question is, should this go in my proposal thread or should i open a new one?

Thanks BM for sharing the idea. I think voting by project is great. Consider the idea of making each project open to many bidders. We can all vote on which projects are the best ideas and approximately how much we are all willing to chip-in. Then many developers can come along and bid on each project by detailing their proposals. This way we will also have backup providers in case something goes wrong with first developer/group.