GNOME.Asia 2018 was co-hosted with COSCUP and openSUSE Asia this year in Taipei, Taiwan. It was a good success and I enjoyed it a lot. Besides, meeting old friends and making new ones are always great.

Talks

• Desktop applications: life inside a sandbox - David King

Flatpak, as you all know, is quite popular and useful these days. So it's good to know some implementation details from this talk.

• Introducing Team Silverblue - Matthias Clasen

As Matthias mentioned in his talk, it's his first time to give this talk. And I think it was quite a success. It's a new variant of Fedora Workstation and it provides the excellent support to container-based workflows.

• The future of the computer classrooms - GNOME inside - Eric Sun

I have to say I enjoyed this talk the most in the conference. Eric used ezgo Linux as an example and explained some interesting ideas, which blows my mind. When we were young and in the computer class, we were taught to use Microsoft Office, Photoshop, etc. All these are . And these software are gonna be the the top options when you are thinking about choosing a office/picture editing software.

• There are more, but I can't include them all

Socials

• The welcom party was held at a bar near Taipei 101. The bar has a open platform, where you have a great view, which is pretty good. You can find beer, food and of course friends there.
• We had a one-day tour to Taipei Palace Museum and Taipei 101 the day after the conference. We had various dumplings and some delicious food for lunch at Din Tai Fung(A top restaurant at 101 where you need queue around 90 mins even at weekday). It was well organized. And a big thank you for Max

Finally

Thanks Max for all the effort making this conference happen. Thanks GNOME Foundation for Sponsorship my trip to the conference.

19 Sep 2018 6:23am GMT

Wordpress

I have been using Wordpress for long. Basically since I joined GNOME because it was required for GSoC. Wordpress works, it's okay. There are themes, it has a wysiwyg editor and you can embed images and videos quite easily. It kinda does the job…

The bad

Now, one of the biggest problems are ads. Not that they exist, which is completely understandable, but rather that they are kinda crazy. I got reports that sometimes they were about guns in USA, or they lead to scam sites.

I also missed a way to link to my personal twitter/linkdin/gitlab. That's quite useful for people to check what other things I write about and how to get more info about what I do.

The ugly

More on the technical side, one of the issues was that I coulnd't create a draft post and share it in private with other people so I could get some review. This was specially required for Nautilus anouncements. And in case I could, how could we collaborate in editing the post itself? That was simply not there.

Most importantly, I couldn't give personality to the blog. In the same way I want the software I use being neutral because for it's just a tool, my personal blog should be more repsentative on how I am and how I express myself. With Wordpress this was not possible. Hell, I couldn't even put some colors here and there, or take the bloat out from some of the widgets provided by the Wordpress themes.

The enlightenment…

Once upon a time, on a stormy day, I wrote the blog post about the removal and future plans of the desktop icons as a guest writter on Didier's Roche blog. And here came the enligthening, he was using some magic PR workflow in GitHub where I could just fix stuff, request to merge those changes, review happens, then gets accepted and published all automatically with CI.

Finally you could review, share drafts, and collaborate much easily than with Wordpress!

Not only that, but also his blog was much more personalized, closer to how he wanted to express himself.

The decision

One thing I had have in the back of my mind for some time is that I need to improve my skills with non-GNOME stuff, specially web and cloud technologies. So what a better oportunity than trying to set up a static web generator for blogs (and other stuff) to mimic the features of Didier's blog?

And decided was it, got some free time this weekend and decided to learn this magic stuff.

The technology

I decided to go with Hugo, because back when I was experimenting with GitLab pages and a project page for Nautilus Hugo seemed to be the easiest and most convenient tech to create a static website that just works. Overall, it seems that Hugo is the most used static website generator for blogs.

I also decided that I would get a theme based in the well known and well maintained bootstrap. Most themes had some custom CSS, all delicately and manually crafted. But let's be honest, I don't want to maintain this, I wanted something simple I can go with.

So I chose the minimal theme wich is based in bootstrap and then applied my own changes such as a second accent (the red in the titles), support for centered images, the Ubuntu font (which I use it everywhere I can), some navbar changes, full content rss support, lot of spacing adjustments, softer main text coloring, etc.

Also, I could finally put a decent comment section by using DisQus, which is added to Hugo with a single line. Eventually I would like to go with a free software solution such as Talkyard, so far I didn't have luck to make it work.

The nicest thing of Hugo is that adding a new post is a matter of dropping a MarkDown file in the post folder. And that's it. That easy.

The result

So here's the result. I think it's quite an improvement versus what I had in Wordpress, although Antonio says that the page looks like Nautilus… I guess I cannot help myself. Let's see how it works in the future, specially since there is no wysiwyg editor. To be honest, using MarkDown is so easy that I don't see that as a problem so far.

I can even embed some code with highlighting for free:

def do_measure(self, orientation: Gtk.Orientation,
               for_size: int) -> Tuple[int, int, int, int]:
    child = self.get_child()
    if not child:
        return -1, -1, -1, -1

    minimum, natural, _x, _x = child.measure(orientation, for_size)
    if self._max_width is not None and orientation == Gtk.Orientation.HORIZONTAL:
        natural = min(self._max_width, natural)

    return minimum, natural, -1, -1

And use Builder with Vim emulation to write this. That is already a big win!

If you want to take a look at the code or do something similar, feel free to take a look and use anything from the code in GNOME's GitLab. I also added an example post in order to see all formats for headings, bullet lists, images, code blocks, etc. Any feedback about the looks, functionality, content, etc. is welcome; finally I would be able to do something about it 😏.

Hasta otra amigos 🍹

18 Sep 2018 11:53am GMT

As I teased about last week I recently played around with WSL, which lets you run Linux applications on Windows. This isn't necessarily very useful, as there isn't really a lack of native applications on Windows, but it is still interesting from a technical viewpoint.

I created a wip/WSL branch of flatpak that has some workarounds needed for flatpak to work, and wrote some simple docs on how to build and test it.

There are some really big problems with this port. For example, WSL doesn't support seccomp or network namespaces which removes some of the utility of the sandbox. There is also a bad bug that makes read-only bind-mounts not work for flatpak, which is really unsafe as apps can modify themselves (or the runtime). There were also various other bugs that I reported. Additionally, some apps rely on things on the linux host that don't exist in the WSL environment (such as pulseaudio, or various dbus services).

Still, its amazing that it works as well as it does. I was able to run various games, gnome and kde apps, and even the linux versions of telegram. Massive kudos to the Microsoft developers who worked on this!

I know you crave more screenshots, so here is one:

17 Sep 2018 2:50pm GMT

A year or two ago I bought Lindsey Stirling's Album Brave Enough. It's wonderful all around, but I really fell in love with Gavi's Song. Three weeks ago I took a stab at playing this on my guitar. It's technically not actually that difficult - After listening to the original and trying to repeat it for several days, I can now actually play through it without too many hiccups (still far from being YouTube'able, though).

16 Sep 2018 8:52pm GMT

My own projects/main developer python-dbusmock: Mock D-Bus objects for creating integration tests umockdev: record/mock hardware devices for bug reports and regression tests Apport: create rich crash and bug information on Linux clients, and send them to bug trackers like Launchpad python-distutils-extra: Extensions and "automagic" wrapper for Python's distutils class postgresql-common: Provide a multi-version/multi-instance management for the PostgreSQL RDBMS Other projects I'm contributing to cockpit: Administer Linux servers via a web browser (tech lead, full-time developer) udev/systemd: Maintaining keymaps, various bug fixes Debian: The universal operating system (developer) GNOME desktop (committer, foundation member, bug fixing and reporting) PyGObject: Use GObject based C libraries from Python through gobject-introspection udisks: occasional bug fixes upower: occasional bug fixes

16 Sep 2018 8:52pm GMT

When designing Ducktype, I wanted people to be able to extend the syntax, but I wanted extensions to be declared and defined, so we don't end up with something like the mess of Markdown flavors. So a Ducktype file can start with a @ducktype/ declaration that declares the version of the Ducktype syntax and any extensions in use. For example:

@ducktype/1.0 if/1.0

This declares that we're using version 1.0 of the Ducktype syntax,that we want an extension called if, and that we want version 1.0 of that extension.

Up until last week, extensions were just theoretical. I've now added two extension points to the Ducktype parser, and I plan to add three or four more. Both of these are exercised in the _test extension, which is fairly well commented so you can learn from it.

Let's look at the extensions we have, plus the ones I plan to add.

Block line parser

This extension is implemented. It allows extensions to handle really any sort of line in block context, adding any sort of new syntax. Extensions only get to access to lines after headings, comments, fences, and a few other things are handled. This is a limitation, but it's one that makes writing extensions much easier.

Let's look at an actual example that uses this extension: Mallard Conditionals. You can use Mallard Conditionals in Ducktype just fine without any syntax extension. Just declare the namespace and use the elements like any other block element:

@ducktype/1.0
@namespace if http://projectmallard.org/if/1.0/

= Conditional Example

[if:if test=target:html]
  This is a paragraph only shown in HTML.

But with the if/1.0 Ducktype syntax extension, we can skip the namespace declaration and use a shorthand for tests:

@ducktype/1.0 if/1.0

= Conditional Example

? target:html
  This is a paragraph only shown in HTML.

We even have special syntax for branching with if:choose elements:

@ducktype/1.0 if/1.0

= Conditional Branching Example

??
  ? platform:fedora
    This paragraph is only shown on Fedora.
  ? platform:ubuntu
    This paragraph is only shown on Ubuntu.
  ??
    This paragraph is shown on any other operating system.

(As of right now, you actually have to use if/experimental instead of if/1.0. But that extension is pretty solid, so I'll change it to if/1.0 along with the 1.0 release of the parser.)

Directive handler

Ducktype files can have parser directives at the top. We've just seen the @namespace parser directive to declare a namespace. There is an implemented extension point for extensions to handle parser directives, but not yet a real-world extension that uses it.

Extensions only get to handle directives with a prefix matching the extension name. For example, the _test extension only gets to see directives that look like @_test:foo.

Block element handler

This extension is not yet implemented. I want extensions to be able to handle standard-looking block declarations with a prefix. For example, I want the _test extension to be able to do something with a block declaration that looks like this:

[_test:foo]

In principle, you could handle this with the current block line parser extension point, but you'd have to handle parsing the block declaration by yourself, and it might span multiple lines. That's not ideal.

Importantly, I want both block line parsers and block element handlers to be able to register themselves to handle future lines, so they can have special syntax in following lines. Here is how an extension for CSV-formatted tables might look:

@ducktype/1.0 csv/1.0

= CSV Table Example

[csv:table frame=all rules=rows]
one, two, three
eins, zwei, drei
uno, dos, tres

Inline element handler

This extension is not yet implemented. Similar to block element handlers, I want extensions to be able to handle standard-looking inline markup. For example, I want the _test extension to be able to do something with inline markup that looks like this:

$_test:foo(here is the content)

For example, a gnome extension could make links to GitLab issue reports easier:

$gnome:issue(yelp#138)

Inline text parser

This extension is not yet implemented. I also want extensions to be able to handle arbitrary inline markup extensions, things that don't even look like regular Ducktype markup. This is what you would need to create Markdown-like inline markup like *emphasis* and `monospace`.

This extension might have to come in two flavors: before standard parsing and after. And it may be tricky because you want each extension to get a crack at whatever text content was output by other extensions, except you probably also want extensions to be able to block further parsing in some cases.

All in all, I'm really happy with the Ducktype syntax and parser, and how easy it's been to write extension points so far.

15 Sep 2018 5:20pm GMT

These past weeks, I've been working a lot on my side project and I've made a new release of it. First of all, the project has been renamed "Foundry" (instead of "rlife"). I wanted to find a better name for this project and as this project is now actually based on Vulkan (that was my primary objective when I started it), I thought it would be a good idea to give a name related to it. Plus, there was no crates already named "Foundry".

So the biggest change is that the computations for passing from a generation of a grid to the next one are not done with the CPU anymore but with the GPU via the Vulkan API. To add the Vulkan support, I've used vulkano. The grid is represented as a Vec where each cell is a u8. So instead of computing and writing sequentially the new states of the cells in another new grid, we have now two grids (one for the current generation and the other for the next one) contained inside images stored on the Vulkan device's memory (ideally the graphic card's memory when there is one on the machine) and the device will launch parallel computations for determining and writing the next states of the cells.

So what are the results in term of performances? It turned out that there are huge gains regarding the time which is taken to compute the next generations of grids. Especially for computing a lot of generations at once and/or for large grids. Here are the results I've got with my machine that have an Intel Core i7-6700 as a CPU and an AMD Radeon RX 480 as a GPU (I've first generated a grid filled randomly and with a certain requested size and then run the computations):

• calculating 1000 generations of a toroidal grid with a width of 1024 cells and a height of 1024 cells with the CPU: 74.040 seconds
• doing the same with the GPU: 0.754 seconds
• calculating 1000 generations of a resizable grid with a width of 1024 cells and a height of 1024 cells with the CPU: 100.603 seconds
• doing the same with the GPU: 1.968 seconds
• calculating 1 generation of a toroidal grid with a width of 16384 cells and a height of 16384 cells with the CPU: 18.917 seconds
• doing the same with the GPU: 0.083 seconds
• calculating 1 generation of a resizable grid with a width of 16384 cells and a height of 16384 cells with the CPU: 25.903 seconds
• doing the same with the GPU: 0.243 seconds

I will soon write proper benchmarks for Foundry for better measurements.

Obviously, this is the very first implementation of the Vulkan API support so there are a lot of optimizations left to do.

See the PR that brings the Vulkan support for more details.

The next goal is to find a way for rendering the grid using Vulkan, so that Foundry can be used within GUI applications.

15 Sep 2018 1:08pm GMT

The GNOME 3.30 release video was announced earlier this week on Youtube. Additionally we now have a GNOME channel on Peertube by suggestion of Greg.

This marks the 10th release video for me which I find super exciting. The videos has been excellent platforms for me to learn and allowed me to reach a consistent level of production quality. For instance, check out the GNOME 3.12 release video which was my first video production.

Production moved to Gitlab

With each video I experiment with new workflows. Traditionally I have been involved in every step of the production apart from the voice-over with very few opportunities for others to step in and contribute. With Gitlab's powerful issue tracking system, this no longer needs to be the case. This has meant that I can spend more time on production in Blender and spread out the other aspects of production to the GNOME community. The work done ithisn the GNOME 3.30 Release video is covered by the following Gitlab issues:

• The 3.30 Release Video Main Issue provides an overview of the 10 main milestones in producing the release video (11 participants) with regular updates from me on how production was progressing.
• The 3.30 Content Gathering Issue collected information from GNOME developers on what had changed in apps and organized how those changes should be screen recorded (25 participants / 16 tasks).
• The 3.30 Video Manuscript Issue used the collected information to create a narrative around the changes resulting in a manuscript Karen and Mike could produce a voice-over from (6 participants / 3 tasks).
• The 3.30 Animation Issue gave an overview of the animations which needed to be produced to match the manuscript and screen recordings (3 participants / 12 tasks).
• The 3.30 Music Issue provided general guidelines to Simon on production of the music and in the future it could provide opportunity for community members to provide additional input.

The sheer number of participants should give you an idea how much big a relief opening the production has been for me. I still account for managing the production, animating the majority of the video and having a finger in most tasks, but it helps me focus my efforts on providing a higher quality result.

Future Challenges

There are still aspects of the production which are still not public. For example, I am not sharing drafts of the video prior to production which creates less feedback in the animation process and makes it harder for translation teams to provide adequate thistranslations in some cases. This is simply to avoid leaks of the production prior to release which has happened in the past and is a big pain point, considering the sheer effort everyone is putting into this. For next time I will experiment with releasing early stage work (animatics and sketches) to see if this could be a meaningful replacement.

For developers, there were many questions and issues regarding the process of screen recording which is documented in this issue. The production sets requirements to resolution and FPS which is not always possible for developers to meet due to hardware and software limitations. I would like feedback from you on how you think this went and how we might be able to improve the tooling. Let me know!

Finally, we have had two unforeseen events which caused the video to be delayed by 5 days. First, we are currently unable to convert subtitles for the release video due to a bug in po2sub. Secondly, the delay was caused by me and Simon having busy schedules close to the release date which is always hard to predict. However, the general policy here is to rather release late than release something unfinished. I am confident that as the Gitlab workflow matures and we improve how work is scheduled, these delays can be minimized.

Conclusion

I hope you enjoyed this insight into the release video production. If you are interested in participating or following GNOME 3.32 Release Video production, subscribe to the 3.32 Release Video Gitlab issue. Thanks to everyone who contributed this cycle!

15 Sep 2018 9:05am GMT

• Pleased to my chat with Randal & Dan at FLOSS Weekly published.
• Booked travel to DINAcon 2018 will be available to do some LibreOffice hackfest'y stuff, and a talk on "How best to migrate to LibreOffice".

14 Sep 2018 4:51pm GMT

• Mail; distracted by a bit of hacking for a customer. Marketing & Sales call, ESC call, early dinner, interview.
• Pleased to see Jona publish our latest LibreOffice Infographic giving an update on what we're doing.

13 Sep 2018 9:00pm GMT

These past weeks, I've been mainly working on my side project (rlife) but I've also done some small improvements for the context menu in Fractal.

First, I found out that there were problems regarding the line returns when inserting a quote: when clicking on the button "Reply", there was a quote inserted at the beginning of the message input but there were an empty lines between each lines of the quote so for instance, we had this:

> A first line

> A second line

Answer

instead of

> A first line
> A second line

Answer

It was because there was an extra new line character appended at the end of each lines of the quote when inserting it in the message input. See this MR for more details.

Next, there were a problem with the name completion in the message input: if after doing a line return, you tried to write a name and complete it, it wouldn't work; you absolutely had to have a space inserted just before the name you wanted to complete to get it work. Here is an example:

If we tried to complete "Rio" to have "Riot-bot", Fractal would search the matches for "line\nRio" among the room's user names instead of searching for "Rio". We would have to add at least a space before "Rio" to have the good match. So to fix it, we had to split the strings to search with all white spaces instead of just " ". Here is my MR to fix it.

I also have the redacted messages simply hidden instead of having them displayed as "Deleted" in this MR.

Finally, I've added appropriate actions for images in the context menu. I added buttons like "Open With…", "Save Image As…" and "Copy Image" and removed the "Copy Text" button for messages that are of the type "m.image". It looks like this:

Here is the MR that implemented it.

I also have an open MR for hiding the option to delete messages in the context menu when the user doesn't have the right to do so (i.e. for the user's own messages or when it has the right to do so in the room (e.g. for moderators or owners)). It's pending for now because there are work done to reliably calculate the power level of a user given a certain room.

13 Sep 2018 4:54pm GMT

Google Code-in will take place again soon (from October 23 to December 13). GCI is an annual contest for 13-17 year old students to start contributing to free and open projects. It is not only about coding: We also need tasks about design, documentation, outreach/research, and quality assurance. And you can mentor them!

Last year, 300 students worked on 760 Wikimedia tasks, supported by 51 mentors from our community.

• Your gadget code uses some deprecated API calls?
• You'd enjoy helping someone port your template to Lua?
• You'd welcome some translation help (which cannot be performed by machines)?
• Your documentation needs specific improvements?
• Your user interface has some smaller design issues?
• Your Outreachy/Summer of Code project welcomes small tweaks?
• You have tasks in mind that welcome some research?

Note that "beginner tasks" (e.g. "Set up Vagrant") and generic tasks are very welcome (like "Choose and fix 2 PHP7 issues from the list in this task" style).

If you have tasks in mind which would take an experienced contributor 2-3 hours, become a mentor and add your name to our list!

Thank you in advance, as we cannot run this without your help.

13 Sep 2018 3:36pm GMT

The Commons Clause was announced recently, along with several projects moving portions of their codebase under it. It's an additional restriction intended to be applied to existing open source licenses with the effect of preventing the work from being sold[1], where the definition of being sold includes being used as a component of an online pay-for service. As described in the FAQ, this changes the effective license of the work from an open source license to a source-available license. However, the site doesn't go into a great deal of detail as to why you'd want to do that.

Fortunately one of the VCs behind this move wrote an opinion article that goes into more detail. The central argument is that Amazon make use of a great deal of open source software and integrate it into commercial products that are incredibly lucrative, but give little back to the community in return. By adopting the commons clause, Amazon will be forced to negotiate with the projects before being able to use covered versions of the software. This will, apparently, prevent behaviour that is not conducive to sustainable open-source communities.

But this is where things get somewhat confusing. The author continues:

Our view is that open-source software was never intended for cloud infrastructure companies to take and sell. That is not the original ethos of open source.

which is a pretty astonishingly unsupported argument. Open source code has been incorporated into proprietary applications without giving back to the originating community since before the term open source even existed. MIT-licensed X11 became part of not only multiple Unixes, but also a variety of proprietary commercial products for non-Unix platforms. Large portions of BSD ended up in a whole range of proprietary operating systems (including older versions of Windows). The only argument in favour of this assertion is that cloud infrastructure companies didn't exist at that point in time, so they weren't taken into consideration[2] - but no argument is made as to why cloud infrastructure companies are fundamentally different to proprietary operating system companies in this respect. Both took open source code, incorporated it into other products and sold them on without (in most cases) giving anything back.

There's one counter-argument. When companies sold products based on open source code, they distributed it. Copyleft licenses like the GPL trigger on distribution, and as a result selling products based on copyleft code meant that the community would gain access to any modifications the vendor had made - improvements could be incorporated back into the original work, and everyone benefited. Incorporating open source code into a cloud product generally doesn't count as distribution, and so the source code disclosure requirements don't trigger. So perhaps that's the distinction being made?

Well, no. The GNU Affero GPL has a clause that covers this case - if you provide a network service based on AGPLed code then you must provide the source code in a similar way to if you distributed it under a more traditional copyleft license. But the article's author goes on to say:

AGPL makes it inconvenient but does not prevent cloud infrastructure providers from engaging in the abusive behavior described above. It simply says that they must release any modifications they make while engaging in such behavior.

IE, the problem isn't that cloud providers aren't giving back code, it's that they're using the code without contributing financially. There's no difference between what cloud providers are doing now and what proprietary operating system vendors were doing 30 years ago. The argument that "open source" was never intended to permit this sort of behaviour is simply untrue. The use of permissive licenses has always allowed large companies to benefit disproportionately when compared to the authors of said code. There's nothing new to see here.

But that doesn't mean that the status quo is good - the argument for why the commons clause is required may be specious, but that doesn't mean it's bad. We've seen multiple cases of open source projects struggling to obtain the resources required to make a project sustainable, even as many large companies make significant amounts of money off that work. Does the commons clause help us here?

As hinted at in the title, the answer's no. The commons clause attempts to change the power dynamic of the author/user role, but it does so in a way that's fundamentally tied to a business model and in a way that prevents many of the things that make open source software interesting to begin with. Let's talk about some problems.

The power dynamic still doesn't favour contributors

The commons clause only really works if there's a single copyright holder - if not, selling the code requires you to get permission from multiple people. But the clause does nothing to guarantee that the people who actually write the code benefit, merely that whoever holds the copyright does. If I rewrite a large part of a covered work and that code is merged (presumably after I've signed a CLA that assigns a copyright grant to the project owners), I have no power in any negotiations with any cloud providers. There's no guarantee that the project stewards will choose to reward me in any way. I contribute to them but get nothing back in return - instead, my improved code allows the project owners to charge more and provide stronger returns for the VCs. The inequity has shifted, but individual contributors still lose out.

It discourages use of covered projects

One of the benefits of being able to use open source software is that you don't need to fill out purchase orders or start commercial negotiations before you're able to deploy. Turns out the project doesn't actually fill your needs? Revert it, and all you've lost is some development time. Adding additional barriers is going to reduce uptake of covered projects, and that does nothing to benefit the contributors.

You can no longer meaningfully fork a project

One of the strengths of open source projects is that if the original project stewards turn out to violate the trust of their community, someone can fork it and provide a reasonable alternative. But if the project is released with the commons clause, it's impossible to sell any forked versions - anyone who wishes to do so would still need the permission of the original copyright holder, and they can refuse that in order to prevent a fork from gaining any significant uptake.

It doesn't inherently benefit the commons

The entire argument here is that the cloud providers are exploiting the commons, and by forcing them to pay for a license that allows them to make use of that software the commons will benefit. But there's no obvious link between these things. Maybe extra money will result in more development work being done and the commons benefiting, but maybe extra money will instead just result in greater payout to shareholders. Forcing cloud providers to release their modifications to the wider world would be of benefit to the commons, but this is explicitly ruled out as a goal. The clause isn't inherently incompatible with this - the negotiations between a vendor and a project to obtain a license to be permitted to sell the code could include a commitment to provide patches rather money, for instance, but the focus on money makes it clear that this wasn't the authors' priority.

What we're left with is a license condition that does nothing to benefit individual contributors or other users, and costs us the opportunity to fork projects in response to disagreements over design decisions or governance. What it does is ensure that a range of VC-backed projects are in a better position to improve their returns, without any guarantee that the commons will be left better off. It's an attempt to solve a problem that's existed since before the term "open source" was even coined, by simply layering on a business model that's also existed since before the term "open source" was even coined[3]. It's not anything new, and open source derives from an explicit rejection of this sort of business model.

That's not to say we're in a good place at the moment. It's clear that there is a giant level of power disparity between many projects and the consumers of those projects. But we're not going to fix that by simply discarding many of the benefits of open source and going back to an older way of doing things. Companies like Tidelift[4] are trying to identify ways of making this sustainable without losing the things that make open source a better way of doing software development in the first place, and that's what we should be focusing on rather than just admitting defeat to satisfy a small number of VC-backed firms that have otherwise failed to develop a sustainable business model.

[1] It is unclear how this interacts with licenses that include clauses that assert you can remove any additional restrictions that have been applied
[2] Although companies like Hotmail were making money from running open source software before the open source definition existed, so this still seems like a reach
[3] "Source available" predates my existence, let alone any existing open source licenses
[4] Disclosure: I know several people involved in Tidelift, but have no financial involvement in the company

comments

11 Sep 2018 8:20pm GMT

All Systems Go! 2018 Tickets Selling Out Quickly!

Buy your tickets for All Systems Go! 2018 soon, they are quickly selling out! The conference takes place on September 28-30, in Berlin, Germany, in a bit over two weeks.

Why should you attend? If you are interested in low-level Linux userspace, then All Systems Go! is the right conference for you. It covers all topics relevant to foundational open-source Linux technologies. For details on the covered topics see our schedule for day #1 and for day #2.

For more information please visit our conference website!

See you in Berlin!

11 Sep 2018 9:21am GMT

COSCUP 2018, GNOME.Asia Summit 2018 and openSUSE.Asia Summit 2018 by Tooth

Last year I'd been COSCUP 2017 at first time, it gave a great impression of COSCUP. It's open, freedom and very energetic. It's very nice this year GNOME.Asia Summit joint with COSCUP and openSUSE.Asia.

In the first day, I participated several sessions, Benjamin's "Supporting Miracast on GNOME", David's "Desktop application: life inside a sandbox", Kat's "Plan your testing" and ZengZhengJia's "GNOME translation".

Children workshop by daisuke1230

At afternoon there are a workshop for children to hack a "Flying paper cup", my daughter very liked this lovely workshop.

GNOME.Asia BoF on Saturday

And at night we had a GNOME.Asia BoF to review the Good vs. Bad, we collected a lot of ideas to make the GNOME.Asia better in future.

In the second day, I made a topic about "flatpak vs. snap", introduced some concepts and basic usages. And I also listened Max's "Community experience", Kukuh's "GNOME Recipes", Shobha's "Humanitarian FOSS projects" and Wen's "GNOME.Asia experience".

As before, the great part of conference is that I enjoy meeting a lot of old friends and making new friends in these two days.

GNOME.Asia group photo by ArvinWu GNOME.Asia and openSUSE.Asia group photo by ArvinWu

Finally, thanks GNOME Foundation's sponsorship for my trip to GNOME.Asia Summit 2018.

More pictures from below links.

https://www.flickr.com/groups/gnomeasia2018/

https://www.flickr.com/photos/coscup/albums

11 Sep 2018 7:53am GMT

The last week I received a telegram message about Gtranslator, that was unmaintained for a long time. GNOME translators uses different tools to translate .po files, Gtranslator is a tool for translator that is integrated with the GNOME desktop, but with the time, Gtranslator is getting old and there are several known bugs that never get fixed.

So I decided to go ahead and become the maintainer of Gtranslator with the main idea of update the interface and fix mayor bugs.

Why we should care about Gtranslator

PO files are plain text files that can be edited with any text editor, but there're a lot of tools for translator to simplify the edition of .po files, these way the program will avoid formatting problems and can also provide some tools to help in the translation.

There's a lot of tools to edit .po files, so, why we need another application? why translators can't pick another useful tool if Gtranslator is unmaintained?

The main reason is the same as we've a text editor or the gnome-builder or other developer tools, because all users want to use applications integrated in the desktop, so it always will be better for a GNOME user a native GNOME app to edit .po files than a Qt one or a webpage.

The other reason is that we need to simplify the translators life to have better and more translations and that can only be done if we're developping the tool that translator will use, because in the future we can integrate Gtranslator with the gnome gitlab, or with Damned Lies, to download or upload translation files.

What's the plan

Gtranslator has a GNOME 2.0 interface, with toolbar, menus, statusbar and dockable widgets:

But in the git repo, the main branch was broken. Someone starts a big refactor, in 2015, to try to update the interface to look more like a modern GNOME 3 application but that refactor never ended so the master branch compiles, but doesn't do anything. There was a lot of widgets that was half ported to a modern code.

There's also some designs to modernize the interface, but the work wasn't finished.

My plan is to continue that work, modernize the UI, remove all deprecated code and warnings and then continue the development from there.

I don't want to spend a lot of time reworking the whole app to have a new one in two months, I want to have a functional app as soon as possible, and continue with a continuous development, improving the UI and the functionality needed by the translator team.

So the roadmap that I've in mind is:

1. Fix the current master state
2. Fix the known bugs
3. Redesign the interface
4. Enhance linking with Damned Lies

What I've done in one week

I started updating the build system, from autotools to meson build, and then I've added a flatpak manifest file, so now gnome-builder is able to build Gtranslator using meson and flatpak and it's easier to develop this way.

This build tools modernization is great because with the new gitlab we've now continuous integration, and that means that the gitlab compiles and generates a flatpak bundle for each commit, making it easier for testers to test new functionality or Merge Requests, you only need to download the .flatpak and install locally, no need to build at all.

Then I started to fix the master branch. There was a project selector view and then you go to the translation view. There was only the .ui files and not working yet, so I reworked that a bit and convert the project selector to a file selector for now and then when you select a file, you've almost the same old interface, but without the menu, toolbar and statusbar.

I've been moving the toolbar icons to the headerbar so we can have the main functionality working. We've now a functional application.

Plugins

Gtranslator has a plugin system and has eight plugins, but that plugins was disabled some time ago. So I've started to recover that functionality but instead of as plugins, I've started to move the plugins to the core app code.

The only plugin ported currently is the translation memory. I'll take a look to the other plugins and view if it's desirable to reimplement that or remove that code.

What's next

All the statusbar functionality is missing right now, I need to find some place in the new UI to show that.

I wan't to start as soon as possible to work in a new widget to show messages, instead of the current table.

The project selection part is a bit hard because I need to think about what's a project in this context. Currently Gtranslator is a .po file editor, but if we change that to manage projects like a group of .po files, I need to think about how to store that information and the easier way for translator to use the interface.

So if you've time and want to contribute in this project, go ahead, you can ask in the #gtranslator IRC channel or talk to me directly. Currently there's no a lot of issues in the gitlab, but as soon as I get a functional version in gnome-nightly flatpak repo and some translators starts to use it, we'll have a lot of things to do.

10 Sep 2018 7:08pm GMT