Topic: Devcoin Venture (Read 4473 times)

Yeah, mark always goes super in depth, probably more so than is necessary

when does voting start?
by the way, markm, you have some very intelligent ideas! 

Made it myself a long time ago.

http://bitcoin.nl/graphics

Off topic, but I like your avatar skull, where did you get it?

Would be pretty great if there was a place you could download high quality opensource imagefiles and send a donation to the artist.
There are sites that offer for example vectorfiles and psd files but you don't always know if you can use them or there is no way to tip the creator.

I would love such a site. 

The delay in obtaining ASICs has been delaying one possible workaround for the lack of merged mining pool software that divides up the merged coins based on how much hashing was contributed.

The workaround I am thinking of is to divvy up the merged coins based on share of ownership of a mining operation that merged mines.

The overheads on such an operation are such that until ASICs are actually in hand and hashing the shares would not look particularly appealing to potential buyers of shares. For example so far i have two dedicated servers out on the net and have ordered a third, because running all the chains to be merged plus the p2pool instance to merge them all while still having all the chains responsive enough to keep the p2pool supplied with work from all the chains promptly takes quite a bit of resources especially with I0Coin and GeistGeld in the merge.

The puny amount of hashing I am currently able to direct at that p2pool instance results in the overhead costs eating a whole lot of the income, so shares of the whole operation at this time would not look very appealing, being largely a share of the overhead costs.

Once all the ASICs arrive (if any of them actually do arrive) the operation overall will look a lot more attractive, albeit by then maybe having absorbed all the overhead costs all these months and gone through all the overhead work of arranging space and power and cooling enough to accomodate them I won't find the idea of divvying the operation up appealing. But I will have the experience of what it takes to be able to seriously consider launching an entire new similar operation that is a divvied up by shares from its inception...

Also, divvying up the actual merged coins need not be how such a thing would operate. it could include trading too, selling all the coins for devcoins.

Then either pay dividends in devcoins or, which i actually prefer to using dividends, be a growth operation that just keeps on buying back shares people want to sell and buying more hashing gear to expand its mining operation.

I prefer a retained earnings operation that buys back shares (and sells them for more than it buys them back at, of course) because it makes people who want to cash out actually have to cash out instead of being able to sit on shares forever while still getting cash out; and also because dividends cause fluctuations in the market price of shares, usually some kind of sawtoothed wave effect.

It seems more reasonable to me that if someone wants cash out the act of cashing out should be an opportunity for someone else to put cash in, thus that cashing out should be by means of selling shares rather than by means of being issued dividends. Also of course all the overhead work and administration of doing dividends is thus avoided making the operation presumably to some extent more efficient than if it did have the whole dividends thing to deal with regularly.

-MarkM-

Is this still open?

DevSeed Project:
https://bitcointalksearch.org/topic/m.2550718

Glari Mining Project works like that (GMP): https://cryptostocks.com/securities/9

There is also DVC security based on it (DVB): https://cryptostocks.com/securities/14

But relationship between two isn't clear. to be honest. I think DVB owns some of GMP shares.

They will get to it, don't worry. They are always working on tons of stuff.

Sorry, perhaps I've missed something, have you already selected top five projects?

If not, when?

We should bring more attention to the bounties, and getting people to start new projects. The more goods and services you can use DVC on, the more it will be worth

CHECK OUT THE NEW DEVCOIN FORUMS
http://homegrownsouth.com/forum/viewforum.php?f=14

Glad you posted this Alex - thanks

Here's an idea:

Building Website CMS's that can easily be configured for toher currencies like Multicoin

- Shopping Cart CMS similar to CoingGig.com

- Exchange CMS (to easily create a BTC/XXX type exchange)

- Online Wallet CMS

etc.

Or even better make one that can support multiple currencies at the same time.

You and also maybe some earlier posts are almost getting ahead of us here, there are some things in the works that might be very relevant to some of the ideas people have mentioned but for technical reasons there has perforce been a slight technical delay in releasing the actual roadmap.

Hopefully the last of those technical delays are being taken care of right now so that very soon now some interesting new additions to the roadmap can be released.

-MarkM-

EDIT: As to musicians using proprietary programs, as long as they can in principle be duplicated in free open source, that is all the algorithms are simply algorithms, freely usable/implementable by any programmer in any programming language, I do not see a problem. Where problems arise is when people try to patent algorithms. As long as the samples are free open source, and the same algorithms / computation can be done on them in principle by simply making a free open source program that performs the same computation / algorithm there is no problem, I think. The problems tend to arise when people start claiming some particular sequence of bits, considered as a sound bite, or some particular algorithm or procedure, regardless of programming language in which it is implemented, cannot be freely used. Or even more abstract expressions of a waveform. "This waveform is proprietary, no noisemaker is allowed to make this exact noise as this noise is special and we own it" type stuff.

Yeah I can see this being an issue. I spent a bit of time making amateur electronic music, and this definitely does come up, even with a friend sending you their track. What often happens is the program will say "looking for X sample" and if you have the same sample pack you can just point the program to the files. I think a music track where the project file is entirely open source, but that uses proprietary samples (or VSTs, or whatever) should be okay, given that most people who make electronic music use proprietary programs at some point or another. That said, there are open source programs, but many musicians are familiar with a certain program, and prefer to make music in that, and like you said, they shouldn't necessarily be forced to change that. I'd say that projects that are entirely open source should get like double the shares, and if you made the samples you'd get shares for the samples as well.

I think it gets even more complicated when the music is made using physical instruments or hardware. Sure, we can open source the score, and the even 3D files allowing someone to reproduce the hardware exactly, but unless you can record the player's performance somehow, that part will be impossible to reproduce. In this case, I think as long as the actual audio is available to freely remix and sample, the artist should still be awarded shares.

And here's an idea: the devcoin music project could have its own "shares", basically it would distribute shares of its own value, that it gets from the Devcoin generation shares, donations, and selling physical albums/t-shirts/etc. This way, each round people could vote on how many shares should go to the music project, and then the music project admins, or even some sort of voting section on the music site, could decide how the music shares are given out.

A big problem with both graphic artists and musicians if the part about open SOURCE.

Both artists and musicians often either fail to grasp the concept of SOURCE or refuse to release SOURCE once they do understand it.

In music for example, a lot of digital music composers actually use proprietary programs and even proprietary "samples", and they not only cannot release those actual "sources" but also refuse to release their own layers of source that take those proprietary components and put them together.

So I suspect for instrumental music we first need free open source instruments, so that when someone composes a score that says "have the violin play this while the cello plays that, meanwhile this drum that drum and that drum play this that and the other drumbeats" kind of thing the SOURCE CODE can INCLUDE the (or at least a) violin, a cello, and the specific types of drums along with the specific impacts upon them that are called for by the piece.

With graphics you often get a similar problem. Someone takes a 3D model they do not want to release or that they cannot (because it is proprietary) release, and use it to create several "layers" of a multi-layer image, then they compile those layers irreversibly into a single layer that is all they are willing or able to release. The "source layers" are not provided, let along any "source model" that was used to compile the "source layers". They end up giving you the resulting compiled gif or jpg or whatever type of image file, the compiled result of using all those various sources.

They can get very irate about all this too, as making you have to go back to them to get any adjustments of the compiled image or compiled track(s) of music is probably how they plan to make their money. They give out a compiled track or image-file, holding back the actual samples and instrument-models in the case of sound or the actual multi-layer image files and actual models used to create them in the case of images.

In short, they refuse to release the "source". All you get is a compiled end-result, not the sources used to build it and the algorithm/procedure/script that does the building of it from those sources.

So a good place to start maybe would be sample libraries and instruments for musicians / sound-effects artists, and 3D models and other stock art that can be released freely with whatever an artist ends up building with it.

Then they won't be able to claim anymore "oh but there is no free open source version of the instruments I used, they are part of a proprietary package I use" because we will retort "then your product is not free open SOURCE, it is proprietary source, and thus is not eligible".

Eventually we can extend this beyond digital. Is a Stradivarius open source, as in all patents and copyrights etc on each individual one are expired so it can be freely replicated once we have replicators? Same with all physical instruments used by a band, etc: if we cannot run the sintruments through a replicator in principle, that is clone them freely, then they do not qualify...

...Remember that replicators, starting at our primitive technology level with so called "3D printers" are on our roadmap. Thus of course by free open source we mean we can freely replicate...

If your Gibson or whatever guitar is so great and makes such great music, lets get its specs down pat so we can churn them out so everyone who wants to compile/execute/perform/replicate the piece of music can do so ... by replicating that special instrument that is the source of that great sound...

-MarkM-

Yes. The 12 share award is not enough for big projects. It's meant for stuff that can be developed in about a week of labor.


No. Bigger projects will have to wait until we get a bigger market capitalization.

I totally forgot about ticket sales, we would need a marketing company too. Devertising or Devent Co...