By good design I mean things like meaningful classes and architecture,
good use of design patterns, good use of abstraction, good
organization of components, high cohesion and low coupling between
components
First, a software, good or bad, doesn't live in solitude – it
models a real world scenario which humans conceive of as a problem and
thus is always associated closely with something called an
"application domain". So, whenever you talk about software, first know
and study the domain – for only then you can attain the
discretion of good and bad.
git – not just good, but an amazing design. It is not a
version control at its core, just a file system. A thin veneer
of functionality on top of the core makes it a version control
system. Get to know the internals of git, and your sense of
software design will be enlightened.
jQuery – not a very well (internally) documented library,
but an inspiring source demonstrating how client side JavaScript
code can do wonders.
NodeJS – if you're into making servers this project has
refreshingly new ideas and patterns to offer.
v8 – very good C++ code, fantastic library to learn/study
virtual machine implementations.
NoSQL projects – Couch, Mongo, Redis, Cassandra – these projects demonstrate smart ways to solve persistence
problems. Also they embrace the idea of polyglot persistence.
Boost libraries – good dose of C++.
OpenStack – very good projects on cloud computing and virtualization.
The Apache Software Foundation – Choose any
of their projects and study it. HTTPd's modular structure is
a great source if you want to see how components come together. APR
(apache portable runtime) – a really good lib also.
mod_wsgi – one of the best C programs I've come across.
"good use of design patterns" – it is NOT important for the code
to correspond to a well known design pattern – it is more
important that it solve the problem "smartly" – that it is
maintainable, reusable and readable. If code is crammed into a
particular "shape" – just to adhere to a design pattern –
it can be bad code.
"not less then 100,000 lines of code" – since when did the
number of lines become a metric of good quality – getting a
taste of "well designed/architectured software" doesn't require it to
be BIG.
Again, remember to study the nature and nuances of the problem domain
first, and then delve into reading the code.
UPDATE: Oct. 2015
InfluxDB -- https://influxdb.com/
This Go project is under active development, and is still NOT very complex. So you can get started with digging into code relatively easily than something like OpenStack.