Snellman: On open sourcing existing code

Posted Mar 23, 2015 9:26 UTC (Mon) by fb (guest, #53265)
In reply to: Snellman: On open sourcing existing code by ledow
Parent article: Snellman: On open sourcing existing code

> We code like junk when nobody is looking.

Sorry but that just isn't true.

I've worked for both proprietary and FOSS projects as a full time job.

FOSS projects tend to be better organized for similar sized projects. Not a question of code quality but really of making the infrastructure around the code (e.g. instructions on how to do this or that, build files, amount of work/configuration it takes to actually build it etc).

I don't think this is because of more or less altruism or concern with aesthetics. The core reason IMO is that on FOSS (any large-ish successful project) **has to** put some effort cleaning the infrastructure because otherwise:
- devs will get pestered over and over again on IRC with simple questions. Often by people that think that a 'dev on IRC' is a 'development help desk at their disposal'
- you lose any chance of having any 'accidental contributors', who come by, fix something, send a pull request and go away.
- new full time contributors are often located a continent away

So cleaning up has a real concrete pay off other than 'the project is neater now'.

On a proprietary code base you don't have 'accidental' contributors. New developers are assigned to work on the project, often sitting two desks away. So the pay off around having perfectly clean build files and perfectly documented README files is, in practice, a lot lower.

Snellman: On open sourcing existing code

Posted Mar 23, 2015 14:14 UTC (Mon) by pboddie (guest, #50784) [Link]

I was going to comment on this much earlier, but many of the helpful commentators have made some of the same points on my behalf, and in more detail, too!

What comes into play here is what Brooks describes in the classic "The Mythical Man Month", which despite discussing large software projects in the main, touches on some of the same problems when you make a software project for more general consumption. You can certainly get away with developing something with minimal documentation, implicit build dependencies, and with a good-enough but infrastructure-specific build system, but as soon as you have other people wanting to use that software (either as actual users or other developers, either within or beyond your organisation), the software becomes a product and demands multiples of the original effort put in to make something that is functional.

Something that is openly developed often has to maintain this readiness for external usage at the cost of time spent on things like documentation, although some Free Software projects manage to muddle through by making new users and contributors "learn the ropes" the hard way. But aside from exceptional cases where the motivation to adopt the software overrides deficiencies in the materials of the "product" and where people will use it no matter what, many projects will struggle to get the attention of their target audience. The last thing potential adopters want to see is a dependency on arcane technologies or a menagerie of weird programs and libraries (or worse: network services) just to even evaluate whether some software does what it is claimed to do.

So, projects developed in the open may very well be oriented towards being some kind of consumable "product", although many of them may also be looking for contributors to help them get to that state, and being exposed to broader requirements and demands (running on different systems and in different environments) by potentially attracting outside help to meet such needs probably keeps the applicability at a higher level than some internal software that will eventually be thrown over the wall.

In short, something without a broader audience in mind probably won't have had much extra effort put in to make it a "product", regardless of the licensing applied to that software, but openly-developed - not merely freely-licensed - software may well have been incurring the costs of building a "product" all along in order to grow the project and get people to use it.