This summer, ThinkShout was named the 9th Fastest Growing Private Company in Portland, Oregon. Admittedly, this came as sort of a shock to me and Lev. Over three and a half years, we’ve grown the company from two dudes renting desks in an incubator space to a full-time team of 17 professionals averaging 10 years of experience each. But most of the time, it doesn’t feel like we’ve come up with any secret sauce for running a successful business. We try to listen to our employees and our peers in the industry. We partner with nonprofit clients trying to make the world a better place, and we do our best to treat them with integrity in all aspects of our work - from our design and engineering practices to our approach to project management and our billing process.
Perhaps there are a few things that we do particularly well. We win our fair share of work in coopetition with our peers in the nonprofit tech industry. But then again, in talking with our friends at ZivTech, Gorton Studios, Aten Design Group, Jackson River, Forum One Communications, and others, what we consistently hear is that there is more than enough work to go around in the world of technology for good.
How is that? What are the mechanics of "the small business of open source" that work for all these firms and, more importantly, for their customers?
You could tackle this question from a number of angles. Conventional wisdom suggests that the business value of open source, both in the for-profit and nonprofit sectors, is simply: you get a lot of stuff for free. This is true. With open source, you avoid licensing fees. With an open source platform such as Drupal, you can pick and choose among literally tens of thousands of free tools and extensions.
But this perspective speaks only to open source’s initial customer appeal. It speaks to the coarse outlines of the sales cycle of open source. You can’t just build a sustainable business off the idea that a platform like Drupal provides a lot of stuff for free.
So, what is the guiding principle of growing a small business around open source? For us, it boils down to:
Our customers benefit tremendously from their own contributions to open source.
Put a bit more bluntly:
Our customers benefit from paying us to give away their code.
To illustrate this point, I’d like to run through some of our numbers as a small business of open source. The following statistics are relative to the publication date of this blog post:
ThinkShout’s team includes 8 engineers with a total of 4,269 commits to contributed modules hosted on Drupal.org.
We actively maintain 24 contributed modules that represent over 100,000 lines of code.
The combined installation base of these modules (i.e., the aggregated number of websites using each of these modules) is over 42,000.
Interestingly, our staff has grown 750% from the end of our first quarter. The growth in adoption of our contributed tools by the community (1,400% since the end of Q1 2011) tracks closely with the growth of our quarterly revenues (1,300%).
Obviously, these statistics are only related anecdotally. On their own, they don’t prove that our open source contributions drive our success.
Still, it is interesting to look at some of the statistics around our client work:
Averaging the last four $80-$150K Drupal website projects we’ve completed, a typical project in this price range is made up of 36,289 lines of custom code and exported site configuration (excluding the theme, or the implementation of the graphic design).
In addition, most of these projects include the release of 1,000-5,000 lines of contributed code. In other words, clients who engage with us on these sorts of projects pay for us either to contribute back major features to a contributed module, or to release one or two stand-alone modules.
But what’s most interesting is that each of these projects leverage at least 4 to 5 of the contributed modules that other clients have paid for on previous projects. Each leverages around 20,000 lines of contributed code that our team has written for similar use cases.
Of course, these statistics reflect the significant cost savings to our clients in going with an open source solution. They get a lot of free stuff…
But more importantly, our clients benefit from becoming financially invested in the direction and cultivation of these open source projects. By becoming committers, they are ensured that their requirements will continue to be prioritized in the future development of the modules their website depend on. They benefit too by the tens, sometimes hundreds, of open source developers reviewing their contributed code for bug fixes and improvements.
Moreover, by releasing the code that powers their websites, our clients connect with other organizations with similar requirements who, in turn, will often contribute additional features to these projects over time. As a case in point, we released the Leaflet module, a web-based mapping solution, on behalf of the Intertwine Alliance in the summer of 2011. The Alliance paid for the initial release, which included a modest yet highly-innovative feature set. Since then, 36 different Drupal developers have contributed code to improve the module, and over 4,500 websites have adopted it.
Similarly, we initially released RedHen CRM, a native CRM solution built entirely within Drupal, for a small cohort of nonprofits with similar needs. In this case, we actually got these nonprofits to work together to brainstorm and prioritize their CRM requirements. Pooling funding, this group helped us launch RedHen publicly in the spring of 2012. Since then, over a dozen of our clients have continued to invest in RedHen, and it has been adopted on over 850 websites around the world. Most impressively, those initial clients that funded our early work on RedHen continue to upgrade their sites with each new release, benefitting from hundreds of thousands of dollars of free development.
Client investments in open source present many less tangible benefits as well. While our developers are inspired to support our mission-driven nonprofit customers, they are particularly excited (and therefore, keenly focused) when their work leads to open source contributions. Not only does this lead to high-quality engineering, it helps reduce turnover among our engineering team, which can be costly for clients. Among our team’s contributors to Drupal, our average turnover is less than half of the industry standard in information technology.
For readers of this post who represent agencies that also contribute to open source, I’d be curious if your data and experience track to ours. Business and nonprofit readers whose teams have paid for open source contributions, I’d be curious to hear your stories as well. After all, open source is all about transparency, which we believe makes us a more effective business.
In this episode you will learn:Tags: DrupalDrupal 7Drupal Planet
I spend a surprising amount of my time as part of keyring-maint telling people their requests are badly formed and asking them to fix them up so I can actually process them. The one that's hardest to fault anyone on is that we require requests to be inline PGP signed (i.e. the same sort of output as you get with "gpg --clearsign"). That's because RT does various pieces of unpacking of MIME messages that mean that a PGP/MIME signatures that have passed through it are no longer verifiable. Daniel has pointed out that inline PGP is a bad idea and got as far as filing a request that RT handle PGP/MIME correctly (you need a login for that but there's a generic read-only one that's easy to figure out), but until that happens the requirement stands when dealing with Debian's RT instance. So today I finally added the following lines to my .muttrc rather than having to remember to switch Mutt to inline signing for this one special case:send-hook . "unset pgp_autoinline; unset pgp_autosign" send-hook rt.debian.org "set pgp_autosign; set pgp_autoinline"
i.e. by default turn off auto inlined PGP signatures, but when emailing anything at rt.debian.org turn them on.
(Most of the other things I tell people to fix are covered by the replacing keys page; I advise anyone requesting a key replacement to read that page. There's even a helpful example request template at the bottom.)
 RT sticks a header on the plain text portion of the mail, rather than adding a new plain text part for the header if there are multiple parts (this is something Mailman handles better). It will also re-encode received mail into UTF-8 which I can understand, but Mutt will by default try to find an 8 bit encoding that can handle the mail, because that's more efficient, which tends to mean it picks latin1.
In a recent project I got the opportunity to tweak Drupal’s Apache solr queries.In this blog p
If you don't, the UK will have to rename itself the K. And that's just silly.
Also vote yes on whether Alex Trebek should keep his mustache.
With Drupal 8 looming on the horizon, everyone is talking about doing their part to contribute. In fact — shameless plug alert — Forum One is running a Drupal 8 Code Sprint tomorrow night! Come on out and code with us.
Wanting to get involved but new to Drupal development, I wasn’t really sure where to start. Through a Drupal DC meetup, I was introduced to the Drupal Ladder. Following the Drupal Core Ladder, I got a practice Drupal environment set up, got familiar with the issue queue, and tested some patches! Of course, all the issues and patches written and tested for the LEARN portion of the ladder only affect the sandbox version of D8 used in the tutorials, but it gives you a great idea of what to expect.
After working through the Ladder, I felt ready to attend some Drupal code sprints. However, one of the biggest problems new people have at code sprints is setting up their Drupal environment. As a newbie, I found the quickest way to set up a test environment on my Mac was through the Acquia Dev Desktop. This is a stack built specifically for Drupal (it’s pre-loaded with Apache, MySQL, PHP, etc.), so no downloads other than Drupal itself should be necessary. For this tutorial, we’ll be using Acquia Dev Desktop 2 Beta.
Note: although I am using the Mac version, the Windows instructions should be the same.Installing Acquia Dev Desktop 2 Beta
From the downloads page, click on Mac / Win Download within the, “Get the Acquia Dev Desktop 2 Beta” box at the top of the page. Locate your download file and double click the file to launch the installer.
- Click Next on the initial screen. The following screen will give you an overview of what is included in the Dev Desktop package: Apache, MySQL, PHP, etc. Review these and click Next.
- Review the license agreement, click Yes if you accept the terms, and then click Next.
- Make note of this next screen. This lets you choose the install locations of your stack and Sites folder. I would recommend leaving these as the default selections.
- The next screen displays the port settings that will be used by Dev Desktop. Do not change these. Simply make note of them and click Next.
- Review your information, then click Next, then Next again to begin the installation.
- Once the installation has completed, click on Finish. If the program pops up, minimize it. We must first download a copy of Drupal 8.
After installing Dev Desktop, we can now get our Drupal 8 environment running:
- Download your desired version of Drupal 8 (use Drupal 8.0.x-dev if you are going to help test and develop D8) by clicking on the .tar file for Mac or .zip for PC in the Download column. Be sure to extract the tar/zip folder if your system does not automatically do it!
- You can place the files inside your Sites folder, or simply leave it where it downloaded. It is advisable to change the name of the directory from “drupalx.x-x.x” to something simpler (e.g. drupal8, drupaltest, d8dev, etc.).
- Bring back up Acquia Dev Desktop, or launch it. Click on Start with an existing Drupal site located on my computer.
- For Local codebase folder, select the Drupal root folder you just downloaded and click on Open. You can leave Local site name as is, or change it up.
- Drupal 8 requires at least PHP 5.4, so select the PHP version 5.4 your Dev Desktop came with.
- For Database, select Create a new database. You can leave New database name as is, or alter as you like.
- Click OK, and your site will be imported into Dev Desktop.
- Select your site from the left, if it is not already selected. At the top of Dev Desktop, click on your Local site URL and it will come up in your default browser.
- On initial launch, your site should go to /install.php. If not, manually enter /install.php to the end of your site URL (e.g. http://drupal8.local:8083/install.php). Select your language, and click on Save and continue.
- Leave Standard selected as your installation profile. Click Save and continue.
- The database info should transfer and auto-fill into the fields, but just in case, enter the following info:
- Database name: name you created during the import (New database name)
- Database username: drupaluser or root
- Leave the password blank
- Under the Advanced Options: Host: 127.0.0.1 & Port number: 33067
Click on Save and continue once the information has been filled out.
Drupal will now install your site. Once finished, enter whatever you’d like for the site name, email, and user configuration, and your Drupal site should be up and running! Be sure to remember the username and password for the account you created, as this is your main administrator account (user 1).That’s All, Folks
Installing Acquia Dev Desktop is fairly quick simple if you follow these steps. Don’t let not having a dev environment stop you from participating in Drupal 8 code sprints, as there are plenty of other AMP stacks available to install, making sure you’re comfortable with one goes a long way. With my development environment setup all that’s left to do now is to actually write a patch…Maybe I’ll take care of that during Forum One’s code sprint tomorrow night!
Have you always wanted to get involved with Drupal core development but don’t know where to begin? Have a Drupal 6 site that you’re looking to upgrade to Drupal 8? The Drupal 8 Migrate in Core initiative aims to provide a robust and extensible migration path from Drupal 6 and Drupal 7 to Drupal 8. A lot of work has already been done, but we’re looking to increase our throughput by training up some testers and developers to contribute to the cause.
To that end, we’ve planned two in-person events and an ongoing virtual event where you can get some facetime with other contributors to get you up-to-speed on the current progress and how you can help. Development experience isn’t required! It takes all types of contributors to complete a project of this scope. We have opportunities for manual testing, documentation writing, UX, theming, patch testing, and patch creating. If you need more of a challenge, I’m sure that chx, benjy, and mikeryan can find something for you to sink your teeth into!
If you can’t wait to get started, please check out how you can properly configure your system in order to contribute. Even if you just want to do some manual testing, you’ll want to check this out. Once your system is ready to go, then find me in IRC (#drupal-migrate) or find us at an upcoming event.-->
This post originally ran on the ADCI blog, and has been reposted with their permission.
On August 30th ADCI Solutions and Omsk Drupal community participated in a worldwide event and organized the first Drupal Global Training Day.
This unique program is being conducted around the world since 2012. Every quarter training activities take place in different countries and cities in a single day. The Drupal Association promotes Drupal Global Training Days where various organizations across the globe host free events to bring people into the Drupal community.
Simultaneously with us 36 companies in Rome, London, Sydney, Madrid, Milan, Chicago, New York, Pakistan, India, and other far-away places conducted trainings for Drupal beginners.
Drupal is an advanced platform with open source software, which is developing dynamically, because about six hundred of thousands of developers around the world are constantly working on the project. Drupal is used for websites of any complexity: from blogs to public and government portals. Sites of the White House, The Beatles, Aeroflot, MTV, Forbes, GEO are working on Drupal.
Learning about Drupal
More than forty people came to get and share knowledge, among them were students, programmers, content managers, experienced developers and newbies who are at their start on the Drupal-way. The training program was built so that students first learned what Drupal is, where it comes from and who it is developed by, what its characteristics are, what open source technology and drupal community are. Then followed a report about advantages and disadvantages of Drupal, for what types of projects it is most effective to use.
During the coffee break, we gave T-shirts with the logo of the Omsk Drupal community to the wiiners of our competitions and made a group photo.
Then we moved on to the practical part. Audience took the basic steps of creating a site. Everybody learned how the Drupal looks and what opportunities it gives out of the box. Without writing a single line of code we made a news site with flexible content filters and sponsors' logos in the footer. Drupal allows an individual, a community of users, or an enterprise to easily publish, manage and organize a wide variety of content on a website. Its modular architecture allows you to put together the components you need to build practically any site. For those who have a general idea of how it works, but have no practical experience, the course was an excellent start.
The day ended with a report on theming. Students learned basic rules that should be followed in order that work with the theme was simple and clear, got aquainted with popular themes and learned how to create their own theme effortlessly.
A Community of Amazing People
As it was the first meeting in the new format of the training, we asked the guests to fill out a short feedback questionnaire. We wanted to know what people are interested in, and what they would like to hear next time. Thanks to the participants, we are pleased to see you. Everyone appreciated the initiative of free educational software. Most noted that they came to learn how to work with Drupal, and this training helped them to make the first step. We were pleased to see the live chat during the break, when the speakers are willing to explain something to beginners with a cup of coffee.
Of course, in the technical sense, Drupal is a CMS/CMF, but for thousands of people it is much more. This community is full of amazing people who are open to dialogue and able to inspire. Last year, the Drupal Association registered 2765 Drupal events. Glad that this year we will fill up this number.
My blog has been suffering alongside my work with DrupalCamp Gothenburg. It's hard work since we're only two guys making it happen this year, and there's a lot done and more to do. It brings me great pleasure to say that we just passed a major mile-stone when releasing the website for DrupalCamp Gothenburg. It's a new take on camp-sites, at least what I can gather. This site wont disappear after a couple of years, when the community looses interest in it. This site will not only promote this year's camp, it will also act as a collection of the earlier sites, tying sessions together, acting like a "blast from the past" - one site to rule them all.
Why, you might ask? Well, time is limited and since it's hard to get volonteers in Gothenburg to help out, this is a way to tighten the information flow and a way to skip doing the same thing year after year (making, coding and releasing a new site). Instead, we will focus on presenting the information from former DrupalCamps in a good way on the site, perhaps making it more interesting for our sponsors since their sponsoring presence won't disappear after a couple of years.
This year, though, we have a new design, since it's a new take on the website all together, and Daniel Andréasson is the one pulling the strings behind the curtain. He has done a lot of work on it, and I'm truly grateful for his help. His effort has given me the chance to focus on the sponsoring part, talking to hotels to bring good rebates to our visitors during the camp-weekend, and also see if some of all the other ideas might come to life at the camp.
Ever have wanted to import data into your Drupal site from JSON or a big ol' PHP array? You don't need to sweat all the gory details of matching up nodes and fields and coding massive for loops. Let the Drupal Feeds module do that for you.
In the immortal words of Queen: “all I wanna do is bicycle!” If you’re heck on two wheels and love nothing more than the feeling of the wind on your face and pavement whizzing underneath your wheels, you may want to consider joining in the Tour de Drupal leading up to DrupalCon Amsterdam.
Drupalers from countries all across Europe are teaming up for the Tour de Drupal, an epic bike ride from the UK and Switzerland to Amsterdam. Taking place the weekend before DrupalCon Amsterdam, the triumphant arrival of the Drupalcyclistas is expected on Sunday, September 28th between 4 and 5 PM at Eta Vondelpark in Amsterdam.
It’s not too late to join in on the bike ride, where you can find information here. Of course, if cross-country bicycling doesn’t do it for you but you still want to cruise around with a crew of awesome folks, consider renting a Yellow Bike during DrupalCon Amsterdam. For €50, you can rent a bike, a bike helmet, two bike locks, a bike map of greater Amsterdam, and insurance. The rental is from Monday-Friday. You can find more information here.
There are a lot of passionate bikers in the Drupal community— and we all care about our causes, too. UK Tour de Drupaler Alan Burke is combining his love of biking and charity by participating in a two-day, 360 kilometer cycle around Galway for charity. For more information about Alan’s ride, click here.
Regardless of whether you fly, bike, or take a train— we’re looking forward to seeing you in Amsterdam.
Image by Sonny Abesamis on Flickr.
Assuming this post shows up then I'll have successfully migrated from Chronicle to a temporary replacement.
Chronicle is awesome, and despite a lack of activity recently it is not dead. (No activity because it continued to do everything I needed for my blog.)
Unfortunately though there is a problem with chronicle, it suffers from a bit of a performance problem which has gradually become more and more vexing as the nubmer of entries I have has grown.
When chronicle runs it :
- It reads each post into a complex data-structure.
- Then it walks this multiple times.
- Finally it outputs a whole bunch of posts.
In the general case you rebuild a blog because you've made a entry, or received a new comment. There is some code which tries to use memcached for caching, but in general chronicle just isn't fast and it is certainly memory-bound if you have a couple of thousand entries.
Currently my test data-set contains 2000 entries and to rebuild that from a clean start takes around 4 minutes, which is pretty horrific.
So what is the alternative? What if you could parse each post once, add it to an SQLite database, and then use that for writing your output pages? Instead of the complex data-structure in-RAM and the need to parse a zillion files you'd have a standard/simple SQL structure you could use to build a tag-cloud, an archive, & etc. If you store the contents of the parsed-blog, along with the mtime of the source file you can update it if the entry is changed in the future, as I sometimes make typos which I only spot once Ive run make steve on my blog sources.
Not surprisingly the newer code is significantly faster if you have 2000+ posts. If you've imported the posts into SQLite the most recent entries are updated in 3 seconds. If you're starting cold, parsing each entry, inserting it into SQLite, and then generating the blog from scratch the build time is still less than 10 seconds.
The downside is that I've removed features, obviously nothing that I use myself. Most notably the calendar view is gone, as is the ability to use date-based URLs. Less seriously there is only a single theme, which is what is used upon this site.
In conclusion I've written something last night which is a stepping stone between the current chronicle and chronicle2 which will appear in due course.
PS. This entry was written in markdown, just because I wanted to be sure it worked.
Every modern framework nowadays provides a scaffolding tool code generator for speeding up the process of starting a new project and avoiding repetitive tasks. Now Drupal does, too! In this session you can build a module while following along with the live demo. You will learn how to take advantage of the Symfony Console Component to provide a CLI tool that automates the creation of Drupal 8 modules, automatically generating the module directory structure, controllers, forms, services, plugins, and required configuration files.
I just returned from my first CiviCRM sprint. It was called the DC Sprint, but as Jeremy has already posted, we were actually in Maryland.
As a first time attendee of a CiviCRM conference and sprint, I really did not know what to expect. I was very pleased that both WordPress and Joomla! received some real attention at the sprint and I hope we are heading to a place where CiviCRM can be truly CMS agnostic.
WordPress CiviCRM installs can now benefit from WP-CLI tools. WP-CLI is a Drush equivilant for WordPress. We were able to merge Andy Walker's port into 4.5 and Tim Otten added full API Explorer support for this. At the developer training day in DC on Saturday, we noticed an issue with civix and WordPress. This also fixed and now civix works with all CMSs without having to be directly tied to one as in the past. These two enhancements will help WordPress developers immensely.
Dana Skallman and I also worked through the unresolved tickets for WordPress. A great deal of progress has been made there, and in addition to all the new features in 4.5 users will find that the WordPress integration is better than ever.
What really made the sprint a great event were the people. We had three CMSs represented and while there was some good natured kidding going on, it is clear to me that the community is focused on the CiviCRM project and supporting Drupal, Joomla! and WordPress.
I cannot wait to see the 4.5 release and I encourage everyone to participate in the CiviCRM Community. Whether you go to a meetup, attend CiviCon in the spring or go to the next Code Sprint, you will not be disappointed and the community will be the better for it.
GSoC 2014 is over and it was a great summer for me. As a student, I lead the development of Entity Embed module for Drupal 8. I learnt a lot about Drupal 8 and the core values of Drupal community. Apart from working on my project, I also got involved with the Media Team and now I'm also trying to contribute to some of the other projects of the Drupal 8 Media initiative. It's been a fun journey with Drupal so far and I expect it to become even better.
To top it all off, I've been selected as a delegate to represent Drupal at the GSoC Reunion summit. Details at the original post on gdo. I'm absolutely delighted that I've been selected as one of the delegates given the fact that Drupal os such a big community. What makes it even better is the fact that Angie Byron, (webchick) will be accompanying me at the summit as she's the other delegate. Its going to be a great chance for me to meet her in person.
I'm all set for the summit. Visa approved, flight & hotel booked. I'm eagerly waiting for this summit and I'm extremely thankful to the Drupal community for providing me with this wonderful opportunity.Tags: Google Summer of CodeReunion SummitgsocDrupal Planet
There are many different ways to host a Drupal website.
Giving back to the Drupal community was one thing I wanted to make sure we did more of as a company. It's been a little over a year since I took ownership of LightSky and our Drupal contributions are increasing. We are actively contributing patches where we can, sponsoring local Drupal meetups and camps and even hanging out on IRC. One thing we have not done until now was to contribute a module. At some point, I would like all my development staff to contribute a module (or modules) back to the community and I figured if I was to ask this of my staff, it was only fair that I did it first. It took some time to figure out what to contribute back, but once I had an idea I was excited to get started.
My first attempt was to write a Tweet Embed module. It would create an input filter so that when you dropped a link to a tweet into it, it would embed it into the content. I spent a few weeks polishing the module and felt ready to submit it to review. After submitting it, it was discovered by an approver that there was an issue in the Twitter module issue queue to implement this exact functionality. That means this module was a no go since it would cause duplication. At the time I was frustrated, but only at myself. I should have been more diligent on ensuring that I was not duplicating functionality.
My second attempt, and the one that would be successful, was to write a module to encapsulate the LinkedIn Company API. The module would pull in shares and display them in a themeable block. I wound up writing two modules, one for the authentication and one to pull in the shares. I spent some time writing, testing and polishing and finally felt it was ready to submit.The Review Process
The review process was immensely helpful. It is encouraged that you do a peer review of three other modules that are awaiting approval. This allows your application to move a little more quickly through the process, but I would encourage you to do it even if that is not something you are interested in. For me, the review process did a few things. One, it allowed me to see how other people were solving problems in Drupal. I've been doing Drupal development for five years or so, but there are always things to learn. It also allowed me to become intimately familiar with what is expected of your module during the review process. After I did my initial set of reviews, I found myself going back to my module and making improvements that I may have not made otherwise.
After adding the reviews to my application issue, I started to get feedback on my module. The feedback that was given was very helpful and informative. I can confidently say that I learned a few things in the process. I got quite a few reviews of my module and each pointed out things that I should fix. At one point the reviewers asked me to contact the LinkedIn module maintainers and verify that my modules functionality was not something they intended to implement. It was not and I got the green light to move forward. From there my module sat in a RTBC state for 3-4 weeks. It was difficult during this time to remain patient, but with so many applications awaiting approval and so few approvers, this is what happens. Eventually, I was granted the ability to promote my module to a full project, and the ability to create full projects in the future.Final Thoughts and Tips
The review process is thorough, and that is a good thing. As a community we want to make sure that the people who are submitting modules are properly vetted and that they use best practices when coding. Although there was a bit of inactivity after the module was RTBC, it was not unbearable and if anything has encouraged me to remain involved in the review process to help alleviate some of the load. The biggest tip I can give is to not only be patient, but also be open to criticism. It's a little nerve wracking to have many people comb through your code line by line, but that is the nature of open source software. The feedback they provide will help you become a better Drupal developer and I know for me it was very exciting to learn how I could do things better. One of my big stumbling blocks the first time around was the fact that I did not do enough research when determining what module to write. Make sure that the module you are submitting doesn't duplicate functionality of another module. If there is a similar module out there, create an issue asking if they intended to implement your functionality. Sometimes a patch is a better place for a piece of functionality than a module and that is how it should be. Putting in a little extra research and effort on your end early on will prevent headaches during the review process.
If contributing is something you want to do, I would encourage you to take the jump and do it. I really do believe that you get back ten times what you give to the Drupal community.
If you have not already be sure to follow us on social media or subscribe to our RSS feed and newsletter. You can also contact us directly or request a consultation.
Last weekend, I (knok), Hideki (henrich) and Yutaka (gniibe) met with John Paul Adrian Glaubitz (glaubitz).
In the past, I had met with another Germany developer Jens Schmalzing (jensen) in Japan. He was a good guy, but unfortunately he gone in 2005.
I had an old OpenPGP key with his sign. It is a record of his activity, but the key is weak nowaday (1024D), so I stop to use the key but don’t issue revoke.
Anyway glaubitz is also a good guy, and he loves old videogame console. gniibe gave him five DreamCast consoles. I bring him to SUPER POTATO, a old videogame shop. He bought some software for Virtual Boy.
DebConf 2015 will hold in Germany, I want to go for it if I can.
Inevitably, though, it can't define the full behaviour of an ACPI system. It doesn't explicitly state what should happen if you violate the spec, for instance. Obviously, in a just and fair world, no systems would violate the spec. But in the grim meathook future that we actually inhabit, systems do. We lack the technology to go back in time and retroactively prevent this, and so we're forced to deal with making these systems work.
This ends up being a pain in the neck in the x86 world, but it could be much worse. Way back in 2008 I wrote something about why the Linux kernel reports itself to firmware as "Windows" but refuses to identify itself as Linux. The short version is that "Linux" doesn't actually identify the behaviour of the kernel in a meaningful way. "Linux" doesn't tell you whether the kernel can deal with buffers being passed when the spec says it should be a package. "Linux" doesn't tell you whether the OS knows how to deal with an HPET. "Linux" doesn't tell you whether the OS can reinitialise graphics hardware.
Back then I was writing from the perspective of the firmware changing its behaviour in response to the OS, but it turns out that it's also relevant from the perspective of the OS changing its behaviour in response to the firmware. Windows 8 handles backlights differently to older versions. Firmware that's intended to support Windows 8 may expect this behaviour. If the OS tells the firmware that it's compatible with Windows 8, the OS has to behave compatibly with Windows 8.
In essence, if the firmware asks for Windows 8 support and the OS says yes, the OS is forming a contract with the firmware that it will behave in a specific way. If Windows 8 allows certain spec violations, the OS must permit those violations. If Windows 8 makes certain ACPI calls in a certain order, the OS must make those calls in the same order. Any firmware bug that is triggered by the OS not behaving identically to Windows 8 must be dealt with by modifying the OS to behave like Windows 8.
This sounds horrifying, but it's actually important. The existence of well-defined OS behaviours means that the industry has something to target. Vendors test their hardware against Windows, and because Windows has consistent behaviour within a version the vendors know that their machines won't suddenly stop working after an update. Linux benefits from this because we know that we can make hardware work as long as we're compatible with the Windows behaviour.
That's fine for x86. But remember when I said it could be worse? What if there were a platform that Microsoft weren't targeting? A platform where Linux was the dominant OS? A platform where vendors all test their hardware against Linux and expect it to have a consistent ACPI implementation?
Our even grimmer meathook future welcomes ARM to the ACPI world.
Software development is hard, and firmware development is software development with worse compilers. Firmware is inevitably going to rely on undefined behaviour. It's going to make assumptions about ordering. It's going to mishandle some cases. And it's the operating system's job to handle that. On x86 we know that systems are tested against Windows, and so we simply implement that behaviour. On ARM, we don't have that convenient reference. We are the reference. And that means that systems will end up accidentally depending on Linux-specific behaviour. Which means that if we ever change that behaviour, those systems will break.
So far we've resisted calls for Linux to provide a contract to the firmware in the way that Windows does, simply because there's been no need to - we can just implement the same contract as Windows. How are we going to manage this on ARM? The worst case scenario is that a system is tested against, say, Linux 3.19 and works fine. We make a change in 3.21 that breaks this system, but nobody notices at the time. Another system is tested against 3.21 and works fine. A few months later somebody finally notices that 3.21 broke their system and the change gets reverted, but oh no! Reverting it breaks the other system. What do we do now? The systems aren't telling us which behaviour they expect, so we're left with the prospect of adding machine-specific quirks. This isn't scalable.
Supporting ACPI on ARM means developing a sense of discipline around ACPI development that we simply haven't had so far. If we want to avoid breaking systems we have two options:
1) Commit to never modifying the ACPI behaviour of Linux.
2) Exposing an interface that indicates which well-defined ACPI behaviour a specific kernel implements, and bumping that whenever an incompatible change is made. Backward compatibility paths will be required if firmware only supports an older interface.
(1) is unlikely to be practical, but (2) isn't a great deal easier. Somebody is going to need to take responsibility for tracking ACPI behaviour and incrementing the exported interface whenever it changes, and we need to know who that's going to be before any of these systems start shipping. The alternative is a sea of ARM devices that only run specific kernel versions, which is exactly the scenario that ACPI was supposed to be fixing.
 Defined by implementation, not defined by specification
 Windows may change behaviour between versions, but always adds a new _OSI string when it does so. It can then modify its behaviour depending on whether the firmware knows about later versions of Windows.