Hacker News Reader

Comment by henrikhansen | Hacker News Reader

This reminds me of The Myth of the Genius Programmer. I.e. the developers who don't want others to see them make mistakes and instead want to look like geniuses. I don't see how they "dig" Open-Source when they really are just releasing their source publicly. No one can see the progress of their projects or participate in their work.

It also amazes me that they consider branches to be cluttering.

View on HN

I wish developers could participate in the work, but unfortunately this is difficult because feature development on the client libraries is tied to feature development on the gateway. Until we release the corresponding features in the gateway, the client libraries wouldn't work.

I was thinking about your comment about seeing the progress of the project. While that is conventional for open source projects, it is unconventional for products. And since our client libraries are tied so closely to our product, progress of libraries is progress of our product. Anybody have thoughts/experiences/etc on sharing day-to-day development of their products? I know some companies do it, but it doesn't seem very common.

One of the issues you'll run into is that if you do make the day-to-day progress available, someone will expect you to support it. You'll either need to explicitly say that it's "use at your own risk" or have to make sure that the exposed "daily" branch works. The former probably isn't useful for the majority of your end users while the latter introduces extra overhead to your development process that you may not want or have time for.

Ensuring that branches are useful and not "cluttering" requires a bit of discipline. It's easy to get a bit branch-happy in which case you end up with changes scattered across a number of branches that may or may not have a consistent starting point. This will cause issues when you have to merge all the updates for a release.

A general rule of thumb is only to create a branch when you need to work in parallel: code needs to be separated to allow for simultaneous updates or if a feature needs to be isolated until it's release timetable is set. This will vary depending on team size, work patterns and the nature of code changes.

Reply on news.ycombinator.com