As concrete5 continues to grow, our organization and roles are changing. When we started, it was just a couple of guys in their basement and a half a dozen sites using the software. Today there are 65,161 users on concrete5.org. More than 130,000 unique sites that have hit our servers for update information. 65,448 sites have connected to concrete5.org and made project pages.
Open Source & Strategy
Announcing community elections!
Wordpress vs. Thesis : concrete5 says “the GPL is stupid”
Wow. If you haven’t heard the drama, you should watch this video. In short, a premium theme developer (DYITthemes) which sells a wordpress theme named Thesis does not release it under the GPL license.
Matt Mullenweg, the co-founder and leader of Wordpress is calling him out on it; “when you violate someone’s license it is breaking the law. It’s a definition of breaking the law.”
Chris Pearson says he doesn’t have to release his theme under the GPL “They are not the highest authority node up on the tree that gets to decide everything that happens underneath them.”
You can watch them get all sassy with each other for an hour, if you want. Plenty of people have and some of them are asking for our view on it.
concrete5 is a competitor to Wordpress in ways, and we had to choose a license when we started as well. We specifically did NOT choose the GPL for exactly this reason. Here’s how we see it…
1) Much of this is about distribution. Our understanding of this is pretty simple:
If Thesis is distributed as a stand alone download that /includes/ a copy of Wordpress, then Chris is legally wrong. If you distribute GPL software, everything you add to it has to be GPL compatible. Clear and simple, period.
If Thesis is distributed on its own, I think Chris might have an argument to make. It’s easy to think “hey this does nothing without Wordpress, it is dependent on it, it needs to honor whatever legal requirements Wordpress comes up with” but I don’t think that’s technically true. The GPL is about the copying and distribution of software and it doesn’t really cover this with a tremendous amount of clarity. There’s plenty of examples that would have been a lot more interesting to discuss than what they did in the interview. For example, just because you’ve written software that runs on Linux doesn’t mean it has to be GPL. If you distribute Linux WITH your software as a single solution it does however. How’s that for weird?
Regardless, Chris would have a much better high ground to stand on if Thesis actually worked with different CMS backends – much the way that C# application you wrote for linux could also run on a variety of other operating systems.
2) Matt seems like an awful nice guy, and Pearson comes off like a total douche in this interview. I’ve never met either, I’m sure they’re both awesome, I’m just saying after losing an hour to listening to this crap there’s a pretty clear answer for who I’d like to have a beer with. That’s a tremendous shame because frankly Chris is the underdog here trying to build and maintain a nice small business and Wordpress is the big player trying to squash entrepreneurialism. Regardless, Matt comes off as the hero cause he’s a nice guy and Chris comes off poorly because of the way he makes his arguments. Important lessons there, it’s probably time for us to do a better job stripping drupal references from our customer testimonials. 
3) Wow you can tell the difference that some funding makes. Let me just be clear about what I believe to be the real motivators here, please correct me if I’m mis-informed: Wordpress Automattic has raised over $40m in venture capital. They have over 25 million blogs out there, and fundamentally they are in the content business. They don’t make their real money by selling wordpress, or taking a cut of marketplace add-ons, or offering paid hosting, or any of the stuff we do, they make their money on content. The advertising value on wordpress.com is huge. You have 25 million individuals using your platform to create content, you can monetize that in big ways. That’s why wordpress may be frequently used as a CMS to build some corporate site, but you’ll never see their core team drop features that help my wife (who has an active wordpress blog about DIY sewing), in favor of features that make some corporate extranet easier to run. Matt doesn’t have to worry about making payroll in two weeks, he has to worry about balancing ads and content on Wordpress.com so my wife keeps going there to find other cool sewing blogs she wants to cross link to. Wordpress’s real competitors are Twitter, Facebook, Google – they’re in that big business of re-inventing media. That’s why the GPL makes sense to them. The more wordpress is out there, the better for wordpress, as long as it’s called Wordpress.
Chris on the other hand is selling a Theme that helps turn Wordpress into a application that does something more. Again I’m just guessing here, but it wouldn’t shock me at all to hear Chris’s company is self funded, profitable, and it hasn’t been easy to get there. The idea of having a product that you sell at $50 a pop being distributed for free or even worse sold for $49 somewhere else has to make him physically sick. The carrot of “but people will want you for support” is a pretty grim answer.
I’m not arguing that Matt has an easy life and Chris doesn’t. Certainly the stress of looking Phil Black in the eye and saying “yes your $40m will turn into $800 million, sir” can’t be fun. I’m just saying the two challenges are very different and you can read the distinction in motivation from just the tone of their voices alone.
4) The GPL is stupid, and O’Reilly did us all a tremendous disservice when he came up with “open source”. Yeah I said it, so blah! When I was a developer growing up in the 80’s, we had licenses that actually meant what they said. If you wanted to just give something away, you called it Freeware. If you wanted to save some money on sales but still own your software, you called it Shareware or Crippleware depending on if you offered a fully functional copy with additional features or if you did something like disable save. These labels came from the DIY software world where entrepreneurs could start successful businesses cheap by distributing stuff on BBS’s. (go look up Apogee Games). Meanwhile there were any number of “big” projects that were being distributed under licenses that made sense for schools and huge corporate problems. NASA develops some standard and wants to share it with the world, how do they do that? Several big software vendors see value in a piece of software existing, but not being “owned” by any commercial entity, how do they do that? Everyone wrote their own license and while it was confusing, it worked. Then in the late 90’s the successful technical book publisher O’Reilly came along and dubbed everything I’ve listed as “Open Source” for the benefit of the media which was having a hard time understanding how Linux could compete with Windows. Well that’s cool and all, certainly having concepts that everyone can understand in a word is great, but clearly we aren’t really there. Confusion abounds. People talk about “free beer vs. free speech” all the time, it sounds like a broken record. Any one with half a brain knows that nothing worth having in life is truly free (in cost), yet we also agree that the idea buying a car with the hood welded shut sounds like getting screwed. The goal to provide some clarity across all the different types of licenses that software was released under by calling half “open source” and the other half “commercial” has utterly failed.
5) You say you want freedom? Then the GPL isn’t for you. It is not “freedom” to force people who extend your software to honor ANYTHING you say. I’m not saying it isn’t a good business idea, I imagine it may frequently be a great business idea, but it’s not “freedom” so don’t try to take the moral high ground. You’re limiting people and it doesn’t matter that the perceived motivation of your limit is to enforce further freedom. Freedom doesn’t work that way, but proponents of the GPL seem to think it needs protection. Here’s how we see it:
If you’re for the GPL, you believe freedom is a fragile flower that has to be protected. “This started as free, we’re going to make sure it says free with all our impressive powers.”
If you’re against the GPL, you believe freedom is a force of nature. It may not look that powerful at a glance, but it’s gonna win in the end. It’s like entropy. It exists, it will win. It doesn’t need your help, all it needs is your awareness and faith, and sooner or later it’ll come out on top.
Freedom is the MIT license which to paraphrase in three words says : “Don’t sue us”. If your goal really is to give something away for no cost and have the world be “free” to do whatever it wants with it, that’s all you need. Limit the creators exposure to liability, which would limit their own freedom, and you’ve made it “free.” Of course if you do that you run the risk of someone taking your software packing it up and screwing you over in any number of ways, but no one said freedom was easy.
These issues with the GPL are not new, and it’s sad to see this play out yet again. Frankly I like to think that any legal document’s job is to create clarity, and whatever your view may be, its clear the GPL is pretty gray in spots. In some ways, I hope this does go to court so we can all get a clear answer on how this thing is supposed to work.
Meanwhile if you want to be part of something that is free, and is eager to be free in a simple understandable way, you should be developing stuff for concrete5.
UPDATE : Orrrrr I’m completely wrong.
As more debate continues in IRC and other forums a point has come up that we didn’t address in the original post. Thesis uses wordpress’s theme engine and that includes any number of lines of code that wordpress wrote. Clearly that is their work, covered by their license, and Thesis is a derivative of it. THAT being the case, he very well may be violating the GPL. What gets interesting there is where is the line for that not being derivative? If he just goes through and renames all the functions and variables but it functions the same way, is that new work? What if he changes some logic too, for loops become while loops, etc. Where is the line where something is no longer derivative but a new thing?
What if Thesis makes an abstraction layer from scratch that does nothing but give them some differently named hooks to the same stuff, and then releases THAT abstraction layer LGPL and continues to sell their theme? That sounds legal, annoyingly stupid but legal.
Regardless the fact that everyone’s so confused about this does bring serious questions to the fore on the worth of GPL and what ‘freedom’ means. I hope we find out.
Open Source Tip #27 – Smart comes in silos.
Most of what I’ve learned from going open source are just good life lessons I probably could/should have picked up anyway, and this one’s certainly in that camp. I’ve always idolized the renaissance man. I’m a big believer in knowing a little about a lot of things vs. knowing a lot about a little. I respect the need for specialists, but even then I think they tend to be better when they’ve put in the work to stretch their intellect across more than one silo of information. It builds empathy and humility to not always be the expert at what you’re interested in.
Going open source has provided me the opportunity to run into any number of people who are very very bright at one thing, don’t foster that fundamental curiosity about topics they have no expertise in, and yet seem to think their impressive intellect makes their opinion right on all topics regardless. Just because you’re amazing at the 100 yard dash doesn’t mean you know dick all about water polo.
I actually had one person complain about their in-ability to do something in concrete5 with the line “look, I /am/ a rocket scientist at such and such university.. I should be able to XYZ.” Strangely I am not a rocket scientist and I dropped out of college, but I can do XYZ quite easily. Go figure.
I was reminded of this just now when a thread on slashdot came up. Some fellow is chastising Apple for calling their new iPhone screen technology “Retina Display.” Apparently this “marketing drivel” has so offended this guy he feels the need to rant about it on slashdot:
“Again though, why the use of meaningless words? Couldn’t he have just said “the resolution/DPI is so dense that your eyes won’t be able to distinguish individual pixels”? What, does the average Apple customer really seek the need of some special word to wrap up the device’s capabilities in? And if they do, what does that say about their average customer?
I think it’s insulting to the people that buy Apple’s products, regardless of whether people seek it out or not.”
Holy crap dude! For real?? Yes. This is what we have language for. You use words and phrases to sum up larger concepts so a conversation can happen at an acceptable pace. Words do create some ambiguity as definitions tend to be subjective, but without some consolidation it’s difficult for anyone to get beyond facts and into useful concepts in a real world situation. I mean clearly this individual is smart enough to understand what a pixel is, how DPI might work, etc… But the basic purpose of language (were not even talking about marketing yet!) seems to not only escape them, but insult them as well.
I take two lessons from this:
1) I am a moron. This one shows up a lot in my life lessons from open source. So far I find the dumber I assume myself to be, the more pleasantly surprised I am when I get something right. If I am hearing about something that others think is awesome and my geek-gland says “that’s stupid marketing drivel,” chances are they’re right and I’m wrong.
2) Just because you’re talking to someone “smart,” doesn’t mean they have a clue what they’re talking about.
Open Source Tip #54 – Somebody WILL do it.
When we were commercial software things we’re, quite frankly, easier in a lot of ways. We had a few dozen clients we had active relationships with, and we worked on about half a dozen projects at a time. In those days it was pretty easy to try out a new idea with the CMS because we would simply put it on the latest clients setup and see what happened. We didn’t really worry too much about keeping everyone on the latest version of the platform, and subsequently we didn’t have to spend a lot of time worried about backwards compatibility.
We also didn’t see a tremendous amount of intentional abuse of our systems. While we did build some large, active, and successful sites, the code behind them was only open to people who had worked with us in the past. To break one of our sites in the commercial days, you’d simply have to guess at vulnerabilities instead of being able to scour code for them first.
Now things have changed. Every feature idea we have is more and more tempered by “what will this do to existing sites or old versions.” We’ve learned about (and quickly addressed) any number of vulnerabilities that some guy in his basement found for free – when paid consultants had found none for five years before. You quickly learn that even the most well intentioned work can cause havoc.
For example, there are two blocks in concrete5 that are commonly used to build navigations: the Auto-Nav block and the Page List block. The Auto-Nav block had been built to honor a certain variable you can set at a page level to hide that page from the navigation. The Page List did not honor the same attribute, and someone from the community pointed out that it really would make more sense if it did. We agreed and “fixed” it as part of some other version changes. Weeks later, people started complaining that their sites we’re missing pages. After some frustration we realized “duh” of course people had built sites that worked around the way the blocks behaved in the past and the simple “fix” to the Page List block actually broke their sites.
We spend a lot of our time trying to manage issues that could mature like this now. I tend to take much longer to release something than I used to. I tend to be more thoughtful about the reasons and needs behind any feature changes. The temptation to “fix” something that could have been better implemented in the first place is very strong. Learning to first resist and then very delicately architect not necessarily the perfect, but rather the lowest impact solution, has been a new adventure for me. Once you go open source it is safe to assume that someone somewhere who is smarter than you and has all the time in the world, is finding the mistakes, finding the holes, and making up their own weird work-arounds which will impact you later. Be careful what you touch because no good deed goes unpunished.
What is crippleware? Why aren’t all add-ons free?
Okay, we’ve been through this enough times that it deserves a clear position from the CEO….
concrete5 core is free and open source. When we say free, we mean “free beer.” Our belief is that content management is a human right, and we are committed to making it easy for everyone in the world to run a website.
However, not every add-on in our marketplace is free. All of them are open source – meaning once you buy it you are “free” to do what you want to it for that site, and you can get “under the hood” completely.
Why do we do this?
A lot of time and money has gone into concrete5. Anyone who doesn’t think we’re generous has vastly underestimated the amount of energy that goes into making a powerful CMS that makes sense and doesn’t require an expert to configure. We are people too however and not only do we need to provide for our families, we also need to continue to put the level of coherent leadership into the project that it benefited from when we were strictly commercial software for 5 years.
A huge part (IMHO – most) of what makes concrete5 so compelling over other projects like Drupal and Joomlais the fact that it does take the risk of saying “this is the right solution” to many problems. No, we don’t believe you really need 300 results for “permissions” when searching for add-ons to a project. How about manning up and just getting the core solution right? That’s our philosophy. We don’t always hit the mark because we’re human, but we’ve done pretty well so far, and that’s the goal for the future as well.
Same deal with the marketplace. Other projects seem to have a pretty low barrier of entry for add-ons. I’m not entirely sure if there even is any barrier, but if it exists, surely the question is “does this add-on work with a clean install of our app? Didn’t break? Okay give them a project area – goooo Open Source!” Well bravo for Free Love and everyone being Super Duper, but I see that as unfair to the next schmoe who is trying to figure out how to solve their own problem. If I download a weather widget and my whole site breaks because it uses the same table as some image gallery I already had running, everyone fails. The weather widget developer looks like an ass, and so does the image gallery developer. Both end up doing way more individualized support than they should to keep their customers happy. Moreover, the overall project fails because now no one can trust any add-on to do anything easily. This is where Drupal certainly is today, just look at Acquia’s business model. This is unacceptable to us.
At concrete5.org you will only find things that work. If they don’t work, we’re gonna make them work for you. $15, $55, or even a couple hundred bucks is a small price to pay for something that solves a real business need for you and is going to work in a seamless, happy, healthy way. When we evaluate a new add-on, the question will be “does it work on an install with EVERYTHING added?” This is a huge challenge, but we think it’s going to be critical to the success of our project in the big picture.
How do we decide what is in core?
Anything that will make a fundamental change to the way concrete5 works which would impact all add-ons and benefits the community/project is free. So recent additions that fall in that category include things like:
- A My Profile section that various add-ons like forums or ecommerce would depend on.
- An advanced file system that all add-ons can use.
- A better way to create shared central blocks.
The reality is that with other projects like Drupal, once you’ve installed one modification to the way core permissions work you’ve effectively rendered their massive marketplace to you. How can the huge community really even help when everyone’s configuration is a unique one off? We’re going to do everything we can to keep this project from splintering into core pieces that don’t work with one another and render all subsequent add-ons a crap shoot.
Anything that we think is a basic building block to 80% of the websites out there in the world, we’ll make either part of the core or free in the marketplace. So things around embedding most types of content, some interaction like guestbooks and forums..etc.. We’re not asking “would everyone benefit” – because who doesn’t want free stuff, but rather “do you /need/ this to get your point across with the software.” Some examples:
- You can place banner ads using the Content Block, the HTML block or the Image block and your site visitors will never know the difference. Want to track click-throughs, impressions, and pull from centralized ad groups that randomize choices? You can do that, you can have it TONIGHT! That costs $55.
- You can assign a date to any page in concrete5, so it’s possible to make many different type of chronilogical interfaces with the core. You can also just include a Google Calendar with the HTML block. Want a month view, list view, and ajax driven agenda view to a multiple calendar system that makes event pages spread across your site? Want that working NOW? You need to pay something too.
How do we price things?
We make it up. We don’t frankly care how long it took us to write it, we don’t care how much the competition sells it for, we’re guessing how much you’re willing to pay to have it “just work.” No lie. This is business 101.
But wait, what about the Community??!?
Here’s some promises to our community we’ve always kept and always will:
- Your stuff can go in our marketplace. We don’t care if you’re selling it or giving it away, if your able to give us a stable, solid, correctly packaged add-on for concrete5 and we don’t think it’s malware, we’ll stick it in the marketplace. I can’t promise you we’ll feature it above our own in every interface view, but we’ll gladly post your free image gallery block right up there next to our own $15 per site one. If yours is better and you can make the community happy using it, so much the better for everyone.
- We will help you sell your own stuff. Software is about support as much as creation. If you’re making something and giving it away, you might consider selling it and making a buck. Getting out of the purely hourly revenue model is the dream of almost every developer out there, and we think we’re gonna make a lot of dreams come true with this awesome marketplace. If you’re making stuff that people want, you should want to help them install and use it safely. You should want to add to it over time. You should be compenstated for your efforts. If you’d like to sell something you’ve built in our marketplace, all we ask is 25% cut of the price. This is less than Apple’s iPhone App store and from what I can tell comperable toDot Net Nuke’s system if not better.
- This stuff is not going to be super expensive. I’ve seen libraries that take this approach where solutions cost many thousands of dollars. Crap, I remember buying a Digital Asset Management system from the Cold Fusion marketplace back in the day for 8k and still shoveling out 30k to the developers to customize it to our client’s needs. This isn’t the model here. The highest price we’ve even debated setting a product at so far is $255. That’s what most targeted consumer software is priced at today. There’s no five figure recurring yearly license fees here.
What does this mean for the project?
It means a lot of great stuff. It means we’re going to end up building a community that is not only passionate, but is actually making a better life for themselves and their families out of their contributions. It means when you go shopping for add-ons for your site, you’ll be able to do it with a smile on your face and try stuff out without fear.
Is it open source? Absolutely yes. Open source as a term is really just a catch all for any number of different license types from the 80’s and early 90’s when we were cutting our teeth in the BBS scene, and this idea honors them all quite well.
If you’re still not sold, ponder this:
THE MAN is actually just A Man.
Thanks for making it though this rant, hope you agree – I’m sure you all won’t. If you don’t I’m all ears on constructive suggestions. If the reply is “it should be free because I want it to be, and it’s not my problem how you or the project succeeed in the big picture…”… the door is that-a way. <grin>
concrete5 to show in Tokyo!
Some very cool people in Japan have taken the lead with concrete5 there and will be demoing it at on Open Source conference this month. If you happen to be in Japan, or have a lot of disposable income and are looking for an excuse to jump on a plane and head there on short notice…. here ya go!
Usagi Project will attend Tokyo OSC with concrete5 Japanese version.
Tokyo Open Source Conference 2009/Spring
Japan Electronics College Building No.7
1-25-4 Hyakunin-cho
Shinjuky, Tokyo, 169-8522
Japan
東京オープンソースコンファレンス2009/Spring
日本電子専門学校 7号館
東京都新宿区百人町1-25-4
RSVP the seminar at
http://www.ospn.jp/osc2009-spring/modules/eguide/event.php?eid=76
Also you can just show up at our demo booth during the event.
———-
Feb 20 (Fri) 10:00am -5:30pm
Feb 21 (Sat) 10:00am -4:30pm
Date & time for first meeting
Feb 20 (Fri) – 21 (Sat) (Seminar starts on Feb 21 11am)
c5 strategy
We’ve gone a little dark new builds of c5 since osCon because we’ve been fully dedicated to this rebuild of SchoolPulse.com. We’re making it all out of c5 and it’s gonna be sexy, easy to use, and provide a lot of great blocks back to the project. It’s consumed every waking hour from everyone I know for the last two weeks and weekends. It’s launching next week.
In the meantime, here’s an email thread I had recently with a new c5 fan where I lay down some of the ideas and plans we’ve been putting together as we watch our baby take off here:
> General feedback was submitted to ConcreteCMS.com. Here is the information.
>
> Name: Dennis
> <stripped>
>
> congrats on your CMS! we are impressed and actually thinking about using it for our clients.
>
> we are a design agency based sydney australia and have a variety of clients, from local hairdressers to government departments. we are looking to use an open source cms to use for our small to medium sites. your system so far seems to be the most user friendly one.
>
> I have worked with other systems before, like joomla and wordpress, etc. now all of them have a massive following and ten thousand different modules, while your system seems to have a limited amount of modules (which is actually quite nice). but what if we need a certain module? could you develop it for us and can we re-use it on projects?
>
> let’s say a blog – writing an article, getting comments (display upon approval), etc – is something like this already developed? if not how much would it be – just an estimate as the specs are a bit vague obviously?
>
> and last but not least, would you feature us on your page as design partner if we return the favor?
>
> that’s it for now from my side.
> looking forward to hearing from you.
>
> cheers
> dennis
> www.digitalgarden.com.au
>
Hey Dennis,
It’s nice to hear from more folk as excited about c5 as we are. Thanks!
In short – yes.
In detail:
1) I think c5 would be perfect for your shop. We too have been frustrated by the lack of coherent control, or scalable architecture in many of the CMS solutions available. We plan to always keep the core of c5 simple and approachable. It’s our belief that most website development challenges can be solved with a dozen or two well architected blocks, and that’s what we’ll be shooting for as we continue to get to the “perfect core” in 2008.
2) We do have a guestbook and blog structure in a previous version of concrete that we’ll be migrating as part of that “core tools” library, I’m sure. Also slated for that: more easily customized navigation controls, multi-lingual interface, a cleaned up advanced permission model (which right now has to be turned on and isn’t quite as elegant as the rest of c5.)… all sorts of more useful goodies..
3) We will be launching a marketplace for blocks and themes shortly as well. If you as a third party developer are interested in making and reselling either, you’ll be able to do it there easily. We’ll also have a job board and something similar to etsy.com’s alchemy where you can request or pledge for developments to c5 that other developers could build for. We’re thinking there will be a 10% commission for the c5 core team, and there may be paid placement opportunities on that site as it matures as well.
4) There will also be a hosting site. It won’t be the cheapest place in town, but it will have a very stable centralized version of c5 running with some nice backup/redundancy options.
5) I would love to feature your email and this reply on our blog at concreteTheStudio.com if that’s amenable to you. Show me some sites built out of c5 and we’ll talk about the Support page of concrete5.org, if you’re interested in that as well.
if you’re ever in pdx, beers on me.
thx again
-frz
ps: i love your site. nicely done.
opensourcecms.com delivers mad traffic!
Well no one on our end posted to you, because you’re quite clear that Beta projects shouldn’t be posted in your rules… and yes.. we read rules.. sometimes.
However, someone from your end must of been at osCon because we appeared on your site a few days ago. Here’s a snapshot of our google analytics for the last month:
Gotta say, we were gonna wait till we had a release we were calling final before posting to you,OpenSourceCMS.com. The fact that we just magically showed up is great! We’ll just take that as a pat on the back that what we consider Beta is pretty damn stable, and we’d like to say thanks.
(ps: hey reader, wanna help? vote for us on their site. when they first added us they linked to our demo in such a way that it wouldn’t work so we got some low votes that are messing up our average.)
OSCON, Redux
So we’re all home relaxing after two grueling days at OSCON. Maybe “grueling” is the wrong word; we had a great time and met a lot of really interesting people, and we got to talk our jaws off about Concrete5. (The phrase “PHP-based content management system” becomes kind of a tongue-twister after a while.) I didn’t get much of a chance to check out the other exhibitors’ booths, because we had a constant stream of people checking out our stuff and I felt compelled to verbally inundate them all with how great Concrete5 is. I did, however, get a chance to utterly destroy Franz at a two-foot-high game of chess, met and Facebook-friended Facebook, and gave a whole lot of people screwdrivers. If any of you OSCON attendees find your way over here, thanks for giving Concrete5 such a warm reception. We’re worn out, but we had a blast.
osCon
We’re at osCon this week! Come check us out!
chuga chuga…
one week later, we’re ranked 800 out of 179,523 projects on sourceforge, with over 150 downloads. We’ve got handful of people helping in various countries, we’re hard at work on our hosting and marketing materials… Our booth for osCon2008 is purchased, we’re hoping to leave that event with 30 active developers contributing their time… we’ve basically got 6 weeks to get ready… very exciting…
first use…
So I originally architected Concrete CMS in a nice little bar in SE Portland to deal with an adCouncil gig we had with too many stakeholders and not enough time. That was many years ago, and since the early days my dear friend and comrade Andrew Embler has taken the loose direction outlined in my sketchbook of “blocks and collections” and made it work on fixed budgets for demanding clients. Concrete has had some really compelling concepts since those early days, but like any box of tools you use hard – there’s some idiosyncrasies that drive you up the wall. Being the guy finally responsible for training clients, and getting content into working sites that make sense – I’ve been looking forward to getting my hands on the complete re-haul concrete5 for some time. I’ve peered over shoulders a lot, but today was the first time I got to play with it on a site I need to deal with.
Wait… Free?
“Okay so let me get this straight, when we first spoke it was $13k to own it, and now its free? Are you sure about this?” a dear friend and repeat client who runs an agency just asked me.
I get that you want to provide for your family, sooo what are you thinking?
Are we going to offer a “freemeium” model where you get crippleware for free and the useful parts in expensive add-ons?
Nope.
Are we going to have a different license depending who you are?
Nope.
Are we going have a donation button or something?
Yes, but it will point to our favorite charity, which can do more good with the cash than us.
So I give up, why do you think destroying your perfectly viable license revenue is going to provide stability and creative freedom?
Here’s what I see. The biggest challenge my crew has is bizdev. We’re not perfect at everything, but we sure can deliver sweet stuff and we improve every day, execept for sales.
We’ve only really won good gigs through word of mouth. We’ve tried just about everything, and without marrying yourself to a particular vertical, it’s very difficult to define a meaningful marketing strategy for a web/IT services company that wants to do “cool stuff.” From my experience you do your best, and try to cultivate as many life long associates and friends who will recommend you as you go.
As the network slowly grows, things get easier over time, but it doesn’t really deliver with security and creative freedom if it ties you to a limited local gossipy scene. (yeah i said it).
So while completely giving away something we have and can charge a lot for, we’re actually doing ourselves a practical favor. Sure, we’ll be giving up a revenue stream, but we’re dropping a expensive business development challenge that we’ve never been good at or interested in solving. We certainly will still spend some real resources to make Concrete5 known – but a lot of that can be our time instead of cash. Moreover, if what we’ve been working on all these years is really as good as we think it is, we stand to jump-start a process that would traditionally take much longer. I’m interesting in seeing what a larger open source developer community might contribute to the project from a code standpoint, but I’m hungry for their evangelism about concrete5 to their clients. I don’t need (or want) to own every dollar that is made off of concrete5. Why not just get out of the way and respond to opportunities as they arise as thousands of people deliver concrete5 powered solutions to their clients?
That’s the practical reason to go “free beer.” The real one is better:
Content management is a basic human right.
It costs next to nothing to write your thoughts on a piece of paper and nail it to a door, it should cost about the same to make a basic website without it having to be a blog. If we can do that, we’ll win one way or another.
concrete5™: value the brand.
Concrete has been around since 2003, this major version update that has been a year in the works and is major version release 5. While our content management system has always been “open source” to our clients, who paid for it; this is the first fully “free beer” open source release we’ve done. We’re giving away our secret sauce and we’re thinking how to protect the years and millions in development that have gone into it.
We’ve come to recognize it’s the brand. We will trademark our name as Concrete5™ – and make money by being the official host, trainer, documenter, and support provider. Conversely we may look at any of those roles and tap a better suited partner as an “Official Concrete5 Solution” in return for some license or revenue model.
The Ruby on Rails guy looks to have similar ideas around his brand and license model, which is also MIT.
Training getaway.
I’ve never been a huge fan of the corporate training week. In my experience going to them as a employee, it’s kinda a paid vacation, yet a boring. It’s great to learn all at once and whatnot, but having someone read a manual to you in front of a computer seems like a horrible way to spend your day when you’re visiting a fun big city.
Answering Questions About Google’s Effort at Standardizing Social Network Widgets, and the Creation of Your First OpenSocial Widget
Andrew Embler – CTO Concrete5
On November 2nd, Google announced its OpenSocial initiative. Amidst the breathless hyperbole there came a prevailing sense of confusion from the world’s web developers (including those around our office). What exactly was this “OpenSocial?” Was it an API? A framework for building web applications? A social network? Was Google invading the Facebook space? All of the above? And – perhaps most importantly – just what the heck are we supposed to learn, exactly?
It turns out that OpenSocial is all of those, and a bit more. It’s also a bit loosely defined, and complete documentation is still a bit scarce. So I’m going to try and fill this understanding gap.
While some good write-ups of OpenSocial have been circulating the web since the announcement (Marc Andreesen’s is particularly fine) none of them really offer a full picture of the OpenSocial initiative, including how it extends current concepts of widgets and the social web. Moreover, none of them really speak to engaged, active web developers about how to “get on track” with it. If you happen to be one of those developers – smart, passionate, and perhaps a little bit late to the party – this should get you going, and quick.
A First Look at OpenSocial: Background
OpenSocial extends out of the rise in popularity of widgets on the web. How am I defining widgets? In the context of the web, widgets are typically HTML, JavaScript and/or Flash, bundled together, into a self-contained mini-applications. Stock tickers, clocks, mini news readers and weather displays are some example of popular types of widgets.
Widgets are not a new concept. The original Macintosh operating system embraced the concept of “desk accessories” – tiny, omnipresent applications, uniquely styled to be recognized at a glance. This continues today in Mac OS X, in the form of the Dashboard. Software programs like Yahoo Desktop Engine (formerly Konfabulator), Google Gadgets (when paired with an environment like Google Desktop) and the Windows Vista sidebar are other examples of widgets at work in the personal computing space.
While these types of widgets are used as productivity enhancers, other types began to gain popularity with the rise of social networking sites like MySpace. Typically built in flash for easy portability, widgets like slideshows, mini games, movie players and scoreboards were meant to be installed in social websites, and to be viewed not by the person installing them, but by others. They are meant to impart information or a sense of style. They are social.
While definitely popular, these widgets are still self-contained. This aspect of widgets makes them portable and easy to install – it’s not difficult for a person to cut and paste a two-line flash embed code – it does limit their utility. Widgets for the web either completely lack customization, or they require a large amount of overhead on the part of the widget creator, to support things like data persistence. Furthermore, widgets don’t know anything about where they’re placed. Finally, not all social websites support the various ways a widget can be delivered (straight HTML, JavaScript, Flash, etc…)
2007: Facebook Applications Up the Ante
In May of 2007, Facebook changed all that, when it officially launched its Facebook Platform: with this, there was one spot in which all Facebook widgets could be listed, and easily added to profiles. Furthermore, the Facebook platform introduced the concept of a “Canvas” page, which gives applications an entire, user-unique view to offer additional functionality, simply when they’re installed by a user. Finally, Facebook applications (in both the widget and canvas view) can access user profile information, interact with the user’s friends, and provide mechanisms for application promotion.
Problems Still Remain
Boy do they ever. While Facebook’s development platform exposes a lot of power, it’s fairly complex, with its own markup language, API and even an abstracted query language to search the Facebook database. Needless to say, these options are completely specific to Facebook, as is 90% of pretty much any application you write for the platform. At this point, developers who want to embrace MySpace, Facebook and traditional websites are stuck writing, at the very least, three completely separate applications. They also must market those applications separately.
Enter OpenSocial
It is against this landscape that OpenSocial arrives. Consumers, web developers and clients all recognize the market for widgets and customizable mini-applications and their spaces. But with a multitude of social networks, how is it feasible for the average developer or development shop to support more than the biggest networks? The best case scenario? Facebook users get the most full-featured application; their app has a fully realized widget, a canvas space with extra full-page functionality, and the ability to tie in to users who also use Facebook. Other websites get a simple widget with little to make it specifically compelling to members of said website. Big win for Facebook. Mixed results for everybody else.
In theory, OpenSocial should change that. According to the OpenSocial initiative: “OpenSocial provides a common set of APIs for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network’s friends and update feeds.”
Clearly, Google is positioning OpenSocial as the answer to the Facebook platform, but one in which any widget or application developer can write once, deploy everywhere. That’s the hype. Does OpenSocial deliver? Let’s answer the questions.
Questions about OpenSocial…Answered
What are the components of an OpenSocial application? What are they made out of?
When comparing OpenSocial applications to widgets for MySpace or other social networks, the answer to this is simple: OpenSocial widgets are essentially Google Gadgets. Google Gadgets are Google’s own implementation of widgets, built in HTML and JavaScript, and served in an iframe. A public API for Google Gadgets already exists, separate from OpenSocial. Up until now, however, these widgets have faced the same problems as widgets on MySpace.com: they’re self-contained, and know little about the environment in which they’ve been embedded.
OpenSocial adds a new API and JavaScript namespace for use inside Google Gadgets. Since Google Gadgets already use JavaScript, using OpenSocial’s JavaScript API is really a simple way to allow your widget to access friends list and some simple information about those viewing it. For example, the following JavaScript, when added to a Google Gadget, gets information about the friends of the person viewing the Gadget:
-
function getData() {
-
-
// Creates an Open Social request object.
-
var req = opensocial.newDataRequest();
-
-
// Adds a new request to this object - let's get information about the person viewing
-
// this widget, and store it mapped to the "viewer" attribute in the response object
-
req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
-
-
// Let's request some more information. Let's get information about the viewer's friends, and store it
-
// mapped to the "viewerFriends" attribute in the response object.
-
req.add( req.newFetchPeopleRequest('VIEWER_FRIENDS'), 'viewerFriends');
-
-
// Let's send the request to the container website, which will load the "onLoadFriends" function when
-
// data is available
-
req.send(onLoadFriends);
-
-
}
-
-
// this function loads with information from any Open Social requests.
-
function onLoadFriends(response) {
-
// viewer and viewerFriends are available in the get() method below because that's
-
// what I named them in the req.add() call above
-
var viewer = response.get('viewer');
-
var viewerFriends = response.get('viewerFriends');
-
var data = viewerFriends.getData();
-
-
}
-
While the API documentation explains additional data types available to OpenSocial widgets, at their core they’re just that simple. More adventurous developers can perhaps dispense with the JavaScript API entirely, and use OpenSocial’s REST-based API for getting data about people, activities and data persistence, but for most the simpler JavaScript API will be sufficient.
Where do the assets for these applications live?
OpenSocial widgets can use assets hosted anywhere on the web, and linked to through simple HTML. Additionally, Google will host your assets on its domain gmodules.com; just upload your images and external stylesheets through a menu option in the Google Gadget Editor, and Google will store them and provide you a URL to link to them.
How do customers find these applications – is there a directory?
Google currently hosts a Google Gadgets directory. Since OpenSocial is simply an API that can be included in Google Gadgets, they will likely appear in this directory without much fuss. Unfortunately, there is currently no list in the directory of which sites support OpenSocial, and to be truly effective and compete with Facebook OpenSocial will need to allow these applications to be added directly from within their container websites. There currently isn’t any documentation on this, although to check out what is known, jump to our section on how a social network might include OpenSocial widgets.
Can I store data in them? How much and at what cost?
Yes, you can store data in social gadgets. The Google Gadgets API has support for saving preferences, meaning that when you add that ESPN Scoreboard widget to your profile, you’ll be able to specify it as having a red background with white text; this instance of the ESPN Scoreboard widget – the one tied to your profile page – will continue to exist with these settings until you change them or remove the widget. Everyone who views the widget will also see it with a red background and white text.
Instances of widgets (like the example above) can also have additional data stored against them for those who might view them. For example, the ESPN Scoreboard widget might not only provide the ability for the person embedding it to set its background and foreground text, but might also offer viewers of the widget the ability to override those settings. These are “viewer”-specific settings, just like cookies on a web page. The settings saved for each instance of a widget are bound to the viewer’s profile, by using the OpenSocial Persistent Data API.
How would we implement this in OpenSocial? Let’s say a widget developer wanted to make it so that a person viewing the widget could save their city and state, so that the next time they viewed the widget they wouldn’t have to re-enter them. This information obviously differs from viewer to viewer, so it couldn’t be saved in the widget’s global preferences. The developer would need to bind this data to the profile of the person viewing the widget. Here’s how he or she would do it:
-
// city and state that the viewer of this widget has selected is passed to this function
-
function saveCityAndState(city, state) {
-
var req = opensocial.newDataRequest();
-
-
// we use newUpdatePersonAppDataRequest to specify that we're updating data the data saved is
-
// bound to the person viewing the widget
-
req.add(req.newUpdatePersonAppDataRequest("VIEWER", "AppCity", city));
-
req.add(req.newUpdatePersonAppDataRequest("VIEWER", "AppState", state));
-
-
// we pass the function that's run automatically when the request completes
-
req.send(function() {alert('Data Saved!')});
-
}
Reading that data back programmatically is similarly simple:
-
function getViewerInformation() {
-
var req = opensocial.newDataRequest();
-
-
// define the fields that we're retrieving for the viewer of the widget
-
var fields = ["AppCity", "AppState"];
-
-
// define the request for the fields above, which uses the fetch person data request
-
req.add( req.newFetchPersonAppDataRequest( "VIEWER", fields), "viewerData" );
-
-
// send the request to OpenSocial API
-
req.send(function(data) {
-
// on completion, this function is run automatically passing the data object to it
-
// "viewerData" is populated because that's what we bound these fields to above
-
var viewerData = data.get("viewerData");
-
});
-
-
}
-
While this example stores strings, I imagine it isn’t too difficult to store complex objects, if you serialize them to JSON first. For more information on how the data returned is structured, check out the Social Google Gadget API documentation.
Do these applications have access to user data?
Short answer, yes. The OpenSocial API gives developers access to a small amount of fixed data (a “display name,” a thumbnail image, a user ID and a profile URL) and a varying amount of data which can be filtered by type, including “BASIC,” “CONTACT,” “FULL,” “MATCHING” and “PERSONAL.” The actual mechanics of using the JavaScript API to retrieve this information are somewhat up in the air, with few examples of applications actually using extended profile data, and no examples of programmatically determining what data is actually available on a container by container basis. Check back soon – or voice your displeasure at incomplete documentation in the Google Group for Open Social.
How does OpenSocial deal with different networks’ design limitations?
This is still a bit of an unknown; while many networks have pledged to support OpenSocial, only a few like Google’s Orkut, Hi5 and Ning actually have environments in which it can be tested, and even in these OpenSocial is only available in the developer sandbox. At a glance it appears that OpenSocial has attempted to gather up some of the most prevalent functionality in the social networking space – an activity stream, basic user information, friends and people in general – and provide access to them. It is up to the container website to determine how much of the OpenSocial API it wants to implement, meaning that the onus is still on the application developer to provide error checking and graceful failure if certain aspects of the OpenSocial API aren’t available. This is too bad, although probably unavoidable.
How does view/edit work?
OpenSocial at its core is really about widgets. In this way, it’s not really concerned about the difference between viewing and editing, beyond giving application developers the ability to save state, and giving the developer a way to specify preferences, which can be exposed and edited easily (this is part of the Google Gadgets framework.)
For these widgets, only one view is ever defined; it is up to the developer to include all necessary view logic within this one context. A widget could present two distinct interfaces – view and edit – to only the owner of the widget, with all other viewers only getting the “View” interface, but this capability must be explicitly included by the developer, including any permissions checks to determine whether certain controls ought to be displayed to someone viewing the widget.
How does Yet Another Social Network (YASN™) take advantage of these widgets?
First, one must become a Google Gadget container, a process which is reasonably well documented, and has been used by many of websites. This, however, is nothing new. To actually make your widgets aware of their container website, and implement the OpenSocial API, a site must implement the OpenSocial Service Provider Interface. As of this writing an official development kit to add these capabilities and expose them via the necessary JavaScript framework is still forthcoming from Google, but they have just released an OpenSocial Container sample.
Do I need to get my applications “blessed” by Google in order to run OpenSocial?
Nope. Although you need to submit your applications for review in order to get them to be included in the official Google Gadgets directory, you may host your gadgets from anywhere and need only a provide a URL to end users who wish to install it.
Why is Google doing this?
There are probably a few reasons.
- Their motto, “Do No Evil.” I suppose this would qualify.
- In the minds of some, this is a warning shot fired at Facebook. If Google is indeed in talks with acquiring Facebook, this might be a bargaining tactic.
- Since OpenSocial gadgets are, by their very definition, Google Gadgets, this increases the profile and number of Google Gadgets available to consumers. This will also increase the number of websites looking to become Google Gadget containers, which promotes their widget platform further.
With millions of mini-applications installed across a multitude of social networks, Google gets increasing access to more data – definitely a win for a company whose business is data mining.
Have any “gotchas” been discovered? Anything that us developers might like to know?
There always are. One of the most useful tips I’ve discovered has been this one:
While developing the Hello World widget described below, I found that Orkut would frequently cache my Gadget output, making active development of widgets a painful, painful process. However, if you append “&bpc=1″ to your Orkut application URL, the site will stop doing this. For example, if you’re viewing your in-development widget at
http://sandbox.orkut.com/Application.aspx?uid=x&appId=x
You can keep from ever seeing a cached version of the gadget by making the URL
http://sandbox.orkut.com/Application.aspx?uid=x&appId=x&bpc=1
Another tip? Double-check the data you get back. While checking the Google Group for OpenSocial, I found that certain details of the API haven’t exactly been normalized across service providers. Attempting to retrieve a profile URL for a user record on Orkut returned the following:
/Profile.aspx?uid=xxxxxx
Grabbing the same data on Hi5 returned a fully qualified URL:
http://sandbox.hi5.com/friend/profile/displayProfile.do?userid=xxxxx
Clearly, this is a problem on Orkut’s part, but keep this in mind – this platform is far from stable.
Building Your First OpenSocial Widget
As mentioned before, OpenSocial widgets are really just Google Gadgets that add an extra API, which allows them to get some information from their container websites. So, to build an OpenSocial widget, we really need to start by building a Google Gadget. And Google Gadgets, at their simplest, are self-contained XML files. To give you the simplest example, here’s a “Hello World” Google Gadget I created, using the Google Gadget
Editor, an inline, JavaScript-powered editor:
The code for this widget is very, very simple:
-
<?xml version="1.0" encoding="UTF-8"?>
-
<Module>
-
<ModulePrefs title="Hello World" />
-
<Content type="html"><![CDATA[
-
<div>
-
<div style="text-align: center">
-
<img src="/url/to/logo.gif" /></div>
-
<div>Hello World!</div>
-
</div>
-
]]></Content>
-
</Module>
(Note: I omitted some miscellaneous style information to make this example easier to read.)
While the Google Gadgets API offers many features for widget creators (including dynamic, styled tab creation, drag and drop, localization, and more) as well as the ability to store information about widgets like their title, author and a link to a thumbnail image, at their core Google Gadgets are really as simple and self-contained as the example above.
Let’s take a look at my widget; sure, it’s fantastic, but it’s a bit static. What if we were to socialize the widget by making it say hello directly to the person viewing it. Wouldn’t that be something? Well, that’s the kind of stuff that OpenSocial can provide.
First, we’ll need to make the Google Gadget include the OpenSocial API. We do this with a simple XML declaration inside the ModulePrefs tag:
-
<ModulePrefs title="Hello World">
-
<Require feature="opensocial-0.5"/>
-
</ModulePrefs>
Next we replace “Hello World!” in our application with “Hello ,” using the DIV as a placeholder that will eventually be populated by our call to the OpenSocial API. Finally, we add in the necessary JavaScript:
-
// sets getData() as the function that automatically gets called when the gadget is loaded
-
_IG_RegisterOnloadHandler(getData);
-
-
function getData() {
-
// Creates an OpenSocial request object.
-
var req = opensocial.newDataRequest();
-
// Adds a new request to this object - let's get information about the person viewing
-
// and store it mapped to the "viewer" attribute in the response object
-
req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
-
-
// Let's send the request to the container website, which will load the "onLoadFriends"
-
// function when data is available
-
req.send(loadViewer);
-
}
-
-
function loadViewer(response) {
-
var viewer = response.get('viewer').getData();
-
var vn = document.getElementById("viewer-name");
-
vn.innerHTML = viewer.getDisplayName();
-
}
The code should be pretty easy to read. First, we initiate a callback function through the use of Google's _IG_RegisterOnloadHandler function; this function automatically runs and causes its function argument to run when the gadget is finished loading. The getData() function then instantiates a new request object to the OpenSocial API, adds a request for information about the viewer, and then sets up the loadViewer() callback, which is run automatically when information returns from the API. This information is then parsed for the viewer attribute (which was set in the req.add() method), and the viewer's display name is inserted into the contents of the viewer-name placeholder DIV.
Limitations of OpenSocial
While the “Hello World” example above should give you an idea of how to build a social gadget, it wasn’t my first choice for a widget. Around our office, while brainstorming ideas for this article, and still somewhat confused about OpenSocial’s exact capabilities, we conceived of a different type of widget. We wanted one that, when placed on someone’s profile page, was able to learn and store that it was placed on a
particular social network. That’s not that compelling – obviously an instance of a social gadget on a profile page is able to tell what container website it’s on, whether through the API itself or even inspecting variables like the profile URLs available. However, in addition to this, we wanted every instance of this widget for a particular user, spread across multiple social networks, to be able to share this data. This would create a “My Social Networks” widget, which would list all of a user’s profiles around the web, without the user ever having to modify the widget or tell the widget that they had an account on Flickr, MySpace, Hi5, etc…
On each website, the user would add the “My Social Network” widget, which would then communicate with every other instance of the widget spread across multiple social networks. We had hoped that OpenSocial, in addition to specifying common hooks for widgets to interact socially within a container website, would focus on people with multiple profiles, across multiple websites.
Unfortunately, OpenSocial doesn’t do this. Each instance of a widget on a container website knows only about the profile to which its linked, and that profile’s friends. My profile on LinkedIn and my profile on MySpace are too completely separate profiles, and OpenSocial provides no ability for widgets to actually understand that these profiles belong to the same person. We had hoped that it would. Yes, OpenSocial allows the developers of the ESPN Scoreboard widget to build them once for Orkut.com and once for MySpace.com, and still hook into each site’s social functionality, but that is the extent of its benefits.
Conclusions
When Google first announced its OpenSocial initiative, about the only thing anyone really knew about it was the type of reactions it would provoke. Yes, we would see the initial outpouring of support; the hyperbole over Google’s massive foray into the social space; its shot against the Facebook ship. Almost as predictable as the praise was the
condemnation: OpenSocial was not that impressive, not that interesting, and really not even worth talking about.
But as always, the truth is much less polarized, and quite a bit more mundane. Actually, OpenSocial is pretty interesting, and does showcase a new, standardized
approach toward building social-website-aware widgets. In a world where every social network joins the OpenSocial initiative, web developers will have to do less work, and be able to support more customers than before. Furthermore, OpenSocial helps Google reassert its presence in the widget space which, honestly I must admit, I’d completely forgotten about. Checking out the OpenSocial API has reminded me of their mature, pretty full-featured Google Gadget offering.
Of course, it’s not perfect. These widgets are really only “social” within their container website; this isn’t an inter-site communication API. Also, while Orkut appears to support different views for its various applications (like Facebook does), this is a decision each social network must make for itself; there’s nothing built into the OpenSocial API to really support or encourage innovations like the Facebook canvas view, which is too bad: our Lemonade Facebook application is fun and informative in widget view, but it really shines when you bring in Facebook platform-specific code, like the ability to invite other users to the application, or the ability to show large-format information in a separate canvas view. Yes, some websites will support these types of
views, but unless they’re built into the API, and the API itself is built in such a way that all of its functionality must be enabled on each container website, developers are still stuck writing website-specific code.
I think these are valid criticisms, but I don’t want to let them overshadow the entire initiative; it’s easy to get hung up on what OpenSocial doesn’t do, and miss out on what it it does. No, you won’t be able to stop writing Facebook-specific widgets yet, but the next widget you make will at least be able to say hello to you by name, on multiple
websites. While application underpinnings won’t become completely website-agnostic any time soon, developers will be able to write less code. So take the time to explore OpenSocial, and voice concerns about its shortcomings; the more we do this, the more likely OpenSocial 2.0 will really be something to write home about.