My views about the Rainbow project (Could also be applied to DNN)
Hi all, It's been a long while since my initial blog....sorry and a lot has happened (went on holiday and I've been busy at work which is why I haven't had a chance to blog).
Anyway I've been following a thread on the Rainbow forum at www.asp.net and what started off as a quick response quickly grew.
To see the thread (about modules within Rainbow and whether or not the number of commercial modules in DNN is a good thing) please go here:
http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=326534#328197
Anyway here is what I just said:
"Hi all,
You have to love these discussions
I have been contributing to rainbow since it started in November, but please don't take my view as the official view (This is just my opinion).
I follow DNN's progress and I just installed the latest version to see how it worked. I think they have done a great job.
Rainbow is still rough around the edges but I prefer it (I won't go into the details etc as that has been discussed on the very many "which portal should I use" posts).
This is how I think we (the rainbow project) should (Take note: "should" not "will") proceed and for those DNN contributors out there, they might want to consider this also:
Core Framework
------------------------
* You have a team focused on the core (get standards in place, extra core functionality etc)
The core should be made up of different projects/components/dlls.
E.g. There are currently 3 seperate dlls for core functionality (plus the rainbow.dll):
1) Esperantus (Language Handling)
2) Rewrite.Net (Url Handling)
3) A Schedular project to allow core code and modules to schedule activities.
Ideally these projects can work together or independantly and are not 100% tied into the portal (Esperantus and Rewrite.Net can be used by standard websites or even DNN).
With seperate projects DNN & Rainbow developers "could" work together on some aspects (esperantus for example) and still have their own portal implementation (e.g. use a different url handler as the way rainbow & DNN handles urls is different).
This saves a lot of time by not re-inventing the wheel (It would also mean developers could just use parts of either framework when something custom was needed [neither rainbow nor DNN suits every situation, but sometimes certain parts of the framework could be used....e.g. Esperantus]).
Free Modules
-------------------
* You have a team focused on Free Modules (we currently have some people doing this with Ender and Jakob doing a great job as project co-ordinators).
This helps insure that there are useful modules that keep in sync with the portal (As the module team stays current with what is happening to the core). It also means people can achieve more at a lower cost of entry.
Currently all modules are included in the core, personally I think in the future it would make sense to seperate them:
- One project - Core framework made up of multiple building blocks
- Second Project - Free Modules.
With regards to the second project whether or not this should be 1 solution with multiple projects (one for each module - Each module contributor is lead co-ordinator for their module and they in turn are co-ordinated by Ender and Jakob so that they keeps in line with future core releases) I don't know. I think that it might be a good idea but that is still to be discussed.
Commercial Modules
---------------------------
* I agree with the post that the reason why there may be more commercial modules for DNN is because of the size of it's user base. But I also think that it is because we haven't released a final V1 release (No point building a commercial product for a moving target).
Personally I think people creating commercial modules to earn some extra money (for single developers or a small group) or as a business (A company dedicated to selling modules) is fine and it gives people more choice (Some commercial modules may offer support and offer functionality not provided by the free modules).
I'm moving back to London in November after living in Denmark for a year in a half and I plan on creating a commercial module at some point to earn a bit of pocket money as I settle back into London life.
For my commercial module (I haven't even started it yet but I thought I would use it as an example) I plan on doing the following and I think it's a good idea for either portal project:
1) Once I have developed and tested it against a solid release e.g. DNN 1.10 or Rainbow V1 I will give a license to all portal contributors (i.e. they can use it on unlimited websites for their site or their client's site but they can't simply resell it as a module) because without the people who work on the core I wouldn't have a portal for my module and without the people who contributed free modules my audience audience wouldn't be as big etc. Of course I would also offer it to those that contributed documentation etc as their contribution is just as important as the others.
Why do this......
a) It's a way of saying thank you for their time and effort.
b) If all other commercial module developers followed suit, it would be an added incentive for additional people to contribute their free time to the project, which would hopefully mean a better product in the end for everyone.
2) It's true that commercial modules may not keep up with the opensource ("free") ones with regards to the rate of change etc. So for commercial module developers I would suggest the following idea:
a) Sell & support your module (I'm not saying they don't already)
b) Give a free license to contributors (as mentioned above)
c) If people like and use your module and would like to contribute bits of code to it in order to improve it, give them credit for their contribution and give them the next upgraded release for free (Or offer them part of the proceeds depending on how much code they have contributed....entirely up to you). This will not necessarily mean that it will evolve as fast as an opensource module, but it could mean that it may grow faster than one which is simply commercial (a hybrid of sorts).
Anyway these are just my thoughts that I thought could apply to both projects.
Let me know what you think and please be gentle
Regards,
John"
Let me know what you guys think either through the thread, blog comments or email.
Cheers,
John