Contributor Spotlight: Daniel F. Kudwien

It's 2009, and Contributor Spotlight is back! This edition, we focus on Daniel F. Kudwien (sun on drupal.org and "tha_sun" in #drupal), CEO of Unleashed Mind.

Daniel is a rock-star Drupal coder who has contributed too many awesome modules to count. A few that you might be familiar with are Administration Menu, which makes the Drupal administrative interface a breeze to use, Upgrade Status, which gives you details on the porting status of your modules between major Drupal versions, and WYSIWYG API, a module with the goal to provide a single, centralized way to add any graphical editor you can imagine to Drupal.

Daniel has a real knack for staring down an extremely complicated problem, ruthlessly slapping away distractions, and coming up with an ingenious solution that not only solves the original problem, but does so with elegance.

Which brings us to the tale of node #8: Let users cancel their accounts.

node/8 is the oldest open Drupal core issue in existence, dating back to 2001. The deceptively simple title makes it seem like this would be a brain-dead problem to solve. Just provide a button for users to delete their own accounts. Duh! What's the problem?

The problem is, what happens when that button is clicked? Is the user account deleted from the database, or only blocked? Some organizations have legal requirements to retain data for 180 days, others have legal requirements to remove all traces of their users. But even trickier, what happens to the content that the user posted? Is it deleted as well? Scrubbed of contents? Attributed to the anonymous user? Simply unpublished? What about other users' content that might reference content posted by removed users, or might be direct replies? Do they get the axe, too?

If you read the issue comments, you will see people coming up with absolutely no shortage of opinions on all of the above, and multiple times, this has caused the issue to go completely off the rails. Most of us had lost hope, thinking node/8 would never get solved.

And then along came Daniel.

With swift precision, Daniel managed to distill the use cases down to the four most common, provide a hook so that other modules can cut in and do their business, and all the while rallying the troops in #drupal to contribute where they could, either by bouncing around ideas or providing language improvements or reviewing the code. And! I'm happy to report that node/8 was fixed at last earlier today, January 8... 8 days after Daniel began his journey. :) This was an inspiring process to watch and to be a part of, and showed that anything is possible if we all band together.

So, who is this mystery man? Is he tenacious, a little bit insane, or both? ;) Find out, in the following interview!

So, tell us a little about yourself.

I'm Daniel F. Kudwien, 27, and live in Karlsruhe, Germany. I'm relatively tall (~2 m/6.5 ft), so you usually see me in a crowd of people. I love to meet people, do crazy stuff, and think creatively. The latter probably being the reason why I chose early to work on and realize ideas with others, leading to the formation of unleashed mind some years ago, our agency that focuses on Drupal. It is very likely that you are using one of the Drupal modules I (co-)authored or took over under the nick sun (mates called me, badly translated and transformed from Mr. Miyagi in Karate Kid, Daniel sun :-D, back in the time I went to school).

How did you find Drupal, and how did you come to love it? ;)

It all started out back in the time of Drupal 4.7, when a project for a client required us to use a CMS that not only works on the PostgreSQL database, but also allowed integration with another, custom web-application. Until then, our CMS of choice was Joomla! (actually, Mambo first), in which we had advanced knowledge. We knew it by heart and actually fixed a ton of bugs, but never happened to contribute back, since it was a weird, non-transparent process. However, since Joomla! did not support PostgreSQL, we were not able to use it for this project, so we looked around for other Open-Source content management systems. We found Drupal. And to be honest, I found it totally weird and did not understand its logic in the beginning at all. Luckily, my brother, Stefan Kudwien (aka. smk-ka, who works with me), explained it over and over again to me, kept telling me That's how a CMS should work! Let's forget about the awkward Joomla way and start building cool stuff!, and finally convinced me to use it (and learn from scratch!).

Of course, we soon found the first bugs. But on drupal.org, everything appeared clean and ordered to me. I started to confirm issues, help out in issue queues by providing support to other users, and also providing information about how a bug could be fixed. It didn't take long until the first maintainer replied Please provide a proper patch!, so I started to train myself in CVS and how to create patches to provide proper patches for bugs we encountered.

It felt very good to be able to change and improve the things we were working with, and we quickly realized that this kind of (at that time unpaid) work dramatically simplified the updating services we provided for our clients.

Bam! 2 years and 41 weeks later, I know that switching to Drupal was the best decision we ever made. The friendly, vibrant, and innovative Drupal community is so addictive that it is not only stunning to work with Drupal, but also an awesome fun to collaborate with all the contributors.

What possessed you to jump into node/8?

Getting things done? I remember that I read multiple times through that issue, since all the replies were totally confusing. So I provided one summary and one proposal to solve it. Actually in the hope that someone more experienced than me would step up and say Cool, that's easy! - but that did not happen. During the past year, I learned from a few potential clients that they chose to skip Drupal due to the lack of this functionality, which was considered "basic", and if the trouble already starts with basic functionality, then...

So on January 1st and 2nd I finally sat down and turned the proposal into patches, and started to get feedback from others. And with each new day I worked (literally) full-time on the patch, the whole thing turned into the challenge: Either now or never. (while never would mean that I would have wasted my time - and there is nothing I hate more than wasting my time, especially when considering that countless people can't await the major Wysiwyg plugin API rewrite that will lead to a whole new content-editing experience in Drupal).

Duly noted: a) No one trusted me to get this done. b) Everyone wanted to see this getting done. c) Knowing the who-is-who in IRC helped a lot to directly point the proper questions to the proper people. d) Without the support of #drupal, this issue would not be fixed today.

How do you think we could help engage more people to take on this work as well?

Standards. Anything that emerges in a pace like Drupal and drupal.org needs transparent and clearly documented standards. I cannot count the number of times I marked issues as duplicate, asked for a proper patch, or pointed to the coding standards. New community members want to help and contribute, but have a very hard time to find out how to do so and thus give up earlier than we want to. What we lack the most are quality patch reviews and documentation, both in core and contrib. If we would take this seriously, we would add the same pressure on drupal.org's documentation as on D7's test coverage.

I would love to see our documentation evolve and would therefore support anyone who takes on this challenge! However, it is like with 8: at this point in time, we need one or more people that concentrate with full energy solely on this topic and come up with crazy ideas to regain the past failures. A "Project Book" module to attach module handbooks to projects? I'll code it. Require 1 handbook page for each patch? I'll support it.

Anything else you'd like to add?

Choosing you as the co-maintainer for D7 was the best decision Dries could have made. You are not only managing intelligently to get more and more developers in contrib back into core development, but also raising the standards for clean, well-documented, and solid code. If my vote would count, I would vote for keeping you as co-maintainer for core in the future.

Lastly, Drupal 7 should not be released without eating our own dog food on drupal.org. If we will manage to make the same mistake twice, then we should not expect that we will not face the same issues we had with 6 again.