Forking and committing - OSS in informatics
I'm always amazed by the plethora and quality of software released by the biomedical informatics community. I personally have benefited from great projects like i2b2 and cTAKES amongst many others, and know of a ton of others that are available for use.
While not to question or point out any particular project, there are examples where there is an existing system that does something quite well, and another organization either funds or gets funding to build another similar system. It's true that in many cases this can bring about a new innovation or new direction in solving a problem, but one also has to question the amount of resource that's being used to reinvent basic components.
To make this more concrete, let's come up with a hypothetical example of two open source de-identification systems. System A is developed and provides an algorithm that performs fairly well, as well as a user interface that allows people to review documents. System B is also developed, has an algorithm that performs a little bit better than System A, but has a user interface that's not as nice. If we were to overlap the feature set, we'd see that both systems took a lot of effort to implement similar pieces, some of which were better in one system or the other. While there may be reasons each system was built from scratch, one can't ignore that pooled resources could have developed a system that performed optimally from a de-id standpoint, and also had a very usable UI for reviews.
I like to think that software developers can actually have a place in addressing this. By following sound architecture principles and best development practices, the core pieces of the system can be put into place in a manner that makes a system component-driven, and therefor more easily extensible by collaborators. The use of repositories like github can let potential collaborators fork the project to meet their needs, and/or commit back changes to share with the rest of the community.
I'm not so naive to think that this idealistic viewpoint is brand new. However, ignoring it won't make it any better either. I truly believe that following best development practices for even seemingly one-off projects (those are always the ones that grow in scope, aren't they?) and being open to taking existing projects to improve them are the right path forward. Funding also needs to continue for organizations who take the fork-and-commit approach, to spur this type of innovation.
While not to question or point out any particular project, there are examples where there is an existing system that does something quite well, and another organization either funds or gets funding to build another similar system. It's true that in many cases this can bring about a new innovation or new direction in solving a problem, but one also has to question the amount of resource that's being used to reinvent basic components.
To make this more concrete, let's come up with a hypothetical example of two open source de-identification systems. System A is developed and provides an algorithm that performs fairly well, as well as a user interface that allows people to review documents. System B is also developed, has an algorithm that performs a little bit better than System A, but has a user interface that's not as nice. If we were to overlap the feature set, we'd see that both systems took a lot of effort to implement similar pieces, some of which were better in one system or the other. While there may be reasons each system was built from scratch, one can't ignore that pooled resources could have developed a system that performed optimally from a de-id standpoint, and also had a very usable UI for reviews.
I like to think that software developers can actually have a place in addressing this. By following sound architecture principles and best development practices, the core pieces of the system can be put into place in a manner that makes a system component-driven, and therefor more easily extensible by collaborators. The use of repositories like github can let potential collaborators fork the project to meet their needs, and/or commit back changes to share with the rest of the community.
I'm not so naive to think that this idealistic viewpoint is brand new. However, ignoring it won't make it any better either. I truly believe that following best development practices for even seemingly one-off projects (those are always the ones that grow in scope, aren't they?) and being open to taking existing projects to improve them are the right path forward. Funding also needs to continue for organizations who take the fork-and-commit approach, to spur this type of innovation.
Comments
Post a Comment