I can think of two reasons why you’d be a DNN Platform addict. Either you think it’s an awesome tool to make some money or you think you can make some money using this. I’m kidding. There is a second group. Those that itch to work on something bigger than they would otherwise be able to work on, together with some of the sharpest programming minds on the planet. Obviously I’m not excluding you’re here for both reasons. But the focus of this post is on the second group. Those that have been bitten by the Open Source bug.
A question that pops up regularly on my email or in forums is: how can I help out? People become enthused by what they see and have a desire to do something back for “the community”. This is awesome. We welcome you. You are carved from the same tree/hewn from the same rock as the rest of us (or however the expression goes). But there is a significant chance this ends up in a disappointment for you. Why? Well, commonly due to a mismatch of expectations. I’ll try to elaborate on some common causes for this.
Common causes of expectation mismatches
Your use case is not necessarily the most common one
Typically, together with our desire to contribute comes a particular scenario for the end product. I.e. we have an image of what the solution should do which it currently doesn’t. This can take the form of a use case you need to solve for a customer of yours, or a pet peeve you’ve cherished. For instance, one of my pet peeves is for a module to cater well in multi lingual as well as non-English scenarios. Another is flexibility for “integrators” (the people that make a site for a client based on DNN using components that we’ve built). What is sometimes very hard to swallow is that others don’t necessarily see your pet peeve as particularly important.
This is where the leadership of the project lead is important. It is the project lead that decides which use cases will be addressed and which won’t. Yes, as in any civil collaborative effort the team has a chance to bring forward use cases and pet peeves. But ultimately this needs to be brought to a coherent vision for the project. An Open Source project cannot survive as a kind of democracy where everyone gets to contribute one goal in turn. Chances are you will end up with a project that wonders in all kinds of directions. I’m convinced it is better to have a clearly defined project that delivers a quality product, than a forever changing product which tries to adapt to the whim of the day. Give the project an identity. And as a potential contributor ask yourself the question: what is my primary goal for contributing? Is it to implement a feature that I want rolled into the product? Then be prepared for “no, thanks” if it just so happens that it doesn’t fit the project’s direction.
We need more than just programmers
This should not need a lot of explaining. Obviously a module consists of more than code. We need designers, testers, documentation writers, etc. But as obvious as it sounds, as hard it is to actually get solved in Open Source. Most people that flock to this platform do so because they are .net programmers and they realize this is an awesome web application framework. Being offered to help out testing or writing documentation is not only demotivating, it is maybe something we’re not even able to do. For the blog module I had testers that helped out. But the documentation I wrote myself. Why? Well, since I rewrote the module and had the overarching vision of the module, the manual was already there in my head. It just needed to get written down. If someone else was going to do it, they’d have to first pick my brain, write this down, and then go through revisions as I’d pick out the mistakes. This is not very motivating for someone doing this in their free time. With regard to design, the story is not all that different. I’m somewhat dismayed that there are so few quality designers that are willing to invest a serious amount of time to our projects. From my perspective, in any case. So ask yourself what you’d really like to do and if this is something that (1) you’re good at and (2) something that the project needs.
Sometimes less is more
This is probably not a big surprise, but every team working on some part of DNN or a module needs to be managed. So DNN Corp manages everything related to the DNN platform, but all the modules are managed by volunteers from the community. And as anyone will attest that has tried this before, managing engineers is like herding cats. Coercing them to a common goal is extremely difficult and time consuming. It takes a lot of energy. And given that most of us would just like to program and that most of these teams are indeed led by programmers, this management task feels like an extra burden that doesn’t necessarily translate into more/better features for the end product. I know, I know. This is somewhat of an over simplification. But we programmers love to code, not spend time on meetings. The bottom line is: if we invite more people to join, this management task increases exponentially. So having more people on board needs to be carefully weighed in a cost-benefit approach. Does this person provide the significant contribution to warrant enlarging the team. What is striking is that this is common knowledge in business, but in Open Source we are often desperately looking for good contributors so we tend to overlook this.
We may need your contribution by tomorrow
Work on modules typically takes place in sprints. That is: we don’t work on a module the year round. Instead, we let a new release simmer for a while, sifting through bug reports to see if there’s anything critical that crops up, before starting work on an update. I then typically program for a number of days, discarding all other work. I completely submerge myself. Cut out the rest of the world. No distractions, just coding. But in a collaborative effort we need to ensure that each other’s availability doesn’t lead to certain team members finding themselves twiddling their thumbs just when they are motivated to sprint just because they have to wait for someone else’s contribution. This is where it’s important to realize that when you volunteer, you may need to “make time”. You may need to be available when the rest of the team needs it. This is incredibly hard in the Open Source world as most have a “daytime” job that will take precedence. So be honest to yourself and the others. What are the chances you can make some time?
How to help when you’re not in a team
From the above I hope you can see that joining the team as a developer is not always possible. And keep in mind that most often developers will prefer to work with other developers that they know. So networking is important, too. But here are some tips on how you can make yourself very useful and become more visible (i.e. network).
Help with debugging
If you’re using the module, you’re already helping out by testing it. Obviously, when you encounter an error you will want to share that with the developers. And Codeplex/Github/etc have good mechanisms to do so. But there is a way you can both help the team and increase your own understanding of the module. By actively helping with debugging. I.e. loading the source version of the module and trying to trace the error to its origin (obviously you’ll need to have the skills to know how to do this which is another great learning opportunity). Typically, a good bug report will include at least the steps to reproduce it. But that doesn’t mean we’ll be able to. Maybe it is related to an external factor. It is very frustrating for the developer when he/she can’t reproduce an error, because you know you won’t be able to do much. And you’ve still lost the time to try to recreate it. So instead of throwing the problem over the wall to us, try to take it one step further and try to determine what the real problem is. E.g. “variable x is not set when the user is not logged in because of the condition in line 123”. This makes it much easier for us to improve the module.
This will be the subject of an entirely new post, soon. But there is an undeniable move toward GIT (distributed source code control) and the methodologies that come with it. This significantly lowers the barrier for you to submit code to a project. So if you’ve been able to solve a bug, you can submit the necessary changes back to the project as a so-called pull request (requesting the project manager to pull in and merge your changes). This is the future. And this will be explained in more details in an upcoming blog post. Currently the DNN MVPs, together with DNN Corp, are looking at how best to move forward with various “core” modules to allow for these pull requests.
Help spread the word
The lifespan of any Open Source project is increased as the number of users grows. The more people that have a vested interest in the survival of the project, the easier it is to find people that will contribute as it is more gratifying than working on some marginal project. So you can help by making sure everyone that could be a potential user has all the info he/she needs to get going. Maybe do a screencast if that’s your thing. Or a blog post. The more exposure, the better. And the better the site looks in those examples, the more uptake of the module. Strive for perfection. It’ll reflect well on both yourself as well as the project. Tweet about the project. Post on Facebook.
Related to the above: help other users by answering questions in the forums. It’s a no-brainer. The developers are busy fixing bugs. We can’t do everything and keep an eye on each and every single channel. We all have other work to return to. An easy way to get started in the community is helping others as soon as we’ve found out ourselves how things work. In fact, this is how I started back in 2003. Answering questions in the DNN forums.
Avoid being unhelpful
Somewhat tongue-in-cheek, but with a serious undertone. Seriously, there are a few things that can tick me off working on an Open Source project. And when you find yourself at the bar after hours during a DNN event, you can corroborate this with the people around you.
Vague error reports
The ultimate worst report is “this module doesn’t work”. But there are milder forms that are equally unhelpful. “The upgrade failed”. What upgrade? I.e. what version were you on previously? What didn’t work? In other words: please be verbose when describing what you did and what you saw. And please don’t forget to mention version numbers (both the module and DNN).
Highly unlikely errors
I saw this recently and I felt irked by it. A tester reported in with a 100% use case blatant error. That is: a huge error that would occur in just about every conceivable scenario. Thinking of the DNN framework something along the lines of “an unauthenticated user can see a link to the Host > SQL page and run scripts”. Or “the module fails to install” on the DNN platform version that is was designed for. At this point you’d think the tester would scratch him/herself behind the ears and go “this can’t be right”. But alas, some just report it in thinking we never looked at the solution while not logged in. Or that we didn’t try to install it on the platform it was designed for. The most likely answer you’ll get is “cannot reproduce, please provide more details”. Because obviously there is something else going on that is interfering.
Pet peeve rants
This is along similar lines as described before about joining a team. You may have a very specific use case in mind and the module just doesn’t do this well. Or you feel the team is otherwise misguided in its approach. And now you feel like shaking some people to let them know they are completely overlooking this huge issue. “Oh, this thing uses tables all over the place. There’s no way I can skin this. Why didn’t you use MVP? It’d be so much better in C#.” Try to put your desire in perspective. First: you are not paying the developers to work for you. I.e. you have no right to have anything implemented that you want to see implemented in the way you want it done. Secondly, the use case you’re describing may be huge in your world, but not in mine. What is a 99% use case to you may be a 0.5% use case to me. And if your pet peeve concerns the “how” (i.e. the architecture/language chosen for the project) then realize that only incremental changes are realistic. If you’re proposing a complete overhaul, consider doing that in a fork/new project. It’s really like you’re proposing to a team of climbers half way up the Everest to go to the K2, instead. Sure, it may have its advantages, but it is just not realistic we’re all going to abandon the work done and come with you. And finally: it could be you’re trying to drive a screw with a hammer. Is this really what this module is set up to do and where the team is taking it? Modesty is key here.
“When is the next version being released” “Hey, last week you said it’d be released this week. Where is it?” Etc, etc. I rarely will let myself be enticed to set a deadline for release. Even in a well run software organization this is done with great care and at the very last moment. And that is in a place where everyone can be held to deadlines and is paid to do their work. Now imagine in a world where any member of the team can go AWOL at any moment. The release of the blog module has been pushed back so many times, I don’t care to remember. And all for very valid reasons. There wasn’t a single week since let’s say June that I didn’t feel like the release was imminent. And yet, every time it got close, it eluded me again as something more or less serious was discovered. Or because of personal circumstances (I ended up in hospital after a serious accident). Or because another tester got on board and wanted to test scenario XYZ. I’ve had to push back many times to testers to let them know: “no, I’m not holding off release because of that”. And still I released months later than I thought I would. You can ask for deadlines, but don’t be surprised if you don’t get one in reply.
Lest the above may come across as, at times, somewhat negative, I want to make sure we end on the positive here. Working in Open Source is incredibly exciting, rewarding, and accessible to all. My main goal of this post was to expose some of the complexities in accepting help from others. We invite you to the party, but wish to make sure you don’t have false expectations. I’ve listed a few ways how you can get started without anyone’s explicit permission. There are more ways, of course. You can start your own module project, for instance. No one’s stopping you. But know that you can do any of the above and you’ll be appreciated and feel the warm glow of the Open Source love