The pre-publication version of this paper has been superseded by the final copy-edited version.
Bringing Open Source Best Practices into Corporations Using a Software Forge
Comments
-
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! -
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 -
@Bernd: What governance problems have you experienced/are you expecting?
-
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
Leave a Reply