4 thoughts on “Bringing Open Source Best Practices into Corporations Using a Software Forge

  1. Bernd Eckenfels

    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

    Reply
  2. Bernd Eckenfels

    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

    Reply
  3. Dirk Riehle Post author

    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!

    Reply

Leave a Reply to Dirk Riehle Cancel reply