>Corporate developers seem to struggle a bit more when a company open sources their internally developed code. It’s not so much the development or coding aspect of it, but more the interaction and community building aspects they struggle with.
Some common items they struggle with:
- No knowledge silos. An open source project can’t afford to have knowledge silos. A successful project needs a team that can work on any piece of the project. This goes against most corporate training where people have very specific roles and responsibilities.
- No Testing Team. Developers are required to write their own unit tests, and integration tests. Many corporate developers seem to struggle with this. They have never had to do it, it’s always been the responsibility of the QA team to write the tests.
- Maintaining the Build. Again, many are used to just writing and submitting the code. Another team takes care of building the software. Note: This isn’t just a corporate problem, many open source projects struggle with this as well.
- Answering and Responding to forum/mailing lists. Typically a developer may never actually communicate with the person that filed a bug report. Part of growing a community is timely responses to questions and bugs.
- Marketing and Promotion. That’s the job of everybody on the team, not just the team leader. Again many aren’t used to having to do this, as the Marketing Department will handle promotion, press releases, etc.
None of these are simple things to address, but when choosing the initial team, look for those team members that may already be involved in open source projects. Seed the team with some of these people, and the initial growing pains for the project will be less severe. The biggest thing though, the team has to be willing to adapt and change, what they did in the corporate environment more than likely will not work with their open source project.