Here are the slides from my WordCamp Europe 2013 presentation, on the subject of using the BuddyPress activity component for neat purposes: http://hardg.com/presentations/wordcamp-europe-2013/bp-activity/
This weekend at BuddyCamp Miami (which ruled btw) I chatted with a number of folks about putting GPL clauses into client contracts. It can be especially challenging when working with universities or other bureaucracies that have hardcore, work-for-hire-ish intellectual property clauses already built into their consultant contract boilerplate. On a number of occasions, my clients and I have worked with the legal departments at universities to develop new language that fits the spirit and law of GPL software. In my opinion, this kind of work is among the most important work I’ve done since I started in this business, even more important than most of the software I’ve written. By having the discussions with legal, and by getting free-software-friendly boilerplate on their books, we take steps toward legitimatizing free software in the university, and making it part of the culture.
Anyway, I was asked privately to share some of this contract language, and I figured it would be more useful to do it in a blog post than in an email. So here are a few examples that have been approved by the legal departments at large universities. (Side note: We should come up with a system for sharing these kinds of strategy docs in a more organized way.)
This clause replaced one university’s extremely restrictive IP boilerplate:
Foundation acknowledges and agrees that enhancements, bug fixes and other custom developments produced under the scope of this agreement will be subject to release under the GNU Public License v2, or another compatible and relevant open-source license.
The following clause is added as a footnote to the existing language about IP:
Section VIII (1-3) shall not apply when work is being performed in the public domain. Consultant agrees to comply with the GNU General Public License version 2, as set out in the Attachment #2, when work is being performed in the public domain.
A few notes about the language in this second example (which their lawyers wrote, not me). First, “Attachment #2″ is a copy of the GPLv2. Second, I think there is a little bit of confusion here about “public domain”, because strictly speaking, “public domain” means that no one owns the copyright, while the GPL is dependent on copyright. I think the spirit of the phrase “performed in the public domain” is supposed to be something like “written for public consumption”. But a literal reading of this clause probably means that I must relinquish copyright over the work done under this contract into the public domain. In this specific case, the end goal is for me to extend one of my existing GPL-licensed WordPress plugins; so I will then be integrating this newly-created public-domain code into the plugin, and then distributing the whole thing under the GPL, with a note that the newly added library is in the public domain. This is not ideal, but it’s OK for this case where I’m building a standalone add-on for my own work – good enough not to continue negotiations :)
If I can dig up others, I’ll post them here. If you have real-life examples, please share in the comments.
This week, Google announced that it’s shutting down Reader. This is the first of Google’s “sunsets” that hits me personally – Reader has been a crucial part of my internet use for the better part of a decade. I happen to think, like Marco Arment, that in the long run the loss of Google Reader will probably be good for innovation in RSS readers and for RSS in general. Google’s hamstrung app has been just good enough for people like me, but non-approachable for non-geeks. A year from now, I’m hoping that there’ll be many more quality players. So, in the long run, I’m reasonably optimistic.
More immediately, though, a couple of causes for concern:
Finding an alternative to Reader. My RSS reading habits are too ingrained for me to abandon them, even for a short time. More than that: following RSS feeds is beyond mere habit, but is check on my intellectual honesty. I follow many blogs whose authors I frequently disagree with, or even dislike. (Contrast this with Twitter, where I’m pretty fickle about whom I follow, and how many tweets/links I pay attention to.) So RSS is, for me, a partial antidote to the echo chamber tendency. That means that I’ve got to find a new app, and migrate over, and I’ve got to do it quickly.
There have been a number of posts over the last couple days listing Reader alternatives. A number of them are cloud/service based, and for practical reasons (such as, um, Google Reader) as well as philosophical reasons (see below), I’m only considering alternative tools that I can run either locally or on my own server. A couple that spring to mind:
- Fever. I’m interested in this one because (a) the screenshots make it look nice, and (b) it comes highly recommended by people I respect, like D’Arcy Norman. I like that it’s self-hosted. I don’t like the fact that its sustainability model is to charge for downloads. It’s not that I don’t think the author shouldn’t be paid – I would be happy to pay $30 or $300 for a great RSS reader app. It’s that the success of the single-developer model is contingent on the willingness of that developer to keep working on the project (paid or otherwise). I’m far more comfortable with software that is community developed under a free license, ideally using a set of technologies that would allow me to modify or even adopt the project if the main devs were to abandon it.
- Tiny Tiny RSS. tt-rss also comes recommended by someone I respect (Mika Epstein, in this case). And it’s community-developed, which I like. It doesn’t look as pretty as Fever, but aesthetics are about fourth or fifth on my list of requirements.
- PressForward. As Aram describes, the PF team (of which I’m pleased to be a member) is working on a WordPress-based tool that, among other things, does RSS aggregation and provides some feed-reading capabilities. PressForward is really designed for a different kind of use case – where groups of editors work together to pare down large amounts of feed data into smaller publications – but it could be finagled to be a simple feed reader. Mobile support is a particular pain point, as 50% or more of my RSS intake is done on my phone, and PF has nothing in place to make this possible at the present time. So, PressForward may not be quite ready for primetime, but I do think that it has promise.
Get the hell off of Google. We all know that Google is a company with shareholders and profit goals to meet. Yet we often act like Google is some sort of ambient benevolent force on the web. Since I started Project Reclaim, I’ve been working on extricating myself and my data from the clutches of Google (among other corporate entities). Reader’s demise is a wake-up call that the time for dilly-dallying is over.
For my own part, I still use a few Google services besides Reader:
- Gmail. I don’t use Gmail primarily anymore, though many people do still email me at my gmail.com address, so obviously I have it open and I check it frequently.
- Picasa. I use the Picasa desktop app on OSX to export photos from my cameras and organize/tag them. I also use Picasa Web Albums as one of my many photo backup services. (Seriously – I back up my photos to no fewer than six different local and cloud services. Nothing is more important or irreplaceable than my family photos.)
- Drive/Docs. Aside from the occasional one-off collaborations, I use Drive to maintain a number of spreadsheets and other documents that I share with members of my family, etc.
- Calendar. I’m not a heavy calendar user, but when I do use a calendar, I like Google because of its integration with my Android phone.
- Chromium. Not Chrome, but still largely Google-reliant, Chromium is not my main browser, but I use it daily for doing various sorts of development testing.
- Android. This is maybe the one that steams me the most, because at the moment there are no truly free alternatives. (Firefox OS, please hurry up.)
In some of these cases, there are easy ways to get off of the Google services. In others, it’ll be a challenge to find alternatives that provide the same functionality. In any case, the Reader slaughter is a harsh reminder that Project Reclaim has stagnated too long with respect to Google services.
More than myself, I’m worried about others – those who aren’t as technically inclined as I am, or those who simply don’t care as much as I do. Google’s made it pretty clear (as is their right, I guess) that they’re not an ambient benevolence. Those who rely on Google then, especially for critical services like email, should take this warning very seriously. Please consider carefully what you’re doing when you make yourself wholly dependent on the whim’s of Google’s product managers, and consider options that are either free-as-in-speech, or services that you pay for in a traditional way.
I’ve just released version 1.3 of BuddyPress Docs, my WordPress plugin that powers collaborative document editing on a BuddyPress site. The main feature of Docs 1.3 is theme compatibility, which means that top-level Docs templates (archives, single docs, and the Create screen) are no longer necessarily top-level. Using the theme compat feature of BuddyPress 1.7 (currently in beta), this top-level content is put directly into the content area of your theme’s
page.php template, ensuring that Docs pages will keep your header, footer, sidebar, and other global elements.
The theme compatibility feature only kicks in if you’re running BP 1.7. Existing installations of Docs on BP < 1.7 will continue to work as before.
Are you a BP Docs user? Are you already testing BuddyPress 1.7? I'd be glad to get your feedback on Docs 1.3. Report any problems on the issue tracker.
Anthologize 0.7 is here. Get it while the gettin’s good!
Version 0.7 includes a number of important, under-the-hood improvements. Some highlights:
- The way Anthologize loads itself has been largely rewritten, which means that it fires up more reliably – and using fewer resources – than ever before.
- Some validation issues with epub exportsr have been cleared up
- In previous version of Anthologize, PDF exports sometimes failed because Anthologize could not copy inline images to the necessary temporary directory. This process has been rewritten so that our PDF library uses WordPress’s standard upload locations, avoiding permissions errors
- A Spanish translation is now available
- Full compatibility with PHP 5.4 and WordPress 3.5
In addition, a Credits page has been added to the Anthologize menu. This new page includes shout-outs to all those supporters of my fundraising campaign. If you donated (and opted not to remain anonymous), check out the Credits page to see your name in lights! And if I’ve made a spelling error, or linked to the wrong URL, please let me know.
This round of development was brought to you by Cyri Jones. Cyri is an educator and technologist doing amazing things with WordPress and BuddyPress in lovely British Columbia, including his ZEN Portfolios platform for student portfolios, and private social networks for a number of local school districts. I’ve had the good fortune to do some work for Cyri’s projects, and I think that the work he’s doing with these free software platforms points toward a very interesting model for putting social learning technologies in the hands of those who can use them. Cyri was also the brains (and brawn) behind the very first BuddyCamp, held last October in Vancouver. Rock on, Cyri!
I use Github Issues as a bugtracker for a number of my projects. My workflow usually includes having the ticket open in one browser tab, and a local WordPress installation open in another browser tab (to test the bugfixes themselves). When I write commit messages, I want to reference the issue number, but by default, it’s buried deep in the
<title> element, and thus not visible on a smallish browser tab.
So I wrote a short userscript that reproduces the issue number at the beginning of the
<title>, so I can see it at a glance. It’s structured as a userscript for Greasemonkey/Firefox, though I imagine you could easily repackage it for Chrome or whatever.
// ==UserScript== // @name github issue number in tab // @namespace http://boone.gorg.es // @description github issue number in tab // @include https://github.com/*/*/issues/* // @version 1 // @grant none // ==/UserScript== var t, ttext, issueno; t = document.getElementsByTagName( 'title' ); ttext = t.innerHTML; ino = ttext.match(/Issue #([0-9]+)/); console.log("#" + ino + " " + ttext); t.innerHTML = "#" + ino + " " + ttext;
Today I’m going to spend down some of my PayPal slush fund by making donations to online causes that are important to me. I do this every year, usually on a day in December (Christmas! Last chance for tax breaks! etc). Doing it in a single day makes it fun, like an event. Here’s a partial list of where I’ll be sending moolah today:
- The Wikimedia Foundation – the fine folks who bring you the advertising-free Wikipedia
- Free Software Foundation – Maintainers of GNU and the GPL, champions of free software
- Electronic Frontier Foundation – Advocates for free speech and other kinds of freedom online
- Hack Education – Audrey Watters’s excellent, ad-free, independent blog on the world of ed tech
- Thirteen – My local PBS station
- Creative Commons – The maintainers of progressive licenses for creative content
You don’t have to give to these specific causes (though you should – they are awesome!), but you should get out there and support some of the causes that you believe in. Even a couple bucks can be meaningful. ‘Tis the season!
The Anthologize fun has begun!
A few months ago, I held a successful Kickstarter campaign to support some development on Anthologize. In the past week or so, I’ve started work in earnest. This first round of development has consisted of a number of unglamorous but important cleanup tasks. A rundown of what’s been done so far:
- Improvements to the way that TCPDF stores its cache files, to avoid permissions errors that can mess up PDF export
- Improvements to the way tags and categories appear in HTML export mode
- Improved compliance with WordPress coding standards
- Rewritten plugin initialization, for better stability across various setups and decreased memory footprint
- Localization improvements
- Better compatibility with PHP 5.4+
This round of development was brought to you by Siobhan McKeown, an early and enthusiastic supporter of my Anthologize campaign. Siobhan is the proprietress of Words for WP, a delightful consultancy focused on writing documentation, publicity, UX, and other copy for WordPress-based businesses. She’s the best at what she does, and rumor has it that she also has a very famous musician for a cousin. Thanks, Siobhan!
It’s been a long time coming, but it’s here: Commons In A Box. Today we’re releasing version 1.0-beta1, the first public release. For some background on Commons In A Box, here’s today’s press release, my Commons Dev Blog post explaining some of the features of Commons In A Box, and the 2011 press release announcing the project.
The primary goal of Commons In A Box, in my view, is to reduce the barrier of entry to setting up BuddyPress community sites. BuddyPress is an extremely powerful and flexible platform for developing social WordPress sites, but getting a BP site right takes knowledge (which plugins are worth installing, which ones work best together, etc) and elbow-grease (customizing your theme, keeping a complex system up to date). These practical requirements have made BuddyPress seem imposing to many users – including, and perhaps especially, the users that need free community software the most, such as educational institutions. Commons In A Box lowers these barriers in a serious way, by helping with plugin selection and installation, and by providing a beautiful and flexible default theme. My hope is that Commons In A Box will serve as a gateway for a swath of potential users into the world of BuddyPress, WordPress, and free software more generally.
The process of pitching, planning, and producing Commons In A Box has been interesting, frustrating, and rewarding. In the upcoming weeks and months, I may write more about this process, and what I’ll personally take away from it. In the meantime, I’ll say that I’m very pleased to be ending this first stage of development, and pushing it into the wild, since software – even imperfect software – is infinitely more valuable when it’s out there, being used, than when it’s mouldering on a developer’s machine. Shipping FTW!