Last night I made a presentation on the “Business of Drupal” to the Sydney Drupal users meetup. The talk covered the subject areas of scalable jobs and wild randomness, basic business models in the software industry, the GPL, eight business models for Drupal in increasing order of scalability, ways developers can deepen their skills and a round up of how various organisations in the Drupal community are structuring the way they do businesss. I have just uploaded the slides to the talk.
For those wanting a little bit more detail without going to the slides, I’ll reproduce some of the content here.
Drupal business models in increasing order of scalability
1. Employment
- Employment at Drupal shop or company
- Income limited by salary (skill, experience)
- Non scalable
- Very regular
2. Pure services
- Contractors, Drupal shops, F2F training
- eg. Cross Functional, Previous Next
- Income limited by incoming jobs (supply) and staff
- Non scalable due to staffing requirements
- Variable regularity, no subscriptions
3. GPL products with services
- Distribution owners, module authors
- eg. Phase2, Ubercart
- Income limited by product popularity and staff
- Non scalable due to staffing requirements
- Variable regularity
4. Drupal hosting platform
- Drupal hosting
- eg. Acquia Dev Cloud, Managed Cloud, Chapter Three Pantheon, Omega8cc Aegir
- Overhead of maintaining platform – Aegir
- Scalable
- Regular
5. Drupal as a service (DaaS)
- Drupal running as a SaaS
- eg. Drupal Gardens, Buzzr, wordpress.com
- Overhead of maintaining platform
- Scalable
- Regular
6. Software as a service (Saas)
- Service accessed via bridge module.
- eg. Mollom, Acquia Solr
- Overhead of maintaining platform
- Scalable
- Regular
7. Products with some non GPL code
- Themes
- eg. Top Notch Themes
- Overhead of deloping product
- Scalable
- Irregular
- Problem: Is the main IP in the code or the images?
8. Products with all non GPL code
- Online training, documentation, books
- eg. Lullabot drupalize.me
- Overhead of deloping product
- Scalable (online training)
- (Ir)regular
Possible areas of specialisation for service providers
- Data migration: Data is like wine, code like fish
- Theming: Where are the themers?
- Custom module development
- Project scoping
- Verticals: distros
- Server admin, deployment (?)
- Performance (?)
The main takeaway idea from the talk was that working in non-scalable areas such as full time employment is a safe option which will yield good results so long as you have skill and apply yourself. However, exposing yourself a little to some “wild randomness” in the form of scalable ventures (startups, SaaS, distros) could be a worthwhile pursuit if you are successful.
8 Comments
I would concur with the concluding summary. As a contractor, I have steady well paid work on long term contracts but am also engaging in some side projects with some long term potential, its definitely the way to have the best of both worlds.
Nice! I love seeing this type of analysis. I’d argue that the PaaS (Platform as a Service), DaaS, and SaaS are all roughly equally scalable, and that all three are more scalable than the themes or training offerings. The reason for that is that you only consume training offerings once, and you have to continually new IP for themes. The *aaS offerings can all be written once and served to infinity.
Hi Robert. Ah ha – PaaS. Another acronym for my arsenal
Yes, I think you could shuffle the last few items around a little. This is due to the amazing powers of the *aaS model: the scalability of products with the regularity of services. I was perhaps putting too much importance on the last two items being products and not enough on the scalability of *aaS.
That said, I really do like the TNT and drupalize.me approaches because the products they are selling are reasonably simple. Once the product has been made it just needs to be hosted and served. ie. much simpler than maintaining a service with all the diligence that that requires. It’s probably easier for individuals to “hit the big time”, so to speak, with these kinds of models, ie. more akin to an author having a best selling book.
In the case of drupalize.me the offering is a subscription method and so there is the chance for it to be ongoing. I suspect that a lot of people would dive in though, binge and then stop the subscription. So yeah, maybe irregular. Some premium theme sites also attempt the subscription method as well.
We are going to see a lot more *aaS in the future
During the presentation of the slides a question was raised as to the true GPL status of images and CSS files. ie whether the TNT approach was valid. The proposition was that the non-GPL status had never been tested in a court and that it was unclear. This may be the case, however, it’s worth pointing to the response Matt Mullenweg got from the Software Freedom Law Center.
This is the approach which the Drupal community has taken as well.
Nothing here answers the question why CSS, Images, JS, etc., are exempt from the GPL. The key is application execution address space. Let me take a swing at my understanding of it. Disclosure: I’m a member of the (legal) bar, a member of the Drupal community, a founder of Acquia with Dries, a former coder (less-so now…), and have built two companies in an open source context. I am not a legal advisor, nor have I done a scholarly work on this topic, nor should what I’m saying be constrained as legal advice to any reader. I simply believe I’m well informed, and can reasonably combine some legal training & software developer experience. (Does that sound enough like a lawyer?
(Simplified,) The GPL says that you must provide the source to a GPL-licensed software application to whom you give a copy of it. The key here is the words “software application”, and what defines one. Early on, a key milestone was the creation of the Lesser GPL (LGPL), which provided for creating GPL-type add-ons that could execute as a run-time-loadable (/executable) component of a larger, non-GPL software applications without “tainting” the larger non-GPL application. This established a precedent (roughly) by describing a “software application” as that which was executing within the memory address space being used by a (single!) computer to perform its function.
As time has gone on, this got even slightly trickier when GPL applications is being used to provide functional web-services (SOAP, REST) interfaces to non-GPL applications. Again, since the web service is executing outside the address space of the accessing-application, the accessing-app is not tainted by the GPL of the web service provider’s code. (Web services would be chaos if the GPL did taint accessing-applications!)
Now apply this to a CMS, e.g. Drupal, and the browser of a visitor:
- When Drupal executes, it starts by executing index.php from Drupal, which is GPL licensed. This sets the address space, and thus the license for the remainder of the PHP files that are loaded – thus, all must be GPL. (Note: There’s a special provision for the PHP interpreter; the interpreter’s license is not determinative of the license of the code it executes, even though Drupal is (technically) executing within the address space of the PHP interpreter.)
- When the Drupal-rendered page is delivered to the browser it is the application execution address space of the browser that “runs” the CSS “software application” sent to it by Drupal. Drupal is not executing the CSS – the browser is. Ditto the JS, images, and for that matter, the HTML (e.g. an HTML 5 “application”).
(Technically, the Javascript that is part of Drupal (core or contrib) sent to a browser by Drupal is not actually being tainted by Drupal’s GPL. It could – in theory – be non-GPL. It is only a Drupal project requirement that JS checked into / hosted (for download) on Drupal.org be licensed by GPL. So, for example, if a company wanted to distribute their own Drupal distro – and did not care to host this distro on d.o for download – that company could include non-GPL Javascript. (This happens commonly across the non-Drupal open source landscape, where various companies sell “packaged distributions.”) Or, similarly, a company offering a SaaS solution might provide a module for Drupal (GPL, and hosted on d.o) which does not directly contain JS, but instead causes the visitor’s browser to do an http GET of proprietary JS from the company’s (third-party) SaaS service (which is then executed in the address space of the browser and talks back to that originating SaaS server).)
Hopefully this is helpful to those reading this thread.
Jay, thanks for the detailed comment. It pretty much covers my understanding of how the GPL operates with respect to Drupal.
The one area I would comment on though is with respect to you discussion of JS not being “tainted” by Drupal’s GPL. One could raise an argument that code which interacts with Drupal’s JS should be covered under the GPL. This would include anything relying on jQuery and possibly the JS settings. Quoting from the licensing FAQ on drupal.org.
http://drupal.org/licensing/faq/
This would probably cover a large proportion of JS written in modules, whether they be contrib or not. Given the way most JS is used with Drupal these days I’d say that it probably would be covered by the GPL. However, I believe that it would be possible to write non GPL JS if it interacted with just the content of the page.
So in general, if you are looking to use copyright law to protect a business model when using Drupal it looks like i can be done with images, CSS, documentation (video, audio, text) and non executed config. This is a good fit for theme developers and training providers.
I’m not a lawyer either so please don’t take this as legal advice.
I was wondering about how the GPL for Drupal works with services and HTML5. If I have a service that uses Drupal and its modules to build and entire web service and one that serves up html5 to a iPhone, what will happen? Is this considered as distributing an application and therefore I would be required to put my entire web service into Drupal.org to protect myself? If so that would be a no starter for me, as I would lose my investment.
In other words, is html5 and Json/XML serving considered as distributing an application that has Drupal in it and therefore, will I be required to GPL my code/service as well?
Thanks,
David
Hi David. My presentation looked at different business models based around the GPL and how they apply to Drupal. I’m not in a position to give legal advice for your specific circumstances. If you have questions about the GPL then probably best to talk to a lawyer. If you have general questions then you could head over to the Legal group at groups.drupal.org. Crell and the other people in that group can usually give a pretty good guide as to what the situation is.
You also could do some research. Try this:
http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL
Generally speaking, I believe that just serving HTML5/JSON/XML is not considered as distributing an application. You are distributing content in this case, not the source code and as such the GPL would not apply to the content. If you owned the copyright in the content you serve then you can license as you see fit.
So looks like Drupal is a starter