Chrisoft::Blog(r#"Software Project Management in the Free Software World")

-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. -