Not Direct Integration But A Suite Of Open Source Products and Services
May 6, 2007
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.
- 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.
- 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.
- 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.
- 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 .
Integrating apps
I completely agree that more integration is required and that we need to better define what "integration" means.
I think that integration has at last six components:
Great List, Kevin
This is a really great list and helps clarify some of our own thinking on the matter.
Small correction
I meant to say that integration has at *least* six components, not "at last".