Posted on July 24, 2009 // Short URL

Drupal Distributions and Features

Jeff Robbins talks with Angie Byron, Jeff Eaton, Karen Stevenson, and Eric Gundersen (of Development Seed) about the state of Drupal distributions including Open Atrium. The team also talks about the Features module and catch up with some Drupal news.

Some links mentioned in the podcast:

http://openatrium.com/

http://drupal.org/project/admin

http://www.lullabot.com/articles/5-step-drupal-distributions

http://www.lullabot.com/articles/photo-galleries-views-attach

http://www.netaustin.net/2009/07/17/do-it-rails-version-your-drupal-database-hookupdate

http://www.funnymonkey.com/drupaled-latest

http://drupal.org/planet

http://code.google.com/p/d7ux/

Comments

Eric Gundersen

Digging more into "Features"

I had a great time talking with Jeff R, Angie, Jeff E, and Karen yesterday. For those of you who are interested in diving more into features, here is a screencast showing how to build a feature: http://www.developmentseed.org/blog/2009/may/29/making-and-using-feature..., and here you can see how it solves the basic staging --> deployment issue: http://www.developmentseed.org/blog/2009/jul/09/development-staging-prod.... You might also want to check out this screencast showing what it looks get to get a feature from a feature server: http://www.developmentseed.org/blog/2009/jun/25/pushing-public-private-u....

Like I mentioned in the podcast, Open Atrium's strength is based on decentralized features. People are going to want lots of niche features, and Open Atrium will just be a starting point for folks. We wrote about our plan for opening this all up here: http://www.developmentseed.org/blog/2009/jun/26/recipe-feature-server. For a quick visualization, check out these graphics: http://www.developmentseed.org/blog/2009/jun/24/distributed-feature-serv....

As I mentioned in the podcast, with the proper infrastructure I see distributed feature servers strengthening the core drupal ecosystem. There will certainly be some interesting conversation on this in Paris, and I'm looking forward to having them.

Thanks for the excellent conversation, 'bots!

Reply

Lanesa Stubbs

Lullabot and Development Seed Interview on Open Atrium

All I can say is this was an awesome interview and I'm a huge fan thef both Development Seed and Lullabot. I'm always waiting for you guys to release a blog post or a podcast. I'm sort of new to Drupal / Drupal Terminology, but not web development nor opensource communities. I have been reading, dissecting and experimenting with Drupal in regards to theming / Drupal Site Building for about 4 months now and have found that getting information from Development Seed, Lullabot, Drupal Modules (http://drupalmodules.com), and other consultantcy and resource sites much easier then the drupal.org website.

The current Drupal.org website is just way to cluttered for one and there's just way to many opinions and views rather then getting straight to the meat of what you need to build and deploy websites. You lose valuable time searching through the threads to find what you need for a specific project.

I think the idea of creating a domain specifically for Open Atrium was a great move as well as putting it in a repository separate of Drupal.org was an excellent idea (not that I'm a huge fan of Github), I just rather know exactly what modules are are dependant of Open Atrium as well as any new addons, changes, releases etc that are specific to Open Atrium, and only resources that relate to the current project. This way the focus stays specifically on Open Atrium rather then waddling through a bunch of threads that some how tend to push you another direction towards another module or project that's similar to Open Atrium, where you lose your focus.

Now for a moment if you're not a ceo of a business or organization, put yourself in the shoes of the CEO / Co-Founder that has to pay salaries and focus on generating income or soliciting funding for a particular project as well as bringing on new staff with the creativity or skill desired for your new projects and ideas. As a CEO you're most likely going to make decisions based on the needs of the firm / business / client needs and your vision for your firm / business rather then that of an outside vendor or competitor. In addition, the CEO continues to be the head lead and voice of their project and make a lot of the decisions regarding it.

So to sum things up, I think that members from the community will still contribute to Drupal, especially if they still have to go their for OR contribute to the ongoing development and maintenance of modules as well as if their dependency of their current project is dependant on other modules that are in the Drupal.org repository.

I think Open Atrium is a huge contribution to the Drupal Community and an excellent example of the magnitude and beauty of what you can do with Drupal. Not just talk but a working example. And it's still FREE ;).

And last, I think that this project will definitely bring on new contributors / developers to the Drupal.org community as well as new contributors to core. Oh and women Webchick.

Reply

Ryan

"Open Lemonade Stand"?

Thanks for all the info and discussion around Open Atrium, Features, distribution, etc. Just installed Open Atrium while listening, and my first impression is "Wow! It looks great!" followed by "I'm not sure what I'd ever do with it." : P

My goal with UberDrupal is a Features powered installation profile for Ubercart sites. I have much to learn and I'm still trying to decide whether it's worth it to inject Feature installation into the install process or not. In our case, the problem is we need the users to perform additional configuration after a Feature is installed, like adding API keys to your PayPal settings, defining your flat rate shipping prices, etc.

Will keep mulling it over... in the meantime, I've already been contacted about getting some Ubercart exportables going so folks can get some invoicing into Open Atrium. Fun times!

Reply

Boris Mann

Features!

"I'm still trying to decide whether it's worth it to inject Feature installation into the install process or not"

Features are for .... features - bundles of specific content/functionality/config/menus/blocks etc. The kind of stuff you are describing is probably best / easiest done at install time - you can do this in D6 in a profile wizard style where you ask people questions and then plug it into the right modules as you go.

With install profiles being overhauled, it might be better to stick to "automate late" and just have good documentation on how to enter that information into the correct place.

The main choice with Features today is how it can help you build an install profile more quickly. And it can -- I really hope I can deprecate install profile API sooner rather than later, since building a feature, exporting it, and then simply adding its name to the "enabled" array in a .profile is so much easier. And that's before the improvements in D7.

Short answer: it's probably worth using features today to do profiles, since the same code can be used to add to existing installs and it is somewhat future proof since it looks just like a module as far as Drupal is concerned.

Reply

Ryan

Thanks, Boris. Makes good

Thanks, Boris. Makes good sense to me, too. We had gone down the trail of a little custom .inc system for defining "packages" you could turn on during an UberDrupal install, but that quickly fell out of my favor. : P

Switching this to just enabling Feature modules will be a cinch.

Reply

Steven_NC

Timely Topics

I found the discussions very enlightening. The Features concept is extremely important. Currently there are several installation profiles that are nicely packaged for specific sites. The problem is that they are not additive. I would like to combine 2 of these packages for mysite.com, which means I can use neither.

I also find keeping the setup (.info, .config, .ini, etc) in code rather than a database much easier to understand and certainly easier to maintain and backup.

Great Podcast.

Reply

Victor Kane

One of the most serious Drupalera discussions I can remember

I think the depth and diversity (to use a vocablo oft used by Karen) in the important points raised so eloquently in this discussion was outstanding, hitting on so many points of concern highly relevant to those of use whose lives revolve around Drupal, and the Drupal community.

I am very enthusiastic about #open_atrium as a way to meet many client concerns, but more important than its contribution in terms of what it bundles, is its existence as a "features laboratory": many of us that simply haven't had time to work with the features module and who are often tearing out our hair over the development and staging problems refered to in the podcast, welcome #open_atrium as a fun way of getting into them. And as Boris points out above, they are future proof and portable to other uses.

But the discussion helped me enormously in another way. As one of the "scrum" persons excited about working on project management features in and around #open_atrium (specifically for my project flow & tracker tool), I became perplexed enough about the github question to raise an issue there in terms of how one would go about developing with #open_atrium in the first place: http://github.com/developmentseed/Atrium/issues/closed#issue/131

To make a long story short, I did not want to clone #open_atrium and then version within it the features which I will be contributing in isolation in the GitHub environment. I simply wanted to develop some features with #open_atrium as a dependency. Even though I was excited about trying out a project based on Git, and trying out the over priced GitHub for free, I wanted my features to be independent and portable to drupal.org as a module in itself, or as part of an installation profile... I didn't want to be married to GitHub for the life of that project, that's for sure.

Even though the issue was closed in the light of an interesting discussion on #open_atrium IRC concerning how to manage vendor branches (a la svn externals, but in Git, for which I am very eternally grateful), and in favor of best practices being to clone #open_atrium on GitHub in order to work on projects working in dependency on that, I am actually going to be using bzr on launchpad (for a number of reasons, the most important being the July 21 open sourcing of launchpad), and will simply export the release tags to Git on GitPad for convenience and so that anything of value I come up with could be merged into #open_atrium should that be desirable.

In any case, just wanted to say that I had already made up my mind in this direction, but this discussion was very edifying and supportive and I just wanted to raise my cap in respect on passing by.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

Reply

christefano

Case Tracker is almost "anti-agile development"

Case Tracker is almost "anti-agile development" and I'm interested to hear if and how other agile shops are using it. What are your thoughs, Victor?

We've been adapting it for our agile workflow since the D5 days are now reimplementing our changes in Atrium. The beginning steps are to use "cases" as tasks, use "projects" as user stories and create a "sprints" site- or og-wide vocabulary.

On another note, I'm frustrated that this "conversation" is in a weblog several steps removed from the Atrium website or a Atrium-dedicated forum. The GitHub issue queue is not a forum.

Reply

victorkane

Case Tracker is too "flat" for an agile approach

The whole idea of visibility in agile requires a more hierarchical approach, where you can drill down from features to user stories to tasks... and from iterations to user stories to tasks... For example you need to be able to write 20 user stories and then assign them to iterations or sprints, and the project needs to be OG, since it is a clump of content, a section.

So Project Flow & Tracker "Paris" would aim to be a plugin replacement (feature or set of features) for Case Tracker (cases could be at most tasks, but the comment system it relies on is inadequate for user story conversations).

Anyway, I will publish it on a "feature server", but it will also be published on drupual.org as a module and/or installation profile, and there is already a groups.drupal.org discussion thread, so no frustration required!

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

Reply

moshe weitzman

our rotten home - drupal.org

Nice podcast. I'm gonna repeat a rant that I delivered to Angie and jjeff in person last week ...

Angie voiced fears about drupal development happenning off of drupal.org. She is worried that decentralization will lead to less creativity or cooperation productivity something. Thus feature servers could be a threat to the project.

IMO, we can do better than fear. For one, why does drupal.org have to sit and watch this innovation? If drupal.org decides to run a feature server, then it will instantly become the biggest, best, most reliable server. Problem solved.

But not really. We don't even consider that option for more than a minute because it is impossible to innovate on drupal.org. drupal.org is run by "the community" which is to say that nobody makes a decision. We have people who want to make improvements all over but we lack a functional process for encouraging them.

IMO, the website drupal.org is completely broken. The Drupal Association has been negiligent in its duty to grow it. The DA seems to be satisfied with keeping the servers up and with paying $100,000 to consultants for a redesign. And then barely funding the implementation of that redesign. Lets add fiduciary neglect on top of "duty" neglect.

As an example, look at http://drupalmodules.com. That site provides 100x more useful information for site builders in terms of which modules to use. Ratings and reviews are not rocket science. Amazon.com launched 15 years ago and it supported Reviews on day one. Lets ask ourselves whats broken about our process that one person can make drupalmodules.com but drupal.org can't.

Back to feature servers. We need distributed feature servers because the Drupal Association is so impotent that it lets drupal.org stagnate in the face of deep needs.

Reply

Senpai

We need change, true, but...

Moshe: We need distributed feature servers because the Drupal Association is so impotent that it lets drupal.org stagnate in the face of deep needs.

Maybe. But maybe we need distributed services to spring up because the centralized methodology of code control and widget management is functionally limiting to our future success as a project. It's old school, broken, dumb, and no longer feasible in the face of today's technological capabilities.

Problem is, it's gonna take a heck of a lot of work to make drupal.org transition from a wooly mastodon into anything sleek, sexy, and diverse. A lot of work. Who's got the time to plan all that out? I sure don't. It seems like a problem that's self-defeating.

Reply

DavidNotik

Hear yea

Hear ye, hear ye.

To both Moshe's points and to Development Seed's vision for distributed Feature Servers and Open Atrium generally. The future is bright, particularly for the infrastructure that powers massively multi-user collaborations like the Drupal effort itself.

As an open source community we rally around revision controlled code and collaborative documents and we get together on IRC channels and there are organizational structures like the Drupal Association whose members the community votes in and so on. We're certainly advanced with respect to how we collaborate and it's in our very nature as an open source community. But we can do much better.

Let's think about what the bleeding edge of online collaboration looks like and how the Drupal.org infrastructure can evolve accordingly. For starters, I think we need to move beyond the Project package to standardizing on a product like Open Atrium and focusing on how massively multi-user online collaboration can work better.

I also expect to help this newly focused area move beyond collaborative documents and issue tracking to things like online decision making and functional group formation so that efforts in the Drupal community can form and have the support, the tools to get things done. Nowadays that support is scattered, from the Project module and its SVN integration to g.d.o. With respect to the latter, by the way, it's worth thinking about moving to an Open Atrium like infrastructure, combining the best of both by adding more features to Open Atrium.

I'll have more ideas to share soon, but I've obviously been thinking hard about this stuff for awhile. I contributed Case Tracker which Open Atrium uses, and I've been researching the bleeding edge of online collaboration under the Woven umbrella (www.wovenlabs.com/workspace).

More soon.

--D
www.d202.org

Reply

Sprugman

even more confusion?

I really appreciated the discussion on this week's podcast, too. My big fear about the "many features servers" idea is that it will get even more difficult to figure out how best to implement something. Not only will you have to check a variety of similarly named modules, but you'll have to check a multitude of features from different servers trying to solve the same problem. Sound horrible to me....

Reply

travisc

Yowza!

Wow, I'm pumped, excited and somewhat reeling from this podcast!

David and Moshe put it well. I say if D.O is broken then it's time to evolve, why fear progress, or over think it? Clearly we've seen that results in stagnation.

For those of us that remember the decision to make Garland the default theme, Steven just made that decision at one point, right or wrong. Maybe more structure, or a deadline (like code freeze) could help other decision making processes? Lets put timer on some of these discussions, take a vote, and empower the people that want to lead.

Anyways great podcast, and yes the future is very bright indeed!

Reply

Smathers

Drupal.org

First off, this was a great podcast.

But regarding Drupal.org...
I'd like to defend Drupal.org but I can't. The site is a massive liability to Drupal. While I can easily keep tabs on goings-on in the Mac world via Macsurfer.com and Macworld.com, I have no idea what's going on with Drupal. Lullabot certainly helps, but sometimes I only hear about something (an awesome module, an obsoleted strategy) useful long after its clear that the Lullabotters are familiar with it. We can't expect Lullabot to be a one stop Drupal news shop, but there is a conspicious absence of one. Drupal Planet is full of high school kids talking about the Drupal redesign of their blog as well as nigh-on-insane rants by developers telling everyone to go to hell for requesting support. Amidst all this Drupal.org itself has become a place hostile to asking questions (we're told to use IRC…which I've never ever used in 20 years of doing web development and related work… why not use Usenet, Gopher, or AOL forums they're all obscure enough?). The interface to the download is impossibly convoluted and the site is filled with not only orphaned modules, but their evil kin, the "For now I want to register this killer name, maybe I will actually write a module that does this, but first I have to learn html and pcp, i mean php."

I used to be much more a member of the community. Now I stay away. My allegiance wavers. Drupal's future is at stake. The site needs major, major work.

Reply