David Tosh wrote an insightful reply to my post on having opensource projects collaborate on development.

He states:
While I do agree with David that better communication between the various open source projects would be a really good thing; I just don’t see it working in practise. Well, not as direct collaborations.

1. The end users: open source projects often gain partisan followers; for good reason - if the software has served them well they want to stick by it. Many of them will not want to think about the possibility of using another application and would rather wait for their platform of choice to gain the functionality.
2. The business model: the large open source projects are usually trying to make money in some capacity from all the hard work put in, so why encourage their avid followers to use another piece of software? Competition still exists within open source.
3. The developers: there can be a fair bit of work involved in proper integration; in fact, in most cases it would be easier to just build a plugin for your own application that replicates the required functionality.
4. The future: direct integrations between similar apps will be a waste of effort if one or other of the applications changes their policy; license; or their very exsitance ceases.

I for the most part agree with Dave, except for point number one and part of two. I consider that zealotry and quite literally foolish. Are Drupal followers going to wait until the Drupal community develops a fully functional course management component that duplicates everything in Moodle?

I think where Dave and I may see things differently is that I think certain software packages like Drupal and Moodle or Moodle and ELGG, or all three for that matter as a potential software or service suite. I think Moodle, ELGG, Drupal and others can be combined into a powerful suite for customers. Simply having them exist and creating open APIs (which I agree are needed and critical) is simply not enough in my opinion. In 1990/1991 when Microsoft Office came out - at least as I recall - it was just a software bundle; there was no integration among the apps. You could cut and paste and open files among them to some extent via the OS API ;). In the mid 90s MS Office stopped being a loosely coupled bundle of productivity software and became a robust integrated software suite. Like it or hate it, people needed it. It worked and we bought it.

In education there is a need for:

• Course management tools
• Content management / website creator tools
• Social networking tools
• Portfolio tools

I think it is reasonable to assume that one framework or software package would have difficulty providing all of the above. It would also become a nightmare for ongoing development - it would be a beast. In fact a company deciding to build such a beast, would probably decide to split up the product into a pseudo standalone suite of tools - for ease of development if nothing else. Word, PowerPoint, Excel are all independent pieces of software with their own independent development teams. But the teams work together to ensure the suite works together and that certain code is shared among the apps.

This is what I am advocating.

Update: David Tosh has tried to work with some of the communities I have mentioned but apparently got responses 1 and 2 for his efforts. I'm not privy to the details or reasons for the rebuff. Maybe there were good reasons, maybe not. I really hope it is not endemic to these communities to refuse to work together in a more formal manner .

My company Donat Group is at the Moodle conference moodlemoot in Edmonton Alberta. An excellent conference for both experts and newbies to Moodle. We are here to present with our partner Lambda on our shared Moodle hosting service for BC post secondaries through BCcampus. I learned a ton at the conference and I am totally turned on to Moodle more than ever now, especially the networkming function in 1.8 and the new gradebook coming in 1.9.

On the business side, we have been talking to a many attendees about our Moodle - Drupal - ELGG architecture (we got a glimpse of Mahara and may look at that in place of ELGG). Everyone we talked to was familiar with the three technologies, but I was surprised when most did not know that Drupal could act as the Social Networking Hub for a learning community as well as a standard CMS "publishing" platform. This was a bit worrisome to me, as considerable work is being done for Moodle 2.0 (release: mid 2008) to create a social networking hub. This may make sense and be in fact the best solution, but it seems that no one has taken the time to see what Drupal can do in this area. One university I talked with had been using Drupal for over a year and had no idea there were social networking tools for Drupal. I pointed out just a few of the sites we have worked on (projectopus.com, gimme20.com, opportunityalert.ca), let alone the hundreds of other sites from dozens of other developers. He was literally shocked at what Drupal could do and he wasn't the only one. Conversely, I would suspect that Drupalers would be shocked at what Moodle could do. I know I was, and we have been using it for a few years!

And here lies the problem - there is very little "official" communication and collaboration between these open source software communities, especially around development. If Drupal or any other solution could provide the social networking layer for Moodle wouldn't it be advantageous to work on that integration layer rather than writing what is substantial new code from scratch? And vice versa, people have talked to me about adding mods to Drupal for course management. Maybe that is the best way to go for somethings who knows, but shouldn't they first look to Moodle for answers to course management? I really think these open source projects need to be coordinating their activities, or at the very least having a high level open dialog on where each project is going and what strategies they cold use to leverage one another.

To help facilitate that, I think these communities should "officially" (whatever that really means) get representatives to sit-in with the other communities coordinating and communicating development. There should be a Drupal rep at Moodlemoots and Moodlers at Drupalcon. The reps should be well known within their communities and have influence (or have extensive knowledge) in the overall strategy of development. I would even suggest that the leads of these projects personally meet once a year and become involved in on another's software to a certain extent. I am using Drupal and Moodle as only two examples, naturally others exist. But these two platforms are good examples as they have a great deal of synergy with one another and are better together than alone and poorly replicating features of the other. Maybe this is happening already, I don't know, but if it is the word is not getting down to the general development community and users.

I am writing this post to ensure that we take the appropriate steps to do what we say we will do.

Donat Group has gotten some flack in the past for not contributing source back to the Drupal community. Since a number of our projects rely on Drupal, it only makes sense (and it's the right thing to do) for us to contribute back to the code base we use. Although we have posted code, and responded to requests for code in the past, we have not known really "how to effectively participate" in the world of open source development. Fortunately, we are now getting some valued help in this regard from ace Drupal developers Lyal Avery and Trevor Freeman who among other things will help us get more of our code back into the Drupal community. Note, there is some interesting code that is owned by the people who hired us to develop it (not us). So, releasing some desired code may not be possible.

The default Movabletype theme (circa 2004) has run its course.

I am upgrading my look thanks to Donat Group designer Ross Howard-Jones, and I am switching to Drupal. The switch to Drupal is not a slag on Movabletype in anyway. We are just looking to standardize our company's internal and external blogs on one system, and considering our extensive experience and existing code base we went with Drupal.

The Drupal mod for converting from Movabletype to Drupal was antiquated, so James updated it and will be posting it back to the Drupal community shortly.

Update: Here's the link to the scripts we used to migrate from MT to Drupal.

So in the the next 24-48 hours you will see a "new me". You shouldn't need to re-subscribe to the RSS feed.