Thoughts on TYPO3

Last month, OSS Watch delivered a series of sessions on communication and participation with open source communities at the TYPO3 Developer Days event in Eindoven.

One of the sessions in our series looked at the theory of communities, the varieties of the communities we form and the motivations involved in each.  The core message of the session is that a FOSS community should be a community of interest, with the interest being the problem solved by the community’s outputs.  While many people in a FOSS community are developers, it’s wrong to view it as a community of practice, since other skills are required for a sustainable community.

What’s unusual about the TYPO3 community, is that while it is presented to the world as a single group, the brand actually encompasses 2 distinct groups. One group produces the TYPO3 CMS system, while the other produces the TYPO3 Flow framework and the TYPO3 Neos CMS.

The original development of Flow/Neos was funded by the TYPO3 Association as the “next generation” of the TYPO3 CMS. Indeed, it was originally called TYPO3 v5.  However, after the initial development of v5, TYPO3 v4 usage and development continued.  When it became clear that v4 wasn’t going away v5 became TYPO3 Neos, and the next version based on the v4 codebase became TYPO3 CMS v6.

The situation now stands that the TYPO3 brand is used by 2 distinct projects which have different development teams, different stated values and different cultures.  While the TYPO3.org website makes the history of the project and the branding guidelines clear, I feel that the TYPO3 community as a whole still has an issue to address.

The Sakai community (now part of the Apereo foundation) experienced a similar situation not long ago.  A sub-group of the Sakai 2 community decided it was time to produce a next-generation system, and called it Sakai 3.  However, it soon became clear that many  institutions funding Sakai didn’t agree with the goals of the Sakai 3 project, which created a rift in the community.

Several key partners withdrew their funding for Sakai 3 (which was rebranded Sakai Open Academic Environment, now called Apereo OAE) and continued to use and develop Sakai 2 (rebranded Sakai Collaboration and Learning Environment, now just Sakai).  The 2 projects now co-exist within the Apereo Foundation, a foundation created to foster software projects which support the goals of higher education.  While the projects have survived, the community suffered.

When a community moves from being a single-project to a multi-project community, as both Sakai/Apereo and TYPO3 have, it’s important that the resulting community identify what key commonality make them a single group.  A FOSS community should be a community of interest, and if projects are to share a community, they should have a shared interest.

Apereo has identified its shared interest in software that supports higher education, within which Sakai and Apereo OAE can now co-exist. With this identity, they’ve now taken on additional projects such as Matterhorn and uPortal, with an incubation programme foster new projects in the future.

If the TYPO3 community doesn’t identify the shared interest of TYPO3 CMS and Neos/Flow, they risk suffering further turbulences as Sakai’s community experienced several years ago.

Fortunately, the TYPO3 community are not blind to these issues. Members of the TYPO3 projects have formed a Community Working Group to look into the issues discussed here and steer the community towards a positive future.

It’s my hope that by learning from Apereo and similar multi-project communities, TYPO3 could become a successful umbrella organisation in its own right.

For more on the history of Sakai and the Apereo OAE, check out the “Sakai” tag in Michael Feldstien’s blog archives from 2010 onwards.

OpenStack Community Anthropology

OSS Watch’s legal officer Rowan Wilson was fortunate enough to see Joel Spolsky of StackExchange speak at Open World Forum about the Cultural Anthropology of StackOverflow.  I wasn’t able to attend, but there’s an longer version of the talk available on YouTube.

YouTube Preview Image

Joel presents some interesting points about how the design of a piece of software affects the way its users behave – this is crucial in this context as the software we’re talking about is a communication tool, so its design affects how a community communicates.

He describes the importance of first impressions

The first impression on StackOverflow is that, if you’re a programmer, you get that these are all programmer questions… If you’re not a programmer you don’t understand a single thing and you leave.

This seems like a hostile and exclusive approach to community management – usually when we talk about building open development communities we talk about being welcoming to ensure we’re not putting off potentially valuable contributions.   However, the goal of StackOverflow and similar StackExchange websites is to get expert answers to difficult questions – people who don’t understand the subject will only create noise, so putting them off from engaging early increases the site’s usefulness.

The talk is an hour long so I’ll leave you to watch the whole thing rather than picking it apart here, but it’s a really good overview of a very successful online support community, and discusses some ideas which might go against the conventional wisdom of community management.

OSS Watch Community Workshop for TYPO3

In November, Mark and I will be in Mannheim, Germany as part of the TYPO3 Marketing Sprint Week, where we’ll be facilitating an OSS Watch workshop focussed on communications in open source communities.

TYPO3 logo

Effective communication in all its aspects is crucial for a healthy open source community, and we’re excited to be able to pull all of these aspects together into a two-day workshop.

You can find out more about the TYPO3 Marketing Sprint Week on their website.

If you’re interested in organising a similar activity for your project or organisation, get in touch with us.

OSS Watch releases Open Source Options for Education

We’ve written several times recently about the UK Cabinet Office’s Open Source Procurement Toolkit, and the Open Source Options document that forms part of it.

The original document lists open source alternatives for common proprietary solutions that might be used in government and public sector organisations.  The types of software solutions listed are mostly generic packages such as operating systems and office productivity suites that would be of use to most organisations.  While it contains some software for specialist areas, the document is designed to be broad so doesn’t go into the detailed needs of each area.

With OSS Watch’s focus on open source within education, we’ve produced a document entitled Open Source Options for Education to complement the cabinet office’s which focuses solely on open source alternatives to proprietary solutions used in educational establishments.

Working with the educational community and with the communities around many of the featured projects, we have compiled a list covering various areas of administration and content production that are specific to education, as well as tools that may be used for teaching specific subjects.  Where possible, we’ve included real-world examples of their usage.

As the document has the same goals as the cabinet office’s, the guidance we wrote on making use of theirs applies here too.

While some of the tools we’ve included may be generic packages that are included as such in the cabinet office’s document, we’ve looked at them specifically in the context of their application to an educational situation, such as using an office package to author e-books.

OSS Watch would like to thank all of those who contributed to this first version of this document.  If you feel that you have a contribution to add, be it an open source alternative to a common piece of proprietary educational software, or an example of one of those pieces of software listed being used in an educational context, you can add your contribution on the publicly editable version of the document, or get in touch with us directly.

Six Reasons Funded Projects Are Set Up To Fail

Agencies run funding programmes with an expectation that many will not lead to sustainable innovations in the longer term. But is the structure of funded projects itself causing projects to fail?

Dr Cathy Gunn and Rhiannon Herrick have been investigating this issue, looking at 22 projects in Australasian higher education from the past five years, resulting in the Sustaining eLearning Innovations report published by ACODE.

Their conclusions are that, while “its unreasonable to expect every great idea to translate into a sustainable system”, that “institutional and national strategic intentions are not reflected in what is happening at practice level”.

In the study, of the 22 projects they looked at, 16 did not meet their criteria for sustainability:

This is largely due to continued  dependence on the initial innovator for support for everything from answering calls from users to sourcing additional funding for further development and maintenance

Sustainability of open source software developed by funded projects is also an issue we’re concerned with here at OSS Watch so I met up with Dr. Gunn at the ALT-C conference in Manchester, where she presented some of her findings.

In her talk, Dr. Gunn identifies six key problem areas for funded projects:

  1. Scoping
  2. Funding constraints
  3. Impact and influence
  4. Planning for the future
  5. Owning the innovation
  6. Skills for different stages

1. Scoping

According to Dr. Gunn:

Most projects are started by an individual with an idea and a passion to translate the concept into reality. Many began because there was ‘nothing available to meet their requirements’ but the scoping process used to reach this conclusion is not clear and there is no evidence that information gathered at this stage is used to inform the development.

[..] it appears that innovators have an idea about what they perceive to be an educational problem and exactly how it should be solved. If they cannot find something that solves their problem in their way, the conclusion is ‘there’s nothing like it’ and they go ahead and create it.

One of the common lines of defence for creating new software without any clear path to sustainability is that ‘nothing met the requirements’. This is something that I’ve heard a great deal when projects present their work and Dr. Gunn is right to point out that this is rarely backed by evidence that the project made a serious effort to find existing work to adapt or build upon.

At a project level I think this can be addressed in two ways. One is by conducting a serious effort to identify and work with existing software – for example, by identifying existing open source communities to engage with to add new capabilities. Another way is to shift the emphasis from development to active use, for example, to scope the project to fit the capabilities of existing software.

The fact remains however that quite a few of the individuals that engage in innovation are, by nature, passionate about and motivated by the idea of developing new systems. However, that passion needs in some cases to be diverted into improving the sustainability of existing software rather than “reinventing the wheel”.

The Sustaining eLearning Innovations report recommends that “Innovators and funding bodies use available evidence, or identify experts or colleagues who are able to assist with more accurate scoping of projects”. This would mean, for example, that funders should exercise more diligence in identifying whether projects were replicating other work, or planning to develop software that already existed, or could be modified to suit their requirements.

In all fairness, funding agencies do try to do this already using external reviewers; however it tends to rely on collective memory of previous projects and programmes rather than a search of existing solutions. Perhaps funders ought to consider such a search as an additional part of the review process, or include reviewers on panels whose remit is to perform a technology search?

The alternative is to rely on projects to perform such diligence at the proposal stage; this is something common in European funding regimes which require a “state of the art” and “beyond the state of the art” component in proposals. The problem lies then in the capacity of reviewers to sufficiently critique the scoping.

2. Funding constraints

Dr. Gunn raised the issue of funding periods; asserting that:

Broad consensus is that project funding for two or three years is sufficient to produce a full working prototype, but not a finished product that is disseminated and sustainable. Externally set parameters like timeframe and budget don’t necessarily serve innovations well. It’s often hard to anticipate what will be achieved within a 2 or 3 year period.

This is a continuing issue for funding agencies. In some cases, programmes provide second-round funding. In the UK, JISC created a series of “Benefits Realisation” grants that were aimed at supporting sustainability activity – such as packaging project outputs and providing training materials. However, in most cases, and especially for larger projects, the structure is such that all funded activity, including sustainability work, has to be conducted within the project timeframe.

This means that projects need to focus on tackling sustainability as early as possible – from pre-proposal stage onwards – rather than tacked on at the end, naively assuming that the design and implementation work will complete on time leaving some time at the end to figure out the end game.

This is why at OSS Watch, we’re keen to engage with projects early on in the process, so that sustainability activities can be planned and executed earlier in the project timeframe.

An alternative model also applied at JISC has been to do much smaller “rapid innovation” projects – for example six month projects with relatively small amounts of funding. This can operate as an “incubator” for identifying potential concepts worth a second funding round, or for further development by the originating institution using their own resources. Paradoxically, the answer for having too few resources allocated to dissemination and sustainability may be to cut funding for it altogether, at least in the initial development stage.

The opposite approach has been to create slow-burn projects that are funded over a longer timeframe – four or five years. The risk here though is that, while there is sufficient time to develop a sustainable product, its hard to predict whether its going to be worth it as so much can change during the project lifetime.

In general, what I’ve observed is that projects and institutions favour larger projects as it makes resource planning easier, while funding agencies often see better results from shorter, smaller projects, but this requires more support, coordination, and – critically – follow up activity.

3. Impact and influence

It may seem surprising given how much emphasis is placed on “impact” these days to find that projects are failing to communicate the benefits of their work; however Dr. Gunn points out that the evidence of benefits that projects provide may be “not in a form that influences players, such as IT departments and those making management level decisions about use of a product within an institution”.

This mismatch between the perspectives of innovators and decision makers has been a major topic in business generally, but is acutely felt in higher education. There have been some interesting initiatives by funders to address this issue – for example some JISC programmes have included specific benefits realisation activities aimed at developing a more coherent message about benefits for potential adopters of the innovation. Others have used taken a user-focussed approach (e.g. the Users and Innovation programme) with a model that encouraged projects to communicate in a less project-centric fashion. I’m not aware however of any analysis of the success of these approaches; anecdotally (being involved in some projects in these programmes) it did seem to have an effect.

4. Planning for the future

Many funded projects do not have a clear roadmap for future development, support, dissemination or sustainability. Dr. Gunn noted that “The main focus of projects is on design, development, implementation and impact evaluation. A different set of skills is required for dissemination, support and ensuring sustainability.” Also, even where both sets of skills are present in a project team or consortium, there can be issues with communications between the groups.

From my own experience, even where programmes require the development of an exploitation plan including sustainability, this is sometimes either done in a very half-hearted way, or is wildly optimistic about the impact that can be achieved with the resources and effort applied.

For example, I still routinely see proposals for making successful open source software that begin with selecting a license, and end with dumping the code on SourceForge hoping a community will magically appear.

Developing realistic and effective strategies for open source community engagement is something OSS Watch has a lot of expertise in, so I’d recommend reading the articles on our site if you’re responsible for such a plan, or to get in touch with us.

5. Owning the innovation

Dr. Gunn puts this very succinctly:

Universities often fund development and are seen by the innovators to ‘own’ the products, but this ownership typically does not translate into meaningful actions to sustain them.

This is something I’ve also heard described as the “Fred in Shed” model – that innovation projects are started in institutions at a safe remove from core services, metaphorically in the shed at the end of the garden. However there is often either no process for moving the innovation into the centre, or for investing in innovations that come from within the host institution. Some are certainly better than others – for example, the Rogō project that was the subject of an earlier post was adopted by central services using its own procurement process – effectively treating the internal project in the same way as an external supplier bidding for the solution being adopted.

In some cases however there seems to be an inversion of “Not invented here”; or as Dr. Gunn puts it:

The bottom line is that innovators and their work are not valued as highly as they should be by colleagues and employers.

Even worse, the host institution is often seen as a barrier, rather than a potential owner:

Around half of the case studies reported deliberate moves to subvert IT Services controls, which they believe would have killed their ideas in the early stages.

Part of the answer may be to try to meet half-way – for central services to smooth the path for innovators and projects so they don’t try to subvert the controls they need to put in place, and for innovators to take the time to understand the concerns of central service departments and work with them rather than against them. At least then there is potential route from innovation to service.

However, the larger strategic issue is whether higher education institutions are willing and able to invest in developing innovation beyond externally-funded projects.

6. Skills for different stages

As also noted under “Planning for the future”, the skills needed for design and implementation aren’t the same as those needed for dissemination, sustainability and community building and as Dr. Gunn notes, its unrealistic to expect the innovator and development team to provide them all.

What can projects do?

Many of the proposals in the report are aimed at funding agencies rather than projects, however there are clearly actions that can be taken by projects at the proposal and pre-proposal stage to mitigate some of these problems.

In the UK, projects can engage early on with innovation support services such as OSS Watch, CETIS and UKOLN to help with the scoping phase;  identifying how their proposal can have a better chance of sustainability by building on earlier work, participating in existing open source communities, or adopting existing standards.

Projects can also talk to the potential owners of the innovation in their institution much earlier – for example, meeting with colleagues in the service departments of their institution before proposals are fully developed to explore whether, if successful, the innovation could be adopted and further developed locally as part of the services portfolio. This may provide proposers with more realistic constraints to work with – for example, to only build on platforms that can be locally deployed and supported. This is something that has always been a bit of a problem for innovators – and a reason why as the report notes projects often circumvent central services – but I think if projects want to have a serious shot at success then they need to think of ways they can work with rather than against their local service units. It may make sense to develop prototypes outside of local constraints – but if done without any understanding of the local services context it can be a missed opportunity for getting in-house support and investment later on.

Project teams can also be more diverse, and include colleagues or partners with skills in sustainability, community building and dissemination. However, they need to be engaged from the start, not brought in at the end of the project.

In conclusion, I think anyone who has worked on funded projects will recognise the problems that Dr. Gunn has pointed out in her work; however I think given the more challenging funding climate its time we all took them much more seriously.

You can download the Sustaining eLearning Innovations report from the ACODE website (PDF, 24 pages). If you’re developing a proposal and are based in a UK college or university, you can contact OSS Watch for advice by emailing info@oss-watch.ac.uk.

Moodle – a homogenous community of users and developers?

When discussing the tools used by open source communities, a conversation inevitably arises about mailing lists and forums.  The received wisdom suggests that the more technical members of the community (often, the developers) prefer mailing lists, while the less technical members (often, the users) prefer forums.

I see this distinction as much like the distinction between the command line and the GUI; Some users know exactly what they want to do, how to do it, and don’t want an interface getting in the way.  Others need to explore, find out what options are available to them, and decide what to do.  In The Art of Community, Jono Bacon notes that forums have a much lower barrier to entry than a mailing list. As a result forums may have a larger proportion of users with less experience of the etiquette of online discussions, which may in itself put more experienced or more technical community members off.

While its important to do your best to give your community members an environment they’re comfortable with, segregating your users and your developers in this way can be detrimental. Users may be excluded from discussions relating to the ongoing development of the software, and feel disenfranchised.  Developers may miss out on valuable feedback from users, and find it difficult to get developments tested in real-world situations.

Moodle’s community works a little differently to this often-assumed model.  The majority of Moodle discussions take place on the community forums on moodle.org, involving the core developers, third-party developers, Moodle system administrators and teachers.  Discussions are categorised into a whole collection of discussion boards, but nothing’s hidden – a teacher is quite welcome to browse and post in the General Development forum, just as a core developer is welcome to ask questions on the teaching forums.  The quarterly general developer meetings are open to all, regardless of technical knowledge.

Beyond the virtual, this homogeneity happens in real life too.  From local user groups to national conferences, developers and users come together to share experiences and ideas.

Does the Moodle community have special characteristics that promote this merging of often separate parts of the community?  There are a few things that stand out to me:

  1. Moodle is a self-hosting project.  That is to say, moodle.org runs on an instance of Moodle, so the community use the tools that Moodle comes with.  While Moodle has a forum module, it doesn’t have a mailing list module, so the default position is to have everyone use the forums.
  2. A lot of institutions that use Moodle employ staff to administer and/or develop it.  This means that users have some exposure to the more technical members of the community within their own institution, putting a human face on them and giving users a better idea of what to expect from such members in the wider community.
  3. Moodle is written in PHP, which makes the barrier for entry as a developer fairly low.  I’ve known of teachers who’ve taught themselves a bit of PHP getting involved with Moodle development, and countless novice programmers who start their programming journey hacking Moodle for their institution.  These developers tend to be welcomed with a reasonable amount of patience.

There are, of course, situations where this merging isn’t as relevant.  Some discussions will only be relevant to the more technically minded members, some only to the more pedagogical members, and so on.  The forum model allows this to work since you don’t need to see the contents of a discussion thread you’re not interested in.  The Moodle core committers also have a chat room for synchronous technical discussions and regular meetings, which would be of limited interest to end users.

This example shows that the received wisdom of a divide between how users and developers communicate can be overcome.  By enabling all members of your community to engage as equals, you ensure that everyone feels involved and enfranchised, which in turn helps foster adoption of your software.