Switches are one of idea, which makes libgreattao amazing. It’s allows interface to morph. For example: we have question dialog with one button(abort) and we add to it ok and cancel. Libgreattao can automatically puts ok and cancel into select list and put exit as separate button. Another example is implementing view switching in file manager. File manager will deliver list of file name, properties and icons and libgreattao takes full advantage about select view and view it in iconview control or in properties list control.

Look at video:

Readers of this blog should be already a little bit familiar with the Ailao brand, which we use for spinning off and commercialization of our academic research. Originally, Ailao was all about text and question answering, but there was always the theme of dealing with unstructured data in general.

Nowadays, Ailao is not just me (Petr BaudiÅ¡) anymore – but a partnership with Tomáš Gogár and Tomáš Tunys, fellow PhD students! And we are widening our breadth to cover documents in general, developing a machine learning computational platform Ailao Brain (just a codename!) as well as working hard on some exciting end-user products. We are also working on a prettier website (including a new look for this blog) and many other things, but more on that soon.

What I wanted to point out is our talk at Machine Learning Meetups Prague. The talk itself (video) is in Czech, but you can enjoy at least our English slides on our bleeding edge technology research (webpage information extraction and text understanding). Stay tuned for more!

Git itself provides support for running hook scripts at many events. It would be nice to run some checks automatically, for example when creating a commit.

The problem is not how to run the checks but how to integrate them, make them fast and safe, provide a nice output, etc…

Overcommit

By chance I came across Overcommit, a nice framework for running Git hooks.

It provides a wide variety of predefined checks which are easy to use. I found some of them really useful:

• Forbid commits to blacklisted branches - e.g. you can forbid direct commits to master because you want to use Pull Requests. This can also avoid mistakes, e.g. once I did a typo in git checkout -b and overlooked that. The following commit and push went by mistake directly to master…

• Run Rubocop automatically to avoid fix up commits later. I see “make Rubocop happy” commits quite often in YaST.

• Run the tests locally before pushing the changes, that makes sure the tests still pass. Sometimes you forget to run the tests or simply you are too lazy to run them.

• And last but not least it can check spelling of the commit messages to avoid typos.

For more details see the Overcommit documentation.

Speed?

A very nice Overcommit feature is that it wants to be quick, your usual git workflow should not be slowed down because of the hooks.

For example it tries running all hooks in parallel and the Rubocop hook checks only the changed files, which speeds it up for large repositories a lot. Running Rubocop over all source files in the YaST registration module takes about 7 seconds on my machine, but when a single file is checked it takes just a fraction of a second.

Installation

I have prepared RPM packages with Overcommit, simply add the YaST:Head repository and run

zypper in "rubygem(overcommit)"

Initializing the Hooks

Now go to your Git repository and set up the hooks:

• Use overcommit --install to install the hooks.
• Add the .overcommit.yml configuration file.
• Run overcommit --sign to sign the current configuration. You will need to run it again whenever the config files is changed. See the Security section in the documentation for more details.

You need to install Overcommit in each Git repository separately, but it is possible to automate the setup.

Using the Hooks

Then you use the git commands as usually, you do not need to change anything to run the hooks. You will just see the results of the Overcommit hooks in the output.

If a hook fails the whole git command fails. So if for example the Rubocop hook fails when creating a commit then the commit is not created and you can fix the problem early.

If for some reason you want to temporarily disable the Overcommit checks run the git command with OVERCOMMIT_DISABLE=1 environment setting.

Example Configuration

Here is an example .overcommit.yml file proposed for YaST:

PreCommit:
  # do not commit directly to these branches, use Pull Requests!
  ForbiddenBranches:
    enabled: true
    branch_patterns:
      - master
      - openSUSE-*
      - SLE-10-*
      - Code-11*
      - SLE-12-*

  RuboCop:
    enabled: true
    # treat all warnings as failures
    on_warn: fail

CommitMsg:
  SpellCheck:
    enabled: true
    # force using the English dictionary
    env:
      LC_ALL: en_US.UTF-8

PrePush:
  RSpec:
    enabled: true
    command: [ "rake", "test:unit" ]
    # do not fail because of translations
    env:
      LC_ALL: en_US.UTF-8

Example Session

I recorded an example session to show the mentioned Overcommit features in action in the registration repository:

It looks nice, isn’t it? (If you like the git status in the bash prompt check this older post).

Conclusion

It looks very promising and it could catch some obvious mistakes early, I will give it a try. I will try using it for some time and then we will see if it could be used in YaST more widely.

In photography most optical lenses use mechanical diaphragms for aperture control. They are traditionally manufactured from metal blades and works quite good. However metal blades exposes some disadvantages:

• mechanical parts will sooner or later fail
• the cheaper forms give strong diffraction spikes
• manufacturers need more metal blades for a round iris, which is expensive
• a metal blade with its sharp edges give artefacts, which are visible in out of focus regions.
• but, contrast is very high by using opaque metal

In order to obtain a better bokeh, some lenses are equipped with apodization filters. Those filters work mostly for fully open arperture and are very specialised and thus relatively expensive.

A digital arperture build as a transparent display with enough spatial resolution can not only improve the shape of the diaphragm. It could feature as a apodisation filter, if it supports enough gray levels. And it can change its form programatically.

Two possible digital diaphragm forms:

• leverage existing display technology
• better aperture shape for reduced artefacts
• apodisation filter on demand for best bokeh or faster light
• programmable or at least updateable aperture pattern (sharp/gausian/linear/…)
• no metal blades or other mechanical parts to fail
• over the years get cheaper than mechanical counterpart
• reduce number of glas to air surfaces in optical lens design
• integratable aperture into lens groups
• display transparency increases quickly and is for OLED at 45% by 2016, which means at the moment just one f-stop
• mobile demands high display resolutions anyway

The digital arperture can easily be manufactured as a monochrome display and be placed traditionally between two optical lens groups, where today the diaphragm is located. Or it is even possible to optically integrate the aperture into one lens group, without additional glas to air surfaces, as is needed with moving blades. Once the optical quality of the digital filter display is good enough a digital diaphragm can be even cheaper than a high quality mechanical counterpart.

More and more security incidents in Free Software projects get publicized in a way that anyone & their grandma understand the impact. Some of these carefuly crafted "campaigns" even make it to the main stream media. This trend, among other things, has sparked a discussion about funding Free Software to sustain the infrastructure everyone is building upon. A discussion which, in our venture capital driven tech world, mostly evolves around financing as a means for getting resources. Who can/should pay whom, to develop Free Software and how. I would like to add another view at funding, one that in my opinion has way more to do with Free Software ecosystem than cold, hard cash: collaboration of free people.

Freedom and what you make of it

The ability to run, copy, distribute, study, change and improve software. This is the essence of it, without these fundamental rights, software is not Free Software. And these fundamentals imply a purpose: Freedom, the ability to do as one wills. To do to software as one wills.

As always, what people make of their freedom is up to them. Some go an preach about it, most ignore it, some use it for their personal gain. However, it's undeniable that the Free Software movement has entailed a community of systematic world wide collaboration. In software development, and I would argue in many other aspects of todays life. We all know the examples of hundreds of developers hacking together on Linux, thousands of authors on Wikipedia per month, millions of pictures in the creative commons and so on. Obviously, if you give people the freedom to do as they want, many of them are inspired to work together for the common benefit. And because Free Software entails collaboration and collaboration is about individuals, making projects sustainable has many dimensions. Money is one.

Challenges and what you do about them

Of course there are many things going wrong today with making Free Software projects sustainable. For instance a growing imbalance between developers and users (Noah Kantrowitz), that developers think they are not getting fairly compensated (Ryan Bigg) or that everybody is waiting for someone else to do something (Marijn Haverbeke). Contributor burn-out. There are many, many more.

The solutions to these shortcomings, discussed in the past months, most exclusively focus on monetizing work. Be it through business models, crowd funding, grants and other forms of injecting money into the equasion. In a recent piece, Nadia Eghbal even argues that somehow venture capital must flow back because all of the VC funded software companies somehow base their work on Free Software. Steve Klabnik thinks this is already happening. Here is the thing: Money will buy you people who contribute, sure thing. But is it money for contributions that made the present? For sure not. Collaborative contributions are the currency of Free Software.

openSUSE Community by Henne Vogelsang licensed CC BY 4.0

People and how you treat them

People have made Free Software as big as it is. Active contributor communities. Humans from all over the world, with different talents, levels of expertise and cultural backgrounds collaborating. All with their own motivations. Some want to learn from others, some scratch their itch, some want to train their skills, some want to boost their resume, some contribute on behalf of a company, some just try to avoid being bored on a Saturday afternoon. If your project does not actively channel all of these ambitions into contributions, if it does not organize the collaboration, if it is not offering shared responsibility and if it does not attract new contributors it's doing something wrong.

An individual/company slapping a license onto code, uploading it to github, merging pull-requests and answering issues is not making a sustainable Free Software project. Yet this is what many do today.

If you look at the most prominent examples of the software people worry about, openssl or NTP, they are failed communities. They disintegrated to a point where collaboration ceased to exist, the remainaing people were not able to do anything to change this (I'm sure they tried hard) and in the end something bad happened, and now they are clearly not sustained. Now we all can throw some bucks together to keep developers developing but that wont make those projects sustainable Free Software communities. In my opinion paying for contributions is to capitulate in the face of to the task of building a sustainable community. There are other things which are more important.

Fund Free Software without money

I guess the most obvious way to fund Free Software projects without money is to contribute in any way possible for you, duuhh. But apart from that I think there are more things we as the Free Software community at large can do better.

In my opinion it's time we help each other to organize collaboration. We need to share best pratices about creating sustainable contributor communities that attract new people.

We also should be more upfront with each other when we notice communities failing. I have contributed code to NTP a couple of years ago and didn't care that it was such a bleak place. Someone merged my patches, I was off again. In retrospecitve this feels like not telling someone their flap is open.

I also think that we need to do better with copyleft project resources. We have the choice between 27 different C++ compilers but if you're looking for marketing materials, web site themes or templates of contributor guidelines you will draw mostly blanks. Convincing prospective users and contributors that our Free Software does something significantly better than the competition is very important, yet we leave each other hanging with this.

Now go do something

Luckily somewhere Free Software people already have started with all of this. There is the community leadership forum where you can talk about all the aspects of your community. opensource.com curates a blog of best practices. Designers started to rally around opensourcedesign.net. People all over start to address the obvious diversity problem our community has. Next month (July 2016) there is a conference to talk with other Free Software people about Open Source & Feelings and I'm sure there is more going on out there.

What do you think about financing Free Software projects? Are you going to do something about making Free Software sustainable?

Yours truly, Henne 💚