The future of OpenClinica and open source

Medical research environments are complex, an overlapping set of scientific, medical, ethical, organizational, and regulatory requirements. Most of the technology used in the space is not resuable/repurposable at all. The idea behind the OpenClinica project has always been to be an open, flexible, reusable core for data capture, provenance, and security that can be the basis of diverse clinical research applications. To eliminate continued reinvention of the wheel for these core capabilties, and to be a foundation for more innovative work.

In pursuit of these aims, OpenClinica going forward will have a smaller, more focused core, with pluggable modules that provide user-specific functionality. The modules will be built on a set of common components (such as dashboards & table widgets, a workflow engine, forms, & rules) that help create high-quality, tailored user experiences. A secure, REST API that's easy to consume will make it easy to interact with the core and have a reliable means for data in & out, with audit, provenance, security, and metadata. An accompanying developer's toolkit will make it easy to develop your own modules using primarily javascript, html, and java, with support for other languages planned for the future.

OpenClinica LLC will continue to develop and release the core code and the common components under open source licenses. Many of the modules we build or contribute to will also be open source, and I hope the same will be true of modules shared by others. We're also making sure there is good compatibility between OpenClinica 3.x and 4 so the path is gradual for the end user.

I'm committed to open source values because I believe it's the best model, long-term, in this domain to create a better mousetrap. We started the OpenClinica project to build a flexible, reusable, shared platform for clinical research. Using a well-known open source license (LGPL) created a basis for transparency and sharing, and helped attract a community. We started a business around it to drive continued development and to make sure a well-packaged, high-quality solution would be available for those who didn't want to fully go the DIY route. Over a decade into the effort, there are thousands of installations of OpenClinica. Extensions and documentation have been authored and shared by hundreds of community members. However, it's also true that 90%+ of the core source code is written by developers employed by OpenClinica LLC. From OpenClinica LLC's business perspective, having thousands of non-paying users helps spread awareness of OpenClinica, and it's great when some of those users become paying customers. But it's very expensive to develop and support this platform, and today it's the paying users who fund the engineers and domain experts that improve the core. External developer participation is what makes the open source project viable, and it's what we need more of to keep as much code as possible open.

In OpenClinica 4, how to build and load a module will be well-defined. Later this month we'll share more technical details about the work so far developing this modular architecture. Modules will build-able by anyone, for your own purpose or shared, open or closed, paid or free, hosted or local. I hope that as a community we can define creative business/sustainability/governance models that incentive us all in the best ways and enable this technology platform to do get better and better.

The plan and vision will evolve, driven by your participation. In true open source fashion, those who contribute most (time, resources, code, documentation, ideas) will have the greatest say. So, please, join the conversation about the future of OpenClinica!

Cal Collins
OpenClinica Project Co-founder and CEO, OpenClinica LLC
«13

Comments

  • toskriptoskrip Posts: 247 ✭✭
    edited April 2016
    Hi Cal,

    I totally understand all the things that you describe here and fundamentally all of these are valid points. The only thing that I want to warn about is the harsh deprecation of core EDC functionalities (that are currently part of the OC monolith) with new modules (where the user base do not exactly know whether, there will be additional consts necessary to use the module). You can argue that, the old functionality is still there and is not removed, but the reality is very simple - deprecated stuff will not be properly maintained.

    OpenSource software will have always more users than developers. Many of people who use OpenClinica today are involved in academic trials and they are not making any profit out of it. For those migrating to enterprise version will simply mean that they need to fund the budget for it from external sources (research grands) which are however not sustainable (because the will take you only over certain time period). The majority of community users are looking for EDC that will provide all the core main functionalities. And the extras (ePRO, randomisation, ...), well yeah these are not critical for basics to work.

    Lets take the example with the monitoring. If you deprecate monitoring features in OC monolith and release a new module for enterprise customers only (even if the APIs and all the application logic will be still part of OC core and available for community) the following will happen. The old monitoring feature in OC core will not get any more attention from your developers so it will slowly but surely start breaking apart, that is the fact. The users will by practically forced to go for enterprise or wait until the community group of developers will establish to prepare appropriate open module (and this will need time, because such need was not revealed to the community at the first place).

    I am not asking to reveal a full business plans. But if you want to have external developers working on open modules there should be at least some basic plan regarding which modules OpenClinica LLC will give to community, and which once are planned for enterprise. Nobody really wants to have duplications in core modules, what good it will bring? I don't think that in this field there is not enough developers to keep duplicated core modules alive.

    I would also be a bit careful with plans like, lets have hundreds of community modules, mixing, overriding their functionalities. This would be **** for deployment, I see new community user testing every available community module to get all the core features just to have a workable system. There is no place for flexibility in core EDC modules. They need to be there, they need to work. User needs to know what he gets as minimum when he install the core.

    BTW I am really interested how will the REST API of OC core evolve. Currently it is a bit of mish-mash with different authentication methods all over the place. Regarding the plans with OC UI with dashboards, widgets... well, those components are helpful for your own modules development, some developers may find them also helpful but personally I think that majority of developers would want to pick they own technology stack so widgets binded to certain platforms and languages would not be their cup of tea. Application developers need well defined and maintained APIs not widgets and also widgets should not be used to hide API inconsistencies (they should be not used as facades).

    Of course all of what I have described are just my own opinions, but my primary point is still valid... community needs to know what features they can expect for free and what features are enterprise.

    best

    Tomas
  • kristiakkristiak Posts: 1,243 ✭✭✭
    So true Tomas! :)
  • juan.debonisjuan.debonis Posts: 35
    Hi Cal,

    I'll have to think clearear first, in order to avoid missundertandings (also expressing it correctly in english, not my native language).

    To help on understandig my opinion, we use OpenClinica for commercial (traditional big pharmas) purposes on studies that do not have the budgets of clinical trials: local observational studies mostly. We have made some little contacts about Enterprise edition but we could not get any further (mostly because of Budget issues). In return, as our clients would not pay much more for these studies, we make our efforts spread the use of OpenClinica in commercial enviromnents (and other opensource tools also, as we use R for statistical analisis, and epidemiological registries): as you know big pharma is not the place to be popular on opensource.
    I think it's a valid strategy by OpenClinica, but I agree all about what Tomas said (It really seems he has good points and clear understanding on the matter). Also read, in other thread, about the experience on testing Participate by universities to then realize that the feature would be only available on Enterprise edition (just taking the comment, do not know about the details).

    As I said, I agree with Tomas, but just wanted to support the most important part, for me, of his statement: we need to know clearly the plans on this new strategy. We may have to understand your decision, but as active participants (as users, extra "technical supporters" by forum, and "spreaders" of OpenClinica) we must know wich parts/modules/features we can implement with our customers or collegues in the future, and if possible, some knowledge on pricing. This will help not failing to our customers and not failing to OpenClinica: in our case, selling features that will not be able to use without paying extra (in our case, we just need basic features, including monitoring, not e.g. randomization).

    Hope to be clear (besides my english, automatic spell checks, spanish mode, did not help). Thank you again for all your efforts and giving the opportunities for small scale studies (tha would not be posible without you and the OpenClinica community) Regards, Juan.
  • lindsay.stevenslindsay.stevens Posts: 401 ✭✭✭
    via Email
    "However, it's also true that 90%+ of the core source code is written by
    developers employed by OpenClinica LLC"

    This has come up many times before. Maybe you don't see it, but from an
    external perspective, OpenClinica LLC has chosen to:

    - Exclude external developers from the test / CI workflow, thereby
    preventing substantial or reliable code contributions,

    - Ignore many external contributions that are received: see numerous open
    and/or unanswered Github PRs open since as far as 2014, (only OC devs get
    merged regularly),

    - Ignore "old" software defects that remain in the code (the mass ticket
    cull that happened a year or so back),

    - Exclude any external contributors from meaningful project management
    roles (and nary a Jira vote counted).

    To put it another way: How are developers supposed to give you free,
    quality code if we can't develop it properly in the first place, there's
    little chance it'll be accepted, it might catch some old bug, and we have
    no real say in the direction of the project?

    These choices form a massive barrier to return on investment for LGPL'ing
    the code. It is not too late to change them and their resolution does not
    conflict with the proposed future of open core / proprietary modules.
  • richard.brookesrichard.brookes Posts: 54
    I agree 100% with the comments by Lindsay and Tomas. There is a real US and THEM feel to the project.

    I would happily contribute development resources if the issues raised would be addressed. I'm sure many others would too.

    Richard

  • ccollinsccollins Posts: 364 admin
    Thanks all for the supportive comments & suggestions. It's great that we all want to make the OpenClinica project work better.

    Lindsay - your points are all valid observations. I'm going to explain some of the reasons why things have gone this way - not to defend or justify, just to help us think about how to do better, and change that 'US and THEM' feel to the project:

    First, the tests - this is a hard one. You're correct that not having something (automated tests, a more open process, etc) available hamstrings external development. On the other hand, we can't currently open source the whole thing - it costs a tremendous amount to build & maintain, and many paying customers look to OC Enterprise for the validation support, the foundation of which is our existing test regime. If we gave this away, OpenClinica LLC would have to shrink considerably & development would slow. Plus doing a quality system in an FDA-compliant manner is hard even in a small group, never mind a widely distributed open community. Last month I instructed our Quality Engineering team to explore ways to segment our existing tests so that some of it at least could be made open. I hope we will have good things to announce soon. If you have other creative ideas please share them.

    Pull requests - we need to do better here, and be far more timely. It's also true some of the requests that have languished are ones where we don't fully understand the requests or don't hear back from developers when we ask questions or make suggestions.

    Ticket "cull" - The project was drowning in a sea of unmanageable tickets. It shouldn't have gotten to that point but it did, and something had to be done. A backlog of 1000+ items, with many duplicates and low quality reports, wasn't helping anyone. Doing this has been helped us fix more old bugs. We should have provided more forewarning about it. My aim is to be much more proactive with new requests now, and to reopen & resolve the issues that are commented on as still important.

    "Votes" & collaborative governance - if we can solve the above problems and enable more distributed participation, that should make it easier to get more done & share more of the decision-making.

    Where to go from here? Let's keep this thread going, but also talk. Would anyone be able to join a Google Hangout next week?
  • kristiakkristiak Posts: 1,243 ✭✭✭
    via Email
    Thanks Cal for the clarifications, it makes it much clearer to me. In a world of limited research grants we who supports universities and hospital research struggle to keep the nose above the water and OpenClinica is our life jacket. Hope it will continue to keep us floating.

    Best

    Krister
  • richard.brookesrichard.brookes Posts: 54
    Great first step with the hangout, I'll be there.
  • toskriptoskrip Posts: 247 ✭✭
    I would also like to join hangout... the best would be to make doodle for this to find out a date that fits the most for everybody who wants to join.

    T
  • ccollinsccollins Posts: 364 admin
    via Email
    Great idea, here's a doodle poll with some possible times for next week:

    http://doodle.com/poll/2ddnme7ds2qz6e98
Sign In or Register to comment.