Over the years, I’ve had a number of opportunities to manage projects based on open source frameworks. The subject of managing these sorts of projects is vast, but in this post, I will share some of my experiences that I hope will be helpful to you.  During our lifetime, the transition into the  “information age”, also known as the “digital revolution”, has generated countless lines of software code. I wouldn’t even pretend to know how many total lines of code have been written, but this infographic is pretty interesting: “How many lines of code is your favorite app.” Whatever the actual number is, it’s huge. Consider how much effort went into writing that code. That’s a lot of value that’s been created over the years, but most of it is isolated, not accessible, and eventually lost.

This is the beauty of open source software. A complex piece of software can easily get into the hundreds of thousands to millions of lines of code. In many cases, companies are solving similar problems independently, over and over again. This is a massive waste of effort. Once companies started to realize that they could build upon a shared body of code rather than reinventing or purchasing expensive proprietary solutions, it only made sense that open source software would become a big deal.  As a result, over the last 15 to 20 years open source software has become a major movement in the IT industry. The movement’s influence has grown so vast that open source projects like Linux have given their proprietary counterparts, for example Windows, a real run for their money. In fact, even Apple’s OSX operating system is based on a Unix derivative that Apple open sourced called Darwin — which borrows from another open source tradition of operating systems called BSD! More recently, Microsoft and Apple have announced that they are open sourcing their respective development technologies, dotNet and Swift. The value of cooperating around open source projects and collaboratively solving complex problems has obviously proven itself.

Olive Technology has been developing custom softwares for our customers for almost 20 years and we have been very fortunate to be part of this open source movement. In fact our open source teams had been instrumental in setting up a Drupal chapter in the city of Hyderabad, which is one of the major software hubs in the world. We periodically support the open source forums and seminars that are conducted in and around the city.

One of the reasons we have been proponents for projects that are developed on open source frameworks is the benefits our clients get from the support of large online developer communities. This support ensures that our clients’ projects will be viable well into the future, even without Olive Technology. For that reasons, we argue that one of the criteria for selecting an open source framework should be its support base. You want to make sure your solution will be supported even when the people who did the initial development work are long gone.

For most of the open source frameworks, advanced features can only be achieved through custom code.  Much of this code doesn’t get shared in the community as the customizations belong to the client. So companies end up “reinventing the wheel”. Ideally, companies would identify those customizations that aren’t deeply proprietary so as to release those customizations back to the open source community so that others could benefit from the customizations in the same way that the company benefited from the tremendous amount of free code they used as the foundation for their customizations. If you use open source, here’s a golden rule we ought to live by: give your code unto others as you would have them give their code unto you… or something like that.

I’ll close with a few pointers for a project manager who plan to work with open source frameworks:

  • Read through the community forums for the framework so you can get a sense of what kinds of challenges you may face with your project. Open source frameworks come with tremendous benefits in productivity, but they all have their weaknesses. Make sure you understand them.
  • Make sure you have a good understanding of how third party services will integrate with your open source framework of choice. Integrating third-party software into your open source framework is likely to be one of the most time consuming aspects of your project. Once you solve a third-party integration problem, consider donating that solution back to the community. It’s likely that the solution isn’t a trade secret for your company and your competitors won’t likely be able to use your generosity to destroy you — but the broader community will benefit from your work in the same way you benefitted from their work by building upon the community’s contributions to the framework you are customizing. Be a good open source citizen. :)
  • As your team discovers problems and overcomes them, share them in the community forums for that open source project so that others can learn from your experience.
  • Temper your expectations. We often jump into open source projects with promises of vast savings and simplicity of implementation. Software is hard. Open source software isn’t a magic bullet. A mismanaged open source implementation can be just as costly as a totally proprietary solution. Make sure you understand the problem you’re trying to solve, and set realistic goals and expectations for your team and/or client.
  • Use agile scrum to manage your project. This isn’t directly related to open source, but I really feel that this is the best approach to achieving your project’s goals.
  • A good developer who is skilled in the underlying language and technologies used by an open source project should be able to quickly come up to speed on the specifics of an open source framework… assuming it’s well documented and well supported by a larger community of developers.

Hopefully this information is of some use to you. If you want to have a candid discussion about how open source solutions may benefit your project, reach out to us and let’s talk shop.