Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Sep 30 2020
Sep 30

Our Drupal contributions history

Srijan has been part of the Drupal community for over 12 years. From very early on, we (Srijan) have been contributing to the Drupal project in multiple ways, from sponsoring nearly all DrupalCons since 2013, to regularly contributing code to core and contrib projects.

Many of our people have been mentors for new contributors at DrupalCons and local meetups. For the past 2-3 years, we even had a dedicated open-source community manager within the organization.

One of the earliest Drupal.org media case studies, published in 2009

Due to the COVID pandemic, we had a fairly large bench earlier this year. Given this, we decided to create three dedicated contribution teams to leverage this time efficiently and increase our contributions. During the same time, Drupal India Association (DIA) had set out a big-hairy-audacious-goal (BHAG) of putting DIA among the highest contributors globally.

Years of contributions and the above 2 events improved our overall ranking in the Drupal marketplace.

Where we fell short

Highly motivated by the dual goal of putting DIA on the marketplace and improving Srijan's ranking in the marketplace, some of our team members digressed from the objective and started "gathering contribution credits".

Soon we realized that out of the 25 contributors, a few were making mistakes like "assigning/unassigning issues without comments", or "submitting duplicate patches", meanwhile gathering credits intentionally or unintentionally in the process.

We acted immediately, realizing our mistake that we had not conducted a D.O "contributions code of conduct" training — as most of them were first-timer contributors.

We asked some of our seasoned contributors to organize a code of conduct training. These contributors led an internal training session to reiterate the Drupal code of conduct as well as build an internal best practices checklist for contributors at Srijan.


                        A screenshot from the training session

While this session helped in improving the quality of the contributions, we still noticed that a few people were not following all the best practices. Community members were still tagging Srijan and registering their complaints…we acted again.

This time we ‘painstakingly’ made a comprehensive report to identify the key issues and the defaulters.

The following unhealthy practices were identified and each team member was evaluated against these-

  1. Assigning/unassigning without comments
  2. Hopping/hijacking issues - i.e.,not reading the issue history and submitting incomplete patches
  3. Submitting duplicate patches
  4. Incorrect patches, or patches without comments/screenshots

Self-evaluation form filled by each team member, against each issue worked on

This detailed evaluation process took about 2 weeks to complete but helped us address the quality issues. These evaluation sheets will be maintained regularly going forward.

Conclusion

With the above steps, we eventually succeeded in putting a stop to the breach of the ‘code of conduct’ by a few overzealous (or careless) contributors.

We should have done a "code of conduct training" and set up a monitoring system so that we could have avoided these incidents. But that’s the benefit of hindsight.

On behalf of Srijan, I would like to apologize to the Drupal module maintainers and core contributors (including other Srijan contributors) who had to face unnecessary challenges due to some of our nonchalant actions.

Srijan is and will remain among the leading contributors to the Drupal community and a responsible one at that.

The purpose of this post is to address our problem of being tagged on Slack in the Drupal group, rectify them with the right practices, and share this learning experience with others to help them avoid these slip-ups.

I would like to end this post by highlighting some of the positive attention that Srijan’s contribution teams have received during the past few months.

Aug 17 2020
Aug 17

Contributing back to the community has always been vital in Srijan’s culture. We did take a back seat for some time like everyone in the industry; however, it was just a little pause. In the early days of 2020, we set some new year goals and community contribution was one not to be missed. As you read along, you would walk through our journey so far.

Status Quo Ante

In March, Srijan was on the first page of the Drupal Marketplace when we thought to initiate the contribution process. Simply put, we were holding a rank between fifteen to the seventeenth position.

While I started working as a Community Manager in the March-end, I was made responsible for improving Srijan’s ranking in the Marketplace.

Never had I imagined then that such a massive epidemic was at our doorstep.

Financial Q1 & COVID Hit

The COVID-19 pandemic that started in March-end led to the cancelation of all the upcoming events. Further, the extended lockdown worked as a catalyst for increasing the ambiguity among the team members on what to plan in future agenda and how long will it take to end.

An enormous number of employees were put on the bench as the project engagement reduced considerably across the globe due to COVID uncertainties. That’s when it struck us that we should leverage this situation to turn it into a positive opportunity for us. An opportunity where we can learn, improve our position in the Marketplace, and most importantly, don’t let Srijanites feel demotivated due to such unprecedented times.

See what we did to give our best-

  1. In the first week of April, we started anew by creating three teams for the time being and kickstarting our efforts to chase our end goal. 
  2. These teams were accountable for running contributions as full-fledged Projects (i.e., teams working in collaboration and performing all Agile ceremonies simultaneously) apart from an additional small group that focuses on contributions as an ongoing task.
  3. As we picked up our pace in mid-April, the team discussions took place following which there were some training sessions provided, and documentation was done for the newbies as well as for others to seek reference. 
  4. Gradually, the team started picking issues, and by the end of April, we were able to contribute satisfactorily, irrespective of the improvement in our rankings. However, this beginning made us feel content.

As said, hard work pays off; eventually, May & June proved fruitful for us. These were the months when the rank improved drastically, and we were now within the top 5 contributors in the Marketplace globally and at the top position in India.

Vertical bars of different colors and lengths-graphThe graph shows the number of patches submitted in total for different Issue types in May & June.

Not only did the teams were proficient by now, but we were also ready with the recorded training sessions and startup guide for the future newcomers to join. We traveled a long way to achieve our goal, but the journey was far more adventurous and taught us things that made our future brighter.

We learned in our journey...

While the teams had gained up to the speed of working for core issues, some unhealthy practices came into the light, such as too many comments on a single issue, or to & fro of assignment and un-assignment, etc., were being followed within the community. 

As everyone learns from their own mistakes, so did we. The teams were run through the sessions by the experienced contributors, where they elucidated the best practices to adopt while working on the issues.

All's well that ends well

By the end of June, we made it to the top 4!Graph to show month-wise rankThe graph shows Srijan’s ranking on Drupal Marketplace from March to June 2020

The ultimate goal

To reach our ultimate goal, we were continually putting efforts to maintain our position in the top 5 quality contributors. Below is the graph to help you understand the scenario betterGraph with vertical bars of various lengthThe percentage of Drupal Core Credits with the Total Credits, as of July 1, 2020, for top 4 Contributors.

Our position as of August 12, 2020, i.e., in the second quarter of the year, was 2nd, and maintaining it requires some serious strategic planning and continuous implementation. 

The credits are evaluated every 90 days. You may lose the hard-earned position if the constant efforts are not dedicated. Given this, it is essential to foresee things and act accordingly.

This is all about the contribution journey of Srijan in the first quarter of 2020. As George Herbert said, “Where there is a will, there is a way,” we have now successfully achieved the second position in the marketplace. 

To know this another exciting journey of ours, where we achieved the second position, you ought to stay tuned for the next blog. 

Meanwhile, keep contributing to the community! :)

Jul 27 2019
hw
Jul 27

This was one of last minute decided and planned Drupal meetups. I was traveling for Decoupled Days and couldn’t plan this meetup well in advance, which meant I only started looking for the venue for the meetup barely 5 days before our regularly scheduled date of the last Saturday of a month. Fortunately, we found a space in 91Springboard, one of our regular hosts.

Since the meetup was announced just three days before, I was not expecting a lot of people able to attend. We had nine attendees in all (out of 15 RSVPs) and we had people traveling from distant areas of Bangalore. Having lived in Bangalore and being stuck in Saturday traffic, I greatly appreciate their dedication to learning.

The meetup started at 10:30 AM with a brief introduction of every attendee. We covered some of the Drupal news such as recent and upcoming events in India and internationally. We also talked about Drupal 9 and other changes in the technology.

Drupal 8 modules for #AI by @paru_523 at the @drupal_bug #meetup in Bangalore. #Drupal pic.twitter.com/nxcGGgLRvc

— hussainweb (@hussainweb) July 27, 2019

At 10:45 AM, we started our first topic with Parvateesam Konapala talking about modules available to utilise Artificial Intelligence capabilities in Drupal 8. The talk was a good coverage of various modules provided by Azure Cognitive Services. Parvateesam also talked about Acquia Lift and how it utilises AI for personalisation.

Next, we have Drupal performance with Big Pipe by @er_pradosh at @drupal_bug #Drupal #meetup. pic.twitter.com/tN7XtFHS6M

— hussainweb (@hussainweb) July 27, 2019

At 11:30 AM, Pradosh Pattanayak walked us through Big Pipe and how it can help performance in Drupal. We covered the traditional sequential rendering of content and the Big Pipe style of rendering with scripting enabled and without JavaScript support.

We then took a short break followed by networking and general discussion on Drupal and related challenges. Discussions ranged from the best way to use entities for complex data structures to how to contribute to the Drupal community more.

We took a group photo and said goodbyes at 1:15 PM. For a barely planned meetup, it was a very organised and a productive day. Once again, thanks to 91Springboard for making the venue available and the support. And thank you to all those who participated and made the meetup successful. Our next meetup is planned on 24th August and I am looking forward to meet you there. You may RSVP by clicking here.

Thank you all for participating in the @drupal_bug #meetup today and all the discussions. pic.twitter.com/T4bl3EQHwS

— hussainweb (@hussainweb) July 27, 2019

Dec 20 2018
Dec 20

To Zach Sines and Taylor Wright, It’s not goodbye, it’s see you later.

Kaleem Clarkson2018 DrupalCamp Atlanta Group Picture

Thanks to all of the presenters and participants who attended 2018 DrupalCamp Atlanta (DCATL). We are excited to provide you with a little holiday gift. The Session Videos are now live. View here

I would also like to thank the awesome DCATL team that I had the pleasure to work with:

  • Sarah Golden — Acquia
  • Nikki Smith — Sevaa
  • Zach Sines — Manhattan Associates
  • Taylor Wright

As with any event, this year’s DCATL had some interesting twists and turns that we were able to overcome. The biggest and most noticeable one, of course, was the construction that was happening at the hotel. Two weeks before the event, I met with the hotel event staff to discuss our setup. On my way into the hotel, everything looked as I expected and it was business as usual. When I entered the lobby I noticed they were putting up a temporary wall that blocks off the hotel bar. During our discussion, I was informed there was going to be some construction going on during our camp but was ensured that the event space wouldn’t be impacted.

The DCATL team arrived at the hotel to load in and everyone was mortified when we saw the front of the building. No more than 10 minutes after we arrived, I received a message from one of the trainers asking, “are we still having the conference?” We immediately started thinking about how we can alleviate the situation, so we took a picture of the building and sent an email out to everyone stating that the interior of the building was okay and that we were still going to have an awesome conference.

It wasn’t all doom and gloom. 10 days before the camp, we were still short on the financials and were kind of sweating it out (although we had reserve funds to cover the costs) thinking of ways that we could reduce costs without getting rid of too much programming. I received a phone call from an employee at Turner, asking if they could be a Diamond Sponsor and would also like to sponsor the after party. WOW! I couldn’t believe we were getting bailed out in the last minute, phew!

After the camp, I got a chance to have lunch with a mentor of mine and we talked about where are the next generation of Drupalers going to come from and what purpose camps serve today vs ten years ago. So based on our discussion here are my top two goals I would like to propose to the DCATL organizing team.

Increase the Number of Case Studies with co-presentations from Drupal shops and their Clients.

Another topic we discussed was how Acquia Engage has taken a different approach by showcasing their clients and providing opportunities for Drupal shops to schedule meet and greets talk with their clients. During the opening session at DCATL I asked the audience, “raise your hand if you have invited a client to attend or co-present at DrupalCamp Atlanta.” Out of all the attendees maybe 2 raised their hands.

Increase the Number of Student Attendees

When looking at some of my Drupal colleague's user profiles so many of us over 10 years. This means we are getting old folks :) But more importantly, where are the next generation of Drupalers going to come from. The state of Georgia has 114 colleges and 326,609 students. I know it takes a lot of energy but we have to figure out a way to use our camp as a pipeline for nurturing the next generation of Drupalist.

For the past 5.5 years, I have had the pleasure to work with Zach Sines and Taylor Wright as board members of the Atlanta Drupal Users Group (ADUG). Both Zach and Taylor were key stakeholders in the restructuring of the organization. Zach took on the writing of the bylaws that states how people are elected, what are the rules for participating, what are the roles and responsibilities of each officer and so on. Taylor has a ton of finance experience so he took on the responsibility of cleaning up our financials and paying all of our bills. These two have been by my side, even after heated discussions and have been what I like to call my nice translators. Sometimes I have the tendency to be too blunt and they were always there to translate my bluntness into that beautiful southern hospitality.

Zach in the Green on the Left. Taylor in the Green on the Right

Earlier this year, both Zach and Taylor informed all of us that 2018 will be their last year serving on the board. Not to get too mushy but I am going to miss them both a lot, I mean a ton. Not just for their expertise but hearing their voices on our monthly calls and some of their hilarious stories. But what is great about Drupal is that you build some lasting relationships and now I consider these two my friends. Thank you for all the work you have put into running these events, and I know this is not goodbye its soo you soon.

With our current vacancies, the Atlanta Drupal User Group (ADUG) is currently looking for new board members to join our team. While the serving on a board can sound intimidating we are really just a bunch of Drupalers who want to give back to the community. All of our meetings are held on a video call. If you are interested or know some who would be a great fit, please feel free to contact us.

Dec 10 2018
Dec 10

Zivtech is happy to be offering a series of public Drupal 8 trainings at our office in downtown Philadelphia in January 2019. 

Whether you consider yourself a beginner or expert Drupal developer, our training workshops have everything you need to take your Drupal skills to the next level. 

Our experience

The Zivtech team has many years of combined expertise in training and community involvement. We have traveled all over the world conducting training sessions for a diverse range of clients including, the United States Department of Justice, the Government of Canada, CERN, Howard Hughes Medical Institute, Harvard University and more. 

We pride ourselves in educating others about open source, and attendees will leave our trainings with the knowledge to build custom Drupal sites, solve technical issues, make design changes, and perform security updates all on their own. We also offer private, onsite trainings that are tailored to your organization's specific needs. 

Our public Drupal trainings for January 2019 include:

Interested in learning more about our upcoming trainings? Click here. You can also reach out to us regarding multi-training and nonprofit discounts, or personalized trainings. 

We hope to see you in January!
 

Nov 23 2018
Nov 23

It’s been almost one month since I wrote the blog post, “DrupalCamp Organizers Unite: Is it Time for Camp Organizers to Become an Official Working Group” and a ton of things have transpired that will catapult us into 2019 with some great momentum. With the support of the many Drupal evangelists, over 50 Drupal event organizers from around the world signed up to attend our first official / unofficial video call.

Then on Friday, November 8, a few hours leading up to the video call, The Drupal Governance Taskforce 2018 Proposal was released. This proposal was put together by the Governance Taskforce in an effort establish a community directive that helps create the next generation of Drupalers. One of the recommendations in this proposal was to provide in-person events, more support, and to establish a Drupal community events working group. The timing of the proposal was perfect for our call. It was really great to see that us organizers were not the only ones who acknowledged that our community events are crucial to Drupal adoption.

Are you a Drupal Event Organizer? Well, join us at our next meeting on Tuesday, January 8, 2019, at 12 pm (EST). Register Here

When the time came to start the call I was a little nervous that not very many people would attend and then all of a sudden the chimes started going off and faces appeared on the screen. After 5 minutes we had 25 people on the call. It was inspirational to be a part of something big. It felt like we were the United Nations :).

Flags of all the Countries that were represented

Countries Represented
Canada, Mumbai, Netherlands, Switzerland, United Kingdom, United States.

Drupal Events Represented
BADCamp(2), Drupal Association(2), Drupal North, Drupal Camp Asheville, DrupalCamp Atlanta, Drupal Camp Chattanooga, DrupalCamp Colorado, DrupalCorn(2), Drupaldelphia, Drupal Mountain Camp, Drupal Camp Mumbai, DrupalCamp New Jersey, Florida Drupal Camp (2),Frontend United, GovCon, MidCamp(2), NED Camp(4),Victoria BC Meetup.

  1. The next meeting will be held on Tuesday, January 8, 2019, at 12 pm (EST). Register Here
  2. Comment on Governance Taskforce Proposal Issue
    To help Dries Buytaert, prioritize the recommendation of creating a Community Events Working Group, we need as many people as possible to comment on this issue. Please view the issue and indicate why you believe this working group is critical to the success of Drupal. Comment now!
  3. DrupalCamp Website Starter Kit
    Out of all of the discussions, the common pain point is that the website takes up too much of our limited resources. The idea of an event starter kit, instead of a distribution, was really intriguing to us all. We also discussed all of the events donating funding to hire a professional project manager to scope out what a starter kit would look like.
  4. Drupal.org Events Website
    Many of us use the great Drupical to let us know what events are happening. But if you don’t know about that website there is nowhere on Drupal.org that is easily accessible that promotes Drupal events. The idea that was brought to the table was to design a new section of the community page that is a space specifically for promoting and producing Drupal events.
  5. A Centralized Drupal Event Statistics Hub
    Another website related item that was brought up was the idea of centralized data hub that event organizers could submit crucial data of events (attendance, budget, programing etc.) so that Drupal.org could display the data and allow for data manipulation. For example, it would be great to know how many people attended Drupal events in one year. This data would be extremely powerful as it could help organizers to compare events, drive corporate sponsorships and adoption, and get more people involved with Drupal.
  6. DrupalTV — A website with all Drupal Videos
    The topic around Drupal video content came up and one of the biggest issues was that videos are all over the place and are not organized. To solve this problem, the idea of a centralized website (DrupalTV) where videos were tagged by topic, presenter, module, etc.. would allow for content to be easily found. This idea was started before our meeting and you can see a proof of concept here.

I was very happy to be a part of this first meeting and I hope that Drupal leadership also sees the work we do as critical and will make us an official working group. There were a lot of great conversations that took place so I am sure that I have missed something. Feel free to comment and let me know and I will update the post.

Nov 09 2018
Nov 09

Last week, the Children’s Hospital of Philadelphia (CHOP) Vaccine Makers Project (VMP) won a PR News Digital Award in the category “Redesign/Relaunch of Site.” The awards gala honors the year’s best and brightest campaigns across a variety of media. 

PR News Award on a table.

Our CEO, Alex, and our Director of Client Engagement, Aaron, along with members of the Vaccine Makers team attended the event at the Yale Club in New York City.

Screenshot of a Tweet posted by the PR News. Source

The Vaccine Makers Project (VMP) is a subset of CHOP’s Vaccine Education Center (VEC). It’s a public education portal for students and teachers that features resources such as lesson plans, downloadable worksheets, and videos. 

The Vaccine Makers team first approached us in need of a site that aligned with the branding of CHOP’s existing site. They also wanted a better strategy for site organization and resource classification. Our team collaborated with theirs to build a new site that’s easy to navigate for all users. You can learn more about the project here.

Screenshot of a Tweet from Vaccine Makers team. Source

We’d like to thank CHOP and the Vaccine Makers team for giving us the opportunity to work on this project. We’d also like to thank PR News for recognizing our work and hosting such a wonderful event. 

Finally, we’d like to congratulate our incredible team for their endless effort and dedication to this project. 
 

Nov 02 2018
Nov 02

You Can’t Put a Price Tag on Visibility, Creditability, and Collegiality

Kaleem Clarkson“pink pig” by Fabian Blank on Unsplash

Organizing a DrupalCamp takes a lot of commitment from volunteers, so when someone gets motivated to help organize these events, the financial risks can be quite alarming and sometimes overwhelming. But forget all that mess, you are a Drupal enthusiast and have drummed up the courage to volunteer with the organization of your local DrupalCamp. During your first meeting, you find out that there are no free college or community spaces in the area and the estimated price tag is $25,000. Holy Batman that is a lot of money!

Naturally, you start thinking about how we are going to cover that price tag, so you immediately ask, “how many people usually attend?” Well unless you are one of the big 5, (BADCamp, NYCCamp, Drupal GovCon, MidCamp or FloridaCamp) we average between 100 and 200 people. Then you ask, “how much can we charge?” You are then told that we cannot charge more than $50 because camps are supposed to be affordable for the local community and that has been the culture of most DrupalCamps.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

If Drupal is the Enterprise solution why are all of our camps priced and sponsored like we are still hobbyist in 2002?

Drupal is the Enterprise solution. Drupal has forgotten about the hobbyist and is only concerned about large-scale projects. Drupal developers and companies make more per hour than Wordpress developers. These are all things I have heard from people within the community. So if any of these statements are valid, why are all the camps priced like it is 2002 and we are all sitting around in a circle singing Kumbaya? In 2016 for DrupalCamp Atlanta, we couldn’t make the numbers work, so we decided to raise the price of the camp from $45 to $65 (early bird) and $85 (regular rate). This was a long drawn out and heated debate that took nearly all of our 2 hours allotted for our google hangout. At the end of the day, one of our board members who is also a Diamond sponsor said,

“when you compare how other technology conferences are priced and what they are offering for sessions, DrupalCamps are severely under-priced for the value they provide to the community.”

Courtesy of Amaziee.io Labs

If a camp roughly costs $25,000 and you can only charge 150 people $50, how in the world are DrupalCamps produced? The simple answer, sponsors, sponsors, and more sponsors. Most camps solely rely on the sponsors to cover the costs. One camp, in particular, BADCamp has roughly 2,000 attendees and the registration is FREE. That’s right, the camp is completely free and did I forget to mention that it’s in San Francisco? Based on the BADCamp model and due to the fact the diamond sponsorship for DrupalCon Nashville was $50,000, getting 10 companies to sponsor your camp at $2,500 will be no sweat. Oh and don’t forget Drupal is the enterprise solution, right?

With all of your newfound confidence in obtaining sponsorships, you start contacting some of the larger Drupal shops in your area and after a week nothing. You reach out again maybe by phone this time and actually speak to someone but they are not committing because they want some more information as to why they should sponsor the camp such as, what other perks can you throw in for the sponsorship, are we guaranteed presentation slots, and do you provide the participant list. Of course, the worst response is the dreaded no, we cannot sponsor your conference because we have already met our sponsorship budget for the year.

At this point, you feel defeated and confused as to why organizations are not chomping at the bit to fork over $2,500 to be the sponsor. Yep, that’s right, twenty-five hundred, not $25,000 to be the highest level, sponsor. Mind you many Drupal shops charge anywhere between $150 — $250 an hour. So that means donating 10–17 hours of your organizations time to support a Drupal event in your local community. Yes, you understand that there are a lot of DrupalCamps contacting the same companies for sponsorship so you ask yourself, what has changed from years past?

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

At DrupalCon Nashville, I got an awesome opportunity to participate in a session around organizing DrupalCamps. It was really interesting to hear about how other organizers produce their camp and what were some of the biggest pain points.

Group Photo — DrupalCon 2018 Nashville by Susanne Coates

During this session, we were talking about a centralized sponsorship program for all DrupalCamps (that I personally disagree with and will save that discussion for another blog post) and an individual asked the question,

“why should my company sponsor DrupalCamp Atlanta? There is nothing there for me that makes it worth it. We don’t pick up clients, you don’t distribute the participant list, so why should we sponsor the camp?”

Needless to say, they caught me completely off guard, so I paused then replied,

“DrupalCamp Atlanta has between 150–200 people, most of them from other Drupal shops, so what is it that you are expecting to get out of the sponsorship that would make it worth it to you? Why do you sponsor any DrupalCamps?”

On the plane ride back to the ATL it got me thinking, why does an organization sponsor DrupalCamps? What is the return on their investment? I started reminiscing of the very first DrupalCamp that I attended in 2008 and all the rage at that time (and still is), was inbound marketing and how using a content strategy and or conference presentations can establish your company as thought leaders in the field, therefore, clients will find your information useful and approach you when its time to hire for services. Maybe this is why so many camps received a ton of presentation submissions and why it was easy to find sponsors, but that was over 10 years ago now and some of those same companies have now been established as leaders in the field. Could it be, that established companies no longer need the visibility of DrupalCamps?

What happens to DrupalCamps when companies no longer need the visibility or credibility from the Drupal community?

The Drupal community thrives when Drupal shops become bigger and take on those huge projects because it results in contributions back to the code, therefore, making our project more competitive. But an unintended consequence of these Drupal shops becoming larger is that there is a lot more pressure on them to raise funding thus they need to spend more resources on obtaining clients outside of the Drupal community. Acquia, the company built by the founder of Drupal, Dries Buytaert, have made it clear that they are pulling back on their local camp sponsorships and have even created their own conference called Acquia Engage that showcases their enterprise clients. Now from a business perspective, I totally understand why they would create this event as it provides a much higher return on their investment but it results in competing with other camps (ahem, this year’s DrupalCamp Atlanta), but more importantly the sponsorship dollars all of us depend on are now being redirected to other initiatives.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

The reality of the situation is that sponsoring these DrupalCamps are most likely not going to land your next big client that pays your company a $500,000 contract. So what are true reasons to sponsor a DrupalCamp:

  • Visibility
    When sponsoring these DrupalCamps most of us organizers do a pretty good job of tweeting thanks to the company and if the organization has presenters we usually promote the sessions as well. In addition, most camps print logos on the website, merchandise, and name after parties. Yes, its only a little bit but the internet is forever and the more you are mentioned the better off you are. But you are from a well established Drupal shop so you don’t need any more visibility.
  • Credibility
    Even the companies who are have been established need their staff to be credible. There will always be some amount of turnover and when that happens your clients still want to know if this person is talented. And if your company is new, being associated with Drupal in your local community does provide your company a sense of credibility.
  • Collegiality
    I saved the best for last. Collegiality is highly overlooked when looking at sponsoring camps. Most companies have a referral program for new hires and when the time comes for you to hire, people tend to refer their friends and their professional acquaintances. There is no better place to meet and interact with other Drupalist than a DrupalCamp. What about employee engagement? In a recent focus group I participated in with a Drupal shop, many of the staff wanted more opportunities for professional development. These local camps are affordable and can allow staff to attend multiple events in a year when you have small budgets.

I must end by saying, that there are so many great Drupal companies that I have had the pleasure to work with and if it were not for the Acquia’s of the world Drupal wouldn’t exist. I understand that CEO’s are responsible for their employees and their families so I don’t want to underestimate the pressures that come with making payroll and having a client pipeline. The purpose of this post was to explain how it feels as a volunteer who is doing something for the community and the frustrations that sometimes come with it.

Oct 29 2018
Oct 29

At this year's BADCamp, our Senior Web Architect Nick Lewis led a session on Gatsby and the JAMstack. The JAMStack is a web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup. Gatsby is one of the leading JAMstack based static page generators, and this session primarily covers how to integrate it with Drupal. 

Our team has been developing a "Gatsby Drupal Kit" over the past few months to help jump start Gatsby-Drupal integrations. This kit is designed to work with a minimal Drupal install as a jumping off point, and give a structure that can be extended to much larger, more complicated sites.

This session will leave you with: 

1. A base Drupal 8 site that is connected with Gatsby.  

2. Best practices for making Gatsby work for real sites in production.

3. Sane patterns for translating Drupal's structure into Gatsby components, templates, and pages.

This is not an advanced session for those already familiar with React and Gatsby. Recommended prerequisites are a basic knowledge of npm package management, git, CSS, Drupal, web services, and Javascript. Watch the full session below. 

Oct 27 2018
Oct 27

If the community is a top priority then resources for organizing DrupalCamps must also be a top priority.

Kaleem Clarkson“Together We Create graffiti wall decor” by "My Life Through A Lens" on Unsplash

Community, community and more community. One of the common themes we hear when it comes to evaluating Drupal against other content management systems (CMS), is that the community is made up of over 100,000 highly skilled and passionate developers who contribute code. And in many of these application evaluations, it’s the community, not the software that leads to Drupal winning the bid. We have also heard Dries Buytaert speak about the importance of the community at various DrupalCons and he is quoted on Drupal.org’s getting involved page:

“It’s really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base.” — Dries Buytaert

With this emphasis on community, I tried to think back to how and when I first interacted with the community. Like so many others, my first introduction to Drupal was at a local Meetup. I remember going to this office building in Atlanta and the room was packed with people, plenty of pizza, soda and, of course, laptops. It was a nice relaxed atmosphere where we introduced ourselves and got a chance to know each other a little bit. Then the lights dimmed, the projector turned on and the presentations kicked off, highlighting some new content strategy or a new module that can help layout your content. After that first meetup, I felt energized because until that point, I had never spoken with someone in person about Drupal and it was the first time that I was introduced to Drupal professionals and companies.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

After attending a few meetups, I joined the email list and I received an email announcing DrupalCamp Atlanta was going to be held at Georgia Tech and the call for proposals was now open for session submissions.

2013 DrupalCamp Atlanta photo by Mediacurrent

I purchased a ticket for a mere $30 and added it to my Google calendar. On the day of the event, I remember walking in the front door and being blown away by the professionalism of the conference as there were sponsor booths, giveaways, and four concurrent sessions throughout the day. But it wasn’t until I was inside the auditorium during the opening session and saw the 200 or so people pile in that made me realize this Drupal community thing I heard about was for real. Over the next couple of years, I decided that I would attend other camps instead of DrupalCon because the camps were more affordable and less intimidating. My first camp outside of Atlanta was Design4Drupal in Boston, DrupalCamp Charlotte, DrupalCamp Florida and BADCamp were all camps I went to before attending a DrupalCon. All of these camps were top notch but what I really loved is that each camp had their own identity and culture. It’s exactly what I think a community should be and for the very first time, I felt that I was a part of the Drupal community.

As provided in my previous examples, one of the advantages of Drupal comes from the great community and DrupalCamps are an important aspect in fostering this community. Running any event can be challenging, but to pull off a respectable DrupalCamp you have consider so many things such as the website, credit card processing, food, accepting and rejecting sessions, finding a keynote speaker, the afterparty, pre-conference trainings, oh and did I mention the website? You get my drift, it's a lot of work. Many of these tasks just roll off my tongue from past experience so ask yourself;

  • Where can I share my knowledge with other people who organize camps?
  • What if there was some way that all of us DrupalCamp organizers could come together and implement services that make organizing camps easier?
  • How could we provide camp organizers with resources to produce great camps?

During the #AskDries session at DrupalCon Nashville (listen for yourself), Midwest DrupalCamp Organizer Avi Schwab asked Dries the following question;

“... giving the limited funding the Drupal Association has, where should we go in trying to support our smaller local community events?” — Avi Schwab

Dries then responded with:

“That’s a great question. I actually think its a great idea what they (WordCamp) do. Because these camps are a lot of work. ...I think having some sort of central service or lack of a better term, that helps local camp organizers, I think is a fantastic idea, because we could do a lot of things, like have a camp website out of the box, ... we could have all sorts of best practices out of the box .” — Dries Buytaert

DrupalCamp Slack Community was the first time that I was provided a link to a spreadsheet that had the camp history dating back to 2006 and people were adding their target camp dates even if they were just in the planning stages. As a camp organizer I felt connected, I felt empowered to make better decisions and most of all I could just ask everyone, hey, how are you doing this?

Are you interested in attending the first online DrupalCamp Organizers meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

Earlier this year I volunteered for the Drupal Diversity and Inclusion Initiative (DDI) and was inspired when I heard Tara King on the DrupalEasy podcast, talk about how she just created the ddi-contrib channel on the Drupal slack and started hosting meetings. All jazzed up and motivated by that podcast, I reached out to over 20 different camp organizers from various countries and asked them if they would be interested in being on something like this? And if not, would they feel represented if this council existed?

Here are some quotes from Camp Organizers:

“I think a DrupalCamp Organizers Council is a great idea. I would be interested in being a part of such a working group. Just now I’m restraining myself from pouring ideas forth, so I definitely think I’m interested in being a part.”

“I am interested in seeing something that gathers resources from the vast experiences of current/past organizers and provides support to camps.”

“I definitely would appreciate having such a council and taking part. I’ve now helped organize DrupalCamp four times, and this was the first year we were looped into the slack channels for the organizers.”

“I really like the idea — what do we need to do to get this started?”

Based on the positive feedback and the spike in interest from other camp organizers I have decided to take the plunge and establish our first meeting of DrupalCamp Organizers on Friday, November 9th at 4:00pm (EST). This will be an online Zoom video call to encourage people to use their cameras so we can actually get to know one another.

The agenda is simple:

  • Introductions from all callers, and one thing they would like to see from the council.
  • Brainstorm the list of items the council should be advocating for.
  • Identify procedures for electing people to the Council: ways to nominate, eligibility criteria, Drupal event organizer experience required etc.
  • Outline of a quick strategic plan.
Sep 29 2018
hw
Sep 29

Another month, another Drupal meetup in Bangalore. This month’s meetup was held at Athenahealth office on Lavelle Road in Bangalore. Since the last month’s meetup was scheduled a week early, there was more than usual gap since the last meetup. This time, we had a full schedule and exciting sessions planned. For all this, we were in a beautiful room on the 17th floor overlooking the gorgeous cityscape of Bangalore (as you can see in some of the photos below). This was thanks to Athenahealth, our gracious host for this meetup.

Drupal Meetup

We started at around 10:30 AM with introductions of everyone present in the room. We had about 30 attendees in total, out of which about 7-8 were first time attendees. After introductions, Taher started the day by talking about updates to Drupal, mainly Drupal 8.6, 8.6.1, and talking about Drupal 9. He also mentioned upcoming events and mainly talked about important dates for DrupalCon Seattle 2019 including session submission deadlines.

We begin today's #Drupal #meetup with @devtaher covering what's new in Drupal. pic.twitter.com/NoITmOOtPI

— hussainweb (@hussainweb) September 29, 2018

Sessions

The first session of the day was about Drupal 8 Plugins and Plugin API by Manoj Kumar of Athenahealth. Manoj described common confusions between plugins and services in Drupal 8 and when to use each of them. He talked about the plugin API itself, specifically plugin discovery and factories. He walked us through a demo of how to create our own plugin type and creating plugins of that type. This included a very lively and engaged discussion about plugins.

First session of the day about #Drupal plugins by @manojapare at @drupal_bug #meetup. pic.twitter.com/RMGrcb1Lp5

— hussainweb (@hussainweb) September 29, 2018

This was followed by a lightning session on using Alexa with Drupal by Rakshith of Axelerant. Rakshith described how a service like Alexa integrates with Drupal, demonstrated the Alexa developer console and described concepts like intents. He also demonstrated tying this together with Drupal where Alexa could respond to user queries like “Read article” or getting a list of articles.

Rakshith talks about using Alexa with Drupal at the @drupal_bug #meetup today. pic.twitter.com/tWc1maQlN7

— hussainweb (@hussainweb) September 29, 2018

Break

This was followed by a few announcements and a break, with refreshments courtesy of Athenahealth.

Thank you @athenahealth for hosting us for this month's #Drupal #meetup and providing a beautiful venue and refreshments. pic.twitter.com/C0p6elSWBH

— hussainweb (@hussainweb) September 29, 2018

And more sessions

After the break, we resumed sessions with an introduction to the paragraphs module by Parvateesam Konapala of TCS. Parvateesam started by explaining what Paragraphs module provides and some of the modules which extend paragraphs’ functionalities. He also gave a demo in which he created paragraph types, adding them to content types, and how to use paragraphs in your site building workflow.

Back from a break and we have @paru_523 giving an introduction to paragraphs module in #Drupal. pic.twitter.com/vOO7Wmw2iJ

— hussainweb (@hussainweb) September 29, 2018

The last session of the day was on using Tome by Malabya Tewari of Specbee. Malabya started by summarising static site generators and how are they different from the conventional approach. He talked where static site generators might be used and their benefits. After talking about a few other systems, Malabya started talking about Tome and how it works. He demonstrated a workflow of a static website

The last session of the day on Tome (static site generator using #Drupal) by @malavya88 at @drupal_bug #meetup. pic.twitter.com/lyC0MNEkNC

— hussainweb (@hussainweb) September 29, 2018

End of the day

We had a quick questions and answers round where people brought up various issues they are facing and we collaboratively discussed on solving them. This was quickly followed by closing announcements and of course, crediting all the speakers and organisers on our meetup planning issue. We also discussed a bit about the format of our meetups and what we can do to improve. After a great discussion on couple of topics on what else we could do, the meetup ended at 2 PM with a group photo. There are more photos below.

Drupal Meetup Bangalore - September 2018

Aug 22 2018
hw
Aug 22

This month’s Drupal meetup was held at 91Springboard in JP Nagar. We held this meetup early instead of our usual last Saturday of the month due to a long weekend.

Drupal meetup

It was a lazy rainy Saturday morning and most of the people made it on time. We started the meetup at 10:30 AM as planned. We started with introductions and a catch-up on news and upcoming events in the Drupal world.

Starting off today's #Drupal meetup with @devtaher @drupal_bug @BangaloreDrupal pic.twitter.com/MF8LoIGGjh

— hussainweb (@hussainweb) August 18, 2018

Umami

Our first lightning talk was by Malabya on Umami, which is an effort for Drupal’s out of the box initiative. Malabya described why Umami was necessary and what are the problems it solves. The slides are available here.

.@malavya88 talks about why first impressions are important and how #Umami helps #Drupal do a better job there. @drupal_bug pic.twitter.com/NPI5rUnMRC

— hussainweb (@hussainweb) August 18, 2018

BLT

This was followed by Srikanth and Tejasvi giving an introduction to BLT. They introduced why something like BLT is required for developing Drupal sites in a moderately large team. They also described the structure of a BLT based setup briefly and answered questions related to BLT.

Introduction to BLT by @srikantmatihali at #Drupal meet-up in Bangalore. @drupal_bug pic.twitter.com/KAaqnR8vu0

— hussainweb (@hussainweb) August 18, 2018

Tejasvi talks about what a BLT setup looks like and the code structure at @drupal_bug meetup. pic.twitter.com/nO96l7xdGt

— hussainweb (@hussainweb) August 18, 2018

Bring your questions

We tried something new this meetup based on feedback. Many people brought in various questions they face when using Drupal. Some of the questions we addressed were:

  • What is config split? How do we use it?
  • Are there any best practices for Drupal multi-site?
  • Issues with layout plugin module in early versions of Drupal 8 and how to upgrade
  • Using paragraphs
  • and more which I can’t remember now…

QnA session at @BangaloreDrupal meetup. @hussainweb talking about Config Split module. #Drupal pic.twitter.com/SqyMpOrVbP

— Malabya (@malavya88) August 18, 2018

Webpack with Drupal themes

We had a short break after the session after which we started the last session of the day on using Webpack with Drupal themes by myself. I started the topic with a discussion on modern JavaScript including newer ES6 syntax and specifically, writing modular JavaScript. I then introduced the template I have put up to use Webpack along with Drupal’s bootstrap theme’s SASS starterkit.

.@hussainweb is talking about javascript and webpack @BangaloreDrupal #meetup pic.twitter.com/QKcUpiWdQi

— Taher Jodhpurwala (@devtaher) August 18, 2018

We ended the day with crediting all the speakers and organisers of the meetup on the issue we have for our meetup. This was followed by our group photo and closing.

Photos

All photos from the meetup are below.

Drupal Meetup Bangalore - August 2018

Jul 28 2018
hw
Jul 28

This month’s Drupal meetup was held at 91Springboard in Koramangala. We are back after a long time and that’s thanks to 91Springboard for providing us with the venue. Snacks in the meetup and lunch after the meetup were courtesy of Axelerant.

We had a total of 36 attendees from various companies in Bangalore. Here is a chart that shows the distribution of various attendees by their company. Notice that SpecBee has the largest participation in this meetup with 14 of their team members attending the meetup.

Drupal Bangalore Meetup - July 2018 - attendees

We started the day at 10 AM with Taher introducing the meetup, schedule, and talking about some of the happenings in the Drupal community. He talked about some of the new features in Drupal 8.6, initiatives that are going to be stable soon, and some of the events like Drupal Europe and BADCamp.

Drupal Bangalore Meetup - July 2018

Sessions

The first session of the day was on improving the developer workflow presented by Malabya. Malabya talked about various aspects of development including setting up the development environment with DrupalVM (Vagrant) or Lando (Docker), managing codebase, version control, dependency management with composer, deployment, and many other best practices around development (not just Drupal development, but even general programming).

Drupal Bangalore Meetup - July 2018

This was followed by a talk about how contributing to Drupal improves your career by Parvateesam. Parvateesam talked about various kinds of contribution, the benefits of contributing particularly to your career, and shared his own journey contributing to Drupal and speaking at various events. Everyone was impressed with how he started off as a speaker at DrupalCamp Hyderabad a couple of years back and now getting selected to speak at Drupal Dev Days and volunteering at Drupal Europe. After this talk, several contributors present spoke about their own journeys.

Drupal Bangalore Meetup - July 2018

We took a break after this session for coffee and snacks courtesy of 91Springboard and Axelerant. This also included a brief opportunity to network.

Drupal Bangalore Meetup - July 2018

The third talk of the day was a lightning talk for Rollout by Napoleon Arouldas. Napoleon described the typical problems faced during deploying code and how we can make the whole process better by using a tool like Rollout. He also handed out coupon for attendees at the meetup to try out Rollout for free.

Drupal Bangalore Meetup - July 2018

The last topic of the day was a discussion facilitated by myself for Drupal Governance initiative. After a very fruitful discussion and walking through a group interview, we ended the day with pizzas courtesy of Axelerant.

Drupal Bangalore Meetup - July 2018

Drupal Meetup

This was one of the better-organised meetups thanks to the efforts of the organising team, especially Taher Jodhpurwala. It was only made better thanks to generous support of 91Springboard for the venue and Axelerant for snacks and lunch. You can find more photos from the venue below, or just watch the video to fly through the photos.

[embedded content]

If you prefer just the photos, here they are:

Drupal Meetup Bangalore - July 2018

I’d like to thank the organisers, sponsors, and attendees for making this meetup a success. See you all at the end of August for our next meetup.

Nov 27 2017
hw
Nov 27

This month’s Drupal meetup in Bangalore was held this weekend, on 25th November. Specbee Consulting office kindly provided us with a venue for the meetup and helped organise the event. This meetup happened after a period of six months, and the motive was to get the meetup activities started again in Bangalore.

We are hoping to make organising the meetups and all related activities much more easy and sustainable for everyone involved in Bangalore. A full discussion of these initiatives should probably happen elsewhere, but by starting off with this meetup this month, we hope to keep this running in a more stable manner with minimal load on the organisers. If you’d like to stay updated on when meetups are announced, join us on Meetup.

The day started at around 10:30 AM with a round of introduction of everyone present. The first presentation of the day was by Parvateesam Konapala and Rakesh James who introduced Symfony Components to everyone. They introduced various components used in Drupal such as Event Dispatcher, Dependency Injection, Serializer, etc… The discussion ended with a talk of tools like Drupal Console.

This was followed by a small break with refreshments provided by Specbee Consulting.

After the break, Taher Jodhpurwala spoke about quickly starting with Drupal development. In the presentation, Taher shared ways in getting started with Drupal development with minimum effort using tools like composer, Lando, etc…

Lastly, I discussed a bit of how we use CI systems like Gitlab and Circle CI to manage, test, and deploy our Drupal websites. The meetup ended at 1:30 PM with a group photo.

I’d like to thank Specbee Consulting for providing a venue for the meetup and all the support and, of course, refreshments. Photos from the meetup are below.

Drupal Meetup Bangalore - Nov 2017

Sep 20 2013
sun
Sep 20

There is an active attempt to fork the Drupal content management system into a new application:

Backdrop — a play on Drupal's name and origin, which originally intended to be dorp.org (Dutch: village), but due to a typo, became drop.org in 2001. Shortly after, drop.org was renamed to drupal.org.

As the name suggests, Backdrop's intention is to get back to the roots of Drupal:

  • Quality
  • Simplicity
  • Developer Experience and Productivity
  • Performance
  • Targeted vision and use-case

The project was kick-started and is driven by a few people that I personally respect and value a lot. In fact, they are representing a group of brilliant people and excellence, which originally turned Drupal into the product that it is today. A group that felt ignored and unheard in the recent past — even though it were primarily these and like-minded people who enabled the world to interpret Drupal as a real product and competition in the first place.

To be clear: Do not try this at home. The attempt of forking Drupal involves hundreds of factors that you are not considering. There have been many attempts in the past, but not a single one succeeded. Yours will not succeed either. Backdrop may or may not be an exception.
(Did I phrase this clear enough?)

The root of all concerns is Drupal 8, which is in development and undergoes major architectural changes for ~3 years already. Though, despite all changes, there's little to no innovation compared to the competition. The focus is to clean up and modernize all core code and APIs, with the intended goal of ending up with a base system whose architecture is more maintainable and sustainable in the future.

The current state of Drupal 8 is poor and not worth to talk about. However, the final and intended state seems to present a clear and diametrical conflict to the former goals, qualities, values, and roots of the original Drupal project.

The situation

I talked to various different parties. What I learned is simple:

People are not listening to each other.

People do not appear to remotely see the points that others are trying to make. In both directions. Assumptions are utterly wrong, frontiers are built before having any clue at all, counter-arguments are overly naive and misguided, and all communication is generally hindered by a good amount of bad-ass trolling.

What I heard was offensive defense and disagreement. No one appears to listen and to truly perceive and understand all arguments, before drawing any kind of lines and/or conclusions.

As if, you know, the world was flat.

In short, a simple and common conflict resolution scenario.

This blog post originally aimed to cover all aspects on the idea of forking Drupal and my personal stance on this particular fork, but after gathering more and more insights on the current situation, I decided to leave out and save those parts for a future post.

Therefore, this post reflects on the communication conflict only.

Solutions are possible. They will require changes. They will cause conflicts. It is a matter of will, listening, and dedication. It is a matter of respect.

Disconnect in Dissent

In analyzing the situation, and in distilling and deciphering all arguments, I did notice that there appears to be a rather large disconnect in understandings and communication.

It's important to note upfront that the situation did not suddenly appear a week ago, but actually evolved over the past ~2 years throughout the Drupal 8 development cycle.

Drupal core developers appear to be coming from a mindset that is deeply stuck in refactoring work of internal core framework subsystems, which happens to involve plenty of abstractions and complexity. These were major and important undertakings, but in all of this work, not much thought went into the question of how verbose these concepts need to be for the average module developer.

A few core developers are showing good will to fix and improve minor developer experience issues. Some others do not appear to see any issues at all, and they seem to not only ignore the arguments that are being raised, but even strongly and blatantly argue against them. Tension appears to be caused by an attitude of:

I am right and know better, and you are just simply wrong.

...which doesn't make it sound as if anyone was listening.

Conversely, people who are looking at the current state of art are deeply confused as to why so much internal complexity and abstractions are verbosely exposed in the user space, and whether that is really necessary.

From what I've heard, the scope and extent of concerns does not encompass a few individual improvements here and there, but instead, is asking for major changes to remove all unnecessary complexity and ensure simplicity (and productivity, for that matter) in user space code.

The primary disconnect appears to be a major difference in understanding of what exactly is interpreted as "complex."

There further appears to be a misunderstanding in that people would have a general problem with object-oriented code, which is not only misguided but also makes an insulting assumption on the technical learnability skills of others. As a consequence, a line is drawn between parties that does not actually exist, which in turn hinders constructive communication.

The same consideration appears to be further manifested by the assumption that the target developer audience of Drupal 8 would be different. Equally based on the idea that novice PHP developers and hobbyists would not be capable to understand and learn object-oriented code. This nonsensical assumption clearly appears to stem from the disparity in understanding of what exactly "complexity" constitutes.

All communication appears to be distorted by another disturbing detail: The API freeze for Drupal 8 was officially announced already, despite the fact that literally everyone and all parties appear to agree that the current state is a total mess and not remotely releasable. This aspect especially supports the resignation of the non-core party, as they're in fact asking for major API changes, which obviously presents yet another unnecessary conflict.

Drupal appears to have taken steps to remedy the situation through a new D8DX initiative. But coherent to all other communications, this initiative starts with a big list of things that are out of question, and just continues with a list of minor issues that may be debatable. In other words, directly building a frontier, before even starting to listen.
Update: It appears the initiative page has been corrected to somewhat address this issue.

Conclusion

It's a tough situation, because there's a lot of frustration all around. In fact, no one appears to be happy with anything. The lack of a clear leadership, ownership, and authority certainly contributed to the final path that slowly but certainly turned frustration into resignation.

Now the question is whether everything sucks and it's too late, or whether there is a chance to resolve the situation by taking a large step back (stop coding, start listening) and bring everyone on one round table to find concrete, working solutions.

Solutions are very well possible. But they certainly require everyone to leave their comfort zone, start being receptive, listen to and ensure to comprehend concerns of others, accept that there are different world perspectives, and most importantly, to allow yourself to make compromises.

My recommendation is to not calm down and defend, downplay, or ignore the issue. Also, don't be afraid, don't be a jerk, and don't be a hardliner. Instead, I want to encourage you to be open, welcoming, collaborative, and constructive in everything you do. Respect others, respect the culture. In short, respect

The Drupal Way™

May 11 2013
May 11

While ago i was looking for an slider module (implementation of JQuery UI slider module), surprisingly i couldn't find any solution except jSlider Form API which wasn't exactly what i was looking for. So i did what every good Drupal developer does, I wrote a generic slider module and shared it on Drupal.org (jQuery UI Slider Field). I even implemented "jSlider Form API" features.

Several months later and after i published several new minor versions, one of the users mentioned that there is in fact another slider module similar to mine!! SliderField and it was quite old too. He suggested joining forces to prevent duplicate modules. I usually find what I'm looking for so it was very unexpected. I think there are two reasons i couldn't find it. The main reason is, the name of the module which is"SliderField" instead of "Slider Field" which makes it difficult to find it only by searching titles that's why having search-able keywords for modules is very useful. Another reason is that I didn't ask the community via IRC and forum, i usually do before writing a new module, there is a group for this purpose in case you didn't konw. Contributed Module Ideas

My module was much more completed and had many more features so it was too late for me, but for the sake of the community i decided to join the two projects and probably any other similar slider related module. For straightforward module like this there shouldn't be really several different modules it wastes community's valuable resources. I contacted the maintainer of the SliderField module proposing to join forces, and since nobody was working on SliderField module for quite some time he agreed and gave me access.

Since the SliderField module was older and had more users, proper thing to do was to make it the main module. Here is what i did afterwards :

  • Implemented all the missing features of SliderField
  • Renamed jQuery UI Slider Field
  • Created a new branch and cloned the new module preserving the git history using this tutorial
  • Implement upgrade path for previous version of SliderField and migrate path for jQuery UI Slider Field
  • Published a working version - Updated module's page
  • Added a note on jQuery UI Slider Field page notifying its users of the new module and my plans
  • Moved all the active issues of jQuery UI Slider Field to SliderField
  • Contacted maintainers of several other slider modules asking them to put a note on their module's page notifying their users about the existence of a generic solution

You may ask why? I could simply continue maintaining my own module, why go into this much trouble!

As you may have already noticed one of the great things about Drupal community is that we all work together to make Drupal better. At the end it doesn't really matter if it's my module , my patch or someone else's. What matters is to have a greater and more powerful tool which we can all use.

All well known Drupal developers have done the same, they gave up their own modules to the other developers because they simply didn't have time or interest to continue developing it or joined the others instead of reinventing the wheel! I personally took over several different abandoned modules and revived them instead of making another similar one, Community allowed me to do that. The fact is if it wasn't because of this attitude we would never had powerful modules like Views, FileFiled, Panels,CCK, etc , Instead we might have had Views2, Views Plus, MyViews! and certainly none of them could possible do what Views can today, it's the hard work of many talented developers, they decided to work together and continue each other's work and that's the result.

So let's all do it in Drupal way :)

Sep 08 2012
sun
Sep 08

I felt like working in a niche until November 2011. I did not believe there was anyone else beyond me in my local area who's seriously using Drupal. But — it was on my walk to the grocery store when two strangers suddenly crossed the street, bumped into me and said "Dude, are you sun from drupal.org?"

How wrong I was. I started my local user group shortly after, in November 2011. Out of fucking nowhere, 12+ people attended the first meeting! With a huge interest in Drupal and fostering a local user group.

Meanwhile, the Drupal User Group Karlsruhe is close to its 1st anniversary. And, we've adopted the DrupalCon spirit recently: We are meeting once a month. We're meeting in a different location each time. The location is different, just like our members are. We want to learn about new things. And the location shouldn't be excluded.

We want to share and exchange knowledge, about Drupal and the world. But how?

The cause.

We originally started to organize our meetings in a Facebook group, via Doodle events, and groups.drupal.org. Plenty of organizational overhead and problems with that:

  • Facebook groups, even though "public", are only public within Facebook, but cannot be accessed nor found from the outside world. Many people understandably do not want to sign up due to data privacy concerns, and have other good reasons to stay away from it. Inaccessible, in terms of accessibility.
  • Doodle events are not found anywhere to begin with.
  • groups.drupal.org has groups and events. But not even long-term users are able to figure out how to use the site in a way that allows to locate and distill the events of actual interest. How are new users supposed to do that then? But nevermind, ~80% of my group members didn't have a drupal.org user account in the first place! (geez, what? — Effin' register now if you're using Drupal but don't have one yet!)

Conclusion: We need our own web site.

We need to be found on the net. And in search results. We need to make it trivial for interested people to join. We need our own mechanisms to figure out the next meeting location. We are our own local Drupal sub-community. We need to feel home, and we need a way to communicate with each other. This matters.

There's excellent shit for that. — But wait.

Question:

What's the problem?

or:

How many things can we attack by asking the right questions?

  1. A concrete use-case.

    Jeff Eaton preached it all over again at DrupalCons and camps all over the world. Dries Buytaert repetitively stated it in keynotes. And even Drupal usability team leads Roy Scholten and Bojhan Somers want it: Installation profiles and distributions.

    Tailored to a specific use-case.

    Since Drupal 5 in 2007, the installation profile functionality in Drupal core was heavily improved. Given these improvements, the community tried hard to reach consensus on the fact that profiles and distros are a good thing.

    Years of discussions later. Under the working title Snowman [also: "Onramp"], a concrete scope and use-case for an installation profile to be shipped with Drupal core was developed:

    Small groups collaborating on a project who want to tell the world about it... and convince others to join in.

    A solid and focused use-case.

    Given that, the Drupal community dived into shitloads of discussions on which functionality would be required in core that doesn't exist yet. And we looked into potential consumers and adopters for that use-case. For example, the global Occupy movement.

    Missing the obvious. Not realizing that we have the identical and perfect match of a use-case within the Drupal community ourselves:

    Hundreds of local Drupal User Groups all around the world have a SHARED INTEREST!

    We want to communicate with each other and the world about Drupal, and our interest is to on-board new people into our local groups. Transferring and sharing knowledge. Taking Drupal to the next level.

    Is there any better incentive to work on Drupal?

  2. Missing Drupal resources.

    You hear the same story. Shuffle. Repeat: Some contributors find their way to contributed projects, but have no idea and are scared of Drupal core. People are not able to find skilled Drupal service providers — they're swamped with work already. And companies that are relying on Drupal and employing people don't manage to increase their skills.

    Dries depicted the Drupal Learning Curve in 2007. I revised that into the Real Drupal Learning Curve later — showing the giant gap between people who stay in custom code forever and those who make the massive leap of contributing to Drupal core.

    Once you take that path, your skills drastically improve. On all levels.

    Hundreds of local Drupal User Groups all around the world have PLENTY OF PEOPLE.

    Did you know that even a single Drupal core patch makes a significant difference on your resume?

  3. Mentor Drupal talent.

    Did you ever consider to contribute to Drupal? Did you ever consider to help someone to contribute to Drupal? Did you know that there are thousands of people who are only seeking for some minimal guidance?

    Have you been inspired, influenced, or brought into Drupal by someone else? People who explained stuff to you, but actually didn't have any reason to waste their time with you? And did you learn something new?

    As of today, you are able to give credit your mentors in your drupal.org user profile. Use it!

    Truth is: You weren't in the position you are today, if there wouldn't have been others from who you've learned. That applies to you, me, and everyone else.

    It only takes the effect of a fucking dead pixel on your screen to understand the impact of a single link in the chain. Let's pretend the one who taught you about Drupal was that pixel — you'd be excited about his/her exceptional behavior compared to all others, but would you give a shit?

    But what if you were that dead pixel, the dead link in the chain?

    You are.

    And you can give a shit. But you can also start to make a difference. Whatever know-how you gained and have, you can truly pay it forward. You can ask yourself where to start. But did you know?

    Hundreds of local Drupal User Groups all around the world have a SHITLOAD OF TALENT!

    Stop fucking ask yourself where to start. Go to your local user group (or initiate one). Grab yourself some attendees and mentor them in contributing to Drupal. Pay it forward.

    They'll be excited to learn about what's going on with Drupal and how they can contribute to Drupal. Bridging the gap? Totally no better way to do that.

    If you need more support, there's an entire Drupal Core Mentoring effort to support you. A true guide for new contributors to find appropriate tasks for their skill level, with a shittonne of stunning results!

    Help them to contribute to Drupal. So they are going to educate, help, and train others to become better, in turn!

  4. Sanity testing.

    Drupal 5 was the last release that was deployed on drupal.org during development. Gone are the times in which we ate our own dog food before releasing the fancy new shit — determining bugs and revealing nonsense early — when things can still be changed, before publicly releasing to the masses.

    Today, drupal.org is driven by 100+ contributed modules. There's no way to keep that code in sync with the daily API changes that are happening for Drupal core.

    But real world testing is important. Most of us don't have an incentive to use the latest and greatest code. We're missing an essential feedback mechanism to learn about mistakes early. We need qualified feedback from people. Before it is too late. Guess what?

    Hundreds of local Drupal User Groups all around the world can TEST!

    We can restore true production site testing and the lack of that feedback mechanism.

    Whose sites would be better suited than those of local Drupal User Groups? What kind of fancy functionality do you have on there that couldn't be restored within minutes on a fresh site? All we need and all we should need for that use-case is Drupal core... [rewind and circle back into the above]

    (And if all fails, what other data than the user accounts do you really need?)

    Rumors are, some Drupal hosting providers will happily hand your local user group one of their managed full stack environments if you decide to contribute to Drupal core in this way, so your group doesn't have to deal with infrastructure/devops shit and can focus on contributing!
    [Providers: Feel free to state your offer and how to apply in comments!]

  5. Focus on user needs.

    Some initiatives are driving some major architectural changes for Drupal 8 in dedicated working groups. Exciting! Everyone of us is on fucking steroids to get those done! But.

    There are almost no new features that make a difference for users.

    Check. A Wysiwyg editor in core, native inline/in-place editing, user profiles, E-mail fields, Link fields, Date fields, a Token UI, a post-module installation guide, native SMTP support, and whatsoeverfucking nonsense, check.

    There's a lot that needs to be done. And for the most part, there's even agreement that it should be done. But everyone's swamped already!

    This is where you and your local Drupal User Group come in. You have the real needs. You are able to shift the focus, onto features that none of the usual suspects has time to work on.

    Hundreds of local Drupal User Groups all around the world can MAKE THAT SHIT HAPPEN.

The solution.

Attend your local Drupal User Group meetings. Don't tell me you can't. Don't tell me you're above that level. Don't fucking tell me anything. Attend them! :)

Explain to everyone how awesome it is to change the system while we can. Tell them how adjusting it for their needs makes their lives so much fucking easier.

Build your local Drupal User Group web site on Drupal 8. Don't be scared. Take the challenge, learn and help to create something new with others!

  1. Help to build the Snowman installation profile for Drupal 8, for your very own user group.
  2. Attract new Drupal people by just appearing in your local user group.
  3. Solve the Drupal talent problem by mentoring someone (or two)!
  4. Ensure Drupal 8 works, by testing it live.
  5. Make Drupal awesome by solving actual user problems.

You can contribute on so many levels. Don't make the mistake that it was about coding only. There's usability, design, project management/coordination (pushing shit forward), front-end/JS/CSS, manual testing, performance testing, and tons of other areas!

What you get. For free:

  • Native HTML5 output.
    (a.k.a. html5 and html5_tools in core)
  • A new configuration system.
    (a.k.a. Configuration staging [and a bit of Features] in core)
  • A new RESTful HTTP router system?
    (a.k.a. Services in core)
  • A fully multilingual and translatable system?
    (a.k.a. i18n and Entity translation in core)
  • A native layout, page building, and blocks system?
    (a.k.a. Beans, Panels and Page manager in core)
  • Views in core?
    (a.k.a. Views in core)

And after explaining all that fancy new shit to others ;) ...you'll notice how you're suddenly right in the middle of mentoring someone in how to contribute to Drupal.

Do it. Pay it forward.

"You", in all of the above, means you.

Nov 01 2010
Nov 01

FOSDEM banner

It's that time of the year again — the nice folks at FOSDEM have granted us a developer room at their upcoming conference (February 5+6 2011 in Brussels, Belgium)!

As usual there were more applications than they were able to accommodate, so we are very grateful for this opportunity for collaboration. Titled "MySQL and Friends", our room next year will be H.2213 with a capacity of 100 seats. It will be at our disposal on Saturday 5th, from 13:00 till 19:00. Like last year, we would like to set up a schedule of talks related to the MySQL server and the various projects that surround it. Each talk will last 20 minutes, plus 5 minutes of Q&A and a 5 minute break for switching speakers, giving us 12 slots in total to fill with excellent tech talks. Take a look at this year's schedule for some examples! I hope we can assemble an even more exciting and interesting schedule for next year.

Quoting from my last year's call for papers:

We are looking for covering a wide range of topics that attract both MySQL DBAs as well as application developers that work with MySQL as their database of choice. Are you developing a new storage engine or other plugin? Do you want to share your experiences and best practices in administering or deploying MySQL servers? Did you develop a new method to scale a MySQL setup? Let us and the audience know about it! You can submit your talk proposal via this submission form.

The deadline for turning in your proposal is Sunday, 26th of December, 2010, after which there will be a voting and rating period to identify the most interesting and attractive topics.

Please check the FOSDEM 2011 information page on the MySQL Forge Wiki for more details and don't hesitate to contact me directly, if you have any questions or suggestions. I look forward to your proposals!

Oct 25 2010
Oct 25

Drupal logoOver the weekend I updated my Drupal 7 test appliance in SUSE Studio to the Drupal 7.0-beta2 release, which was released on Oct. 23rd. I also added phpMyAdmin upon a user request, to provide a web-based method to work with the MySQL instance, if needed.

In addition to the lightweight "headless" appliance (which can only be accessed and configured via a remote network connection), I've now also created a GUI-based version. This appliance starts a minimal GNOME desktop and a Mozilla Firefox browser, which in turn opens the Drupal installation page by default. I hope you will find this useful if you want to toy around and test Drupal 7 without having to go through the entire OS and LAMP stack configuration yourself. In fact, you can even test this appliance via the recently added test drive option from right out of your web browser!

The appliance is now also available in OVF format. SuSE Studio now also builds Amazon EC2 images, which don't seem to be available for download from the SUSE Gallery yet. I assume this is a recent addition to the continuously improving SUSE Studio functionality, hopefully these images will be made available soon.

Sep 17 2010
Sep 17

Drupal logoThe Drupal community just recently released another alpha test release of their upcoming Drupal 7 version, to shake out the remaining bugs and to encourage more users to test it.

If you would like to give it a try, but you don't have a free server handy, how about using a virtual machine instead? Using the fabolous SuSE Studio, I've created an appliance based on openSUSE 11.3, Drupal 7.0-alpha7 and MySQL 5.1 with the InnoDB plugin and strict mode enabled (both for the SQL mode and InnoDB mode. Using this configuration helps to ensure that Drupal works well with the current version of MySQL/InnoDB and does not use any "questionable" SQL statements. This might be especially interesting for additional modules - Drupal core did not reveal any problems using strict mode so far.

You can download disk images for VMware/Virtualbox/KVM or XEN from the SUSE Gallery (free login required). Just boot the appliance in your virtualization application of choice, choose your keyboard layout and step through the network configuration and Time Zone selection. Once the appliance has booted up and the login: prompt appeared, point your web browser to the appliance's IP address to start the Drupal installation/configuration. MySQL has been pre-configured, there is an empty database named "drupal" and a user "drupal" with the same password to access it. You just need to enter this information in the Drupal Database configuration dialogue during the installation. Anything else can be configured to your liking.

After you have finished the installation, you can toy around with a fresh Drupal 7 installation! Install additional modules, change the themes, add content. And make sure to report all bugs that you run into while doing so! Have fun.

Nov 05 2009
Nov 05

This blog post is a by-product of my preparation work for an upcoming talk titled "Why you should be using a distributed version control system (DVCS) for your project" at SAPO Codebits in Lisbon (December 3-5, 2009). Publishing these thoughts prior to the conference serves two purposes: getting some peer review on my findings and acting as a teaser for the actual talk. So please let me know — did I cover the relevant aspects or did I miss anything? What's your take on DVCS vs. the centralized approach? Why do you prefer one over the other? I'm looking forward to your comments!

Even though there are several distributed alternatives available for some years now (with Bazaar, git and Mercurial being the most prominent representatives here), many large and popular Open Source projects still use centralized systems like Subversion or even CVS to maintain their source code. While Subversion has eased some of the pains of CVS (e.g. better remote access, renaming/moving of files and directories, easy branching), the centralized approach by itself poses some disadvantages compared to distributed systems. So what are these? Let me give you a few examples of the limitations that a centralized system like Subversion has and how these affect the possible workflows and development practices.

I highly recommend you to also read Jon Arbash Meinel's Bazaar vs Subversion blog post for a more elaborate description of the limitations.

  • Most operations require interaction with the central repository, which usually is located on a remote server. Browsing the revision history of a file, creating a branch or a tag, comparing differences between two versions — all these activities involve communication via the network. Which means they are not available when you're offline and they could be slow, causing a slight disruption of your workflow. And if the central repository is down because of a network or hardware failure, every developer's work gets interrupted.
  • A developer can only checkpoint his work by committing his changes into the central repository, where it becomes immediately visible for everybody else working on that branch. It's not possible to keep track of your ongoing work by committing it locally first, in small steps, until the task is completed. This also means that any local work that is not supposed to be committed into the central repository can only be maintained as patches outside of version control, which makes it very cumbersome to maintain a larger number of modifications. This also affects external developers who want to join the project and work with the code. While they can easily obtain a checkout of the source tree, they are not able to put their own work into version control until they have been granted write access to the central repository. Until then, they have to maintain their work by submitting patches, which puts an additional burden on the project's maintainers, as they have to apply and merge these patches by hand.
  • Tags and branches of a project are created by copying entire directory structures around inside the repository. There are some recommendations and best practices on how to do that and how these directories should be arranged (e.g. by creating toplevel branches and tags directories), but there are several variants and it's not enforced by the system. This makes it difficult to work with projects that use a non-standard way for maintaining their branches and can be rather confusing (depending on the amount of branches and tags that exist).
  • While creating new branches is quick and atomic in Subversion, it's difficult to resolve conflicts when merging or reconciling changes from other branches. Recent versions of Subversion added support for keeping better track of merges, but this functionality is still not up to par with what the distributed tools provide. Merging between branches used to drop the revision history of the merged code, which made it difficult to keep track of the origins of individual changes. This often meant that developers avoided developing new functionality in separate branches and rather worked on the trunk instead. Working this way makes it much harder to keep the code in trunk a stable state.

Having described some downsides of the centralized approach, I'd now like to mention some of the most notable aspects and highlight a few advantages of using a distributed version control system for maintaining an Open Source project. These are based on my own personal experiences from working with various distributed systems (I've used Bazaar, BitKeeper, Darcs, git, Mercurial and SVK) and from following many other OSS projects that either made the switch from centralized to distributed or have been using a distributed system from the very beginning. For example, MySQL was already using BitKeeper for almost 2 years when I joined the team in 2002. From there, we made the switch to Bazaar in 2008. mylvmbackup, my small MySQL backup project, is also maintained using Bazaar and hosted on Launchpad.

Let me begin with some simple and (by now) well-known technical aspects and benefits of distributed systems before I elaborate on what social and organizational consequences these have.

In contrast to having a central repository on a single server, each working copy of a distributed system is a full-blown backup of the other repository, including the entire revision history. This provides additional security against data loss and it's very easy to promote another repository to become the new master branch. Developers simply point their local repositories to this new location to pull and push all future changes from there, so this usually causes very little disruption.

Disconnected operations allow performing all tasks locally without having to connect to a remote server. Reviewing the history, looking at diffs between arbitrary revisions, applying tags, committing or reverting changes can all be done on the local repository. These operations take place on the same host and don't require establishing a network connection, which also means they are very fast. Changes can later be propagated using push or pull operations - these can be initiated from both sides at any given time. As Ian Clatworthy described it, a distributed VCS decouples the act of snapshotting from the act of publishing.

Because there is no need to configure or set up a dedicated server or separate repository with any of today's popular DVCSes, there is very little overhead and maintenance required to get started. There is no excuse for not putting your work into revision control, even if your projects starts as a one-man show or you never intend to publish your code! Simply run "bzr|git|hg init" in an existing directory structure and you're ready to go!

As there is no technical reason to maintain a central repository, the definition of "the code trunk" changes from being defined by a technical requirements into a social/conventional one. Most projects still maintain one repository that is considered to be the master source tree. However, forking the code and creating branches of a project change from being an exception into being the norm. The challenge of the project team is to remain the canonical/relevant central hub of the development activities. The ease of forking also makes it much simpler to take over an abandoned project, while preserving the original history. As an example, take a look at the zfs-fuse project, which got both a new project lead and moved from Mercurial to git without losing the revision history or requiring any involvement by the original project maintainer.

Both branching and merging are "cheap" and encouraged operations. The role of a project maintainer changes from being a pure developer and committer to becoming the "merge-master". Selecting and merging changes from external branches into the main line of development becomes an important task of the project leads. Good merge-tracking support is a prerequisite for a distributed system and makes this a painless job. Also, the burden of merging can be shared among the maintainers and contributors. It does not matter on which side of a repository a merge is performed. Depending on the repository relationships and how changes are being propagated between them, some DVCSes like Bazaar or git actually provide several merge algorithms that one can choose from.

Having full commit rights into his one's own branch empowers contributors. It encourages experimenting and lowers the barrier for participation. It also creates new ways of collaboration. Small teams of developers can create ad-hoc workgroups to share their modifications by pushing/pulling from a shared private branch or amongst their personal branches. However, it still requires the appropriate privileges to be able to push into the main development branch.

This also helps to improve the stability of the code base. Larger features or other intrusive changes can be developed in parallel to the mainline, kept separate but in sync with the trunk until they have evolved and stabilized sufficiently. With centralized systems, code has to be committed into the trunk first before regression tests can be run. With DVCSes, merging of code can be done in stages, using a "gatekeeper" to review/test all incoming pushes in a staging area before merging it with the mainline code base. This gatekeeper could be a human or an automated build/test system that performs the code propagation into the trunk based on certain criterions, e.g. "it still compiles", "all tests pass", "the new code adheres to the coding standards". While central systems only allow star schemas, a distributed system allows workflows where modifications follow arbitrary directed graphs.

Patches and contributions suffer less from bit rot. A static patch file posted to a mailing list or attached to a bug report may no longer apply cleanly by the time you look into it. The underlying code base has changed and evolved. Instead of posting a patch, a contributor using a DVCS simply provides a pointer to his public branch of the project, which he hopefully keeps in sync with the main line of development. From there, the contribution can be pulled and incorporated at any time. The history of every modification can be tracked in much more detail, as the author's name appears in the revision history (which is not necessarily the case when another developer applies a patch contributed by someone else).

A DVCS allows you to keep track of local changes in the same repository, while still being able to merge bug/security fixes from upstream. Example: your web site might be based on the popular Drupal CMS. While the actual development of Drupal still takes place in (ghasp) CVS, it is possible to follow the development using Bazaar. This allows you to stay in sync with the ongoing development (e.g. receiving and applying security fixes for an otherwise stable branch) and keeping your local modifications under version control as well.

I've probably just scratched the surface on what benefits distributed version control systems provide with this blog post. Many of these aspects and their consequences are not fully analyzed and understood yet. In the meanwhile, more and more projects make the switch, gather experiences and establish best practices. If you're still using a centralized system, I strongly encourage you to start exploring the possibilities of distributed version control. And you don't actually have to "flip the switch" immediately — most of the existing systems happily interact with a central Subversion server as well, allowing you to benefit from some of the advantages without you having to convert your entire infrastructure immediately.

Here are some pointers for further reading on that particular subject:

Oct 29 2009
Oct 29

So you're a small startup company, ready to go live with your product, which you intend to distribute under an Open Source License. Congratulations, you made a wise decision! Your developers have been hacking away frantically, getting the code in good shape for the initial launch. Now it's time to look into what else needs to be built and setup, so you're ready to welcome the first members of your new community and to ensure they are coming back!

Keep the following saying in mind, which especially holds true in the Open Source world: "You never get a second chance to make a first impression!". While the most important thing is of course to have a compelling and useful product, this blog post is an attempt to highlight some other aspects about community building and providing the adequate infrastructure. This insight is based on my own experiences and my observations from talking with many people involved in OSS startups and projects.

First of all, realize that your community is diverse. They have different expectations, skills and needs. Pamper your early adopters. They are the multipliers that help you to spread the word, if they are convinced and excited about what you provide. Put some faith and trust in them and listen to their input. In the beginning, you might want to focus on your developer community and the tech-savvy early adopters, but this of course depends on the type of product you provide and on what your target audience looks like. In any case, make sure that you provide the necessary infrastructure to cater the respective needs of these different user bases.

Also remember that you can not overcommunicate with your community. Blog heavily, write documentation/FAQs/HOWTOs, build up Wiki content and structure, create screencasts. Don't rely on the community to create any of this in the early stages. But be prepared to embrace and support any activities, if they arise. Solicit input, provide opportunities and guidelines for participation!

While it's tempting to do: don't establish too many communication channels in the beginning. Keep it simple and reduce the different venues of communication to an absolute minimum at this point. A new forum with many different topics but no comments looks like an art gallery with a lot of rooms, but they are either empty or there's just a single picture hanging at the wall. Nobody wants to visit that, he'd feel lost in the void. At the early stage of a project, I think it's essential to keep the discussions in as few places as possible. This helps you to identify your key community contributors (the "regulars" aka the "alpha geeks") and to build up personal relationships with them (and among themselves).

Consider establishing a forum with only a few topics, start with one or two mailing lists. Also make sure that these are actively being followed (e.g. by yourself or your developers) and that questions are being answered! I personally prefer mailing lists over forums, but I'm probably not representative. Ideally, it would be nice if there would be a unified communication hub that supports both posting via the web site like a forum, or via email or NNTP (similar to Google Groups). This keeps the discussions on one central place (which eases searching for specific keywords/topics) and still allows users to choose their preferred means of communication. Unfortunately, I haven't really found any suitable platform for this approach yet — suggestions are welcome! And once your community grows and people start complaining about too many or off-topic discussions, you can think about further separation of the discussion topics.

Allow your users to submit and comment on issues and feature requests by providing a public bug/feature tracking system. Use this system for your release tracking and planning as well, to give your users a better insight into what they can expect from upcoming versions. Also, make it very clear to your users where bug reports and feature requests should be sent to! Should one use the Forums or the bug tracker for that? A mailing list or forum makes it easier for users to participate in these discussions, but makes it more difficult to keep track of them and to ensure they are being followed up on. For the sake of simplicity, I would actually suggest to remove any separate forums about these topics. Instead, educate your community early about which is the right tool and venue to use for such requests. This saves time and resources on your side and helps to build up an initial core of community members that can then educate others about "the ropes". Otherwise you end up with the burden of keeping track of every feature request or bug report that was posted somewhere, ensuring it has been added to the bug tracker...

If your community infrastructure consists of separate building blocks to provide the required functionality (e.g. forums, bug tracking, wiki), consider setting up a single-sign on (SSO) technology and establish a unified look and feel between these applications. Your users should not be required to log in with more than one username and password, and every application should share the same login and profile data. However, only require a login, if absolutely necessary! Many users feel alienated by having to enter their personal data, even if they only want to lurk around or browse through existing discussions or documentation. As an additional benefit, it helps you to quickly identify your "community stars" in the various sections of your site: Who reports the most bugs? Who is the most helpful person on our Forums? This information could also be published on your community site, giving users the opportunity to build up reputation and karma. Community infrastructure sites like Drupal or Joomla provide an excellent foundation to get you started, while offering enough room for improvement and additional functionality at a later point.

Lower the entrance barrier and make it as easy as possible for people to get started with your application. Don't just throw a source archive at them, hoping that someone else will take care of doing the binary builds. Put some effort into building and providing binary, ready-to-install packages for the most popular platforms that your target audience is likely to use. The three most important platforms to cover are Microsoft Windows, Mac OS X and Linux. While users of the latter usually have the required tools and experience in building stuff from source, Windows and Mac users are usually "spoiled" and don't want to be bothered with having to install a full-fledged development environment before they could eventually evaluate your application.

When it comes to Linux distributions, you should look into building distribution-specific packages. This heavily depends on the requirements for external libraries that your application is using, which might differ on the various flavours of Linux. Depending on the purpose of your application, you may either focus on the more desktop/developer-centric distributions like Mandriva, openSUSE, Ubuntu, or on the distributions commonly used in server environments, e.g. Debian, CentOS, Fedora, RHEL, SLES (Yes, I am aware that most distributions are multi-purpose and serve both tasks equally well, and it's of course possible to use each of them to get the job done — it's a matter of taste and preference). If possible, make use of existing build infrastructure like Fedora's Koji build system, Launchpad's Personal Package Archives (PPA) or the openSUSE Build Service (which even allows you to build RPMs and DEBs for non-SUSE distributions) to automate the building and provisioning of distribution-specific packages for a wide range of Linux flavours. If your application is slightly complicated to install or set up, consider providing a live demo server that people can access via the Internet to give it a try. Alternatively, create ready-to-run images for virtual machines like Parallels, VirtualBox or VMWare. Everything that makes it easier to access, install and test your software should be explored.

In closing, make community involvement a part of your company culture and make sure that you preserve enough time to take care of it. Community engagement has so many different aspects, you don't necessarily have to be a developer or a very technical person to get involved. I'm aware that doing community work can be seen as a distraction and definitely takes away time from other tasks. But community involvement should become a habit and a well-accepted part of everyone's job — this is much easier to establish while you're still small and growing.

Sep 10 2008
Sep 10

MySQL UniversityTomorrow (Thursday, 11th of September) at 9:00 PST/16:00 UTC/17:00 GMT/18:00 CET, there will be an new free MySQL University Session. MySQL University started as an internal training program for MySQL engineers, to share and spread knowledge about their areas of expertise and has been available to the public for quite some time now. It covers a wide range of technical topics around the MySQL Server and usually takes place once per week.

For the first time, the presentation will not be performed by (former) MySQL employees/developers, but by two of our "Sun Classic" colleagues: Jyri Virkki (OpenSolaris Web Stack community lead) and Murthy Chintalapati (Sr Engineering Manager, Web Stack development) will talk about the OpenSolaris Web Stack:

OpenSolaris Web Stack is an OpenSolaris project and community building an integrated stack of popular open source web tier infrastructure technologies such as Apache HTTP server, MySQL, memcached, PHP and Ruby On Rails optimized for Solaris platform. This session introduces OpenSolaris Web Stack, its status and future development including addition of newer technologies such as lighttpd, Varnish etc., as well as the ease of use features for developers and deployers. We will also be discussing an experimental web stack IPS package repository and it could be leveraged to build and make available popular end user applications such as Drupal.

MySQL University sessions are free to attend - all you need is an IRC client (to post your questions and comments) and an audio player capable of playing back an OGG audio stream, so you can listen to what is being said. See the Instructions for Attendees on the MySQL University pages for more information on how to log in and attend. The audio stream will be recorded and published on the MySQL University pages for later consumption, in case you can't make it or want to listen to a previous session.

Sep 04 2008
Sep 04

One of the sessions at DrupalCon I attended was Larry Garfield's talk about "Drupal Databases: The Next Generation", which gave me a good insight into the current state of the Drupal database layer and how they plan to overhaul it for Drupal 7. The key points that I took away:

  • A new API based on PDO
  • Object-oriented, requiring PHP5
  • Support for using prepared statements
  • A unified access API
  • A query builder
  • More support for other database systems (currently Drupal supports MySQL and PostgreSQL only). In particular, they are keen on adding SQLite support, to ease local development.
  • Support for master-slave replication (by randomly distributing reads among the hosts)
  • Support for using different database types in parallel (e.g. using SQLite for read-only tables, MySQL for everything else)

The slides and a video of the presentation are available, if you want to check it out. There is a task list on the Drupal.org web site that keeps track of the ongoing activities.

Sep 03 2008
Sep 03

I had a nice chat with Kieran from Acquia at DrupalCon last week - we discussed how people running local Drupal user groups could expand their outreach into other communities, in particular into the MySQL User Groups. Scott Mattoon captured our conversation on video, which is now available on blip.tv:


Video thumbnail. Click to play
Click To Play

The gist of what we talked about: if you are organizing a local Drupal User Group Meetup, check out http://mysql.meetup.com to find out if there is a local MySQL user group nearby. Chances are high that there is! And if not, you may find at least people in the area that would be interested in meeting about this subject. We also maintain list of user groups on the MySQL Forge Wiki. Consider extending your invitation for your next meetup to these folks as well! It's very likely that someone would be interested to learn more about Drupal. The same applies to other user groups, e.g. from the PHP community.

I personally run a MySQL User Group here in Hamburg, and I usually extend my invitations to a number of channels and mailinglists, including the local PHP, Perl and Linux User Groups. Every once in a while, a new member from these communities shows up.

So this thing works the other way around, too: if you are the organizer of a MySQL Meetup, have you thought about looking at http://groups.drupal.org/ yet? Maybe you will find a Drupal User Group in your very own town that you could invite to learn more about MySQL and exchange contacts? If you are looking for more tips on how to run and expand your User Group, I've created a page with useful hints about this topic on the MySQL Forge Wiki. Your feedback and additions are very welcome!

Sep 01 2008
Sep 01

I'm back home from DrupalCon 2008 now - it has been a great event! I met a lot of nice people from the Drupal Community and learned a lot about this CMS. I've been very busy in uploading the remaining pictures from the event to my gallery - so here's for your viewing pleasure:

I also gave two talks and held a BoF there - the slides have now been attached to the session nodes, one of them (the HA session) even includes a video recording:

I've also uploaded some pictures from FrOSCon to my Gallery now, hope you enjoy them! The slides of my FrOSCon talks are now uploaded to the conference system as well:

Aug 28 2008
Aug 28

Hello and greetings from DrupalCon 2008 in Szeged, Hungary!

We (Thierry Manfé, Scott Mattoon and myself) are having a great time manning our booth and talking about Drupal, MySQL and Open [email protected] with the nice crowd of Drupal Users and Developers here. Sun is a gold sponsor of the event and we're giving a number of sessions as well.

Today I gave my first presentation about MySQL Backup and Security - Best practices - unfortunately I ran a tad bit out of time at the end... The slides have already been attached to the session page, so you can read up on the last few things I was going to talk about. Feel free to contact me, if you have further questions!

Tomorrow I'll be talking about High availability solutions for MySQL: An Overview and practical demo, which will also include a practical demonstration of a two-Node Linux Cluster, performed by Jakub Suchy. In the afternoon, I will also hold a BoF about bzr - The Bazaar source revision control system

I've also uploaded some pictures from the event (and some impressions from the city) on my gallery (more will follow later). Enjoy!

Aug 05 2008
Aug 05

I am going to Drupalcon Szeged I just got informed that two of my session proposals for DrupalCon 2008 got accepted - I will be speaking about the following topics there:

The second talk will be held in cooperation with Jakub Suchy, who will take over the practical demo. Sun Microsystems is a Gold Sponsor of the event and I am glad that we can show some support for this truly amazing and vibrant community CMS. DrupalCon 2008 will take place from August, 27th-30th in Szeged, Hungary. The list of proposed talks looks truly impressive! Among the key note speakers will be Dries Buytaert and Rasmus Lerdorf. I look very much forward to this conference. If you have a chance, make sure to attend it!

Apr 28 2008
Apr 28

This article describes how to install the Drupal 6.2 CMS on MySQL 6.0, using the Falcon Storage Engine. The operating system is a default Ubuntu 8.04 "Hardy Heron" (x86) installation.

I will make a few assumptions here, in order to keep the instructions simple: a fresh OS install, no other MySQL databases or web services are running or have already been installed. Both MySQL and the web server are installed on the same host. You should be able to become root to install packages and to have access to the local file system and the system configuration.

This article will explain how to install and configure Apache/PHP, MySQL 6.0 and Drupal 6.2.

Prerequisites

Running Drupal requires a web server (e.g. Apache) and PHP. We will use the packages as shipped with the distribution and will then install a MySQL 6.0 preview binary from http://dev.mysql.com. Other web servers like lighttpd will work equally well, but this article focuses on using the Apache web server.

Fortunately the MySQL 5.0 client applications as shipped with Ubuntu Linux are compatible with the MySQL 6.0.x client/server protocol, so we only make use of the 6.0 server and will use the installed, pre-compiled client applications and libraries to connect to it - there is no need to recompile PHP or anything to get going!

First of all you have to make sure the following packages have been installed (e.g. by using a package management tool like the Adept Package Manager, synaptic, aptitude or apt-get):

  • apache2
  • libapache2-mod-php5
  • php5
  • php5-common
  • php5-mysql
  • php5-gd
  • mysql-client-5.0

To enable the mod_rewrite Apache module (as recommended for Drupal), you need to enter the directory /etc/apache2/mods-enabled and create a symlink to the module loading instructions:

cd /etc/apache2/mods-enabled/
sudo ln -s ../mods-available/rewrite.load .

This will ensure, that mod_rewrite will be loaded when Apache starts up.

Additionally, you have to edit the file /etc/apache2/sites-available/default and make one change. In the directives for the Directory /var/www, change AllowOverride from "None" to "All". This will make sure that Drupal can enable the rewrite engine to allow nicer looking URLs.

Now restart the Apache server to apply the changes:

sudo /etc/init.d/apache2 restart

To verify that Apache is up and running, try opening http://localhost/ in a browser on the same machine that runs the web server. You should get a simple page, stating that "It works!".

Installing the MySQL 6.0 Falcon preview

Now that the web server is up and running, we need to install a MySQL database server that the Drupal installation can use. Download mysql-6.0.5-alpha-pb87-linux-x86.tar.gz (or any newer package, if available) from http://downloads.mysql.com/forge/falcon_feature_preview/

Create a /etc/mysql/my.cnf file with the following content (replacing the existing file, if necessary):

[client]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/var/run/mysqld/mysqld.sock
default-storage-engine=falcon

The default-storage-engine option will make sure that every CREATE TABLE statement will default to using the Falcon storage engine. Now extract the binary tarball distribution into /usr/local and perform the following steps to finalize the installation/configuration:

$ sudo groupadd mysql
$ sudo useradd -g mysql mysql
$ cd /usr/local
$ sudo tar zxvf ~/mysql-6.0.5-alpha-pb87-linux-x86.tar.gz -C /usr/local
$ cd /usr/local
$ sudo ln -s mysql-6.0.5-alpha-pb87-linux-x86 mysql
$ cd mysql
$ sudo chown -R mysql .
$ chgrp -R mysql .
$ scripts/mysql_install_db --user=mysql
$ sudo chown -R root .
$ sudo chown -R mysql data
$ sudo ./bin/mysqld_safe --user=mysql &

The installation procedure is outlined in more detail in the reference manual at http://dev.mysql.com/doc/refman/6.0/en/installing-binary.html

If you want to enable the automatic startup of MySQL at system bootup time, you need to install an init script in /etc/init.d/ - follow the instructions as outlined in the reference manual. Note that the mysql.server script has been moved from the directory support-files to share/mysql for the binary tarball distributions and that the current 6.0 documentation has not been updated yet (I filed BUG#36382 about this).

Now start the server using the mysqld_safe script:

$ sudo /usr/local/mysql/bin/mysqld_safe &

Next you should verify that you can connect to the server and that the Falcon storage engine is enabled:

$ mysqladmin version
mysqladmin  Ver 8.41 Distrib 5.0.51a, for debian-linux-gnu on i486
Copyright (C) 2000-2006 MySQL AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version          6.0.5-alpha-pb87
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/run/mysqld/mysqld.sock
Uptime:                 43 min 6 sec

Threads: 1  Questions: 6  Slow queries: 0  Opens: 15  Flush tables: 1  Open tables: 8  Queries per second avg: 0.2

$ mysql -u root
[email protected]:(none) > SELECT * FROM information_schema.engines WHERE engine='Falcon';
+--------+---------+-----------------------+--------------+----+------------+
| ENGINE | SUPPORT | COMMENT               | TRANSACTIONS | XA | SAVEPOINTS |
+--------+---------+-----------------------+--------------+----+------------+
| Falcon | DEFAULT | Falcon storage engine | YES          | NO | YES        |
+--------+---------+-----------------------+--------------+----+------------+
1 row in set (0.12 sec)

Before performing the actual Drupal installation, you need to create a Drupal Database and a user account. I chose "drupal" as the user name and password, please use some more sensitive values for your own setup!

[email protected]:(none) > CREATE DATABASE drupal;
Query OK, 1 row affected (0.01 sec)

[email protected]:(none) > GRANT ALL ON drupal.* to 'drupal'@'localhost' IDENTIFIED BY 'drupal';
Query OK, 0 row affected (0.00 sec)

Now MySQL 6.0 is installed and ready!

Installing Drupal 6.2

Now that the web and database server have been set up and configured, it's time to perform the installation of our application, the Drupal content management system. Start by downloading drupal-6.2.tar.gz from http://drupal.org/ (by clicking on the Drupal 6.2 download link on the front page).

Remove the default start page /var/www/index.html and extract the content of the drupal tarball into this directory. Then change the ownerships of these files to the user that apache runs under (www-data by default):

$ sudo rm /var/www/index.html
$ sudo tar --strip-components=1 -zxvf drupal-6.2.tar.gz -C /var/www
$ sudo chown -R www-data /var/www

The Drupal package installation itself is now done, the remaining installation and configuration steps are performed in a browser by opening http://localhost/ in your browser (reload the page if you still see the "It works" default page).

DrupalInstall_1

Follow the instructions in the Drupal installation manual on how to perform the actual installation. In the "Database Configuration" dialogue, use the MySQL database username and password that you created earlier.

DrupalInstall_2

Now the Drupal installer should perform its duty and you should see you fresh Drupal installation up and running!

DrupalInstall_3

Once the installation has finished, let's verify that we're really running on Falcon by running the following query in a MySQL command line client:

mysql> SELECT TABLE_NAME, ENGINE from information_schema.tables WHERE TABLE_SCHEMA='drupal';
+-------------------------+--------+
| TABLE_NAME              | ENGINE |
+-------------------------+--------+
| access                  | Falcon |
| actions                 | Falcon |
| actions_aid             | Falcon |
| authmap                 | Falcon |
| batch                   | Falcon |
| blocks                  | Falcon |
| blocks_roles            | Falcon |
| boxes                   | Falcon |
| cache                   | Falcon |
| cache_block             | Falcon |
| cache_filter            | Falcon |
| cache_form              | Falcon |
| cache_menu              | Falcon |
| cache_page              | Falcon |
| cache_update            | Falcon |
| comments                | Falcon |
| files                   | Falcon |
| filter_formats          | Falcon |
| filters                 | Falcon |
| flood                   | Falcon |
| history                 | Falcon |
| menu_custom             | Falcon |
| menu_links              | Falcon |
| menu_router             | Falcon |
| node                    | Falcon |
| node_access             | Falcon |
| node_comment_statistics | Falcon |
| node_counter            | Falcon |
| node_revisions          | Falcon |
| node_type               | Falcon |
| permission              | Falcon |
| role                    | Falcon |
| sessions                | Falcon |
| system                  | Falcon |
| term_data               | Falcon |
| term_hierarchy          | Falcon |
| term_node               | Falcon |
| term_relation           | Falcon |
| term_synonym            | Falcon |
| url_alias               | Falcon |
| users                   | Falcon |
| users_roles             | Falcon |
| variable                | Falcon |
| vocabulary              | Falcon |
| vocabulary_node_types   | Falcon |
| watchdog                | Falcon |
+-------------------------+--------+
46 rows in set (0.00 sec)

Looks like we were successful - all Drupal tables are using the Falcon storage engine! Congratulations.

From here on, you can configure and change Drupal to your heart's content. Note however, that additional Drupal modules may contain code that is specific to the MyISAM or InnoDB storage engine, your mileage may vary. In that case it would be great to notify the module developers about these incompatibilities.

If you want to quickly populate a Drupal installation with content for testing, you can use the "Devel" module. I used it to create 500 users and 10.000 test pages on my demo installation. Even though this was performed within a virtual machine running VirtualBox, the system still was very responsive and the creation of the content proceeded amazingly fast! But I did not perform any serious benchmark or load tests (it would not make much sense in a VM anyway).

Feb 14 2008
Feb 14

Yesterday, Drupal 6.0 was officially released - check out this screencast to get a 29-minute tour on the new features in this release.

We'd like to congratulate the Drupal Developer Team and Community for reaching this milestone and are happy that the MySQL Server continues to serve well as the database backend for this awesome content management platform!

I had the pleasure of evaluating and reviewing a previous release of Drupal for the Open Source Content Management System Award from Packt Publishing and it has been one of my favourites.

Keep up the good work!
 

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web