From 9d3c8c0e6e1a7ba43bf3dc19350d1dca68b657a3 Mon Sep 17 00:00:00 2001 From: Chris Xiong Date: Sun, 10 Feb 2019 11:16:07 +0800 Subject: Initial commit. --- blog/post/2018-06-05.html | 216 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 216 insertions(+) create mode 100644 blog/post/2018-06-05.html (limited to 'blog/post/2018-06-05.html') diff --git a/blog/post/2018-06-05.html b/blog/post/2018-06-05.html new file mode 100644 index 0000000..a68f33e --- /dev/null +++ b/blog/post/2018-06-05.html @@ -0,0 +1,216 @@ + + + + +Chrisoft::Blog + + + + + + + + + + + + + + + + + + + + +
+ +
+
+

Software Project Management in the Free Software World

+
2018-06-05
#sophistry
+
+

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

+
+ +

+
[1]: I used the term +"open source" in the original +presentation, which is more familiar to the audience. But the actual focus +is the free software world.
[2]: The maintainer of gogs is
+
+ +
+
+
+ \ No newline at end of file -- cgit v1.2.3