[Drawkit] CreativeCommons a permanent part of DrawKit?

[Eric Jarvies]

On Jun 21, 2008, at 8:00 PM, Troy Rollins wrote:

>
> On Jun 21, 2008, at 6:42 PM, Eric Jarvies wrote:
>
>> i was just throwing ideas/opinions out there... the nature of  
>> collaboration/open source/etc.
>
> I understand what you are saying, and don't completely disagree with  
> all of it. But what you described in that document sounded more like  
> you'd like to see DK move from an open source collaborative project,  
> into more of a closed source commercial framework project. Graham  
> can of course do whatever he wants, I'm just hoping it doesn't  
> follow that course.
>

it's hard to nail down some thoughts/perceptions to words... much gets  
lost in translation, so to that end, i apologize if i may have caused  
any misunderstanding about my sharing of ideas(troy), to imply that  
they were anything other then ideas.  in truth, over the years i've  
seen great projects like graham's come and go, namely because of  
having to survive(financially).  it would just be nice if there was an  
owner's manual to success one could follow and learn from.  but sadly,  
there are only case studies and examples of previous efforts.   it  
would be nice if a project could identify a core user group, 'xx'  
number of other projects that would integrate/license the  
offering(like dk), and essentially share it's hard costs, the obvious  
benefit being each only pays a fraction of what it would otherwise  
cost them to do it themselves.  but getting this type of core group  
takes time and effort, and no matter what, it takes collaboration on  
both ends, meaning, the user must support the maker, so the maker may  
support the user(financially speaking).  and to say that this type of  
thinking is along the 'open source' line of thinking, is subjective to  
each owns idea about the matter.

dk kit is the type of framework that requires dedicated, long term  
users/licensees, because of what it is(it is not a growl or sparkle,  
for example).  and so, if graham is to realize financial success(or  
just pay for his programming labor at minimum) with dk, he needs  
people/projects/companies that are on the same page as he is, in terms  
of short/mid/long term goals, at it relates to added features and  
functionality, and the support(bug fixing of each feature release)  
thereof(again, my ideas/opinions, be they right or wrong, hammer on  
the nail, or completely off base).    these types of users are users  
that will want and appreciate graham's excellent code writing  
capability, as a means of delivering to them a viable, working, and  
kick ass product, which in turn they can redeliver in their own form/ 
app to their clients, which in turn they support.   and so it is this  
thinking(and of course, this is my thinking, and it does not make it  
right or wrong, it's just how i see it, and how i am sharing it with  
you) and reason with which i write these ideas/suggestion, merely for  
the sake of at least considering them, if for no other reason then to  
rule them out.

my particular interest in graham's dk product relates to creating a  
gis application for os x, i suppose similar to what he is doing with  
his own product.  and so, if something ever comes of it, i would like  
to work out a deal with graham that addresses core functionality,  
being improved and added over time, which he implements and supports,  
whilst affording me the opportunity to pay only a fraction/percentage  
of what it would otherwise cost me to do it myself, or pay someone  
else to do it for me, wherein i own it.  the disadvantage of me owning  
it, is that means i also need to continue improving it, meaning  
footing 100% of the bill.  and so, if it was possible for me to be  
part of a group of licensees of 'xx' number, wherein we share dk's/ 
graham's development costs, then that would give me(and my product)  
more of a chance to survive, whilst also giving graham and his product  
a chance to survive. does this represent open source, who knows...  
i've seen so many interpretations of open source that it's really hard  
to tell, so let's just say it's a flavor of open source.

anyone that has spent a lot of time creating/giving birth to a  
product, in earnest, and with passion and conviction, knows how hard  
it is to take both advice and criticism from others, as it relates to  
their baby.  inherently this goes against the grain of our make-up,  
and we are easily offended, and feelings are more on the sleeve.  so  
no doubt my words, and everyone's else's words, as it relates to our  
opinions and advice, no matter how good or bad, either in concept of  
intent, no doubt strikes a nerve.  we all want it 'our' way, and so we  
argue and bide for space, attempting to effect the outcome so it  
favors us and our own motivations.

troy makes valid points, and his likely represent the majority of  
users that would like to take advantage of dk.  breaking into the  
shareware market(and software product market) is tough, and making  
money is even tougher... much less turning a profit.  brad(uli too)  
make good points regarding 'making money on the framework' and how it  
is indeed difficult, considering what it is(again, it's not like a  
sparkle, etc.).  it's a great body of work, but it is a specific one,  
and it is a fairly integrated one as it relates to the products that  
would incorporate it, meaning it would be an integral part of the  
resulting application.  a software product that wishes to phone-home  
can easily add sparkle, and within a matter of minutes/hours, can be  
up and running.  but the software will not be dependent on sparkle,  
meaning it's easily added, and thus could also be easily removed,  
without really effecting the intended purpose of the application.  but  
dk on the other hand is something that would indeed be integrated,  
meaning, it could not easily be added/removed, without effecting the  
entire purpose of the application(correct me if i'm wrong).  and so  
this is why it is limited in the market, and why it is a much more  
difficult prospect to deal with when determining how to go about  
making it available, especially as it relates to open source, and all  
it's given flavors and interpretations).  and so, as brad mentioned,  
perhaps the best route is indeed via your own applications, and  
perhaps providing commercial licenses and contract work to third  
parties as another means of income.  perhaps dk should have a base  
code repository/license that allows anyone to use it(open source,  
commercial), and contribute back to it, whilst also having premium  
components that are plug-and-play, but must be licensed/paid for.

so, if a software developer/programmer wishes to add extended  
functionality to dk, they may pick and choose from your premium add- 
ons, and pay the license fee accordingly(and you could of course also  
offer support packages).  each add-on being self contained, with it's  
own version number, charging upgrade fees for major(additional  
features) version releases, and providing all minor(bug fixes)  
releases for free to licensees.   this would allow anyone to use/ 
incorporate dk into their app, without being bound to license fees.   
the code repo could grow more active in terms of user contributions.   
and for companies/developers/programmers wishing to purchase plug-and- 
pay add-on's to dk which you've spent your time and energy creating,  
then so be it... they make that choice, you recoup hard costs(and  
hopefully earn profits).

perhaps it's worth honestly discussing what an ideal scenario would be  
regarding using dk.  some questions worth asking might be:
	1. if you were to use dk in your project right now, upon completing  
your project, and your software application representing 100%, what  
percentage of your project/software application would be dk?
	2. if you could use dk right now, as it is, in your software project/ 
application, without financial obligation, would it serve the purpose  
your software application requires, wherein you would not need any  
additional update from the dk repo?  meaning, you take dk as it is,  
and do with it as you need, end of story.
	3. if dk, as it is, was available to you to use in your software  
application without any financial obligation to dk/graham, wherein  
you, and others, including graham, continued to improve it/contribute  
to it, each having access to these improvements(free of charge), would  
you also be interested in having paid options afforded you by dk/ 
graham, in the form of plug-an-play modules(or whatever they would be  
referred as- modules, plug-ins, components, whatever.)?  meaning, if  
graham spent his time(time=money) programming add-ons to dk, and  
offered them to dk users at coop rates, would that be something you/ 
your software application would take advantage of/benefit  
from(assuming the add-on(s) served a purpose for you/your software  
application)? and if so, would you pay upgrade fees each time that add- 
on was upgraded(major version)?
	4. if you had to create dk verbatim, what financial value/worth would  
you estimate it to have?  meaning, how many man hours would it take  
you to create dk, and what would you charge someone?  or, what do you  
think dk is worth off the top of your head?

specific questions to graham:
	1. how many man hours do you have in dk?  and if you were contracting  
this work out to a third party, what do you think you would have  
charged to create/deliver dk to a client, as it is?  personally, i am  
very interested to know how many man hours you have into dk.
	2. why did you decide to make dk an open source project?  what is it  
you wish to accomplish with dk, or what do you think will be  
accomplished that will benefit dk/you in doing so?
	3. what do you think is the potential market-size for dk, in terms of  
actual software applications that would use/benefit from it in one  
form or another?

there are many other questions that could be posed, but these are  
fairly straight forward and easy to answer.

i find this(dk, you, and the early stages of making a project open  
source) a very interesting and controversial topic, and i hope my  
opinions, comments, point of view, and questions are not perceived in  
a negative manner.  i am just truly interested, as it is indeed an  
interesting topic.  i'm impressed by your wherewithal as is evidenced  
in the resulting dk framework, and i personally see it as a viable  
means by which others(myself included) may quickly get their own  
software application to market.  but as previously mentioned, what i  
am most curios about is how you are able to turn this into a  
financially prosperous model in terms of opening it up for others... i  
mean, it seems you are perfectly capable of growing and adding to dk  
as is needed, and as you see fit, for purposing/using in your own  
applications, without the help/contribution of others.  so the trade- 
off is a bit perplexing to me, and perhaps it's not understanding your  
intentions that is causing me to be as curios as i am.  like, why did  
you not first release source code to gradient panel, a much 'lessor'  
project in terms of scope(not discounting it) when compared with dk.   
and gradient panel has a much larger audience, as it is similar to a  
growl, sparkle, sm2dgraphview, etc., wherein it can be added to an  
application to extend it's capability, whilst not being dependent upon  
it.  certainly gradient panel would be a much easier open source trial- 
run for you then would be/is dk, or at least this is how i see it.

respectfully,

eric jarvies



> --
> Troy
> RPSystems, Ltd.
> http://www.rpsystems.net
>
>
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net