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

  1. Bernd Eckenfels

    Soft­ware forges are basi­cal­ly enabling teams in main­tain­ing intranet web infra­struc­ture. This self ser­vice speeds up set­ting up team infra­struc­ture how­ev­er it can also cause a gov­er­ance prob­lem for pro­duct devel­op­ment.


  2. Bernd Eckenfels

    for exam­ple dif­fer­ent code lay­outs, dif­fer­ent mean­ings to sever­i­ties of bugs and tasks. No aggre­gat­ed view over mul­ti­ple projects. In addi­tion to that depen­den­cy man­age­ment of soft­ware arti­facts is a big one. And well.. release man­age­ment might also be a big­gy.

    Peo­ple like QA or tech­ni­cal writ­ers work­ing on mul­ti­ple projects will have to adopt to each projects “style”.

    So some infra­struc­ture (like ded­i­cat­ed CVS/SVN repos­i­to­ry) is bet­ter not used, right?

    May­be it is gen­er­al­ly bet­ter for inhouse point solu­tions (as opposed to pro­duct devel­op­ment).


  3. Dirk Riehle Post author

    I’m not sure I under­stand. Wrt tools and inte­gra­tion, forges are like CASE tools and have sig­nif­i­cant ben­e­fits over a set of non-integrated tools.

    In fact, I’d argue that because the meta-data is in one place, the forge data­base, and the dif­fer­ent tools are at known loca­tions, it is much eas­ier to get a com­pre­hen­sive overview across projects. If you don’t have some­thing like this, but only have a bug track­er here, a con­fig mgmt over there, etc. you loose the inte­gra­tion.

    As to oth­er aspects like cod­ing guide­li­nes etc. I think the­se are out­side the scope of CASE tools or forges or a stan­dard­ized but not inte­grat­ed tool col­lec­tion.

    In gen­er­al, I think, if you want to enforce cer­tain behav­ior or process, you can always imple­ment it, whether a forge or not.

    Thanks for your com­ments!


Leave a Reply