I'm trying to understand why UML is not used in most free software projects. For example, my Debian/Linux system has probably more than ten thousand free software packages, and I cannot name even one which has been developed using explicit UML framework and methodology. For example, Qt, GCC, Linux kernel, bash, GNU make, Ocaml, Gnome, Unison, lighttpd, libonion, docker are free software projects which (AFAIK) don't mention UML at all.

(My guess is that UML is very well suited for formal subcontracting of development tasks, and that is not how free software is developed)

Notice that while I did read some material about UML, I don't claim to have a good understanding of it.

Actually, I cannot easily name a free software where UML has been used (except perhaps some UML tools implemented as free software). Perhaps openstack is an exception (something there mentions UML).

(even old free software projects might have adopted UML after they have been started, but they did not)

Some colleagues working on Papyrus mentioned that most free software projects did not have at their beginning any explicitly (and deep enough) formalized model. Also, UML looks much more related to Java than it claims (I am not entirely sure it would make sense for Ocaml or Common Lisp or Haskell or Javascript, and perhaps not even for C++11....). Perhaps agile software development is not very UML friendly.

See also this answer to a somehow related question. M.Fowler's blog Is Design Dead? is insightful.

PS. I don't think it is mainly a matter of opinion; there should be some objective reason, and some essential characteristic of free software, that explains why. I tend to guess that UML is only useful for formalized subcontracting, and is useful only when some part of the developed software is hidden, as in proprietary projects. If that is true, UML would be incompatible with free software development.

NB: I am not an UML fan myself. I don't define UML as paper documentation only, but also as a [meta-]data format for software tools

  • 32
    Maybe cause UML is crap? Or is it because most free software is lacking a good documentation? Commented Dec 14, 2015 at 10:04
  • 20
    You have it other way around. There must be objective reason to use UML, not other way around. FOSS doesn't use UML, either there is no objective reason, or all reasons are not accepted by FOSS community.
    – Euphoric
    Commented Dec 14, 2015 at 10:17
  • 19
    For some of the projects you listed, the reasons are rather obvious: because time travel hasn't been invented yet. UML was first standardized in 1997. The GNU project is from 1983, GCC 1987, Bash 1988, GNU make 1989, Qt 1991, OCaml 196, Gnome 1997. Only lighttpd and Unison are even young enough to have been developed using UML, but lighttpd is written in C and Unison in OCaml, both of which are languages which cannot be described well in UML. Plus, Free Software developers generally believe in writing code in such a way that it can be understood without the help of external tools. Commented Dec 14, 2015 at 10:54
  • 27
    UML is not used very much in open or closed source software development. It's mostly used by people who talk about software development. Commented Dec 14, 2015 at 21:44
  • 17
    The same reason UML isn't used much in non-free software development. It sounds good on paper but in practice doesn't seem to offer any real benefits.
    – JohnB
    Commented Dec 15, 2015 at 11:33

3 Answers 3


There are different ways to use UML. Martin Fowler calls these UML modes and identifies four: UML as Notes, UML as Sketch, UML as Blueprint, and UML as a Programming Language.

UML as a Programming Language never really took off. There has been some work in this area under different names, like Model Driven Architecture or Model Based Software Engineering. In this approach, you create highly detailed models of your software system and generate the code from those models. There may be some use cases where this approach is useful, but not for general software and especially not outside of large companies that can afford the tools that power this approach. It's also a time-consuming process - I can type the code for a class faster than I can create all of the graphical models necessary to implement it.

UML as a Blueprint is often indicative of a "big design up front" project. It doesn't have to be, of course. The model can be fully described for a particular increment, as well. But the idea is that the time is spent creating a design in the form of UML models that are then handed off to someone to convert into code. All of the details are spelled out and the conversion to code tends to be more mechanical.

UML as Sketch and UML as Notes are similar in nature, but differ based on when they are used. Using UML as Sketch means that you will sketch out designs using UML notations, but the diagrams are likely to not be complete, but will focus on particular aspects of the design that you need to communicate with others. UML as Notes is similar, but the models are created after the code to aid in understanding the code base.

When you're considering this, I think everything above is true for any kind of modeling notation. You can apply it to entity-relationship diagrams, IDEF diagrams, business process modeling notation, and so on. Regardless of the modeling notation, you can choose when you apply it (before as a specification, after as an alternative representation) and how much detail (full detail to key aspects).

The other side of this is open source culture.

Often, open source projects start off to solve a problem that an individual (or, today, a company) is experiencing. If it's being launched by an individual, the number of developers is 1. In this case, the communication overhead is extremely low and there's little need to communicate about the requirements and design. In a company, there's likely to be a small team. In this instance, you'll likely need to communicate design possibilities and discuss trade-offs. However, once you have made your design decisions, you need to either maintain your models as your code base changes over time or throw them away. In Agile Modeling terms, "document continuously" and maintain a "single source of information".

As a brief aside, there is the idea that code is design and that models are just alternate views of the design. Jack Reeves wrote three essays on code as design, and there are discussions on C2 wiki as well, discussing the ideas that the source code is the design, the design is the source code, and source code and modeling. If you subscribe to this belief (which I do), then the source code is the reality and any diagrams should just exist to make understanding the code and, more importantly, the rationale behind why the code is what it is.

A successful open source project, like the ones that you mention, have contributors around the world. These contributors tend to be technically competent in the technologies that power the software and are likely also to be users of the software. Contributors are people who can read source code just as easily as models, and can use tools (IDEs and reverse engineering tools) to understand the code (including generating models, if they feel the need). They can also create sketches of the flow on their own.

Of the four modes that Fowler describes, I don't think you'll find an open source project, or very many projects anywhere, that are using modeling languages as programming languages or blueprints. This leaves notes and sketch as possible uses for UML. Notes would be created by the contributor for the contributor, so you probably wouldn't find them uploaded anywhere. Sketches diminish in value as the code becomes more complete and likely wouldn't be maintained as that would just take effort on the part of contributors.

Many open source projects don't have models made available because it doesn't add value. However, that doesn't mean that models weren't created by someone early in the project or that individuals haven't created their own models of the system. It's just more time effective to maintain one source of design information: the source code.

If you want to find people exchanging design information, I'd recommend looking at any kind of forums or mailing lists that are used by contributors. Often, these forums and mailing lists serve as the design documentation for projects. You may not find formal UML, but you may find some kind of graphical representation of design information and models there. You can also pop into chat rooms or other communication channels for the project - if you see people talking about design decisions, they may be communicating with the graphical models. But they likely won't become part of a repository since they aren't valuable once they have served their purpose in communication.

  • 1
    Lots of text but only last but one paragraph actually answers the question. Also, did you reopen the question just so you can answer it?
    – Euphoric
    Commented Dec 15, 2015 at 14:20
  • 7
    @Euphoric Although the last paragraph answers the question, the rest of it is necessary to set the background and normalize on terms and concepts. And no, it already had 4 reopen votes - I casted the 5th and answered.
    – Thomas Owens
    Commented Dec 15, 2015 at 14:24
  • 4
    +1 Very comprehensive answer. In my opinion, the preceding paragraphs explain the conclusion. Well done!
    – Andres F.
    Commented Dec 15, 2015 at 15:53

Lets use Linux as example,

  • It's not an Object Oriented project, some parts, like the VFS can be modelled in UML, but others can't be or not very effective, i.e. basically just a straight translation from struct into a class diagram with no relationships.
  • UML is good for documentation, to get some one new to a project gets up to speed. That is not something that really catered for by Linux, people are expected to learn it themselves.
  • Not sure what UML tool to use, people need to agree on something if it was going to be maintained. There was a free java application for that, but I don't think many would want to use it.
  • In the 90's GUI was still a challenge on Linux. Just go dig the mailing list archive, I bet you won't find any kind of graphics other than the logo for Linux itself in xpm format to be shown in boot up time. Plain text is the preferred format.
  • I don't think no one really cared for design. People care about features and if they are accepted then the code will be scrutinised. Use cases are still best described in words, just like how standards like POSIX and SUS are written.
  • A lot of objects in the domain of operating systems are well understood and standardised within the community. E.g. people would know how a struct in_addr looks like in memory, no diagrams could make it clearer.
  • UML doesn't help much in modelling algorithm, like the memory allocator, scheduler, interrupt handlers, etc. The source is probably easier to understand.

Those are the things that I can think of in Linux project settings. It's more about practicality, I guess. Curiously, I don't remember Tanenbaum used any UML in his OS text book in describing Minix.

Probably worth mentioning, I also don't use UML at work. Probably 20% of people I work with know some subset of UML.

  • 4
    Linux does use object orientation, it just does not use an object oriented language. True, linux also contains parts written in a very procedural style, but other parts, like the kernel module interface, are decidedly object oriented. Commented Dec 17, 2015 at 9:06
  • There are more than class diagrams in UML. Commented Sep 28, 2018 at 12:58
  • Every big software project requires object-oriented design. Commented Jun 16, 2019 at 23:11
  • The contributors need to understand a standard modeling language before working on the project, and that's what justifies the need of a software modeling documentation whether in UML, SysML, IDEF0, ODL or OCL. Commented Jun 16, 2019 at 23:19

UML is a representation, so it's a form of language, and for argument's sake let's assume its purpose is to communicate a mental model from one person to another.

What I look for in a language is its efficiency in capturing changes to one's mental model. Suppose after writing the description of one's model, a small change needs to be made. How big a change must be made to the representation? In a textual language, a way to measure that is to run a diff between the code before and after, and count the differences. In a graphical language, there should be a similar way to measure the difference.

IMHO, I call a language "domain specific" (DSL) to the degree that it minimizes the measure above, which has obvious benefits in reducing maintenance cost and bugs. How to make a DSL? There are several ways. One of the simplest is to just define data structures and methods in an existing programming language. This adds nouns and verbs to the base language, making it easier to say what one wants. (Note: I do not look for a DSL to have no learning curve. It may be that the reader of a DSL must invest the one-time cost of learning it.)

The important point is: In all cases, the DSL has to contain the terms that make expressing one's model, and changes to the model, convenient. Since there is no obvious limit to the range of possible domains, no single DSL can serve all of them.

My impression of UML is that is what it tried to to.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.