Will "the Mighty" Strohl

Helping With DotNetNuke Bug Fixes

DotNetNuke, since its very beginning has always relied on the community for all levels of involvement.  The core code base has never been, and still isn’t any different.  It is, after all, still an open source project, albeit a very large one now. 

There are numerous bugs that are in the code base right now.  Thankfully, most of them are small ones.  The larger bugs require a significant amount of time and resources, and more importantly, extensive testing.  Those bugs are the ones where the DNN Corp engineers really shine now, as they tend take the lead on those bugs.  However, that amount of time and resources does leave many of the smaller bugs leftover, waiting for someone like you to help with.

As a result, I often see statements in forums and twitter resembling something like, “This is such a simple and easy thing to fix. I cannot believe that DNN Corp hasn’t fixed it yet.”

I have heard many different reasons why various people don’t contribute any bug fixes to the DNN project.  I hope to dispel any myths about these questions here.  It is my intention to help you feel comfortable submitting your own code to the DNN project.

I Don’t Know How to Contribute

Since our community is so large and spread across nearly every continent, it’s no surprise that many people don’t know how to contribute code to the project.  Probably the easiest way to submit your own code to the project is to login to the DNN bug tracking tool, and submit your code file and/or changes.  This is quite easy. 

Just create an account, login, and click “Create Issue.”  The rest should be self-explanatory.  However, be sure to be as descriptive as possible in explaining your issue and the code changes you wish to submit.  Be sure to also be as thorough as possible in explaining what the proposed changes in the code are, and why.

This is slightly different with existing bugs.  In that case, just find the bug that you think you’ve fixed, and submit a comment to it.  There, you will be able to also talk about the same things already mentioned, as well as submit your proposed code changes in attachments.  Easy stuff!

If you’re a developer, this gets even easier though.  You can submit bugs using SVN!  Philip Beadle did a great job of explaining how to do this, so I won’t steal his thunder.  Instead, go to his blog, where he tells you how to submit a bug patch using SVN.

My Code Will Never Get Used

This is, by and large, the biggest myth in the DNN community.  While I can completely understand why some people feel this way, it is simply not true.  For example, I have submitted probably 10 or more possible bug fixes during my time in the community.  I estimate that only 3 of them were ever used.  (Purely guesses on both numbers, as I didn’t research those numbers before writing.)

While I am sure my proposed code fixes worked quite well, there are any number of reasons that they might not have been used.  Since, I cannot remember each of the submissions I’ve ever submitted, I am going to speak about this in more of a general nature.

First, there are any number of possible use-cases that I might not completely understand that DNN implementations are worrying about, and my code might not be sufficient for those instances. 

My code might contain an unknown security flaw.  (Few developers know security too.) 

My code could be irrelevant because a new feature or refactor might already be planned or in progress which will not require or conflicts with my submission. 

Additionally, due to the resources that were in place, my code might have never gotten reviewed to be included into the core.

The point here is not to further discourage you from submitting your own updates, but rather to prepare you for that moment where you get no feedback about your seemingly “perfect” code that you submitted to the project.  There could be any number of reasons that it didn’t get included (yet?).

Why Should I Contribute to DNN Corp? They have paid engineers now.

Yes.  There are indeed engineers that get paid to help develop new features for DotNetNuke.  However, that doesn’t mean that there are enough of them to fix everything – especially in the time line that you’d like.  Also, since they are paid engineers, those valuable resources are much more likely to first be directed to mission critical stabilization, new features, and bugs that are mission critical first – potentially leaving a bug that’s important to you behind for a future release in the near or distant future. 

Like any other company with an engineering department, there is a finite level of resources with which to use. 

DISCLAIMER:  I have absolutely nothing to do with how or what goes on in the engineering department at DNN Corp.  In fact, some of the “reasoning” listed here is purely speculative, but based on my experience working in other companies.

Do you really want that bug that’s nagging at you fixed now? 

Think of it this way, if there is a bug that you want fixed, is it better for you and your customers to wait until DNN Corp can put your specific bug on their list of priorities, or should you fix it quickly yourself, and see it put out in the next release cycle?  On one hand, you would have no idea if or when it would get put into the road map.  On the other hand, you could be instrumental in helping to fix this seemingly simple bug that’s nagging at you and many other community members.

Think of the value that you would have to be able to tell your customers that the bug will be fixed, which version of DNN it will be in, and it was YOU who found and fixed the issue!

The good news behind all of this is that as a community member, you still have more power than you think you have.  We are each part of the driving power that continues to keep DNN successful today.  Without you and your code contributions, DNN wouldn’t have gotten this far, and this remains a truth today, and through the future.  DNN is and always will be an open source project first and foremost.

Look at some of the successful open source project such as Mozilla, MySQL, Linux, and so on.  Many open source projects have companies that guide the way now, but their communities continue to drive the project forward in terms of bug fixes, new features, and more.  (Yes. I know this statement varies slightly with the project, but you get the point.)

“Open source only works when you contribute.”
Joe Brinkman

I love that quote.  :)

blog comments powered by Disqus