[Drawkit] CreativeCommons a permanent part of DrawKit?

[Eric Jarvies]

graham,

a very log read... probably stuff you you've already considered, so  
think of it as merely someone collaborating as much.

On Jun 20, 2008, at 7:47 PM, Graham Cox wrote:

> Hi Troy, Everyone,
>
> From today, DrawKit no longer uses the Creative Commons license  
> (which was not very appropriate in any case). Instead, a BSD-style  
> license will apply. The next Beta drop, due very soon, will include  
> all updated headers and a new licensing text document. The CC  
> license will probably still apply to documentation, etc where it is  
> more appropriate.
>
> I'm sure the use of a BSD-style license won't be controversial.

good choice.

>
>
> What might be however, is the fact that I'm considering charging for  
> commercial use (definitely free for non-commercial and education  
> however, and this is clearly stated in the licensing doc). This  
> stems from the fact that I too would like to put food on my family's  
> table, and right now, Drawkit is not helping me do so. My aim is to  
> build commercial apps on top of DrawKit and generate income that  
> way, but the fact is that work on DrawKit is taking up substantial  
> amounts of time which is directly delaying work on other projects,  
> which as a result are unlikely to be completed for a while yet.  
> Having given up the day job in order to commit fully to these  
> projects (and Drawkit itself) this leaves me in a position where  
> it's only the good will of my wife that is keeping us afloat.  
> Therefore I have started to think about whether I should try and  
> make some income from DrawKit itself.
>
> At this stage I'm not committed to the idea, but mulling it over. I  
> would expect that any such fee would be negotiated on a case-by-case  
> basis with the potential user - clearly if you're Microsoft I would  
> charge much more than if you are a struggling Indie developer.

you really should setup a subversion repo and trac front-end(with a  
handheld of useful trac plugins).  apply an hourly rate to your work.   
checking out docs from the repo, and checking them back, properly  
comments with what was done, will keep track of time that was spent on  
each and every part of dk.  re-purpose this data and post the  
statistics on your trac front-end, along with number of documents, how  
many lines of code, etc.  if you apply $50 value to each hour you  
spend on dk, and you spend 500 hours on it, then it indeed has a value  
of $25k, for example.  put up a donation pool allowing folks to  
contribute, and of course, deduct those amounts against time invested,  
always keeping an account of this(full disclosure).  do not bother  
with other expenses like electricity to run your computer, or internet  
access, etc., as those you would pay anyways... just keep track of  
your time/programming hours.  also, you can go to guru.com,  
rentacoder.com, etc., and pull from those sites statistical  
information(averages) of how much programmers earn to write obj-c  
code... you could take info from a dozen of so sites and use the  
average amount as the amount you apply towards the hours you spend on  
dk.

so let's say dk costs $25k to code.  ho many applications does dk need  
ot be used in in order to pay for that.  then, with both bug fixes and  
feature additions, how much is needed to pay for that.  of course,  
this only accounts for your hours.  naturally, as a project, it also  
needs to net a profit(fruits of your labor). so, dk needs to seek out  
projects online that could benefit from dk, and negotiate with these  
projects/people, working out deals for them to use dk.  what's the  
magic number?  25 projects at $1k each?  then, each pays a fee for  
major upgrades(minor bug fix version being free). this fee needs ot be  
based on what was added to dk, and why.  and so, the svn/trac site  
needs to keep track of the most active interest in dk features... if  
the users want a special grid system, or a gis component, then figure  
out how many man hours it will take for you to implement this, and  
post that number on the site ,and allow the user to vote which  
addition is most pressing/important, and then commit to that.  the  
whole benefit of another project/company/person using dk, is so they  
need only pay a fractional % of what it actually costs to code/create  
that update/feature.  if a feature costs(after rfp'ing it out, and  
doing your own calculated cost estimations) $5k to implement, then you  
need to figure what value dk has to it's type of users.  meaning,  
would a dk user pay $500 for the feature, or $200, or $1000, or ???

go into this looking at at as a cooperative.  you need to establish  
when the threshold occurs.  this means, how much more does dk need in  
order to be a final, plug and play offering?  wherein if nothing more  
was added in terms of features, but only existing code was fixed of  
all it's bugs, then what would that be and when would that be and how  
many total man/programming hours would you have invested in it, and  
what would be the hour rate of each of your hours?  what dk is to be,  
and how much dk costs in terms of programming hours, are the two  
targets you need to figure out for certain.  once figured out, then  
you will have a financial worth based on minimums(man hours only).  if  
from that point nothing els was added to dk, then all that would need  
to occur with dk periodically, would be making modifications each time  
a new os version was released, assuming the new os release requires  
changes in dk(usually the case).  then, it's these changes and man  
hours that much be paid by license holders.  so, if you have 20  
license holders, and the next os update required you to invest $1000  
in man hours, then each license holder would need to pay $50 if they  
want the update.

figuring out the target numbers is the most important part of this.   
if dk costs you $50k to put together, then you need to figure out the  
minimum number of licenses holders that would be required to support  
this effort.  so this means you need to know your market, which means  
you need to figure out who dk's market is, and what that specific  
market is capable of paying in general.

of course, you need to also figure out you committed long term plan,  
which is presented to your potential buyers.  ideally, you want  
clients that ant you to improve dk, so with each feature update(major  
versions), their own product improves, meaning they too can charge  
their customers and be justified in doing so because the added  
feature(s) is worth it.  and this, without doubt, is the toughest part  
of figuring out where dk is to be in the marketplace, and this comes  
with time and with user feedback, like you've been getting these past  
months.  will your majority market-share be gis, cad, cgi, all the  
above?

i would suggest you spend a week or so searching online and concluding  
what the top 20 os x frameworks are that are similar in scope to dk.   
go through their lists/history, and see how long they've been at it,  
their current user-base, licensing fees they charge, etc.  dk is not a  
growl(free), nor is it a sparkle.  so what is it and where do it fit  
in?  dk needs to target the printer/plotter manufactures, and any  
hardware product that requires a software component... these will be  
paying customers. cad/cam/gis/etc companies or government agencies  
that must satisfy a process using a custom software application...  
these will be your paying customers.  start-ups, both funded and out  
of pocket... these will be your testers and provers, and some will be  
your paying customers.  your non-paying users will be most important  
to dk in testing dk, reporting bugs, etc.  and so this is why you do  
not charge fees for opensource/free projects.

in order for you to generate income that will justify the effort, you  
need to target those who would benefit most.  this means dove-tailing  
and piggy-backing on larger, established projects.

and of course, your own products...

but no matter how you slice it, the bottom line still needs to be  
accounted for, and if you let a week turn into a month, and a month  
into a year, without applying a value system to dk(like the example/ 
ideas i mentioned above), then dk will fail, because if it cannot put  
food on the table, then you cannot dedicate your time/life to it.  so  
establishing relationships with folks like troy, et, al, is a must.   
and from the get-go, both troy and you need ot know where each stands,  
and where each is going.  if troy is building a product that will  
depend on people purchasing it, then troy has to compete in the  
marketplace, and he has to find his customers, just like you have to  
find yours.  if you offer a viable product that does what it is  
advertised, then customers will remain customers, loyal to their  
provider... just as the provider must also be loyal to their  
customer... it's a two-way street.  but i cannot urge enough how  
important it is for you to establish a fair scale/gauge and fully  
disclose it as suggested above... FAIR people cannot argue or dispute  
such disclosures... they can only respectfully negotiate terms... and  
that's the name of the game.  so establishing what exactly it is they  
are negotiating is key for you now, and the sooner you conclude the  
better.

if i came to the dk site for the first time, and i was able to see, at  
a glance, the time you've spent, and the value/worth of this time, and  
discern for myself that your numbers are fair, then i will continue  
investigating dk.  once downloading it and seeing for myself that it  
is what it claims to be, then i will continue investigating it.  once  
learning on your rules/terms, and your short/mid/long terms goals for  
dk, and what is required for it to continue/succeed, then i will  
continue to investigate dk... and more importantly... you!  if i  
realize that you are grounded in reality, and you disclose goals(full  
disclose), and history shows you meet these goals, then i know that if  
i support you by becoming you customer, that you in term will support  
me by doing what you say, as it relates to improving/building/ 
expanding dk.

go to sourceforge, et, al, and look at the graveyard of GREAT initial  
starts.  there are so many projects that had such great potential, but  
because they were mre passion based then they were financially based,  
they failed.  don't get me wrong... passion is important.  having a  
labor of love is important, and always these yield a greater work.   
but if you cannot pay your bills spending all your time doing it, then  
there comes a point you cannot do it anymore.  and this is why full  
disclosure ALWAYS works best.  people that will not use or benefit  
from your project would likely donate $10-20 to it if they were able  
to breath the fresh air of honest, realistic, full disclose.

if dk needs 30 customers to survive, then 31 customers means a  
profit.  how many customers does dk need?  and how much do they pay?   
that is the question that you need to figure out, and that means  
market research one one side, dk development in the middle, and  
marketing and sales on the other side.  nail-down this tri-combo and  
dk will succeed as an open source project that remains active and  
advancing.

regarding amounts charged to startups, and people who are not  
companies with product offerings, or that have funded projects... work  
out percentage deals with them, wherein you get 'x' amount of each  
sale.  this way, you support that person, who is much like yourself,  
and what goes around comes around... you will be supported in equal  
fashion, or greater.  people will argue there is no way to account or  
track this type of deal... and they are right.  it takes honest people  
to make this type of deal work, and so, you will quickly learn who is,  
and who is not honest, and at that point you waste not another second  
of your valuable time on those types.  but those who are honest and  
earnest, they'll send you that monthly check, be it for 3 sales or 300  
sales.  if their software is benefiting from dk, and they are  
succeeding, then they have their heads on straight.  also, the os x  
community is easily ascertainable, meaning, between macupdate.com,  
versiontracker, et, al, one can get a ballpark idea of what another is  
doing in terms of their software and it's market penetration.  this  
assumes mass-market retail software products.  on the other end, you  
have mission-specific products, that perhaps will only ever yield a  
handful of users/customers, but perhaps those customers pay a much  
larger amount for that license.  in these cases, once again, that is  
easy to investigate.

i would say that for start-up software makers that wish to use dk, if  
you only charge them a one time fee, then that would be bad for dk/ 
you.  i truly believe you need to get your software into products that  
intend to benefit from your major version updates.  it's this type of  
relationship that dk should seek.  mr software maker, dk will deliver  
to you 'this' and 'that' on a regular schedule, so that you do not  
have to pay the "$x" amount it would cost you if you did it solely,  
but instead, it will only cost you a fraction/percentage, because dk  
is spreading the actual development cost across 'x' number of  
customers like yourself.  so what would cost you XXXX is only going to  
cost you XXX.

in closing, i truly hope dk matures and succeeds, and if it were all  
based on the code alone, it surely would.  so to that end, i hope the  
other key ingredients to making dk successful do indeed manifest for  
dk, and for you, as you clearly deserve it from where i am sitting.   
dk is wonderful and full of promise, it need only find it's right  
place, and serve that place well.

this instruction video we do for you/dk ... i assure you it will  
generate a fair amount of attention, and modest interest in dk.  gotta  
cross-market/promote whenever possible, and doing instructional videos  
using dk as the subject is ideal.  most/all the cocoa/obj-c sites will  
surely add it to their pages, they need only be made aware of it.

another thing, regarding other successful open source projects, both  
free and fee based, i would suggest making dk play nicely with them.   
from growl, sparkle, baseten, to lizardtech's mrsid sdk.  doing so  
gains you real estate on their sites, thus creating a wider audience  
awareness of dk.

oh, one last thing... i know you are creating your mapping  
application, as you've mentioned.  initially, finding projects you  
could contract, which would use dk, and in part(or in whole), allow  
you to build/add to dk, as a direct result, would be ideal.  this  
would provide income for you, whilst also adding to dk overall.

regards,

eric jarvies


>
>
> So please let me know your thoughts. I don't want to kill off the  
> interest and traction that is slowly being gained, but hey, we gotta  
> eat! If you are a commercial developer, would this cause you to  
> rethink your project? Look elsewhere? What?
>
> cheers, Graham
>
>
>
>
> On 21 Jun 2008, at 1:27 am, Troy Rollins wrote:
>
>> I know that this issue has been discussed on the list from  
>> reviewing the archives, but I'm wondering what the final result is.  
>> Since I feed my family from selling the software I make, I can't  
>> afford to use anything in it which virally affects my ability to  
>> sell it. As I understand it, the CreativeCommons license will have  
>> this impact, and force me not to use DrawKit - which would be a  
>> real shame, since I'm really getting the hang of it.
>>
>> I honestly don't mean to be "pushy", but any chance this will be  
>> (officially) clarified sometime soon? Do I need to rip it out of my  
>> app now, before it goes too far?
>>
>> Either way, thanks again Graham.
>
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net