The pre-publication version of this paper has been superseded by the final copy-edited version.
Software Research and the Industry
Research publications and comments on the software industry, open source, and inner source
The pre-publication version of this paper has been superseded by the final copy-edited version.
Software forges are basically enabling teams in maintaining intranet web infrastructure. This self service speeds up setting up team infrastructure however it can also cause a goverance problem for product development.
Bernd
@Bernd: What governance problems have you experienced/are you expecting?
for example different code layouts, different meanings to severities of bugs and tasks. No aggregated view over multiple projects. In addition to that dependency management of software artifacts is a big one. And well.. release management might also be a biggy.
People like QA or technical writers working on multiple projects will have to adopt to each projects “style”.
So some infrastructure (like dedicated CVS/SVN repository) is better not used, right?
Maybe it is generally better for inhouse point solutions (as opposed to product development).
Gruss
Bernd
I’m not sure I understand. Wrt tools and integration, forges are like CASE tools and have significant benefits over a set of non-integrated tools.
In fact, I’d argue that because the meta-data is in one place, the forge database, and the different tools are at known locations, it is much easier to get a comprehensive overview across projects. If you don’t have something like this, but only have a bug tracker here, a config mgmt over there, etc. you loose the integration.
As to other aspects like coding guidelines etc. I think these are outside the scope of CASE tools or forges or a standardized but not integrated tool collection.
In general, I think, if you want to enforce certain behavior or process, you can always implement it, whether a forge or not.
Thanks for your comments!