|
|
|
|
|
|
by richbradshaw
1605 days ago
|
|
|
There is often no time pressure, and no commercial pressure. This means that polishing around the edges, e.g. documentation can have more time applied. There is also different context - for internal tools, the scope is often well understood. The team who are using it are long term colleagues. There is no need for a logo, flashy landing page etc to convince people to use the tool. There is no need to sell it to stakeholders - they asked for it in the first place. We can also make really good assumptions about what features can be cut. In an internal tool we know our users, we know which teams need the tooling etc. We can do training. So we can very deliberately ignore certain use cases etc. In OSS we don't know any of that, so often have to cater to everyone, hence building a much more robust tool. It's also some survivorship bias - the incredible OSS projects rise to the top and do have all this stuff. There are 10,000 internal tools built for every 1 popular OSS tool. The 'bad' OSS projects aren't being seen or used, so we don't notice how bad quality those ones are. |
|
|