Dang it. I had a whole hours worth of ideas written here, press
the 'Post' button and get a 'Sorry, an error occurred'. Hit the
back button and it's *ack* gone! Like five times.
Anyway, here were my major points, of what seem to be the issues
w/source, how DNN developers sell modules, and the issue if Core Team
compensation in general. Please remember these are just one
person's thoughts.
1. Would a Subscription Model be the ideal way of selling
modules? Personally, with the manner in which the core product is
constantly update, I think a subscription model for add-in modules
would be the best way to take care of customers. This is from one
customer of course, just me. I've lost us a lot of money by
purcasing single modules w/no source, and now it's money tossed to the
wind.
2. Would a Subscription Model improve revenues, yet also improve a
customer relationship? Again, this is one of my main
issues. Customer relationships...or the LACK of them. It's
why I'm so taken w/Scott's Subscription Module and his whole site
setup. He has forums to discuss issues and potential features
w/customers. Polls to find out what they'd be interested
in. Pages that talk about what he's thinkin' of writing
next. You can PM him. He's available. Yet the site is
automated enough that he still manages to be able to add modules, and
it's easy to see the new modules.
3. How could the DNN community optimize the goal of a 'community', yet
provide the best means of success to all developers, including the core
team? Well, IMO, a site that lists all modules available.
That *any* developer can register and add their Subscription
information and the modules available is a start. I know that
dotnetnuke.com has something like this, but they've created a barrier
to entry, and they've made it an additional piece of work *they* have
to deal with, instead of allowing each developer to deal w/it.
What Macromedia, Adobe, Microsoft and other companies that provided
products w/API's so developers could add plug-ins to add features to
the products, is they had/have a 'catalog' that add-in developers could
pay to advertise teir wares. Well heck, the core team could just
add the URL information of the custom modules site. And make it
separate from DNN. Thus anyone that downloads the DNN code (who
reads the docs of course!), would know of a central area for all
Subscription DNN module sites.
4. How to recompense the core team? This has been an issue
in my mind ever since I found DNN. I keep thinking, all these
add-in module makers are getting revenues. Yet the folks that
created the environment don't get diddly. Doesn't seem
right. I know the Open-Source Model, and all that. And
that's good. Keep it that way. But say the core team
decided to make a Subscription Module a sub-project, or develoopers
just agreed to sign up for Scott's site and download his. Anyway,
if it was a sub-project, then they could add a feature to allow
multiple paypal payments to vendors...one to the developer, and a
small, reasonable percentage to the core team. And perhaps even
make the percentage recommendations based on how much someone is
charging for a module. I mean if someone is selling a module w/o
source for 300 bucks, it only seems fair the core team get a larger
amount. They could divvy up the funds as they wish, of course,
also. The vendor could even stipulate what percent if they
wish. This way, the core team *is* getting recompensed for all
their work, the developer ain't gonna miss 5% or whatever, and the
advertising part is taken care of because the URL would be known to
access all the info about these Subscription Sites right there in the
'install notes'. And this would help resolve the next potential
worry....
5. Would adding subprojects end up hurting developers?
Well, not if Item 4 was implemented, right? I mean, the core team
could concentrate on improving and adding features to the core.
Which would be free. Revenues would be genned from the small
percentages from *all* modules using the subscription module (say this
would be a requirement to get listed on the Subscription Sites and
Module Available site...that the developer download and use the
Subscription Module). Then, why would the core want to start
making custom modules? They get revenues generated from the ones
there already! Now sure, perhaps one or two features of some
modules, that are closely related to the core in the future might get
bounced, but in general, it's a built in way to provide funds for the
core team, remove worry that there'll be a mountain of sub-projects in
the future, DNN users would almost *all* be familiar w/the URL to find
and subscribe to get modules, and most important...it would still be a
community ala Scott's thinking.
6. Related to Item 1, say some Subscription sites aren't
successful. Well, it could be because their code stinks, or
there's a vertical market that isn't interested in what they have to
sell, or lots of reasons. There's nothing stopping future
Subscription Providers to join forces to improve *all* their
revenues. Say one Vendor has a forum module (this is just
an example!). And another has a Private Messaging module, and
another has a Chat module. Well, there's no reason why they
couldn't join forces, create ONE subscription site, and provide all
three related products. And just charge a higher yearly
subscription fee for access to all of them. It would mean less
work because three developers are maintaining ONE set of customers, and
would likely lead to increased revenues to boost, because folks that
might not buy a forum, but want PM would not have access to both.
And vice-versa.
7. Finally, folks could still advertise specific modules and stuff on
sc. No one is stopping anyone from doing this. In sc's
defense, they saw a hole in the marketplace, and like any entrepreneur,
took advantage of the opportunity. But IMO, selling module by
module, with umpteen upgrades, is a death knell. Impossible for
us customers to keep track of, and IMO, DNN is *crying* for a
Subscription based model. Right now it's a veritable monopoly
however.
And there's no standard on providing source and such. And the
closer the community stays, the easier it is to know if someone's
stealing (shame on them) PA's and using them w/o payin' for them.
That hurts EVERYBODY. Us customers, because it means that vendor
might not be around, obviously the vendor, and also the core team,
because they wouldn't get their donation percentage. Anyway,
that's my two cents. I hope no one takes this as an attack,
because it's not meant to be. I just *like* this community, and
want it to have recommended policies in place so it stays one, no
matter how big we are. I remember a couple of days ago some
PHPNuke dide coming over here and asking how the heck can people be
charging for add-in modules when they're free w/PHPnuke. Well,
all I can say, with my many years experience in marketing and a
consumer is, 'ya get what ya pay for'. I used to use PHPNuke, and
don't anymore. I won't get into the reasons. Let them
argue about it.