Two years ago I got a request for a field that allows users to specify an age range. Google told me that there is no module for that (actually, a pretty odd result in the Drupal world). I’ve decided to create one. The first version supported only integer ranges and had a very simple field formatter.
Basically, this story is typical. Probably, each Drupal developer has been there: no good contrib resulted in custom solution (doesn’t matter if it’s a module, a theme or distribution). The problem here is that a lot of drupalista stop there.
After a couple of days, I decided to publish it on drupal.org! My first step was to check for any similar modules. Core Number module was my choice. Most of the field and instance settings, as well as formatters, were cloned from it. So, the first public version was born. (See its review:“Module Monday: Range” by Jeff Eaton, Lullabot)
My module was a sandbox project. In order to become a full project, your sandbox must pass Project application queue. There is a good how-to on drupal.org. After 2 months and some code polishing, I received my first full project on drupal.org: Range module (actually, my module was merged with existing module for D6, because Drupal community prefers collaboration over competition; details here).
This happened 2 years ago. I’ve learned a lot since that time. Here are my top 4 lessons learned.
1. Any contribution counts
At the beginning, actually, I was almost sure that such kind of module will not be useful for any significant amount of users. My best estimate was 100 installs max. And I’m amazed at just how wrong I was.
At the time of writing this (end of February 2015), drupal.org reports over a thousand active installations. A thousand! It still impresses me. My goal was to help a couple of guys with a simple Numeric range field. I’ve never thought that it will be used on such a huge number of sites across the Globe.
Furthermore, the community has created a number of feature requests. Suddenly, I’ve realised that such a rather simple module is actually helpful. Wow! It’s such a great feeling.
My message here is simple: contribute. You never know where you end up.
2. It’s impossible to predict all the use cases
After the first release version was published, I was thinking:
“What else can be added there? What is the possible roadmap for the next version?”.
To be honest, I had not come up with anything interesting or valuable for the community. I had no idea where to move next. However, I was not disappointed. I felt that my job was done. The module works good. It does what it’s supposed to do. Period.
Stop, not so quick! Any contribution will grab some attention sooner or later. During those 2 years, I’ve received around 15 feature requests! A lot of them were so good and, in fact, obvious, that sometimes I was feeling ashamed! Without the community, the module would remain very rudimental. The Drupal community taught me to think out of the box!
To summarize: if you are stuck with no new ideas, let the community help you!
3. A successful module must integrate with all the most popular Drupal contribs
The Drupal core is not enough. Most of the sites use a lot of contrib modules to achieve their goals. A truly useful module can’t be integrated with Drupal alone. You might hate Views or Feeds, but those modules are extremely popular. Thousands of sites are using them. If your module doesn’t support them, less people will be using it. It means that a smaller part of the community will be helping you. And the community is quite important for any open source product, like Drupal, like your small module. The list of contrib modules your module must integrate with varies and heavily depends on the purpose of the module in question.
Integrate with as much contrib modules as possible. Become an integral part of Drupal’s ecosystem.
4. Tests are essential for happy life
Over the years, I have failed a couple of times introducing regressions. Luckily, those issues hadn’t damaged any data, but I’ve learned a very good lesson. When it comes to open source products, which can be used in various situations and out of your control, you must provide your best effort to produce the highest quality possible. Behind each installation there are valuable data, there are human beings. Don’t let those people down. Write a test. It’s one of the easiest ways to improve quality of your code.
Don’t be lazy. Just sit and write tests! They might save someone's business.
The community has shifted my horizon. Currently, this is the list of future improvements.
1. Cover the project with tests
As I said before, I think tests are essential for any mature software product. My top priority at the moment is covering the Range module with tests in order to be confident in future updates.
2. Make from or to value optional
There is an awesome feature request: make from or to values optional. It's a great, great idea. However, the Range module is too fragile due to the lack of tests! So, first things first.
3. Introduce Form API range type element and make it HTML5
This one is inspired by another feature request and Drupal 8. Again, this is quite a good, smart request. Probably it’s too big to go under 7.x-1.x branch. I plan to introduce 7.x-2.x branch and put this update there. Don’t panic, 7.x-1.x will be supported for some time. And, of course, upgrade path will be included. Also, we are glad to help with some custom modifications or any sort of Drupal support.
4. Drupal 8
After implementing all the above, I plan to port the module to Drupal 8. Ideally, 7.x-2.x and 8.x-2.x branches should have the identical functionality. But, you know, sometimes it could not be possible.
That’s all I have in my mind for now. Maybe not a lot, but I hope the community will like it. Anyway,I’m totally open for suggestions. Just create a feature request on drupal.org Range module issue queue. Alternatively, post your ideas (or issues) in the comments below.
In the end I would say only one thing:
don’t hesitate, start contributing now!