[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Thoughts on strengthen our Whonix community


#1

Continuing the discussion from Tor project support of Whonix:

@torjunkie asked some very meaningful questions and shared the insights on the Whonix community in this post.

I have also been thinking about how to strengthen our Whonix community for a while. I am going to present my ideas below and please feel free to share your insights, too.

What Whonix needs most right now?

In my opinion, contributors are the most valuable resource to an open source/free software project. It is even more important than donation. This is because when a person is driven and motivated by the incentive interest, his/her productivity and creativity can exceed several well-paid workers adding up together. Just looking at those familiar and lovely faces in the Whonix, you will understand how energetic a contributor can be.

My guess is there are potentially a lot of people who really would love to contribute to the Whonix community. One critical problem to them may be Whonix is not very contributor friendly right now. @Tibo 's question on how to contribute to Whonix also reflects the problem.

How to make Whonix more contributor friendly?

onionshare, as an open-source project, has a very high contribution rate comparing to other projects. It is not an coincident that it is contributor friendly at the same time. From my personal experience, I was able to use one afternoon to read the code and do a contribution even though I had never used it before. It is unfair to compare it directly with Whonix because of the scale difference between the two projects. But the concluded secret to its success in the post will benefit Whonix, too:

I did learn a lot from onionshare especially in terms of making a project contributor-friendly. I have concluded what I learned as follows and I would really appreciate if there is anything you would like to share on this:

Being responsive and constructive to issue

  • politely ask people who report the issue if they can help with that
  • let them do not panic because you will be able to help them

Being responsive and constructive to PR

  • what @mig5 has been doing (at least) in this PR is exemplary

BUILD.md

Provide a BUILD.md to guide developers to setup the environment:

  • how to get source code
  • how to install needed dependencies
  • how to test the application
  • how to build a package

Low coupling design and code

Low coupling design and Low coupling code make it much easier to add additional features on the existing one (my first commit on this PR https://github.com/micahflee/onionshare/pull/610/commits/b2c310f2e01ba192b9c78f51313c33bbc0002579 has only one line deleted which indicates onionshare has done an excellent job on this.)

dev_script

Provide a dev_script to “[l]oad onionshare module and resources from the source code tree” so that tester does not have to spend time building it and then testing it for every single change.

Unit tests

Robust unit tests to expose most of the problem immediate (helping contributor with the debugging)

Apart from the points mentioned above, there are many other things that could help Whonix becomes more contributor friendly.

Better Contribution Guide

I consider presenting people with a better guide to contribute, is the first priority to make it contributor friendly. I have been preparing and will release a guide on the Whonix workflow and this is part of the discussion.

A full picture of Whonix

Potential contributors and even users may also need a more general picture on how Whonix works to understand the beauty of its design. This demonstration can be done by a problem-driven article. For examples:

  1. Tor Browser is only one step away from de-anonymization --> then you may use a system that rejects all the non-Tor connections.
  2. The rejection of non-Tor traffic is controlled by an application which can be disabled once the system got root-privilege compromise --> Then how about two VMs for isolation.
  3. Tor bundled application in Whonix-Workstation and the Tor installed in Whonix-Gateway will create a Tor-over-Tor situation --> Then disabled the stacked-Tor by providing wrapper in Whonix-Workstation.
  4. Tor Applications in Whonix-Workstation need to talk to the Tor control port --> Then we need to filter the messages from Whonix-Workstation since it should not be trusted.
  5. There is identity correlation attack --> Whonix helps you with stream isolation for popular applications by default.

Better package description

The questions above can also be used in the packages introduction on Github. Whonix uses a script to auto-generate Github introduction, however, there are many redundant parts making the README of each package not easy to read. It is true that having some redundant parts is much better than leaving it blank, but it will definitely attract more people to look into the packages on Github if we could provide a well-written introduction and may be even a GIF picture in the README in the future.

A Whonix people page

A Whonix people page will make people feel their work is appreciated and let them have a much stronger sense of belonging to a community. The people page will also help people get familiar with the community members quickly and know who they should talk to when having a problem/idea.

To clarify, Whonix does have a maintainer list in Whonix wiki. But it is not like what Tor and Qubes have:

https://www.torproject.org/about/corepeople.html.en

Google Summer of Code and Outreachy

I just realized that Whonix could apply for the GSoC and Outreachy itself and GSoC policy may even prefer Whonix than those more famous projects. We should definitely take these opportunities.

How to make Whonix more well-known

We noticed that even some people who use Tails had never heard of Whonix. To increase the popularity of Whonix, I came up with the following ideas.

Recommendation from well-known people

It would be nice if people can publicly support Whonix and we quote their words to promote Whonix, like what Qubes does on its homepage. However, I also understand that recommending a project can be a huge responsibility and people will think twice before doing it.

Frequent release

Non-stopping commiting to the project may not be as noticeable as doing a release to the people outside of the community. We may consider doing more small release frequently than doing a huge release after a long time (like Whonix 13 -> 14).

Slashdot, Hacknews and blogging

When we do a release, submitting an article (probably just part of a Whonix Blog) to the Tech/Geek news will help draw more attention to our project.

Internationalization

Making Whonix support different languages may increase the user base greatly, which will in turn increase the potential contributor base.

How to make Whonix organization structure healthier

Avoid single point failure

@Patrick as the lead developer of Whonix has been involving into and taking care of almost every single part of the Whonix. The forum statistic shows that Patrick is the “most replied to” person for most of the contributors. However, considering the resource a human being can spend, this centralized communication and working mode is not sustainable with the growing of the community. The centralized communication mode will also put Whonix at risk of single point failure. Currently, let’s say, if Patrick suddenly stepped down, it may take a long time for Whonix to recover.

Luckily, many efforts has been made towards this goal. The exemplary interaction and collaboration between @torjunkie and @0brand have shown us working pairs or groups will help Whonix community to be more decentralized. I am also glad to hear that Patrick will focus on the core development because it will make Whonix less centralized, too.

What’s more, to decentralize Whonix organization, it is also important to let more people get familiar with the entire picture of Whonix so that they can in turn help/mentor other new contributors.


Private messaging for members with common threads posts
#2

@iry You are spot on with your analysis. I am curious about your experience looking at the core components like the OS build script. What barriers to entry did you personally find when looking at it?


#3

Great job and well thought out iry!

I’ve been doing a lot of thinking lately on how to encourage community members to contribute with wiki contributions. For the most part I believe people see the wiki and they are intimidated by the numerous pages and how well written it is. They may wonder what they could possibly contribute that is not already there. Not only that, community members do not realize that making contributions to wiki chapters is an effort by multiple people and the original content submitted is a far cry from the finished product. For me personally, those are the two main reasons why it took me so long to start contributing.

What can be done:

  • Better Contribution Guide (Great idea!)
  • list of tasks that need to be completed (wiki). Include simple/easy tasks that new contributors would feel comfortable doing. This would be good to break the ice and get people started e.g removing white spaces in the wiki.
  • make sure community members know that anonymous wiki edits means - no login of any kind is needed. i.e. Logging into forum account is not required.
  • make community aware that content is whats important when editing wiki. Others can polish up the page after its submitted. This works well for myself and torjunkie- who does the polishing of course.
  • Most don’t realize that completing smaller and/or menial tasks, which would have been done by a Whonix dev, frees them up to …code. When thought of like that, completing tasks like that is very important. This could be mentioned using better language of course. Speaking of that, where is my humble teammate?

More ideas to come?


#4

Imho you can’t compare Tor or Qubes to Whonix. They got a lot of funding over the years, have several paid devs and people dedicated to project management, business, funding. The target audience/user base is also much bigger.
While intrinsic motivation is great it usually declines over time and the main reason why feature X exists in project Y is mostly the devs like it or found it useful. Something similar could be said about why people dig into the source code or edit a wiki.
A lot of other open source projects suffer from the same problems as Whonix does.
The end result is then either

  1. development ceases completely like with torchat, ricochat and many others
  2. only features relevant to developers are supported
  3. donate if you want support
  4. post code or gtfo

The question is also where and what you want Whonix to be or which features are missing. I think the core components mentioned by @iry like protection against deanonymization, stream isolation … work quite well. If someone wants something new he/she would need to be either very convincing or choose option 3 or 4.

Sort of relevant current discussion: https://www.reddit.com/r/linux/comments/88d4pv/open_source_maintainers_owe_you_nothing/


#5

I am not sure.

Why doesn’t anyone contribute to make it easier to contribute?

I am not sure that more developer documentation helps to get more developers. Sometimes more content to read means only to swamp and deter potential contributors.

For example, long time ago an introduction into Whonix source code was requested. Now there is:

https://www.whonix.org/wiki/Dev/SourceCodeIntro

Is it useful to have or does this only increase the amount of stuff one thinks one has to read to just get started?


Does this also apply to Qubes or is it easier to contribute to Qubes?

Because…

There are a lot Qubes and Qubes-Whonix users. And Qubes-Whonix specific issues.

https://github.com/QubesOS/qubes-issues/labels/C%3A%20Whonix

Many of them don’t require understanding all of Whonix fully or even don’t require no understanding of Whonix source code at all. Some are pretty isolated issues not concerning a lot components. Yet no one submits patches to fix any of them.


Qubes can be happy to have found contributor HW42.

  • He wasn’t part of the original Qubes development team as far as I understand.
  • Qubes doesn’t have excellent developer documentation either. Building Qubes used to be far less documented and far more complicated.
  • Yet HW42 managed to get a similarly deep understanding of Xen and Marek. He’s even writing Xen patches. (I don’t have the skills to judge if he is as knowledgeable as Marek already or close.)

I don’t believe it’s useful to help too much get someone contribute something. Either, someone is

  • (1) capable to do it without a lot help
  • (2) not capable to do it without a lot help

There have been a few cases of people who kept asking in an attempt to get me to implement what they actually wanted to implement. And then when it was done to explain all the pieces when it was only about polishing work, the contributor disappeared.

So there needs to be a balance. People who have shown to not abuse it, who are have demonstrated to work and deliver, should be much more supported.

(Those who submit pull requests that only need changes are usually not suspect of trying to abuse anything. Care has to be taken when it starts as a forum discussion but never any code develops.)

(In case of (2) there is also the risk of good will and yet in effect consuming more than providing energy. So focus has to be on (1).)

Yes, but contributions should also be simple.


Most projects only have 1 or 2 core developers. I don’t see it often that new people join the core of a project after it has reached a certain level of complexity.

One advice of mine for starting a new Open Source project would be start it with multiple people and let everyone see how it goes from a very few lines to more and more lines. That way everyone gets it bit by bit and can see how it develops. Then no one comes late and has to catch up with a huge backlog of things to learn.


Debian has a ton of maintainers doing a ton of work. Yet they get no to minimal attribution.

(Questions to verify yourself: How’s the maintainer of the Debian Firefox package, or libssl package? How to find out who that is? Possible to find out, but not popular.)


#6

Feel free to continue any in separate forum subjects if useful.


That said, I wonder how Debian does it. Perhaps it is more of a social and organizational challenge than developer documentation issue. It’s not easy to contribute to Debian without ever meeting up with anyone from Debian, yet they have a ton of maintainers.


https://github.com/Whonix/Whonix links to https://www.whonix.org/wiki/Dev/Build_Documentation. And what do you think about the most recent https://www.whonix.org/wiki/Dev/Build_Documentation/14_full? Sufficient?

I could use some specific recommendations for specific packages to get that.

What do you suggest for https://www.whonix.org/wiki/Contribute?

Very good!

The git submodule stuff is complicated indeed. But I couldn’t think of a way to link the packages together from https://github.com/Whonix/Whonix in any other way. I wouldn’t find any similar project to compare with. Tails has also no great way to solve this. (Building Tails really from scratch is very hard. (Build basebox.) Most files are within their main repository. So no much per package separation last time I checked.)

What we could do is doing it like Debian / Ubuntu / Qubes.

  • There is no “Debian/Debian” main source repository that pulls all the packages together.
  • With Whonix…
    • One can start with Debian.
    • Install all dependencies from Debian.
    • Do not execute any binary code from Whonix.
    • Build and install all Whonix packages from source code.
    • Build Whonix (VirtualBox, KVM, raw image or physical isolation) from Whonix source code with the locally built packages.
    • Security feature determinedness builds: Easier to implement deterministic builds.

With Debian / Ubuntu / Qubes the process is different.

  • Developers build packages and upload to remote repository.
  • Downloadable images / templates are built using an Open Source built script but packages are installed from the remote repository.
  • Security feature determinedness builds: Harder to implement deterministic builds. (Newly updated, uploaded packages in the remote repository make it impossible to rebuild an earlier released image deterministically. Unless one would be copying/investing something like snapshot.debian.org.
  • That’s why they don’t need git submodules.

I wonder if I simplify the Whonix structure to Debian / Ubuntu / Qubes. Then we’d have

  • Whonix developers (rolling and often breaking)
  • Whonix testers (rolling and hopefully not often breaking)
  • Whonix stable-proposed-updates (rolling and hopefully not often breaking)
  • Whonix stable (sometimes testers gets frozen, tested and released)

–> Easier official builds.
–> Not so easy to rebuild a specific version. (Since no longer exact git commits of all Whonix packages are together in Whonix/Whonix.)
–> Packages could be more independent then. (What you probably mean by “Low coupling design and code”.)

That would be cool. Works for some components. For some it’s too complex.

That would be cool. Works for some components. For some it’s too complex.

There are too many packages / features / too much code in https://github.com/Whonix already. I doubt I’ll ever get to it. I’d have to throw out 80% or so (including tb-updater, sdwdate, whonixcheck, …) (aka “super slim core”) to ease maintenance and make time to concentrate getting dev_script, unit tests, build.md and what not implemented for remaining packages.

That would be cool to have. However, I am not skilled in making pretty websites, so have to rely on community contributions for that.

There are all cool but chicken (not enough time) egg (cool do have) issue.

We had a Whonix core task on GSoC through Qubes but no one applied.

https://www.qubes-os.org/gsoc/#project-ideas

Seems too big to complete with redhat and co. Or are also smaller projects hosting? Perhaps worth a separate forum subject.


#7

Good Evening

I love Whonix. I am convinced it’s by far the best anonymity tool available out there. While I like Tails, Whonix is by design much more secure. I wish more people would know and use Whonix. It requires a bit more effort at the beginning to get things working, but really it isn’t a big deal even for a beginner.

I understand developing and maintaining such a project requires huge work and man hours. I would hate to see the Whonix project slow down or even cease to be maintained. I would love to contribute, but how? I am not a developer, I am not a coder. I have read up a lot on Tor/Whonix topics, and I always try to know more, but my technical abilities are limited.

What can simple people like me do to help the project? End-users without the technical know-how to help coding.

More generally, I think the biggest problem that faces Whonix is its low recognition among Tor users and anonymity seeking communities. It is paradoxical, given how good it is a tool to achieve reasonable anonymity. Usually only fairly knowledgeable people have heard about Whonix, while Tails is known by every script kiddie. I don’t know how to change that. In this regard the collaboration with Qubes is a good thing, as it increases Whonix exposure. But there is still a lot to do to make Whonix more known.

Could it be related to its appearance? No offense, but the default Whonix theme is ugly. Of course this is a matter of personal preference (I hate KDE), but when you compare it to other modern distros, or Tails (its biggest competitor), new users may have the impression that Whonix is outdated, or not user-friendly. It really looks like a machine right from the 90’s. It may repulse new users.


#8

You’re helping just by being active on the forum. If you’d like to make other contributions.

https://whonix.org/wiki/Contribute#Easy_.2F_Anyone