DVO Ad Code Terms of Agreement

By Dave Volek

Thank you for your interest in DVO DVOA. I believe DVO DVOA is a new approach for website publishers to take control of ads showing on their website while earning more revenue. I also believe that I have created a process for independent programmers to further the DVO DVOA concept—while having some financial incentive for their great contributions.

Download MS-Word Document
Download PDF File

Menu

Version Details

DVO DVOA Version: “Original”
Development Thread for “Original”

Developer Programmer
Name		 Mailing Address
Email Address		 Version
Name		 License
Fees		 Version
Date
Primary Dave Volek #30, 108 Garrow Avenue,
Brooks, Alberta
T1R1J5,Canada
dave@davevolek.org		 Original $99.00 August 2013
Secondary None None None $0.00
Tertiary None None None $0.00
Total $99.00
4th None None None None
5th None None None None

Terms: Website Developers can use the DVO DVOA Package. Programmers can enhance the code and market it. The full terms of usage can be found at https://davevolekinventions.org/DVOA/Terms.html.

Payment: To be fully licensed to use DVO DVOA, the buyer must pay the primary developer the fee stated in “Total.” Primary developer will pay secondary and tertiary developer their stated license fees. Total fees for this version is $99.00 (U.S.).

Point of Sale: PayPal and in American dollars.

Refund Policy: All Sales Final, no refund. Check https://davevolekinventions.org/DVOA/likeDVO.html to ensure you and your server are ready to implement this DVOA package.

Technical Support: While we believes we have made the process comprehensible to most experienced HTML programmers to implement “Original” without any technical support, we still offer three hours of support for this version of DVO DVOA. Please note that response may not be immediate and may require our support staff to access your FTP site.

Sales Contact for this version of DVO DVOA: Dave Volek, Email: dave@davevolek.org. Website: https://davevolekinventions.org/DVOA/index.html

Definitions

Website Publisher: The owner of website who implements DVO DVOA on his or her website.

Programmer: An individual programmer, a programming team, or a corporate entity who implements DVO DVOA on a website.

DVO Programmer: A programmer who enhances DVO DVOA concept and offers his/her versions for sale.

DVO DVOA Code or “code”: All programming code for DVO DVOA. This shall include database programming, HTML programming, any other programming from other programming language as programmers see fit, and documentation.

Phase 1: The first model for DVO DVOA. It has the following general characteristics: (1) Primary Developer sells the DVO DVOA package to the publisher, and the publisher implements it on the publisher's website (2) Publisher finds his/her own advertisers and obtains payment directly from these advertisers, and (3) Ad Database sits on publisher's server, and publisher changes database as ads are sold or replaced.

Enhancement: Improvement to an existing version of code. Enhancement shall include adding new features, improving existing features, or deleting redundant features.

Version: Code that has had at least one enhancement from a previous version—and is being offered for sale to publishers.

Version Name: The name given to a version created by a programmer.

Version Details: Text that provides version name; primary, secondary, and tertiary developer names and contacts; the license fees for these developers; total license fees; links to terms; payment terms; refund policy; support details; and other sales information.

Primary Developer: The DVO programmer who made the last set of changes to the DVO DVOA code in a development thread.

Secondary Developer: The DVO programmer who made the second last set of changes to the DVO DVOA code in a development thread.

Tertiary Developer: The DVO programmer who made the third last set of changes to the DVO DVOA code in a development thread.

Subsequent Developers: The DVO programmers who made all the previous changes (from the fourth set and on) to the DVO DVOA code in a development thread.

Development Thread: The succession of versions from the original code to a current version. All DVO programmers involved in making changes must be named in this thread. Multiple threads are anticipated as the original code is enhanced by different programmers in different ways.

Phase 2: The second model for DVO DVOA, which will be built after Phase 1. It shall be characterized by the following: (1) Publisher and advertiser communicate and reach agreement through accounts provided by the online DVOA broker, (2) Payment from advertisers to publishers shall be conducted through the broker, with the broker taking a percentage of these fees as his/her revenue, (3)l; the ad database shall sit on the broker's server(s).

4% Royalties: the percentage of broker's total revenue that will be paid to all DVO programmers of the development thread to build a Phase 2 version. The royalties shall not include any deductions for any operating, marketing, development or any other expenses related or not related to running the Phase 2 version.

Buyers for DVO DVOA

There will be three kinds of buyers of DVO DVOA:

  1. Website publishers who will implement the DVO DVOA code on their website.
  2. HTML Programmers who have, directly or indirectly, purchased the DVO DVOA package on behalf of their clients, the website publishers.
  3. DVO Programmers who believe they can enhance DVO DVOA by making changes to its code—and later sell the enhanced versions of DVO DVOA to other buyers.

Characteristics of DVO DVOA

First, let's discuss the most popular form of online DVOA: the cost per click (CPC). There is one dominant DVOA broker providing this service between online advertisers and website publishers, with about 10 other brokers providing similar CPC services.

As an inventor, I have no interest in creating something other people have already created. But being both an advertiser and publisher, I am frustrated with my current online broker, and I doubt I could get better results with one of the competitors. So, with my limited resources, I have invented a new system of internet DVOA.

I use the term “invented” rather loosely because I believe my system goes back to an older time of marketing when “the battleground was in the customer's mind.” DVO DVOA will be based on providing sufficient impressions on a serious visitor going through the website to better ensure that that visitor has an impression locked somewhere in his or her mind. As the customer gains more impressions, especially from other marketing sources, he or she becomes more influenced to effect the desired action of the advertiser. In other words, DVO DVOA is only one piece of the larger marketing puzzle. It's not that important whether DVO DVOA becomes the medium that finalizes the actual sale.

So here's how DVO DVOA works:

The website publisher sets up some ad space on his/her webpages my appropriate webpage spacing and using the DVO ad unit code.

The publisher sets a frequency each ad will be shown. This is done by creating a pool of “X” ad spots, and giving each ad spot a graphic. The program will randomly select one of these graphics to show when the webpage calls for an ad to be displayed. This means the frequency for each ad is 1/X. To set a reasonable frequency, the publisher will look mostly at ensuring a sufficient exposure to serious visitors.

If the advertiser wants a firmer impression, he can buy more ad spots from the publisher.

The publisher also sets the price for each ad spot on a per calendar month basis. Any unsold ad spots can be used by the publisher for some self-promotion, great visual effect, philanthropy, or some other purpose.

The advertiser determines whether the publisher's website can reach the desired target audience and whether the frequency, website traffic, and price are acceptable. If the advertiser likes the DVOA opportunity the publisher offers, he/she will submit the ads to the publisher.

If the publisher agrees that the ads are suitable for his/her website, a business deal has been made. The ads will show on the website; the advertiser pays the publisher.

The publisher can fill any unsold ad spots with whatever graphic he chooses.

Phase 1 of DVO DVOA will consist of selling the program code and documentation to the publisher, who will then implement the package on his server and website. The publisher will somehow find his/her own advertisers and obtain payment for DVOA services.

Phase 2 of DVO DVOA will consist of providing an actual online DVOA brokerage service. Publishers and advertisers will set up their accounts and find each other through the brokerage service. When a deal has been struck between an advertiser and publisher, the advertiser pays the broker and the broker then pays the publisher. The broker takes a small fee for this transaction.

Terms for Website Usage

  1. When a website developer purchases the code from a primary developer, the website publisher can then implement it on his or her website.
  2. This publisher cannot sell, rent, lease, lend, or give away the code to another website publisher.
  3. The website developer may use the code as many times as he/she wants on his/her website(s). If two or more websites have different ownership, even a partial difference, the websites must each purchase their own DVO licenses.
  4. If the website changes ownership, DVO DVOA must be repurchased.
  5. If an HTML programmer, directly or indirectly, buys the code for a website publisher, that programmer cannot legally use that code for another website publisher.
  6. An HTML programmer cannot enhance the code until he/she pays the license fee again to the primary developer. At this time, he/she shall be deemed a DVO programmer.
  7. If an HTML programmer has his/her own website and implements the code on that website, the HTML programmer is also a DVO programmer for that version. In other words, such an HTML programmer need not repurchase a version of DVO DVOA if the code implemented on the HTML's actual website.

Phase 1

Legal Disclaimer

These terms for Phase 1 and 2 development for DVO DVOA provide a unique team process for independent programmers to participate in building and profiting from a unique online DVOA program. This program could eventually rival today's online DVOA brokers. Any DVO programmer participating in this process has to accept all the conditions stated in these terms.

However, I should warn potential DVO programmers that the terms were written without benefit of legal advice of any kind. Sorry, I just couldn't afford to pay such fees during the inception of this project, especially to law firms specializing in international copyright laws. As well, this process is, I believe, a new process for software development. Even with professionally written terms, it is unknown how well this process would hold in a court of law.

Therefore, any DVO programmers looking to participate in this process are now forewarned that the legal protection for their work may not be there for them. I absolve myself from any obligations if these terms cannot hold in a court of law. DVO programmers participate at their own risk.

Unforeseen Circumstances

I had some great motivation for creating this unique structure of independent DVO programmers building DVO DVOA. My original business plan was to sell copies of my code, earning whatever I could from these sales. But I knew that my time in the “product cycle” of this concept was going to be limited. If DVO DVOA is to become popular, I will get some sales from the “early adopters.” Then, very likely, someone would take the code I developed, improve it, and then most likely market their version better than me.

Initially I thought that I would be happy to get $3000 in sales for something I needed for my website anyways. I deemed this as sufficient compensation for my efforts. But I really didn't like that I would get not any credit for this idea: not a good result for this unacknowledged inventor. So I put myself to thinking: “How could I get the credit (and a more suitable financial reward) for my DVO DVOA—given that I really don't have the financial resources or expertise to take this concept much further than the original idea.

This “terms” document is the product of my musings. It brings many DVO programmers working as a team—and under my umbrella. So when a successful Phase 2 version is complete, I will be acknowledged as its creator. I think most readers will consider these terms a very wise move on my part.

If you read this document, you will realize that I am a person that likes to think of potential challenges and solve them before they become problems. But regardless of how well I have formulated this structure for independent programmers to build DVO DVOA, this document may not be able to resolve some circumstances I cannot envision at this time. These circumstances may hinder the development of DVO DVOA. Hence I am giving me the authority to alter some of the terms of this document.

When such a circumstance arises, I shall consult with the community of DVO programmers but trying my best to convince DVO programmers to work with the existing ruling. But if there is a reasonable consensus to make changes, I shall enact the changes. I am hoping that I won't have to go in this direction. We shall soon see.

Please note that I will not be resolving any disputes between DVO programmers. See Community of DVO programmers of how to handle supposedly dishonest members of this community.

Legal Jurisdiction

Any civil legal activities pertaining to DVO DVOA shall be conducted in the Province of Alberta (Canada) with its business laws and civil proceedings.

Clause added in April 2014

Banking

It is important that all DVO programmers use the same banking system. Therefore all DVO programmers will be obligated to use PAYPAL bank and price their versions in American dollars.

DVO programmers are free to use other payment methods, but must always have the PAYPAL and American dollars available. If a DVO programmer requests a payment from PAYPAL, it must be done in PAYPAL.

Making Enhancements and New Versions

When a DVO programmer has selected a version and paid the appropriate license fees, he/she is given the right to modify the code. Enhancements can include but are not limited to:

  • Adding new features.
  • Replacing existing code from the version with better code.
  • Removing existing code.

Development in DVO DVOA Phase 1 must be based on a “per ad spot per calendar month” basis.

There will be a strong pull to develop a “cost per click” model. This direction will not be allowed in Phase 1 because there are at least 10 companies already providing this service. DVO programmers must innovate towards something new, not copy current DVOA models in this competitive industry.

When the DVO programmer feels enough enhancements have been made to be of value to DVO DVOA buyers, he/she can start marketing these enhancements as a new version. He/she shall give the version a new name.

In the new version, the DVO programmer becomes the primary developer. The primary developer shall determine his/her own license fee.

Responsibility of the Primary Developer

The primary developer of each version has some responsibility to ensure continuity of the community of DVO programmers. These responsibilities are:

  1. Provide a name for the new version.
  2. Rename the primary developer of the previous version as the secondary developer of the new version. The same fees of that developer will be applied to the new version as “secondary development” fees. The new primary developer cannot change these fees.
  3. Rename the secondary developer of the previous version as the tertiary developer of the new version. The same fees of that developer will be applied to the new version as “tertiary development” fees. The new primary developer cannot change these fees.
  4. Move the tertiary developer to the subsequent developer list. The fees from the former tertiary developer will no longer be applied the license fees.
  5. Maintain the continuity of the development thread by listing all DVO programmers in “Version Details.”
  6. When a sale is made, the primary developer must immediately pay the secondary developer and tertiary developer their stated license fees. It is the responsibility of the primary developer to make contact with these two developers and set up the PayPal transfer.

Presentation of These Terms

The exact copy of these terms can be found at https://davevolekinventions.org/DVOA/terms.html.

A primary developer must also provide these terms to ensure they are communicated to his/her buyer(s). The primary developer shall provide a webpage with these terms. The webpage shall also include two downloadable links of these terms, one in PDF format and the other in MS-WORD (edit enabled format). The primary developer must make appropriate links to this webpage to ensure buyer(s) of his/her version have had opportunity to inspect these terms.

With the exception of “Version Details,” the DVO programmer is not allowed to alter any of the terms. The primary developer can add an appendix to the terms, but this appendix must be clear it is not part of the original terms. Any appendices can be kept or removed at the discretion of a future primary developer, but it cannot be altered. If there is any discrepancy between the original terms and any primary developer's appendix, the original terms shall prevail.

The “Version Details” of the terms must be altered for each version. It must reflect the appropriate primary, secondary, and tertiary developers, their stated license fees, and total license fees. It must reflect the entire development thread and the link to “terms” on the primary developer's website. The primary developer may have some special sales considerations that need to be communicated to his buyers.

The primary developer must include his/her copy of “Version Details” in the all program files as a section of text and all technical documentation.

Recommendations for DVO Programmers

To become recognized as a great DVO programmer, such programmers should consider the following suggestions:

  • Let buyers know of any conditions where your version will not work—before you make the sale.
  • Conduct thorough testing on your version of the code. Consider this testing more important than a refund policy. If you do refund a purchase, consider it your fault that the refund occurred. You should not ask secondary and tertiary developers to return their license fees to you. It's probably not their fault the program did not work well. If the fault does lie in their programming, you should have caught the bug in your testing.
  • If website publishers or other programmers find bugs in your code, your reputation will suffer. Development threads with your name in them won't sell too many copies to website publishers. Other DVO programmers will not enhance your version, so you will lose potential secondary and tertiary sales. Any development threads you are involved with will likely not be used for Phase 2 development.
  • Likewise, if your name is associated with quality and innovation, you will make many sales at all three development levels. You improve your chances your development threads have of being used for Phase 2 development.
  • Edit the setup instructions to teach your buyers how to work with your enhancements. Include this document as an important part of your software package.
  • Consider the price for your version carefully. Lower prices will be more attractive for future sales. When you get a reputation for quality programming, you should be able to charge higher prices and still make sales.
  • List the entire development thread in your documentation and code—even though the subsequent developers are no longer being paid. Build and maintain your respect within the DVO Programmer community. And you could lose your Phase 2 royalty if you don't include the previous developers in your version.
  • When sending payment to a secondary or tertiary developer or receiving payment from a primary developer, send appropriate documentation in your own template.
  • Consider putting your great enhancements on several promising development threads to increase your chances of being included in a Phase 2 development. This will mean paying more license fees, but this is a balance you will have to figure out for yourself.
  • The earlier you make a new version, the better your success of being on a development thread that is selected for Phase 2.
  • Have a marketing plan for selling your version directly to website publishers. If your version sells well, then other programmers are more likely to improve your version.
  • Support programmers who have enhanced your version by providing links on your website to their websites. Explain to your potential customers the enhancements these programmers have made to your work. Let them decide which version to buy. You will receive the same revenue whether you are a primary, secondary, or tertiary developer.
  • Anticipate that your version will be obsolete in a year's time. It is unlikely you will become rich with this version, but you should receive sufficient compensation for your efforts if you have developed a good version and marketed it well. Remember, you could be eligible for some of the Phase 2 royalties—even if you are no longer earning Phase 1 revenue from your version.
  • If you want to continue earning Phase 1 revenue, make more innovations to DVO DVOA. Put yourself in the development threads several times.

Example

Here is a story of how I see DVO DVOA being sold and enhanced.

I have named my version “Original.” I've decided to sell Original for $99. Let's assume that I sold 20 copies to website publishers, which gives direct sales of $1980.

These 20 sales indicate that DVO DVOA is starting to get a good reputation. Three programmers like the concept and want to enhance it. DVO programmers named Bill, Connie, and Atushi buy the code from me (my total: $2,277). While they are making their enhancements, I sell another 10 copies of Original to website publishers (my total: $3,267).

Each of these three programmers enhances “Original” and makes some sales to website publishers. The “web of programmers” would look like this:

So let's now talk about development after “Original.”

Bill

On the left, Bill purchased Original from me. He didn't make a good version. All three of his customers could not implement the code, and Bill had no interest in fixing the problem. Bill still paid me three times as secondary developer (my total: US$3,564). As well as no further sales to website publishers, no DVO programmers wanted to enhance Bill's version. I took Bill's link off my website as a DVO developer because it would not be professional for me to recommend it. Thus Bill's development thread died, and Bill has disappeared from DVO DVOA.

\

Connie (1)

Connie purchased Original from me. She made some enhancements to create a new version she called Sundial-1. She sold eight copies to website publishers, and she paid me my secondary developer fees: 8 x $99 = $792 (my total is now US$4,356).

Fernando

Connie also sold a package of Sundial-1 to another programmer named Fernando. Fernando paid Connie $158. Connie then paid me $99 (my total: US$4,455). This gave Fernando the right to make his version called “Breakwave.” He deemed his share of Breakwave to be worth $60 a package, so Breakwave's total price was Fernando's fees ($60), Connie's fees ($59), and my fees ($99) to make the total price of $218.

At this point, a potential customer of DVO DVOA has four possibilities: Original for $99, Granite for $134, Sundial-1 for $158, and Breakwave for $218. The customer can choose where he finds the better value: are Connie's and Fernando's enhancements worth the extra money? And hopefully no more sales of Granite will happen.

Fernando sold 12 copies of Breakwave to website publishers for a total of $2,616. He pays Connie $708; he pays me $1,188. (my total: $5.544). Fernando keeps the rest.

Connie (2)

Connie liked the enhancements Fernando had made. She bought a copy of Breakwave from him. Being the tertiary developer, I got another $99 (my total: $5,643). Since Connie is also the secondary developer of Breakwave, she would actually pay that $59 license fee to herself: i.e., she really doesn't have to pay this fee.

With Connie's enhancements of Breakwave, which she called Sundial-1A, she sold a lot more copies. But at this point, I have become a subsequent developer and receive no license fees from Connie's sales of this version. If a website publisher wants Sundial-1A, he/she pays Connie $168. Connie pays Fernando $60 a copy. Being both the primary and tertiary developer, she keeps the rest for herself.

Until Sundial-1A was made, my Original was probably the best value for customers. It was the cheapest version and had a reputation for being easy to implement. Many potential customers preferred Original to Sundial-1 and Breakwave. So I sold another 22 copies of Original (my total: $7,821).

But with Sundial-1A having more features, not really costing that much more than Original ($168 vs. $99), and Connie having developed a reputation for developing a good product, Sundial-1A is a better deal for customers than Original. My version is no longer selling.

When promoting Sundial-1A, Connie presented the development thread as follows:

Developer Programmer
Name		 Address Enhancement Name License Fees
Primary Connie London, UK Sundial-1A $59
Secondary Fernando Madrid, Spain Breakwave $60
Tertiary Connie London, UK Sundial 1 $49
Total $168
4th Dave Volek Brooks, AB, Canada Original None

Some readers may be wondering why I have capped the license fees to three levels. The first reason is that after Connie, Fernando, and Connie (again) have added features to make DVO DVOA even better, my original code is becoming much less of the total program. At some point, I have to admit that the creative efforts belong more to someone else than they belong to me. They should have most of the reward. Being relegated to a subsequent developer still has its advantages for Phase 2 development. And of course, there is nothing to stop me from getting back into the development thread, enhancing Connie's Sundial-1A, and starting to make sales as primary developer again. But I'm not going in this direction, and I will be content to let others to take the post-Original reward during Phase 1 development.

A second reason is that we have an upper limit as to how much we can charge customers. Our customers can sign up with the other DVOA brokers at no cost, so we need to be realistic with the fees that we can charge and still expect sales. I have set the price for Original at $99. I would like about twice that fee, and I think I would earn more profit with this higher price. But I have to consider future DVO programmers getting a fair compensation for their work on furthering DVO DVOA. If my license fees were $199 (instead of $99), it would become harder for these DVO programmers to sell their versions—when they have to add their fees to my $199. So I have reduced my fees to help these early DVO programmers along, as it is still in my best interest to advance DVO DVOA into Phase 2. DVO DVOA just might not go further than Original if the price were $199—even if my Original makes a lot of sales.

And a third reason to cap fees to three levels of development is to keep the payment process simple. When a primary developer makes a sale, this system is fairly straight forward for who and how much the primary developer has to pay: just two simple payments to the secondary and tertiary developers.

Finally, if DVO programmers find this structure provides sufficient profit for their efforts, they will want to continue with this revenue stream. They do this by making more enhancements to the concept. In other words, capping the payments at three levels of development actually encourages further development.

Atushi

Now let's look at the right side of the diagram. Atushi is a rather ambitious programmer from Japan. He adds some interesting features he thinks Japanese customers will like and spends a lot of time developing code to make these features work. He calls his version “Mt. Fuji.” He decides his work is worth $185 a package. Add my secondary fees, the total package costs comes to $284. Atushi understands his Japanese market quite well, creating his technical documentation in both English and Japanese. He sells 31 packages and happily pays me my secondary development fees (my total is now $10,890).

Connie likes Atushi's work and buys Mt. Fuji from him. She pays Atushi $284; Atushi passes $99 to me (my total is now $10,989). She brings both of her enhancements from Sundial-1 and Sundial-1A into Mt. Fuji, which means her programming efforts are not as involved compared to when she first built them. Connie calls her version Sundial-2 and prices her share of the total license fees at $59, making Sundial-2 the most expensive version at $343.

Connie is better at marketing to a western audience than Atushi, So she sells 42 copies of Sundial-2 to customers who would not likely have bought Mt. Fuji. Thus Atushi is rewarded by Connie's marketing expertise by receiving 42 x $185 in revenues from these sales. As tertiary developer, I get 42 x $99 (my total is now $15,147).

With Sundial-1A ($168), Sundial-2 ($343), and Mt Fuji ($284) on the market, it would be expected that Original ($99) and Breakwave ($218) are now obsolete. Both website publishers and future DVO programmers will want to purchase the advanced versions from their primary developers rather than purchase my and Fernando's versions.

In this hypothetical story, I have earned $15,147 in revenues. While I would certainly like more money, I would be satisfied with this situation for I have been compensated reasonably well for my effort expended and resources spent to get DVO DVOA together. Any Phase 2 royalties would be a bonus for me.

I don't think any DVO programmer is going to get rich from DVO DVOA, but there should be a reasonable compensation for good programming and good marketing. But if a computer programmer has: (1) good knowledge of HTML and database programming, (2) some spare time, (3) a website from which to market his/her version of DVO DVOA, and (4) a good career network, creating a version of DVO DVOA may be an interesting life experiment for such programmers. A budding programmer may also need to develop experience or a portfolio. If you fit this criteria, all I can say is to give DVO DVOA a try—and see what happens.

Community of DVO Programmers

I have previously alluded to a “community of DVO programmers.”

If I can sell 20 packages of DVO DVOA and at least half of these customers prefer this new DVOA concept, DVO DVOA is going to grow organically. It will attract the programmers who will put their time and expertise into furthering this idea.

In some ways, these DVO programmers will be competitors. But I think most will see themselves as team members, guided by this structure to ensure a reasonably fair compensation while encouraging future development. They will be building on each other's efforts to attain a Phase 1 version worthy of being converted into a true online DVOA broker, which is Phase 2.

And as alluded to earlier, the legal framework just might not be there to provide sufficient protection for the rights of all DVO programmers. If this is the case, then this document only becomes a set of guidelines for those DVO programmers who wish to abide by the rules set out. In other words, there may be no protection from “cheaters.” Even so, in the absence of any other agreement, this document would still be most referred to in a court of civil law, so it should not be dismissed that easily.

Rather than using legal means to keep all DVO programmers in line, the community of DVO programmers should establish a culture that uses social means to push cheaters to a state of discouragement.

There are third kinds of cheaters I can anticipate. The first kind will be primary developers who do not pass on the appropriate license fees to their secondary and tertiary developers. The second kind will copy code from other DVO developers and put it on other development threads and claim it as their own creation. A third kind will cut DVO programmers from the development thread—or add their name (or other names) into the development thread that really did not create any new versions.

If you feel a DVO programmer is one of these cheaters, your best course of action is to stop enhancing any development threads the cheater(s) has been involved. If you have been truly cheated, then that cheater will try to cheat other DVO programmers and eventually the community will realize that one of its members is not contributing to the process. With more DVO programmers coming to the same conclusion as you, the cheater's development threads will stop expanding. Eventually the cheater will realize there isn't much reward for him and leave the community voluntarily.

Try not to get involved in gossiping and backbiting about potential cheaters in the community of DVO programmers. First, you could be wrong about that person. Second, that person could accuse you of cheating. Since there is no forum to prove who is right or wrong, now both of you look bad in the community. Just be assured that the community will eventually find the truth—and stay away from that person's development threads. If you have developed a good reputation in the community, your shunning of suspected cheaters will get attention from other community members.

Whether you sell your versions to suspected cheaters is up to you.

I think it's important to emphasize that the community of DVO programmers, whether they number five or 50 or 500, needs to create its own culture. It should be a culture that respects and honors the creativity, the innovation, and the effort of all its good contributors. This culture understands that it will take many minds and a team effort to build this concept to its full potential-and these terms are a structure that allows this process. But the community is also a culture that sidelines contributors who are only there to make profit for the least effort. Identifying the good contributors from the poor contributors should be a responsibility of the good contributors. Not furthering the work of poor contributors should be a goal of this culture. If done well, this social force will not only create a few fantastic Phase 2 versions for online internet DVOA, it will be fair to the good contributors in terms of their financial compensation.

I don't like lecturing responsible people, but I think it's very important to tell this message again. To all primary developers: Please, please, please pay your secondary and tertiary developers when you get a payment!! This ensures the continuance of the DVO DVOA concept. Plus if you are regarded as not paying, you could be written out of any Phase 2 royalties. Do you want to be left out?

Phase 2

All the previously discussed development of DVO DVOA constitutes the rules of Phase 1. This model may be as far as DVO DVOA ever goes.

However, my vision has DVO DVOA becoming a bona fide online broker for online DVOA. I can see website publishers offering their ad spaces under the umbrella of a DVO DVOA broker. Advertisers work through the broker to find websites on which they wish to advertise. If the advertiser likes the terms the publisher offers (mainly ad frequency and price), and the broker provides the online mechanism to effect the deal. The advertisers pay the broker; the broker pays most of this money to the publisher; the broker keeps a little money for his/her service.

When a programmer decides to take DVO DVOA to Phase 2, he/she will likely not want to rewrite the entire code to make this advanced version work: there will be a lot of useful Phase 1 code that can be used. As well, he/she might want to retain the DVO DVOA brand name to help market his Phase 2 version. And even though such a programmer will undergo a significant investment to make the transition from Phase 1 to Phase 2, he/she still needs to acknowledge the investment and efforts made by previous developers to get DVO DVOA to this position. Listed below are a few terms for how this publisher is going to acknowledge these developers plus some other important rules.

  1. The Phase 2 programmer can choose any development thread that he/she feels is best suited to build Phase 2. No Phase 1 developers can challenge this decision.
  2. All programming from this development thread can be used to build Phase 2.
  3. If there is code in other development threads that is not in the selected developmemt thread, the Phase 2 programmer cannot use that code.
  4. When a programmer decides to build a Phase 2 version and has selected a development thread, that programmer should pay the development thread’s primary developer three times his/her stated license fee, the secondary developer two times the stated fee, and the tertiary developer the stated fees. In this way, the Phase 2 programmer has paid all Phase 1 licenses and can legally use any code from the development thread in Phase 2, plus any future updates of Phase 2.
  5. When a programmer decides to build a Phase 2 version, the programmer shall make a reasonable attempt to communicate his/her decision (including the chosen development thread) to the DVO programmer community, which will likely have developed several social media outlets. One obscure social media outlet will not suffice as reasonable.
  6. Any Phase 2 development must include a mechanism similar to the General Characteristics of DVO DVOA for Phase 2; i.e. payment on a per calendar month for ad space of a specified frequency.
  7. Other DVOA mechanisms are allowed for Phase 2, but we recommend not going in this direction.
  8. All versions on that development thread get one share of the royalty, with the exception of Dave Volek who shall get ten (10) shares for “Original.”
  9. Some developers will likely have more than one version on a development thread. They shall have one share per version.
  10. The royalty shall be 4% of total revenue earned by the Phase 2 version. For example, assume Sundial-1A becomes the development thread for a Phase 2 project. This means 13 shares: Dave 10, Connie 2, and Fernando 1. If the revenue in the first year is $520,000, the development thread gets $20,800. Dave gets $16,000 of this money, Connie get $3,200 and Fernando gets $1,600.
  11. Royalty payments are annual payments, to be made within 30 days after each anniversary of the Phase 2 launch.
  12. The royalties shall cease nine years after the Phase 2 version is launched.
  13. If it is found that a Phase 1 programmer in the development thread chosen by the Phase 2 programmer did not pay the appropriate license fees to the primary, secondary, or tertiary programmers, that non-paying programmer shall be excluded from receiving any shares for the royalties of the Phase 2 version.
  14. If it is found that Programmer X removed another programmer from the development thread chosen by the Phase 2 programmer, that Programmer X shall be excluded from receiving any shares for the royalties of the Phase 2 version.
  15. If it is found that Programmer X added versions that never happened to that development thread, that Programmer X shall be excluded from receiving any shares for the royalties of the Phase 2 version.
Other Phase 2 Notes

There may be more than one Phase 2 programmer. These programmers will likely be competitors, each with their own version of Phase 2. There are no exclusive rights to the first Phase 2 programmer.

Phase 1 development may still be occurring as a Phase 2 version is being built or even after a Phase 2 has been built. However, a good Phase 2 version should make any Phase 1 version obsolete.

If a Phase 2 developer wishes to retain the DVO DVOA brand name, the programmer must add a secondary name to DVO DVOA to differentiate his/her version of Phase2; for example, “DVO DVOA: Sundial” or “DVO DVOA: Mt. Fuji.”

If a Phase 2 developer wishes not to use the DVO DVOA brand name, the 4% royalty still applies to the development thread the Phase 2 developer has chosen.

I capped the Royalty payments at nine years for a good reason. If a Phase 2 programmer builds a successful Phase 2 version, the concept will soon by copied by competitors. The Phase 2 programmer is going to have to be innovative and make investments into improving his/her Phase 2 version to stay competitive. The original contribution from the Phase 1 development thread will have had little to do with the success of that Phase 2 version a decade from its launch. The development thread should be thankful to the Phase 2 programmer for being competitive in the nine-year period of royalty payments.

Lost Shareholders

The Phase 2 developer shall also make a reasonable attempt to find any “lost” Phase 1 developers who have not maintained good contact information. The Phase 2 developer shall keep their royalties in a separate bank account to be claimed with sufficient proof of identity. If, five years after the termination of the royalty payments, the lost Phase 1 developers are still not found, the Phase 2 developer shall disburse these funds to the Phase 1 developers with known contact information.

So What's the Punishment?

I'll be quite upfront about this three-level license process and its transition from Phase 1 to Phase 2. I certainly don't have the financial resources to take a DVO programmer to court for not paying my secondary and tertiary fees, especially on an international basis. I don't even have the resources to hire lawyers to draft a more legally sound agreement, based on international copyright laws.

DVO DVOA is going to organically evolve. Eventually one or two Phase 1 versions are going to have a right combination of good features and good marketing that are going to be very acceptable to many online advertisers. The primary, secondary, and tertiary developers are going to make a lot of money with these versions.

If Phase 1 becomes this successful, then someone is going to invest heavily into building a Phase 2 version. What started out as a crazy idea in my basement office will then be worth millions of dollars. When there’s a lot of money, people have more incentive to take other people to court who have violated the terms of a legal document. And there are international legal firms who work on a contingency basis. This means instead of charging their clients hourly fees as the lawsuit proceeds the courts, the legal firm will take a substantial share of the proceeds if they win or attain an out-of-court settlement. If 30 or so programmers believe their rights have been violated, it's financially better for them to assign their legal rights to this firm. If the proceeds from a court settlement or out-of-court settlement are split 50/50 between the honest DVO programmers and legal firm, the programmers are still ahead.

But if the chain of properly paid licensees can be proven, the lawsuit will have no basis. No contingency based legal firm will touch this case.

DVO Development Thread Association

DVO Programmers in a development thread can create an association to protect their interests for Phase 2. Here are the rules:

  1. Those advocating for an association must make a reasonable attempt to find the working contact information of all the shareholders.
  2. The association shall be formed with at least 50% +1 of the shares of working contact information agreeing to the association.
  3. Before the official vote is taken, those shareholders advocating for an association must provide a reasonable communication opportunity for those shareholders who don't want an association to represent their position. These could include paper documents from the “against” side to be attached or enclosed with the “for” side or links to the “against” side webpages from the “for” side webpages. The “for” side must communicate with the “against” side(s) to ensure this communication is made available to all shareholders of working contact information.
  4. The legal jurisdiction of the association and whatever bylaws are made specifically for this association must made available to all shareholders. The association's articles shall be under the legal rules of that jurisdiction and the association's bylaws.
  5. All shareholders shall belong to the association, even if they did not agree or could not be practically found.
  6. Once the association is formed, the Phase 2 developer shall pay the association the entire 4% royalties.
  7. The association shall be allowed reasonable expenses to run the association, which could include legal expenses. It is unlikely that “reasonable” shall be a large salary for its manager and management team.
  8. The association shall release funds excess of usual operating expenses to the shareholders, with each share getting an equal amount of the amount released.
  9. For the lost shareholders, the association shall put these funds in an interest bearing bank account.
  10. If the lost shareholders are not found five years after the last royalty payment, the bank accounts shall be turned back to the association and the associations shall pay all funds to its shareholders of “working contact information,” each share getting an equal amount.
  11. At this point, the association shall dissolve.
  12. The association can also dissolve at any time with a 50%+1 vote subject to the association's articles and bylaws. If the association is dissolved in this manner, the Phase 2 developer shall pay the 4% royalties directly to the shareholders.

If the Phase 2 developer is honest with the Phase 1 developers of the development thread, there should be no need to form an association.

FAQ

Website Developers

Q1: Is it possible to place DVO DVOA ad units and ad units from other DVOA packages on the same webpage?

A1: There have been some reports that some online DVOA brokers have placed code that disables ad units from competitors' ad units. The first version of DVO DVOA, Original, will not have any such coding, so publishers can experiment with two different systems on the same webpage. I anticipate that most DVO programmers will not create any such code to disable ad code from other brokers.

Phase 1 Development

Q2: From the hypothetical web (Bill, Connie, and Atushi), it seems the DVO programmer's license fee does not change as the version moves from primary to secondary to tertiary developers. Is this correct? If so, why?

A2: Yes, this is correct. The license fee, once stated, is moved by primary developers from primary to secondary to tertiary payments. For example, my $99 fee is applied at all three levels, and I cannot change it. This fee drops out of the payment at the fourth level of development.

The main reason for this structure is to keep things simple for the primary developer to be honest—and to be seen as being honest. With honesty being so observable, the evolution of DVO DVOA can continue.

While it could be argued that the fourth, fifth, and maybe sixth levels still deserve some compensation, this would both complicate the payment process for the primary developer and set prices and administrative costs too high. This could increase the appearance of dishonesty as well as fewer sales.

A DVO programmer should anticipate his/her versions becoming obsolete at some time. If there is an expectation of continual revenue in Phase 1, the DVO programmer must continue to innovate and make new versions.

Q3: Connie made version Sundial-1A. How did she do this?

A3: She could have done this in several ways:

  • She could have enhanced the code for Original.
  • She could have enhanced the code for Sundial-1.
  • She could have enhanced the code Breakwave.
  • She could have replaced existing code with better code.
  • She could have removed some existing code.
  • She could have added a brand new feature.
  • She could have done more than one of the above, creating two or more enhancements in the same version.

There really is no rule to determine what an enhancement is or how it is made. But if a programmer makes enhancements that really do not better DVO DVOA, then the DVO programmer community should stop buying that programmer's enhancements.

Q4: Connie seems to be working several development threads. Is this allowed?

A4: There's nothing to really stop this—and it should be encouraged. I anticipate there's going to be many cross links between the threads as programmers move their enhancements from one thread to another. It's all part of the process to create that really great version, which then stands a better chance of being marketable in Phase 1 and being in the development thread chosen for Phase 2.

While Connie has to pay more license fees to get her enhancements on several threads, she will be spreading out her work to ensure a better chance of Phase 1 revenue plus increase her chances of being part of the Phase 2 royalties. Connie—and other DVO programmers—should constantly be strategizing to determine their best position in Phase 1 development.

Q5: What's to stop Connie from taking Fernando's enhancements to Atushi's thread? Or vice versa?

A5: Practically speaking, nothing is stopping Connie! She has access to Fernando's code and can pretend that it is hers. Ideally, the solution for such plagiarism has to come from the community of DVO programmers refusing to further her development threads. And Connie should also be aware that she could be legally written out of any share of any Phase 2 royalties.

Rather Connie should encourage Fernando to put his enhancement on to Atushi's work. Or she could encourage Atushi to put his enhancement onto Fernando's. When these new versions have been completed, Connie can then enhance these programs, after she pays the appropriate fees.

However, if Connie finds ways to improve Fernando's code in a development thread that Fernado is named, this would be a valid enhancement—as long as she pays Fernando's and his appropriate license fees. If Fernando has not put this code onto another development thread, then Connie cannot make the changes to the code on that thread.

If Fernando has created a great enhancement with some great coding, he should put it on several promising development threads. Not only will Fernando be helping these threads grow, he will be expanding his revenue base. If he keeps his great feature on only one thread, eventually another programmer is going to take his idea and write his/her own code to express that same feature. Fernando will have no future claim if the code is newly created.

Q6: Connie has three enhancements that she believes she can add to Dave's Original. How should she handle her development?

A6: Connie has two choices. First, put all three enhancements under one version. She would have to pay Dave $99 only once. The disadvantage is that this version would only earn her one share of the 4% royalty, if that development thread is selected for Phase 2.

Second, she could add the three enhancements one version at a time, creating three new versions of DVO DVOA (she will then be listed three times in succession in the development thread). She will have to pay Dave US$99 for each of these three versions as Dave moves from primary, secondary, and tertiary programmer. If this development thread becomes a profitable version of Phase 2, Connie will have three shares of the 4% royalty.

Going this second way has another advantage. Connie would have pushed my $99 out of the license fees to be paid. As the primary, secondary, and tertiary developer, she could arrange her three levels of license fees to total less than US$99, making her advanced version much more attractive than my original version. But would Connie be compensated well for her programming efforts at such a low price?

I would recommend that Connie's best self-interest should lie with one version with three enhancements. This version will be less confusing for her future customers to inspect and buy—and they will see more value. Instead of creating three slightly different versions on one development thread, Connie should put her resources towards putting a better version with the three features on several threads.

Each DVO programmer has to figure out his/her own balance between the best possible short-term revenue, best possible long-term revenue, paying the lowest amount for license fees, and positioning him- or herself in the development threads and in DVO programming community. Each programmer will have to develop his/her own business strategy.

Q7: I have created this great version of DVO DVOA, yet it is not selling. What is wrong?

A7: To answer your question, let's take a quick look at the 4 P's of marketing.

  1. Product: Are the enhancements you made something the customer wants? If not, then the customer will likely go to other versions.
  2. Placement: Are potential customers able to find your version with relative ease?
  3. Presentation: Is your message clear? Does your target customer understand what you are selling, especially your enhancements for DVO DVOA? How is your version different from other versions?
  4. Price: Is the version you are offering set at a reasonably acceptable price (with your fee, the secondary fee, and the tertiary fee) to the customer? How does your pricing compare with other versions of DVO DVOA? Would it be better to develop from a development thread that has lower license fees from the secondary and tertiary developers?

Before you buy a version of DVO DVOA to start enhancing it, you should answer all these marketing questions to develop your own strategy.

Even though you may have done your 4 P analysis quite well, you may still find that sales are not that great. Many corporations, with great marketing wisdom and budgets, have launched great products that were marketing failures. There really is no guarantee in any kind of marketing.

Basically you won't know how well being a DVO programmer will work for you until you try. After you get one version out, then you can make the right decision whether to proceed or abandon the DVO DVOA concept as part of your income.

Q8: Most computer programmers are not natural marketers. How can the DVO programmer community make use of programmers who are the better marketers? How about good marketers who are not really HTML or database programmers? Can such people become DVO programmers?

A8: It would be a shame for great DVO programmers to become discouraged because they can't sell their great versions. It would be a shame for this community to discourage marketing talent from helping it along. Therefore, I'm going to make some rules for talented marketers to become part of a development thread in DVO DVOA.

If such a marketer wants to market a particular version of DVO DVOA—and really adds nothing for significance features to that version, that person can become a DVO programmer and be placed in the development thread under these conditions:

  1. The marketer pays the primary developer the primary developer fees. The marketer pays the secondary developer the secondary developer fees.
  2. The marketer pays the tertiary developer five times the tertiary developer fees.
  3. The marketer designates himself as the primary developer and updates the version detail appropriately.

Note that the primary developer no longer has the responsibility of paying the secondary and tertiary developer. The marketer will be making payments directly to the secondary and tertiary developer.

By getting a license in this way, the marketer is clearly stating to the DVO programmer community that his talents lie much more in marketing rather than in programming. This marketer, who will then be deemed as a full DVO programmer, will have the same responsibilities, obligations, and compensation for Phase 1 and Phase 2 revenue as all DVO programmers. If the marketer is indeed a good marketer and is honest with the DVO programmer community, the DVO programmer community should consider this member an asset.

If the marketer is successful, the former primary developer (now the secondary developer) and former secondary developer (now the tertiary developer) should profit well from the marketer's efforts.

The former tertiary developer will be pushed out of the fee structure, which will be very unfortunate for that developer if the marketer is successful. This is the reason for the five-fold compensation for the tertiary developer. While there may an argument that this five-fold payment is unfair to the tertiary developer, there are two things to consider. First, there is no guarantee that the marketer will be successful, so the marketer is taking a bigger risk than the usual DVO programmers, who are adding new features. So for a tertiary developer on a version that been sold to an unsuccessful marketer, a five-fold payment is better than nothing. Second the tertiary developer is always free to enhance another version and keep his Phase 1 revenue continuing. Someday he just might be the secondary or tertiary developer of well marketed version.

Q9: If a marketer becomes a DVO programmer in the previous question, his version and the version he bought will be essentially the same code. If a DVO programmer wants to enhance that version, which version should he use?

A9: The DVO programmer can buy either of these two versions to be allowed to enhance the code. That DVO programmer will use his own criteria to make the decision. He need not buy both versions.

Q10: What are the costs to being a DVO programmer? How should this affect the price I place on my license?

A10: To get more sales than other DVO programmers, you may choose to set your fees very low, let's say $15. What happens when a prospective customer sends you an email expressing interest in your version?

First, you should realize that there will be several email exchanges between you and the customer. This takes time and energy. If you are not compensated for your time to be “an internet clerk” to administer this sale, eventually you will realize that you are wasting your time being a DVO programmer.

Second, not all initial contacts will result in sale. If your closing rate is 1/3, then the administration costs for the two sales that did not happen need to be paid from the revenue of the one actual sale.

At $15 a sale, you are not paying yourself a clerk's wage, let alone recovering your time spent on programming. I recommend that you make your license fee at least $40.

Q11: How will PayPal affect how we do business?

A11: PayPal will extract 5% of each transaction as their “bank fees.” As much as we would not like to pay these kinds of fees, I think PayPal is still the best option for DVO programmers around the world to work together. Another internet banking system would likely leave more potential DVO programmers out of the process.

Let's assume that a version is selling for $300, with the primary, secondary, and tertiary developer each getting $100. When the primary developer sells a package, PayPal deducts $15 from the payment. The primary developer has $285. He has to pay the secondary and tertiary developers $100 each. They each will have a $5 PayPal fee assessed against their payments.

In essence, PayPal gets $25 from this transaction. The primary developer ends up with $85; the secondary and tertiary developer end up with $95 each.

DVO Programmers need to consider PayPal fees when establishing their license fees.

As an aside, the example above seems to show that being secondary and tertiary developer is a little easier and profitable than the primary developer. While I didn't really plan for this dynamic, I can see it helping DVO programmers encouraging other DVO programmers to enhance their work.

Q12: How will accurate records of the various development threads be maintained?

A12: I am hoping that there is enough honesty in the community of DVO programmers to properly update the development thread (in “Version Details”) as new versions are created. I am hoping that the punishment of being excluded from the Phase 2 royalties is enough incentive to be honest.

I foresee that 200 development threads, each with 10 to 100 DVO programmers listed is very possible. There could be 5000 versions of DVO DVOA by the time Phase 1 turns into Phase 2.

Sorry DVO programmers! You would have to pay me a lot of money to keep track of all these versions to ensure the proper people are being included in the Phase 2 royalties.

I think a good system is there to keep accurate records for proper recording of the development thread(s) that is chosen for Phase 2. I shall leave it to the DVO programming community to build a culture that keeps proper records of the development threads.

Having said all that, I am volunteering myself to keep track of all mail and email address changes for DVO programmers if they happen to change their contact information. Please submit your new contact information, along with the names of the version you have created, to dave@davevolek.org. I will put them somewhere safe.

Please understand that it would be possible for someone else to misrepresent you in this change of contact information. While I will instruct future users of the “changed address” list to use the original contact information first, I advise you to use an email address that you are likely to keep for a very long time.

Q13: What are some possible Phase 1 features for the future?

A13: I developed DVO DVOA to what I needed on my website. I can see several other features that could be added, but weren't necessary for me to put DVO DVOA together:

  • Having the setup program size the ads (“Original” can do this, but requires some simple editing in an HTML file)
  • Better or more formatable HTML display table for ads
  • Security features to prevent unlimited copying of the program
  • Two ad units of different sizes on the same webpage
  • Animated and video ads
  • Ad stream (morphing from one graphic to the next graphic) rather than ad spots.
  • Audio ads
  • Mobile ads
  • Text ads in ad image format
  • Automated payment processes
  • Statistics Trackers
  • Interactive Surveys for ad images
  • Preprogramed ad sequence to let advertisers deliver a changing marketing message
  • Linking ad spots from similar websites using DVO DVOA (i.e. allocating ad spots to draw ad images from another publisher.)
  • Geographical placement of ads (i.e. dividing the world into regions and setting up an ad pool in each region).

I'm sure more great features will be invented and developed that I just can't see.

Phase 2

Q14: Why does Dave Volek get ten shares in the royalty payment when other DVO programmers only get one share for their version?

A14: Here's the logic that went behind this decision:

  1. Three shares for developing the DVO website to see the vision for DVO DVOA
  2. Three shares for the actual code, testing it, and writing the technical documentation
  3. Three shares for developing this structure of DVO programmers to work together
  4. One share for resolving unforeseen issues as DVO DVOA evolves and keeping track of address changes.

Q15: What's to stop a Phase 2 developer from not paying the royalties to the development thread it selected?

A15: First, the royalties have been kept low and given only a nine-year life span. It would be cheaper for a Phase 2 developer to adhere to these terms rather than face a great lawsuit if the Phase 2 version is very successful.

Second, the framework for a development thread to form an association and hire a legal team should encourage the Phase 2 to pay all the royalties directly to the shareholders. A Phase 2 developer should prefer not to deal with this association.

Q16: What are the main differences between Phase 1 and Phase 2 development?

A16: Phase 1 can be built by independent programmers, working part time and on their own schedule.

The transition from Phase 1 to Phase 2 is not going to happen by tacking on a few hundred lines of code to an existing Phase 1 version. Phase 2 will likely require a formal team of programmers working more fully on this project, adding many new features to make a Phase 2 version work. Although Phase 2 will get the benefits of Phase 1 programming and marketing, Phase 2 is going to require a massive capital investment to bring it to completion.

Q17: Given the expected investment by the Phase 2 programmers, isn’t 4% a little too much?

A17: This should not be much of a concern for two reasons. First, a Phase 2 version should appreciate the efforts made by the Phase 1 development thread to get DVO DVOA to the place where Phase 2 is viable. When the Phase 2 version is built, the Phase 2 developers won't be selling a totally new DVOA concept to skeptical advertisers. Paying 4' royalties will be much cheaper than a big marketing budget. Second, I suspect the Phase 2 programmers are going to come from a pool of Phase 1 programmers. These programmers will likely be on their selected development thread several times, so some of the royalties will be coming back to these Phase 2 developers.


Home · Concept · Marketing
Advertise on: OilFinancier · TDG · New Perspectives
Advertise like us · Buy DVOA
Purchase Details · Terms and Conditions · Setup Instructions
Statistics · The Future · Credits

 
© 2009 Dave Volek. All Rights Reserved.