About 4 months back, the Flash team at Comcast Interactive Media released LogBook, our first official open source project. This blog post is a retrospective on the experience. The main reason I am writing this entry is to show that open source serves more than just the developer ego, and a company that allows open source of projects actually benefits from such projects. Hopefully someone can use this entry if they ever need to convince someone on open source projects.
Preamble
As I had mentioned in my pre-launch post, LogBook started as an internal tool that we wrote to debug our Flex applications. Pretty soon this had become an essential part of the application development workflow. We realized there was a real need for a tool like this in the development community and so brought up the idea of open sourcing the application with the development managers and the VP of Engineering. The developer group at CIM had already been participating in the open source community, releasing updates to some Java projects that power our sites, however we had no experience with starting a new open source project. But given our history with open source, selling the idea of open sourcing was a lot easier than you would imagine (special thanks to the legal team at Comcast who got all the legal stuff done so fast, unlike a lot of the stories you hear about projects getting bogged down with legalities)
LogBook was an ideal candidate to get our feet wet with the process of open source projects. The project’s codebase was small (about 15 classes when we started it) was almost completely separated from any other project we worked on. We also knew that the project was not something that grow faster than we were ready for: not a lot of developers enable any kind of logging in their applications and even fewer use the Flex logging framework which is what we released the first build for, but the small scope of the project was by design, being our first open source project, there was a learning curve for us too (I have released quite a bit of code on this blog over the last couple of years but managing a project is a lot different).
With all groups signed off, LogBook was released on Feb 12th, 2008 on Google Code. The project was released under the MIT license. We also started a google group to discuss the evolution of the project. We also made an effort to keep project related conversation in the open, so email exchanges on the LogBook project even within the CIM team happened via the group mail address. Google analytics were also enabled.
LogBook Today
Four months since the project’s release, here is the project’s status:
Based on the numbers here, with 486 visits to the downloads page and 804 to the main page (which has the direct download link), I would imagine the project has been downloaded around 500 times, which is really cool. The source code itself has been checked out about 216 times. Not bad for what started as a quick debug app between 6 developers ;).
So Why Open Source?
There are a lot of books out there that talk about the advantage of open source projects, and there is no dearth of open source success stories (Apache, Eclipse, etc). However while these examples are great, in our case, LogBook would always be a small project with a few commits every now and then. So why should a company take on the headache of opening up the source code ? Below is a list of the not-so-obvious advantages of releasing code under open source licenses.
1) Much better code quality:
It was really surprising how much better the LogBook code is today than it was when we decided to open source it. A lot of us had put a few snippets of code here and there when it was an internal tool. But when we decided to open the code base, members of the team decided the code was not good enough to open source (Go developer pride 😉 !). Same goes for the user interface as you can see below:
LogBook pre-release:
LogBook post-release:
Thanks to the open source project, LogBook is a lot more pleasurable to work.
2) Bug fixes = education
Once bug reports started coming in from other developers, we took some time to review those and see if when we could finish them. But the bugs taught us things that we didn’t know. For example, there was a bug that talked about LogBook hanging when a you tried to clear more than 100 logs from the list. The code looked fine, we were using ArrayCollection.removeAll() so we were baffled for a while. When we replaced that with ArrayCollection.source = new Array(), the performance went back to normal. Details of the bug/fix can be found here but this situation was never discovered internally. Had we not open-sourced LogBook we could have used removeAll() in code in one of our production projects, where CIM might actually lose money/audience if the application hung or something. We have fixed quite a few such bugs and a lot of them have taught us new things. Its almost like having a group of technically savvy QA engineers for free ;).
3) Bigger developer pool
The main reason users give for open sourcing code is to have tap a bigger developer pool than if the project is maintained internally. Our biggest non-Flash-Team contributor was Mat Schaffer, a colleague at CIM . While Mat is not part of the Flash team, he has been interested in Flex and this project let him contribute patches to the LogBook project. The collaboration also taught me more than a couple of things in managing project updates / dependencies, domains that are a lot more mature in the Java world which is Mat’s domain at CIM. For example, I have now started using patches for atomic updates to the LogBook code, which is so much better than running through a number of files trying to update code.
4) Open code + good ideas = easier collaboration
The Flash team gets to work with teams from a lot of other groups / companies and a lot of our projects are around integration. With LogBook, we actually started collaborating better. Once LogBook was out, we actually had a project where we sent the developers from another group the link to LogBook and asked them if they would consider using it for logging events from a black box solution we were getting from them. Since LogBook also scratched their itch as well (they needed to monitor how their code was behaving at runtime too), and since its so easy to integrate LogBook based logging, at the end of the day both teams agreed to logging certain events that either of them could see. Since LogBook was not an internal project, they did not have any problem with integrating code that did not add any dependency on a library owned by us. As we open-source more code, it would be great if other teams we work with use that and contribute to that rather than everyone build their own version of the same functionality.
5) Potential New Hire Litmus Test
Another interesting aspect has been the ability to point potential new hires to code in the LogBook project and see how they understand that. Candidates can also be asked to look at and discuss an open bug on the project, since a lot of our day-to-day work is around bug fixes, its a stronger litmus test than a theoretical algorithm kind of question at an interview. Since LogBook represents the way the team at CIM codes, the candidate’s understanding of the code is a good metric to how well he’ll perform with the rest of the code that is internal to CIM. And if the new hire is not up to snuff, we haven’t shown him any CIM propriety code. We haven’t done this yet but its definitely something we want to try going forward.
The Future of LogBook
LogBook as a project is still going strong. A few months after we released LogBook, we also added the CIM Logging framework to the LogBook project. This allowed pure AS3 projects to use LogBook. We also recently launched a hosted version of LogBook, which is exactly the same as the installed version but doesn’t require the application to be installed.
We are also planning to release more code under the MIT license, and a lot of this will be used in the next version of LogBook. The next feature on the roadmap is User preferences with the ability to save things like recently used log keys so that you dont have to remember them (issue #7 in the issues page). The team tries to implement features and bugfixes as we get time as per our needs, so some features may take longer to implement than others but if you want to join the project and help us steer this along, do join the user group and make some noise ;).
p.s:
And for all you Java/OSGI developers out there, also check out CIM’s cimspringfield open source project. I won’t attempt explaining it cos, well …I cant 😉
Code Zen 