I’m a relative newbie to the world of open source development. So you’ll generally find me being pretty pragmatic about the pro’s and con’s of open source development, the roll your own vs. commercial … there is not one right answer for everyone. I asked one of the Sourcerers (I’ll have a post on “Sourcerers” soon) to walk me through a couple of examples of what approaches they take to development that leads to people using Sourcery Codebench.
This is a pretty simplified view of the world and I’m choosing to ignore the true complexity and challenges people face given a complete tool-chain is more than the compiler and includes a debugger, libraries, and has compatibility concerns with kernel versions and so on. So bear with me as I learn more about how to better make use of open source development and try and articulate what I’m learning, please comment with any clarifications or questions.
One of the scenarios that was discussed was needing a bug fix or new feature that is being implemented in let’s say GCC and you really want to make use of that piece of goodness. Isn’t that the whole point to open source development, being able to as a community make contributions that all of us benefit from.
You don’t really just want to take the latest and greatest from the active trunk, and most people don’t do it, but in theory you want that new fix or feature. Unfortunately, with GCC as with any other real software development you have some phases where things are being worked on, are in churn and may not be very stable. And then you have active periods of stabilization and you’ll get release candidates and eventually have an official release version.
But sometimes you need that one fix/feature and it needs to meet your project timeline. The nice thing, which of course doesn’t come without some level of effort, would be to isolate your development, be able to integrate in fixes selectively, validate them and then bring them into your development branch.
What the Sourcers do for some of our customers is either implement needed features or enhancements or track needed features. Then those can be selectively brought in and validated before providing an updated tool-chain to our customer.
Now we could stop there but we have an active policy to then submit those changes upstream so they are available to the community and then also validated and available in subsequent versions. I finally understand what people are talking about on google+ when they say will this ever make it upstream?!?!
Now when I actually was talking about this to better understand what an embedded software OSS tool-chain has our whiteboard had gdb, glibc and there were lots of trunks, branches and … well that’s a little too confusing to try and explain without a real whiteboard session so I tried to use GCC as a simplified example