What is a module?

• allows you to extend Drupal without touching Drupal core code
• wraps related code into packages that can be used in other projects or shared with the entire community
• allows collaboration with the community with common standards

Different types of modules

• Glue modules: put little changes that you need to make to the way that Drupal is processed - not things shared on d.o, but created to achieve specific small things on particular site(s)
• Input filters: take input from users and convert them into something more fantastic (e.g. PHP Filter, Markdown)
• Module plugins: extend established modules that have their own APIs (e.g. Filefield, Views Custom Field)
• Utilities: provide tools for other modules (e.g. token)
• Navigation (e.g. admin menu, teleport)
• Administration (e.g. Admin Menu, Dashboard)

What to ask yourself before you start coding one

• Why am I doing this? Is it really needed? Are you just scared of looking for other modules, installing them, and still not getting what you want?
• Reasons to conquer fear-driven module creation:

1. Time is important
2. Forks suck - can’t split resources, dev time, user base with multiple solutions
3. Your reputation is at stake - people will call you on duplicating existing modules

• Reduce risk progressively. You can’t know everything about every project out there, but every time you think you need custom code, do this first:

1. Do a Google site search of Drupal.org to try to find something that does what you want to do
2. Start talking to real people on Drupal User Groups, groups.drupal.org, and IRC to see if they know of an existing solution.
3. Install a few modules and play with them, exhaust what they can do so you can learn more and more about existent tools
4. Grep an entire contrib repository for what you might need

A few more things before you start…

• Assume your code will be shared and follow Drupal coding standards
• Negotiate the time you’re going to put into this - make sure you have enough time to make it look good!

Methods for starting

• Gut (copy and empty) another module
• Frankenstein (copy and paste from other modules)
• Cheat (use templates)
• Ninja (compose from scratch/memory)

Let’s pick a name

• Check out contrib from CVS and scroll to make sure your name doesn’t exist
• Or do a Google search of Drupal.org
• You’re going to be using the module name in all of your functions, so choose your name accordingly (not too long, not too funky)
• Using module name in core files, so keep it short
• Use all lower case letters and underscores rather than dashes

Start building

• Put your module in /sites/all/modules
• create .info file in your folder; your module will now show up in admin/build/modules
• create .module file in your folder; when you enable your module, code in there will execute
• Add other files to your module: JS, CSS, and module broken down into .inc files if necessary

How do modules add or extend functionality?

• Through hooks, which hook in processes
• You don’t need to start from scratch because of hooks
• Example Goal: redirect user to appropriate taxonomy term page after submitting a recipe. To do this we’ll use hook_form_alter(), use the Devel module, and Drupal API reference.
• Form API - simplifies working with forms. Forms described consistently as PHP arrays, have control over access, validation, and submission, and provide added security

Demo, watched but did not take notes

Changes in Drupal 7

Breakout conversation: CiviCRM and the Drupal Community

notes started partway into the conversation

• How does a person contribute in bite-sized chunks to a code base that is monolithic?
• You can write Drupal modules for CiviCRM - that’s the best way to extend CiviCRM and is a recent development with added hook support
• Drupal has Form API, CiviCRM has Quick Form - you have to be willing to make that leap and learn something new
• there’s a big gap between the users and the developers
• there seems to be a Drupal/CiviCRM PR problem
• CiviCRM can either be broken down into smaller modules are not; just have to make a strong decision and stand behind it.
• Need to put projects out there that’s well defined for people to work on. Give people more concrete ways to get involved. Give specific points of contact for the work.
• CiviCRM is changing. In recent years the concepts of components have appeared, making things more modular; the API and hooks are better developed
• The thoughts that are going on internal to CiviCRM developers that might please Drupal folks need to be publicized better
• Thoughts about having Minimal and Standard installations (maybe Custom too) similar to Drupal 7 installation
• Could have a packged up Drupal/CiviCRM installation to make things easier
• more training videos and materials
• aesthetic differences between Drupal and CiviCRM can also be challenging when going from the former to the latter
• Large CSS and templates cleanup is underway for CiviCRM
• idea to develop a guide to CiviCRM for Drupal developers to ease transition, point out parallels
• modularize WYSIWYG so that people can choose to either use CiviCRM-bundled WYSIWYG or Drupal WYSIWYG API module

There were about 12 participants in the conversation; folks who were here and who were not are encouraged to add their thoughts, fill out these notes, say “I was there,” etc!

(notes starting partway into the session)

• There’s an opportunity to grow Drupal if we can start to get at the diversity conversation
• definition of Drupal community is problematic - very technical requirements, but there’s a vast community that aren’t people who aren’t on D.o or have cvs accounts, implementers and users. Developer-centric approach is limiting. Rise of “themer pride” and project management props makes a difference.
• The “do-ocracy” is so spread out that there’s never going to be a technical definition of degree of participation in Drupal; makes it easier to inherit biases in society
• Power is still based on very developer centric values, e.g. webchick was nominated to make the LGBTQI g.d.o group because she wouldn’t get messed with because of her high stature as a dev in the community
• in any community it’s important to create a sense of openness - not just inclusiveness but many paths to involvement, recognize importance of other roles that extend platform to a broader audience
• primary problem of Drupal community is creating a platform that is usable, extensible, etc - this problem benefits from a diversity of perspectives on all levels, will result in better solutions
• there’s definitely “#notadeveloper” scoffing attitude in the community
• Drupal as an entity is not in the position of building on-ramps. While within the community there are real tensions along lines of identity and privilege - same as larger society - don’t see a specific on ramp barrier to people with lack of privilege
• do-ocracy isn’t a problem when
• problem is who’s going to do anything about this? Drupal Association is the only official entity, could they espouse values of diversity, inclusion, non-discrimination and “enforce” by vocally disapproving when things like the image on the Drupal Card Game goes down
• class is another big vector of power and privilege, but not always as visible a marker as race/gender/sexuality - might be a foothold
• we might have more success with stopping nasty things (i.e. sexist comments/images) from happening than trying to get buy-in for proactive diversity
• what’s the process for handling when “bad things” go down in the community? what recourse to people have if things are going on in the community that are outside of the spirit of Drupal?
• there has to be individual accountability
• some distrust of looking to higher authorities for enforcement
• is it possible to charter local groups?
• false notion that safe spaces organized within Drupal Community like groups.drupal.org will not actually result in better technical products, code, etc
• demonstrating ability for Drupal to be more accessible, egalitarian, open is important
• q: have people ever recruited others to Drupal, especially others who don’t look like others in Drupal?
• a: HopeFoundry - taught non-programmers Drupal, 1/3 of them are becoming active with Drupal, some of them have provocative stories that need to be told, a model that can be replicated. Do it at an application level, you can choose to be diverse
• “Drupal = a big building with no doors on the ground floor; if you go around back and up the stairs to the IRC channel you can find a way in”
• In any community, the most influential people are the most invested. As communities grow the core group starts to expand as well. Community can occur organically if more people buy in and do something about it, build on-ramps to Drupal, on small-scale/individual levels, makes the community evolve.
• Do we feel comfortable bringing people in to Drupal who are not part of the majority/privileged classes in Drupal?
• Bringing people like me (in this case queer, poc, politically left) would not go so well, afraid they’d just get pissed and never come back
• Some people are activated by getting pissed off, some people are turned away - they deal with this throughout their lives, don’t want to deal with this
• Encouragement for people to write blog posts, public thoughts on what we discussed here, get it out there
• The people in the room have it in us to change things
• Focus on ground up, grassroots response and action on these issues
• We need more models for training and curriculum to bring more, different people into Drupal

Starting Out

• going from contractor to shop = making a lot of mistakes and surviving them

defining the type of shop you are - what are you selling, what is your market?

• identify your team’s strengths and go with them, but also be adaptable in case your market shrinks
• CivicActions - thought they’d be leading shop for political campaigns and candidates and nonprofits - they’re a mission-driven, values-based company and choose clients accordingly. Quickly dropped notion of working for political candidates & shifted to large international nonprofits. Also use Agile project management, so they have ramped up competency around working with clients and bringing in projects on time and on budget
• figure out what you really enjoy doing and what you’re good at, focus on that

Mission Statement & Business Plan

• you should have both of those early on, but those should be changeable and adaptable
• these help you create your website content, in your proposals, etc
• think about the value proposition that you bring to your clients
• do what you do best and outsource the rest - the skills necessary to build websites are not the same skills you need to run a website-building business

Partners?

• Find people who fit good roles. If you’re a dev, find a business person, or vice versa.
• Define roles for each partner
• Partners need to help boost each other, split tasks
• CivicActions started by 3 partners, were at 13 partners at peak, now at 9. Transitioning from LLP to C-corp. Business structure impacts liability, ability to raise capital, tax structures, and decision making structures. Need to be really clear about corporate structure, decision making, and responsibilities. Don’t need to be set in stone, can rotate or swap tasks.
• Sometimes partners are more affordable than employees.
• Good idea to have a business-focused partner and a tech-focused partner.
• Have to have clear expectations for each partner - clear responsibilities, make sure they’re aligned.

Management

• Remove vs office - sometimes being remote takes too much time to communicate, for some people it works better to work together in person.
• CivicActions: intentionally remote, no office, let people live wherever they want to live. Business units or teams called “pods” will get together to sprint for a week at the beginning and ends of projects. Face time is important early on and throughout. Get together at DrupalCon, other conferences, video conferencing, phone calls
• If you’re a “virtual” or distributed company, the overhead you save on rent, office, etc can be devoted to getting the team together in person
• Have people who are willing to be flexible, work across timezones, are responsible and dedicated

Bids, Juggling Projects, etc

• Advice = don’t do fixed bids! Irresponsible to your shop and to your clients, especially when working with unpredictable open source.
• Juggling more and longer term engagements - you need a business person to juggle all the moving pieces internally and externally
• Balancing contributions to the community vs client work - balancing internal business dev with client work is also very difficult (building biz, website, documentation, etc)
• share back with the community - write up what you’re doing, share your products, write up case studies and white papers. build personal brand.

Investors & Growth

• investors and loans? CivicActions bootstrapped the company, never took out loans or got investors. Advice: if you can’t do this without capital, you might not want to do this now
• Another company did take out loans to facilitate staff growth
• CivicActions project estimating worksheet - very useful
• get advice from other shops, open source community, get advice from friends and family
• if someone’s trying to pressure you into doing a fixed bid, you can give a “best estimate” range, do best to come in the middle
• educate clients so they’re okay without fixed bids - provide estimates with an asterisk,
• prioritize the important pieces from the RFP first, do things in order of priority, if you hit the end of the budget it won’t be such a big deal to leave the little details off
• get a lawyer, get an accountant! start out with good contracts revised by
• CivicActions doesn’t employ people, they have contractors

Sales and Marketing

• create reusable templates for RFPs, Estimates, and Proposals
• demonstrate & publicize community participation and contributions - meetups, camps, local community sites, conferences
• contribute! in open source as in academia, publish or perish
• develop or claim modules or other products in desired markets (e.g. mapping, media, mobile, etc)
• make friends with the “competition”

Basic Roadblocks to Progress

• Cashflow is King! Especially once you get employees, since partners don’t necessarily get on payroll.
• Get upfront money on projects. CivicActions does a monthly upfront; you can ask for half up front for the project, things like that.
• Charge finance fees on late bills
• Don’t get too excited about the high points, don’t get too scared about the low points
• Have a clearly defined payment schedule in proposals and contracts
• Taxes - very hard to anticipate, have to anticipate
• Accounts Receivable = what you’ve got invoices out for that you haven’t gotten paid for yet, have to stay on top of this and do your best to collect

Get Help

• SCORE - Service Corps of Retired Executives, SBA, Business Schools (sometimes they can give you interns)
• Collaborate with other shops
• Consultants email lists

My questions

• pacing growth (staff AND projects)
• speak to the shift from contractors to full-time employees
• if you don’t use fixed bids, what do you tell your clients, ESPECIALLY nonprofit clients?

Panel of the people on this page, also listed below. Sorry for lack of attribution for each comment!

How has managing a Drupal firm changed over the years?

• the focus of a firm is often inward; as Drupal has changed they’ve had to shift to focus outward. As Drupal grows, community grows and you have to be a part of it in order to be successful. Volacci has a partner program where they form relationships with other shops, build and nurture relationships as communities grow
• Used to have to sell Drupal to clients harder, but that’s eroded and changed over time - people started calling them
• As Drupal shops start to appear & Drupal gets higher profile, more competition forces shops to innovate and do things better

What are some of the best decisions you’ve made in your shops?

• working with Drupal is the obvious one
• team relocated from small town in Virginia to a larger city - able to attract and maintain good talent more easily
• a different attitude towards telecommuting
• process is important, but it’s also important to show your clients how your internal processes add value for them
• focus a lot of time on getting team to dance well together - it’s expensive, but everyone who comes into Development Seed gets Getting Things Done and Made To Stick. It’s very difficult if you don’t create a culture, have a consistent base within your organization, creating a GTD culture and having a common lexicon. Two other books for management specifically: Good to Great (prevent burnout!) and Getting to Yes (help decision making process as a team)

Context

• Eric Gunderson, Development Seed: 17 people
• Dave Terry, MediaCurrent, 12 employees, started focusing on Drupal in Fall 2007
• Jon Clark, design group, 6 member team, denver, 4 years in Drupal
• Ben Finklea, Volacci, 60 person firm in Austin
• Jeff Walpole, Phase 2, 32 people, founded in 2001, Washington DC
• Glenn Hilton, ImageX, 12 full time, founded 2001, started Drupal in 2005

Where do you go to recruit good people?

• As an owner, start with culture and vision of the company
• Get a lot of great people from Craigslist - Volacci finds lots of people who do good stuff that’s not Drupal specific well and teach them Drupal
• determine what percentage of management time is appropriate to dedicate to recruitment
• get the wrong people off the bus, get the right people on the bus.
• Always be recruiting, always on the look out
• Keep feeding work to freelancers and look for people to bring onto your team
• Read a book called Who
• call up colleagues & other companies to see if they have good leads on new talent

How to retain employees over time?

• find good fits, self-motivated communicators
• foster a good work culture & environment
• client work is training; product work can be more rewarding. Product culture is essential for staying sane.
• Need to find good structure early on for crafting contracts
• Development Seed basically fix prices solutions that they deliver, which is terrifying.
• Figure out a way to fix scope and be stubborn with clients
• It’s your job as a manager to facilitate your team; crazy client stuff will break down your team
• key to keeping employees is the direct relationship with owner or supervisor - that’s what will make them stay or leave. That comes down to communication. High salaries won’t do it.
• One perk: $2500 per year tuition or education reimbursement. Continuing education is a bigger perk and advantage than money. Send people to DrupalCamps and DrupalCons, get books, etc. Ask for knowledge share in return - e.g. 15 minute debrief at staff meeting.
• Culture of open communication and truly open debate. Not just token opinions, but real debates that change the way company works fosters ownership.
• Hire slowly, fire fast - don’t keep people who don’t work well.
• Volacci has no vacation policy - don’t track vacation, yet to have anyone abuse that. Go as long as you want to, but don’t drop the ball and get your work done. Have a weekly Volacci University - someone teaches a 30 minute course to the company on anything they want. Every Friday is WIFLE - What I Feel Like Expressing - each person has an opportunity to express anything they feel like expressing. No one can talk while you’re talking, everyone thanks each other for sharing, opportunity to get issues out and off chest. Rule that you leave it in the WIFLE. Also have weekly kudos meeting. When you get a kudo, you get to take a Pez dispenser from anyone in the room white elephant style

What’s the most useful technique for getting/increasing sales?

• Must create relevant, fresh content - blogging, white papers, whatever
• Form partnerships and alliances. Some of your best projects will come from other Drupal firms. Outreach to larger firms, ask for their leftovers, work on smaller projects which lead to bigger engagements and form alliances
• Contribute back to the Drupal community
• Blog posts take time, need to be strategic. You can make concrete, specific posts about technical problems and how they’ve been solved
• Errant volume in sales is as destructive as errant volume in recruiting. Better to grow slowly to get the right sales and the right clients, otherwise you’ll lose focus and go where they want to go and not where you want to go.
• Find a niche and be the best possible firm in that niche

Presented by Jeff Miccolis of Development Seed

(missed most of the beginning, talking about features and exportables)

• Ctools is special
• Strongarm gives you access to the variables table — start to capture values from variables table
• these components are the configuration that descirbes how your site behaves - Strongarm lets you bring out and safeguard those important decisions
• Features should be used throughout the development process - not intended to come up later, meant to be there the entire time.

Creating a Feature

• Create a feature through the Features UI - add in various components
• Once you’ve built the feature, Features module gives you a way to see the status of the feature; lets you track whether any elements have been changed or overridden from what you set in your feature. Click Overriden, gives you a diff
• Using the Features web UI you can create a new feature, make updates to existing features, or revert the changes made from the prior iteration of the feature
• Drush has many Features commands - features (list all available features), features-export (export a feature from your site into a module), features-update (update a feature module on your site), features-revert (revert a feature module on your site)

Example of Features in development:

• Alex makes a feature
• Jeff pulls it down from version control, adds a couple of views to the features, updates the feature and commits in version control
• Young adds theme overrides
• Alex fixes Jeff’s and Young’s bugs
• Alex rolls the feature out
• Jeff makes views adjustments - when he clears his cache all of everyone else’s changes to the feature reappear on his site
• Rolled out.
• Alex makes views adjustments to fix Jeff’s…
• Young makes adjustments
• Roll out again
• Views changes are only made once. No need to manually copy stuff down, make changes on production AND staging, etc. Each change has a commit log within version control because everything is done in code.
• Process helps you avoid dumb errors; provides more accountability (making sure what you do is properly there; less likely for someone else to screw it up later; easy to enforce what’s been done and figure out who did it.
• Overhead of staging goes away; go straight from dev to production.
• Not having a distinction between configuration and code is bigger than just this: you’re able to maintain something like Open Atrium

Features for exporting Features as modules

• First: sequential IDs on configuration is the enemy. Use a machine name as the primary idea
• Second: when in doubt, use Ctools (http://civicactions.com/blog/2009/jul/24/using_chaos_tools_module_create_exportables)
• Your job: database schema, UI
• Ctools’ job: loading and exporting your configuration
• What’s left: dependency detection, which is optional but useful
• hook_features_export() - lets you add modules, add components, allows for delegation

Best Practices around building Feature modules

• Kit - the goal is to offer a straightforward base package for building state-of-the-art Drupal sites while specifying how Features built on top of Kit can be compatible
• Kit includes Feature and Theme specifications
• kitf (feature specs): unique namespaces, user roles & permissions, variables, paths & menu items, block visibility & theme regions, dependencies, problematic components
• kitt (theme specs): regions, page template variabls, element attributes
• these are currently working documents based on developer feedback

Distributing Features

Presented by Larry Garfield (Crell) of Palantir.net

The Views Stack

• Views are a three-part stack - how Crell explains to clients
• bottom of the view is the What Level - what data am I looking at - narrow down your entire database to what you want using filters, args, fields, sorts, and relationships
• middle is How level - how data is displayed - styles, flows, pager, and area
• top is Where Level - Display (e.g. block, page, panel content pane, RSS feed) - also now includes Access and Exposed Form
• this maps to the Views UI

Views Plugins

• themable: display, style, row style, pager, exposed form
• non-themeable (logic and functionality): access, argument default, argument validator, caching, query

Types of Handlers

• Fields (Views fields, not CCK fields) - SELECT part of query
• Filters - WHAT part of query - condition that’s hard coded into the view, though users can change the conditions
• Arguments - a contextual filter, the value of which is built dynamically by something in the environment. By default on a page display that’s pulled from GET but doesn’t have to be in other display plugins.
• Sorts
• Relationships - essentially a JOIN to grab fields from a variety of different base entity types, lets you do a lot of amazing queries more prettily than you can do with your own SQL queries
• Area “plugins” - new in Views 3, should be plugins but handlers - replaces Header and Footer text from Views 2, but now this is pluggable

(left session)

Presented by Michael Morris and Dave Leonard of Phase 2 Technology

How to work with stakeholders

• give people a proper introduction to Drupal - lots of weird terminology, figure out how to explain it clearly and properly
• explain open source - talk about the community, understanding what free means (as in speech, not just beer), make sure they understand that you might share the work you do for them with the community
• expalin that Drupal isn’t magic - takes time, work to get a good site
• Set expectations properly - make sure you present realistic timeline, 3-5 month timeline is reasonable for most Drupal sites from start to true finish - QA, testing, fixes, content posted, etc
• Communicate effectively - recommend using tools like Basecamp or Open Atrium, have a project portal to communicate within team and with client. Supply status reports with regular updates about tasks completed, pending, late, to be started or completed. Have regular meetings with clients.
• Drupal can be difficult to grasp at times.
• Train stakeholders properly. In-person training is the best solution. Give administration guides, though find the balance; want to avoid too much documentation that will get stale. Minimalistic starter guides are a good approach. Short screencasts are also useful and can be linked up within admin interface itself.
• Encourage early stakeholder testing. Are the details right? Does it actually meet their needs? Want to find this stuff out earlier rather than later. No substitute for having site owners/users actually using it. “If you have a site launch in two weeks and your site owners haven’t used it yet, you’re probably in trouble.” Does it look great (to the stakeholders)?
• Hard projects need stakeholder involvement. Make them part of the team, help them help themselves, hold them accountable for their own success - they’ll be working hard on this site, too.

Executing on difficult Drupal projects

• Understand the Drupal learning curve. There’s a wall you hit when you get into Drupal really deep; need to understand this so it doesn’t surprise you mid-project. Prepare yourself for mistakes, learn from them.
• Put the right project team mix together: project manager involved through the entire course of the project - risk negation, status checks, accountable for stakeholder satisfaction; analyst to define requirements and do testing, transform needs into defined, achievable tasks; designer; web producer; developers (maybe 1-3, someone primary)
• Encourage role flexibility. Don’t be a baseball team (each person only covering the immediate area around your position). Be more like a soccer team - follow “the ball” around, don’t be afraid of taking on other areas
• Be agile and manage scope effectively. Look into actual Agile workflow. Set sprints, iteration goals and planning meetings, work through the project like that. Don’t have to necessarily define everything up front; try to do it in chunks while managing scope effectively. Be firm on scope but flexible on features; prioritize properly, get the right things in first and push others into the backlog. Open backlogs up to your clients.
• Foster intra-team communication. Consistently use good task management tools (Phase2 uses Jira). Use real time communication.
• Insist on quality from team members: not buggy, not sloppy, everything covered.
• Hard projects need right team and good processes; have a multi-disciplined team that understands the Drupal ecosystem and an agile approach that allows for flexibility.

Defining scope and requirements

• Start digging! What are the site’s goals? Who is the audience? What is the focus of the content? How do your editors work? What are other sites you like?
• Requirements toolbox: site map, wireframes, specs, system diagrams, design comps, user surveys, user stories, style tiles
• Create a site map to define the breadth of a site, navigation (primarily good for visualizing hierarchical navigation, not so much contextual navigation)
• Brainstorm and sketch layout ideas as a team
• Create detailed wireframes with detailed annotations; someone can look at them and really understand how their site is going to function.
• Don’t neglect the details. Get all the way into the nitty-gritty in the upfront planning process to save time during the build out.
• Document integrations with system diagrams - how the site you’re building integrates with the entire ecosystem of the organization (e.g. CRM tools, syndication, content import or export)
• Document the specifications somewhere where internal team and client can see it.
• Meet design expectations; wireframes often aren’t enough to ensure client satisfaction with end results.
• Hard Drupal projects make defining requirements even more challenging. Use proven analysis techniques. Don’t neglect details. Don’t focus on just the website - think about the whole system.

Addressing common challenges

• Replace (clients’) bad habits with good ones. Don’t get surprised by old, leftover expectations about workflow.
• Structure content properly.
• Pay attention to permissions; sort out who is allowed to do what.
• Use taxonomy effectively.
• Present a clean admin interface and give clients a good editing experience. Use a WYSIWYG that works smoothly and properly.
• Allow editors to curate and innovate on their website, e.g. editors’ choice features on the site that can be implemented easily by site editors.
• Provide for editorial workflows that work well, smoothly, allow for fine-grained control. Implement presets that anticipate how things will appear on the site.
• Represent content relationships correctly.
• Differentiate between authors and users as necessary. There might be multiple authors or non-user authors that the default Author field can’t necessarily handle.
• Improve search with Apache SOLR - lots of big improvements, allows for great filters, bias search results
• Pay attention to roles and permissions.
• Migrate content accurately. Have a solid understanding of what they were doing in their old system so that you can carry legacy items over when they’re needed. Check out Migrate and Table Wizard for as much of the heavy lifting as possible, but you may need to do some more cleanup work; the earlier you can evaluate the complications there, the better.
• Hard Drupal projects have a more diverse set of challenges to solve. Use Drupal features and functionality the right way. Meet the needs of editors and content writers. Solve problems with the right techniques.

Q&A

• Q: How much discovery in the sales process, pre-contract and payment? A: Learn as much as you can at the outset though set boundaries, sometimes need to charge for it. The more info you know, the better an estimate you can give your client for the project (timeline and cost)
• Q: Firm on scope, flexible on features? A: Give a budget estimate and try to stick with it; sometimes they do fixed price, sometimes they do time and materials. Have to bound the problem; be firm on scope so that if big huge things are introduced you can say no
• Implicit Q and A: site maps, wireframes, etc are packaged as deliverables, artifacts are visible to clients
• Q: How does training work? A: Usually build in training time; minimally do two big training sessions (2-3 hours) for each project, along with lots of preparation. Usually throw in 3-4 working days of training prep and delivery. Alpha release, training, then hand the keys over to clients for initial use and testing. No one gets site use access before the training session.
• Implicit Q and A: build analysis and discovery into the paid process of the site building, hope you made good estimates in the proposal process. If the estimates are off, gently ask for more money, try to reprioritize, slow down expectations so that they have a chance to see how a Drupal site works before adding on more features.

Presented by Angie Byron (webchick)

• Angie discovered Drupal by looking at the source of the spreadfirefox.com website!

FAQs

• Feb 2008 - Drupal 6 released, Drupal 7 opened
• Sept 2009 - feature freeze (no new features
• Oct 2009 - code freeze
• Nov 2009 - polish phase (UI cleanups, accessibility, etc)
• When it’s ready - Drupal 7 release; “when it’s ready” is when there are zero D7 critical issues
• Should I start building sites on Drupal 7 now? Answer: Qualified Maybe. If you work with folks who are already involved with core, been through module porting, used to building sites where you have to fix upstream bugs and are willing to go all of that, then it’s a good idea. Otherwise, if you’re not in that very small segment of people, not so much. Not really for stable, public-facing sites until betas or RCs.
• Should I start playing around and testing it? YES! Test, try to break it, report what you break and how.
• Should I start porting modules and themes? YES!!!!!!! A great way to spot problems in core earlier rather than later
• #D7CX = Drupal 7 Contrib Experience - pledge to have a full D7 release of module on the day that D7 comes out. At last check ~200 projects
• What about upgrades? Too early to tell, but “we’ll break your code, not your data;” upgrade path actively being developed; Coder Upgrade module that’ll do a bunch of the module upgrade for you; #D7CX; Upgrade Manager to help with your site upgrade through the web UI.
• A lot is going to break from D6->D7 - CCK, files, etc. But the Coder Upgrade module will help!

Demo (from install up)

• New D7 admin theme (called Seven)
• New choices upon installation: Standard and Minimal, different languages
• D7 has translatable fields - any field can be marked as translatable
• new translation interface in D7
• nicer presentation of D7 errors during installation
• PHP 5.2, MySQL 5 are minimal requirements for D7
• Drupal can run on top of any database that PDO supports. Anything in the D6 and below DB system that ever sucked is fixed in D7
• password encryption has been improved for better security
• Server settings are location aware - default country and native time zone handling support in Drupal
• receiving email notifications about installed modules is now made more evident
• permissions have been improved - now a permission around running site updates so you can allow non-user/1 users to run updates
• PHP code can be toggled on and off in one place (with PHP module?)
• Toolbar at top for admin and shortcuts bar - shorcuts can be set up per role, per user
• D7UX - Leisa R. and Mark B. hired to make things work and look much better, those changes & recommendations have been integrated
• Overlay - you can make edits, config changes, etc without being moved away from the page you were on before you started those edits and changes
• Customizable dashboard = new landing page of admin panel
• jQuery UI 1.8 and jQuery 1.4 (latest version) are in D7 core out of the box
• Dashboard tabs also include By Task and By Module very visibly
• Onboard Help system got a big revamp
• native image handling WITH IMAGECACHE (now Image Styles) in Drupal core
• vertical tabs in content editing UI
• CCK is in core - you can add fields to all SORTS of stuff, attachable to any entity.
• D7 now ships with an Administrator role - no more need for admin_role!
• permission names are now translatable; permissions have help text to help folks understand implications
• filter access is now inline on permissions page
• users can delete their own accounts (if you give them permission)
• modules page includes help, settings, and config links for each module inline
• You can INSTALL NEW MODULES THROUGH THE UI!
• you can have public and private files systems all at once
• automated testing framework is built in to D7
• Appearance page got a big revamp, much prettier, and all of the “butt-ugly” (webchick’s words tho I agree) table-based themes
• New Stark theme - Drupal’s default HTML markup and CSS styles, good baseline to start working from
• Drupal’s default markup is much improved, more Zen-like, don’t need Zen theme as much anymore since those improvements have been moved into core
• many accessibility improvements

How to help?

• download Drupal 7, test, report issues (search first!)
• fix bugs
• port modules/themes
• write coder upgrade module rules
• #drupal-contribute on IRC
• Parc 55 Hotel, 2nd floor (where reception is): ChX Coder Lounge during the Drupalcon, every night from 6pm until everyone passes out from exhaustion

Presentation by Liza Kindred

Background on Liza and Lullabot

• Liza’s background is fashion - “a lot of stuff that most people here don’t care about” - and art, nonprofit boards of art orgs, now a Lullabot (employee #3)
• Liza is obsessed with open business models
• Lullabot - podcasts, high-level consulting, site architecture, development, training, books
• Lullabot is not only professional and successful but cheeky, funny, nontraditional, fun

Open Source Business

• awesome video comparing open seeds to open source - navdanya.org
• same ideals that are true in open source technology are true in open source business
• make mistakes - Lullabot has made many ones (epic ones) and it’s and important part of doing open source business.
• Lullabot is an awesome place to make mistakes - e.g. Angie Byron’s major data import messup made her Lullabot’s data import expert
• Be forgiving, create an environment  where people feel comfortable admitting to their mistakes, recognize value of lessons learned from mistakes
• “Management’s job is not to prevent risk but to build the capability to recover when failures occur.” Ed Cartmill, President, Pixar
• “room for stupid” - Addison Berry’s concept - takes “stupidness” and help other people to not be - help others learn the lessons you learned the hard way, value that sharing
• “give it away” - do what good chefs do - out-teach, out-share, and out-do your competitors
• Create, then capture - Open Business Models by Henry Cheeseborough (sp?) - create value, then capture value. Drupal business is a pie; Lullabot grows the pie bigger so we can all share the pie. More room for everyone.
• Ways to contribute back - not just code!
• Social Signal - gave their intellectual property from four years of consulting, strategy, and development and made it available for free online under Creative Commons
• have to balance giving away vs making enough money - at a certain point you have to draw boundaries, determine what you actually charge for.
• consulting vs development: dev is building, consulting is recommendations, best practices
• Liza did some surveys of small Drupal shops, got data on what rates people are changing. She’ll post them soon. (All of the rates are higher than my highest rates! Hmm.)
• Threadless business model - designers submit design (1500 designs submitted per week), community votes, when they rise to the top the designs are chosen and printed. Designers are paid $2000 per design that’s chosen, additional money on reprint
• “have faith” - if you have faith in what you produce, you feel more comfortable giving it away
• Example: In Rainbows, Radiohead album that they gave away. They weren’t able to count the ones they gave away as album sales, but the “official” sales still sold 3 million copies and topped the charts
• Moby - his sites are on Drupal, including mobygratis.com - given away for free to small filmmakers, nonprofits, etc

Lullabotisms

• 20/20 rule - Lullabots get 20 hours a week of client time, 20 hours a week of whatever else they want to do
• No Bad Clients - mean people suck, only work with people who are nice and interesting and return the favor
• Saying No - Liza’s first job description was to say no, filter through all of the requests, tell almost everyone no (client gave her a nickname - the Velvet Hammer!)
• Rule of Threes - clients need to be nice, have a healthy budget, and/or have a fun or interesting project. Each client has to have two out of three, one of them being “be nice”
• keep it open!

Audience Q&A

• Q: How do you structure ownership, profit sharing, etc? A: don’t do ownership because it is expensive for Lullabots; have done profit sharing; try to give good, competitive compensation (though not at the top) but make it an excellent place to work. Not a monetary part of the compensation but a really big part of the compensation.
• Q: how do you identify the people you want to hire? A: Used to have a saying - never hiring, always looking. Open source = meritocracy - sit back, see who’s really awesome, grab them up
• Q: how do virtual teams work? A: up to 17 people, no office, entirely virtual, all over North America. Everyone works from home or their own office. Get together a couple of times a year entirely as a team (usually Drupalcon North America or Do It With Drupal). Tools for communication. Use IRC, IMing, Skype, team calls, screen sharing. In constant contact!
• Q: are Lullabots paid hourly or salaried? A: Salaried! At first it was hourly, went from group of freelancers to employees after about 1-2 years. REALLY HARD TO DO - Liza spent a year on the transformation! (eek!) Core Lullabots all full timers with 401k and benefits and all, though some contractors as well
• Q: How does advertising work? Google Ads, Targeted Search, etc? A: They do some of that. Lullabot was started on $10K, never got outside investment, never took out a loan. Competing now with much bigger budgets, so they’ve had to start doing a little advertising
• Q: Where does most of the revenue come from? A: for a long time it was mostly consulting, now more evenly split between consulting, development, training. Had to diversify over time. Made cognizant choices. DVDs are a product but they’re a service company; saw that the economy was changing, people would have smaller amounts of money to spend, Drupal was growing huge so needed new ways to reach more people
• Q: How did Lullabot start? A: first did dev, then started doing higher level consulting, then realized they needed more Drupalistas out there so started doing trainings to create a bigger Drupal pie to sustain themselves on multiple levels (training revenue + more people doing Drupal to make Drupal sustainable and successful)
• Implicit Q, A: for startups, use freelancers for as long as you can before converting to employees - so much overhead and resources go into making people into employees!