This article is based on a presentation project I did for the software project management course. The original presentation can be found here[1].
As mentioned in another article, software engineering college in China (one of which I am currently studying in) mainly deals with the development cycle of proprietary programs with a very specific purpose (i.e. enterprise software), such as software system for a library or an electric grid. Unfortunately, there are very few instances of free enterprise software in the wild. Therefore it's safe to assume that I still know nothing about the life cycle of a free software project except my own experience.
Project charter. What?
Approximately 50% of the class is focused on the project charter. How the charter is issued. Why modifying the charter is vital when the client requests to make a change in the requirements. This list can go a lot longer.
However, project charter doesn't seem to play an important role in free software projects, at least compared to what I have learned. Even some huge free software projects such as KDE omits the project charter. Instead they have brief description of every sub-projects and use their 'philosophy' to govern the whole project.
This can lead to problems though. When decisions need to be made, the only ones involved are the current maintainers. Free software projects fall into roughly four categories according to the way new features are introduced:
- Linux kernel/LineageOS: developers submits changes, got reviewed, and
possibly merged.
Linux kernel is such a huge and complex project that probably only users extremely familiar with it know what new functionality they need. Also the code needs to have a reasonable wide range of use cases to be merged. This sets a pretty high standard for the contributors. LineageOS, on the other hand, is a lot easier to get started. However being mostly a community project, they cannot simply get every requested features implemented without help.
- i3wm: this will never turn into compiz.
It is important for i3wm not to turn into compiz. However sometimes this can be abused for dictatorship over the project (e.g. gogs, which resulted in a fork into gitea.[2])
- systemd: let's add a email client to this.
j/k. - ...
Tools and outdated approaches
Over the years, the process of building a commercial software has evolved a lot. However, the process of building free software seem to be stuck at what it was like in the 70s forever: (nearly) everything is still on mailing lists. Indeed, VCS, issue tracker and CI simplified a lot of stuff. And the infrastructure has also improved a lot from that of the 70s. But we are still no where close to a well-organized process. Personnel management is almost completely relying on faith. Deadlines can be pushed back again and again. That's it.
Free software that is...
... developed as if it was proprietary software.
A very typical instance: Android. Repositories are not updated until new release comes out. Many related patents are held by Google. Even codename needs revealing.
Another (less-known) example is Deepin, which one of my friends works for. It's infra is far less open to public than that of Debian or even Ubuntu. Public opinions are ignored from time to time.
While making the project much more better-organized, this approach automatically makes the project dictated by the project management team. Many benefits of free software doesn't apply to such projects, which makes them closer to those 'shared source' software. Although still can be forked freely, most forks die out pretty quickly, as these projects tend to be pretty large in scale, maintenance of such a project is no trivial task.
This is certainly not the best way to do it.