Hacker News Reader

Comment by pavel_lishin | Hacker News Reader

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko.

I know of at least two teams who would kindly ask me to refrain from doing this; me doing the work doesn't mean they don't have to do any. They still have to take the time to review my code, provide feedback, possibly explain to me their standards and conventions. Afterward, they have to maintain and own my changes - what if I introduce a bug? What if the feature is popular enough that they now have to add additional functionality onto it?

View on HN

Plus the ability to jump into another repo with zero assistance to implement a change is not common. Aside from the technical skills needed, other stuff like filling out change control forms or making sure the build passes CI isn't something you can do with repo access alone. To go down all those possible roads with anyone who asks can turn into a full time job when you multiply it in a large org.

Then after supporting those requests and cleaning up after those people, you job becomes lumpy and irregular with tons of people owning your time. Getting out of a role like that either takes years or quitting.

Setting up teams for inner source work can be done and tends to earn itself back, but most teams aren’t set up for this. Typical solutions for the issues you mention: trusted committers to review and merge work without having that role burden the whole team, contribution guidelines to set standards, 30 day warranty to avoid getting code dumped in their lap that’s broken but also avoid having too many owners of parts of the codebase.

Anyway, I would recommend going to the inner source commons website and reading a few of the success stories like paypal’s.

Interesting and I’d love to hear more about this “30-day warranty” concept. How’s that work in practice and how do you use it to avoid having too many owners? (Does it revert to the original system owners after 30 days?)

The full explanation is on the inner source patterns website: https://patterns.innersourcecommons.org/p/30-day-warranty

Heaven forbid someone introduce a popular feature into an internal tool. I do know the concern here, but it seems to miss the forest for the leaves on the trees.

At scale, if you let everyone do this, suddenly you're maintaining 50 features that were contributed and are each used by...two teams. Ownership with contributions requires really strong culture. (this is the same reason that you don't always see a PR just approved to an open source library.)

You mean just like when someone thought it was a cool feature to have JNDI lookups in Log4J ?

Are you going to assume ownership of that change if it breaks in production at any point and the team needs to provide support? Because I surely don't like owning pieces of critical code that wasn't implemented/explicitly maintained by my team, doing code archeology while putting out fires caused by 3rd parties' code is in the not-so-much-fun category of work.

Reply on news.ycombinator.com