Management Challenges of Open Source

The lifetime of many Open Source projects often rely on the lifetime of interest of the Project Leader. If the interest of the leader wanes then so will the success of the project. What can be done to allow more collaboration on existing ideas?

Currently there is always the driver of a project, the project leader or manager will create and inspire the team that builds anything in Open Source and for the scale of the work different levels of this hierarchy exists. However, one problem that does still exist with Open Source is that the project is often dependant on that manager or driver. If for some reason this person is unable or unwilling to spend any more time on the project then it could die. If the software is popular then ‘forking hell’ may ensue, it may get branched off into new tentatively connected projects that causes confusion.

Because of the nature of Open Source it is available to all but it still prevents many from working on it.  The project could possibly get transferred to new management and given more longevity but there is always the danger of smaller less popular projects just stopping dead. Often I have picked up old Open Source projects and used them by expanding some part of them to achieve what I want it to do but didn’t have the time or inclination to run a new project with it. Often the changes to the project are very small in comparison and really not worthy of creating a new branch or fork anyway so it just fulfils a singular purpose for me. The shame is that this purpose is probably something that someone else would find useful and the knowledge and use of the work is lost to them.

So Open Source needs a bit more tweaking in my understanding, it needs to become more – well – Open.

Allowing anyone at any time the ability to come in and add to it. Of course the problem that can occur then is multiplicity or corruption. Often a programmer that comes in later to an application that can be used for his own purposes will unwittingly break something. Not necessarily anything important to the programmer themselves because they have no need of that particular function within the project, but still something that if added to the final or latest version of the application becomes a problem for someone elsewhere, who suddenly finds his needs are no longer being met.

So the challenge is in the process, to allow for change and evolution, even allowing for integration with other projects but in a structured and safe way, together with the need not to strangle the poor upcoming developer in policies and requirements but to engage collaboration for anyone.

Quite an open challenge…

This entry was posted in Programming. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *