Tuesday, September 18, 2012

Thinking about Nvidia in Ubuntu

Here's a basic description of what I'm talking about at UbuntuForums Ubuntu+1.

Makes sense? Let me know.

Thursday, May 31, 2012

A lot of work being done

I've been away from UbuntuForums and Ubuntu+1 sub-forum for 20 days or so. Setting up our server in a way that team members can use it without creating extra management work (or would break our host security policy) demanded more time than I had previously imagined. 

Installing Apache, a CMS, etc is easy, of course. However, in order to do it right, I had to create basic drafts for all daemons, web services, features we plan to use now and in the future. Only then, I could create a complete process/specification that is solid, safe and extensible, thinking about the future. From members single authentication to many services at once, users/groups/permissions for every feature to log management and snapshots/backup plans, it all had to be designed, implemented and tested.

The main goal of this effort is to create a solid basis for members to work on and improve. U+1 will encourage all members to:
  • Propose & create team groups, areas and activities;
  • Submit ideas, manage their submissions;
  • Convert selected ideas into private or public blueprints;
  • Add content to and discuss blueprints;
  • Convert blueprints to formal projects (with leadership, management, recruitment, resources, goals, schedule, metrics, etc);
  • Manage formal projects, in all aspects;
  • Implement and manage projects.

Why is this challenging? Well, we're not only talking about development. This should also encompass testing, documentation, translation, training/education, recruitment, accessibility and even marketing/communication, sponsorships, partnerships and professional services: The infrastructure must be solid, yet flexible enough and ready to accept members work in many areas. That will be done using some CMS features (with customization to user profiles, forum/blog), MediaWiki functionality, php-bb, etherpad-lite, email aliases and mail-lists integrated to web services, local private/public pastebin/imagebin, git server, packages/updates trackers, bug trackers, key-based SSH access to shell accounts, PPAs, custom IDE (eclipse with PyDev, CDT, PDT, Shelled, Wikiedit, Wireframe Sketcher, Mylyn, git and bzr), some automation and VMs, etc. It's a lot of work to be done on QQ. Hopefully we can focus on putting it all together still in this cycle, but there's no reason to rush. We will do it right.

Despite all this technical work, I've been talking to a lot of people, current and future members, other Linux users and communities, and getting some feedback on a viable long-term roadmap for the team. All feedback, ideas and opinions have been positive - I am more convinced than ever we're on the right track.

As soon as the new beta site is up, the main priority is to upload a list of tasks members can contribute. I'll be working tomorrow on final tests of the Apache/CMS/git integration. We will be using a professional CMS/Template as a base for all development and customization (to speed things up and focus on what's really important - that's the whole point of using a CMS). This is already up in  a git development tree. 

It's 4:53AM here... Tomorrow I'll send instructions to a couple members that volunteered to contribute with web development, so they can test it too and, hopefully, start working.

Wednesday, May 9, 2012

The team server is up :)

Finally! We're at uplus1.org

Now we'll look into implementing:
  • OpenID for login
  • Define Public/Private areas and content
  • Customize the Joomla Template, add areas/resources
  • Implement MediaWiki as the main host for the team documentation
  • Convert current Wiki content (MoinMoin) to MediaWiki (as drafts to be improved)
  • Set current wiki content to sync from MediaWiki
  • Team Blog (multi-author)
  • Provide members with mail aliases, blogs (or track their blog and social updates)
  • Team bugtracker (Launchpadlib-based)
  • Embed Shared Google Calendar for team events
  • Deploy / Customize Early Adopter (integrate with Team Tracker)
  • Verify / Inform Copyright/TM Legal Notice clearly
I'm fixing the template as you read this (and for the next days) and I'm too lazy to do it on the background and post a blank "under development" message. So don't mind all the breakage you'll eventually see in the page.

Contributors are welcome to help us put all of this together. We need people that can help with web development (Joomla, HTML, PHP, Javascript, JQuery, etc), web design, doc writers, security, etc. 

Monday, May 7, 2012

It's time to step on the break - Let's relax for a cycle

Unfortunately, testing discussions seem to be far from the reality of the U+1 Team and the issues we have discussed over and over in last cycles. We had 100% of these issues posted to QA meetings blueprints. Most of them are being ignored. A few less important topics are being discussed for a couple seconds.

Looking from another angle, 99.9999999999999% of Ubuntu users do not participate in testing, bug reporting or contribute in any way. There's nothing wrong with that. They're users, we're users, community contributors. We did our share and it's ok to take some time off. 

I suggest we do not participate in general testing activities and bug reporting for a cycle. There's nothing wrong with that. Many other users will test and report, there are all these tools and automation, the world won't fall apart. Let's test the Development Release for ourselves, simply because we love it. Let's invest in learning stuff, having fun. Let's recruit a lot more users and grow, learn a lot and raise the bar in testing, teach others and mentor new members, develop our tools and get used to them, integrate the team and create cool processes, develop rich documentation.

Maybe I was wrong and too ambitious. Perhaps that's what we should invest on, being such a new team.

Once Ubuntu is ready to respect this team and its testers once again, we'll be ready for action and more prepared than ever. It will be relaxing to just hang out, have fun and learn for a while.

By the way, here's something in recognition of testers work throughout PP and previous cycles.


UDS - QA-Related Meetings (updated May 7th, 2012)

For those that couldn't go to UDS, but still care about QA and testing, below is the list of QA-Related meetings dates/times and a link to their blueprints. Clicking on these links will open a Launchpad page in which you can read the blueprints specs and add your thoughts to the discussion whiteboard.

* UPDATE: List updated with IRC channels @ Freenode (irc.ubuntu.com) for remote participation (May 7th, 2012)

* UPDATE: Click the times to open them in timeanddate.com and check the conversion to UTC or the place of your choice. (May 7th, 2012)

Monday (May 7th)
16:15 - 17:00 PDT: qa-q-community IRC: #ubuntu-uds-room-201

Tuesday (May 8th)
11:00 - 11:55 PDT: qa-q-release-communication-improvements IRC: #ubuntu-uds-junior-ballroom-1
12:00 - 13:00 PDT: qa-q-manual-app-testing IRC: #ubuntu-uds-grand-ballroom-g
15:00 - 16:00 PDT: qa-q-isotracker-testcases IRC: #ubuntu-uds-grand-ballroom-g

Wednesday (May 9th)
10:00 - 10:45 PDT: qa-q-ubuntu-qa-tools IRC: #ubuntu-uds-room-201
15:00 - 16:00 PDT: qa-q-backlog IRC: #ubuntu-uds-room-201
17:05 - 18:00 PDT: qa-q-metrics IRC: #ubuntu-uds-room-201

Thursday (May 10th)
09:00 - 09:55 PDT: qa-q-community-of-practice IRC: #ubuntu-uds-grand-ballroom-f
10:00 - 10:45 PDT: qa-q-iso-testing-process IRC: #ubuntu-uds-junior-ballroom-1
16:15 - 17:00 PDT: qa-q-qa-testing-cadence IRC: #ubuntu-uds-grand-ballroom-h
16:15 - 17:00 PDT: qa-q-ubuntu-automation-test-harness IRC: #ubuntu-uds-grand-ballroom-a

Friday (May 11th)
12:00 - 13:00 PDT: qa-q-add-test-coverage IRC: #ubuntu-uds-grand-ballroom-g
15:00 - 16:00 PDT: qa-q-builds-smoke-testing IRC: #ubuntu-uds-grand-ballroom-g

Video streams and remote participation via IRC were mentioned and links to it will be available soon. We must try take part in these discussions as their results have a potential influence in our work with Ubuntu Development Releases.

Sunday, May 6, 2012

About testers and PP Release Notes

Some people have warned me today that the list of testers was, unfortunately, not linked to Precise Pangolin Release Notes. I have found that the link to the Release Notes is placed at the bottom-right of the download page. See the screenshot.

Ubuntu download page and the location of the link to the Release Notes 

However, as it was brought to my attention, the page this link points to has no mention of testers. Testers are mentioned at another page, not linked to Ubuntu.com or to the Release Notes page. A cached image of the current Release Notes page can be accessed here.

Well I don't have much to say about it. It's frustrating. That's not how things should have happened and it does give us a lot to think about.

Sunday, April 29, 2012

U+1 - Focusing on the Basics

Ubuntu Precise Pangolin (12.04) was release and, at U+1, we're already using Quental Quetzal repositories. We have some time now, until development starts, to define what our team will target in this new cycle.   

We've seen some basic problems, persisting bugs, move from release to release in the last cycles. By helping users at UbuntuForums General Help support area, Ubuntu+1 sub-forum and other communities I participate, looking at old and new Launchpad bug reports and also my own experiences with Ubuntu, I think we have an undeniably weak spot in the most basic part of this OS that can (and does) largely impact its adoption rates and branding: The installation process.

Many will say they never had a problem with it. Or that it has improved a lot in previous cycles. I won't disagree to that. But I ask people that consider Ubuntu's installation as a perfectly working and reliable process to look at this page and count the number of mentions to Ubiquity. Go to a popular support resource, like UbuntuForums and count problems that relate to Ubiquity/Wubi, Boot/Grub or basic hardware drivers and kernel modules. Google for tutorials on this OS and see how many different people invested their time and knowledge to invent different ways to help users fix issues related to the basic installation process.

I think that having a reliable installation is a priority, and it's Factor #1 inhibiting a larger adoption of Ubuntu in end-users PCs and the corporate segment. I'll discuss Factor #2 soon.


1. Getting the OS
  • Define a standard, certified and working process for downloading and burning the OS ISO:
  • Properly downloading and burning a MD5 checked ISO (CD/DVD/USB);
  • Making sure the media is set in a way that PCs can boot from it;

2. Installer (Ubiquity) processes
  • Understand all Ubiquity installation steps and make sure they are sane, do not crash or fail
  • Verifying that partitioning is done correctly. Previously existing partitions should be respected, a proper MBR must be set.
  • Old instances of Grub should be removed or updated, and a proper Grub install must occur

3. First Boot (Jockey)
  • Proper hardware detection, mainly for VGA and Network hardware (Wi-Fi, Ethernet)
  • Present the user with human-comprehensible text, explaining the urgency of choosing a driver/module for each hardware, as well as the pros and cons of each
  • Properly execute the user choices


It won't be easy to have a whole team focusing on these targets. Likewise, managing their work and contributions, ideas and insights will also be a challenge. But it is doable.

In my next posts, I'll detail my strategy to join our team resources and fight these bugs.

Tuesday, April 24, 2012

Quantal Quetzal: Focus on quality. What to expect?

Ubuntu Precise Pangolin (12.04) reaches the end of its development cycle this Thursday (Apr. 26th, 2012). As this release now becomes the main Operating System for most users and a hot topic for FOSS-related blogs and other media, it is time for us testers to say goodbye to it and, once again, move on to the upcoming release.

Mark Shuttleworth announced it today: Ubuntu 12.10 will be named Quantal Quetzal. Ubuntu old-timers won't be amazed by our traditional naming convention.  If you read Mark's announcement, you will realize what is really important about this development release: supposedly, it comes with a promise for an enhanced focus on quality.

It's exciting. Yet, I couldn't interpret this announcement in a positive way. Everyone should read it and reach their own conclusions.  I'll express my point of view and my interpretation in the following paragraphs. 

"Keeping the release usable at all times"
This was started in PP due to a request from Mark, which was formalized as a blueprint. In theory, it encourages users to try the development releases, creating a larger amount of bug reports. In practice, people discuss:
  • Do we really need more low added value bug reports, mostly from non-technical users? Or do we need less, but high added value, bug reports from technical users? I pick the second option. 
  • Do we want developers to focus on keeping the release usable for non-technical users or do we want them to not feel restrained and be bold in their coding and innovation? Again, I'll pick the last.
  • Do we want our support resources to be flooded, daily, with help requests from non-technical users that broke their systems while installing a development release? Or do we want our small group of active contributors and testers to focus on what they should primarily do (testing)? Needless to say, I stand for testing.
  • What do we gain by having more non-technical users trying an unfinished product, not reporting bugs or reporting things that are not bugs and using support resources? Many simply disable or ignore apport warnings. It only makes some sense if they run automated tests in their PCs and feed a database automatically. Oh, wait, that's the idea, right? Maybe we could also get 1 million monkeys to test Ubuntu. It's certainly easier than investing minimal resources and efforts on proper training and education of good testers.
"Continuous integration, smoke testing and automated benchmarking of the release, since we can do it all in the cloud"
Unfortunately, this is a confirmation of Ubuntu's high-level management strategies to rely more on automated processes than on testers and real brains. What we have seen in this cycle, with tools like System-Testing and Checkbox, the "Friendly" initiative and the non-creative and repetitive focus on the pointless and inhumane ISO-Testing efforts supposes the nonexistence of technical users willing to contribute by testing development releases in-depth and in smart ways. It assumes all testers are non-technical, thus pushing bizarre and tedious testing tasks to as many users as possible (note that I mentioned users, not testers) and justifying that with pledges for more and more contributors. Sadly, this one is, at the very least, insulting. If you disagree, please find one single mention of human-based testing, living testers, in this announcement.

"Quality starts at the source, it’s not something that can be patched in after the fact"
As expected from the above, Ubuntu will extend its pressure over developers and try to push that upstream. Again, it's all about tools, with no mention of testers whatsoever.

"From a styling point of view, we think in terms of quadruples: this next release starts a cycle of four, which will culminate in 14.04 LTS. So there’s an opportunity to refresh the look"
Contrary to the expectations of many, including me, we may see yet another cycle of extensive focus on UI/UX. Unity is cool, works much better now and you might think it could be fixed, improved, enhanced in parallel to a big effort on something else. Something like fixing new and, mostly, persistent bugs. It makes sense to most people I talk to, when we're talking about a non-LTS release. However, judging by the announcement in question, I see no indication of that. 

So, what can we expect from QQ in terms of quality? My answer is: Unfortunately, no change from what we have seen in PP. If we want to do things different, we can't expect much support and endorsement from the OS high-level management and it's legacy structures. I see no change in the horizon.

Wednesday, April 18, 2012

Restoring the OS to default

Note to self: Ubuntu should have a button labeled "Click here to restore factory settings" in gnome-control-center. The same option should be presented on Grub. It should have 2 steps of confirmation and require user password. Threads like this, and so many others we'll see in the next 30 days or more, make it clear it's impossible to help most users. 

Maybe, during install, the user could see an option to create a restore partition. The ISO would copy itself to it. This partition wouldn't be mounted on fstab by default, therefore being protected (to some degree) from most users. It's more or less what Windows does now by adding the OS installer to a hidden partition.

It's not enough for Ubuntu to work. It needs to fix itself. Maybe that's what's missing.

Saturday, April 14, 2012

Small victories and good perspectives

We are gladly beginning to work as a team at U+1. We have reached 40 members, with many technical users joining lately. Most meetings were fruitful (specially on the LiveTesting initiative) and members are gradually interacting through our IRC channel (#U+1 on Freenode). Some are volunteering to take over tasks.

In my opinion, the main step to "trigger" members contributions in the new cycle (QQ) is to provide them with innovative, easy to use and effective new tools. So, infrastructure is the main focus now.

I have taken the challenge of providing this team with some infrastructure to myself. Right now, I'm working on:
  • I have implemented the typical MeetBot that everyone uses in my own infrastructure. But I'm changing it's code to offer some interesting features (bug tracking related);
  • I'm working on a Team Bug tracker tool, that is able to put all U+1 Launchpad Bug Reports and their status in a unified HTML table. The goal is to allow our team members to follow-up on each other's reports, improve and re-test them, check if they were really fixed, etc;
  • I'm also developing a system to auto-diff current ISOs from the previous ones and point out which packages/files were changed from day to day, as well as a list of previously reported bugs for the target packages. The project is temporarily labeled "Today's Targets". Ideally, we can have our members look at this webpage and dedicated their time and brains to what's really relevant, reporting bugs as soon as they enter the code, and not testing the entire ISO a couple hours after every milestone release;
  • I have registered .org and .net domains we may possibly use soon, to host all these tools and future ones.

I want to have testing-versions of all this tools up before QQ alpha. Once they are up, it won't be hard to get some people to contribute, improve and, maybe, maintain them. This is not targeted at taking the workload off me: I believe that a crucial factor to keep tools adequate to its users reality and, thus, interesting, usable and adherent to testers true needs, is to have them developed and improved within the team, by its own users.

Other than that, potential alliances and talks with true leaders are beginning to solidify into ideas to partnerships. The whole idea of working together in a partnership-based model is gaining momentum (finally). Threats still exist (and they always will), but they are not stopping this team.

Release week
I think Release Week will be important for us in this cycle. Many users will be updating from LL, MM to PP and attempting to run a hardware accelerated ("3D") desktop for the first time.

As we've seen before, a flood of problems with destroyed partitions and crashed installs, improper setup of VGA Kernel modules and drivers, outdated VGA hardware (only informed to user after the update process), wrong X settings, broken perms and modes in setup files, etc, is about to happen (again...).

Although it can be troublesome for UbuntuForums staff, I see it mainly as a good "reality check" (AKA "cold shower") for the overly optimistic and a "wake-up call" for everyone else.

A strengthened will to change, strong words from otherwise quiet or cautious (political) leaders and greater adherence to bolder proposals usually arise in such times. Who knows, maybe those responsible for the current structure and status can open some channels to U+1 in such a scenario. Time will tell.

Monday, April 9, 2012

User types, gaps and building bridges

When I used to go online in the 90's, mostly all users were technical. Everyone on BBSs was part of a group and working on something complex, talking about this or that box and trying not to pay anything to the their telco. Later, on IRC, everyone was using BitchX and trading cracked dial-up ISPs passwd files and dl-view "educational" videos (more like animations, actually). It was fun, I won't deny it. 

Later, as the Internet became absolutely usual and present in any household, communities were flooded by sane, ordinary and respectable citizens: common people (or almost it). This was nice. You can now see people talking about anything and building bombs or hacking the world isn't the only subject.

However, polarization between technical and non-technical users has created a huge gap. Moreover, the most relevant gap we have is actually between technical users, as I'll explain soon. When building communities and trying to motivate users in FOSS projects, it seems like half of the members are at each side of this canyon. Joining communities and motivating users to participate more actively of projects seems to be directly related to creating bridges some will use to cross this gap. 

I believe most people will agree that there are (at least) 5 basic types of FOSS users: 

  • The clueless: Ordinary users with no technical knowledge at all. When they manage to go online and find some community that seems to refer to the software (or OS) they're using, they just post a senseless complain (more likely) or a reasonable support request (more rarely, and deeply appreciated). At any rate, these users can't contribute to projects in their current skill and experience levels. We help them and they disappear.
  • The villains: Villains will do what we expect from them in real world, but in the digital universe. They will disrupt communities, spread FUD, attempt to break groups apart, start flame wars, destroy structures in exchange for power, etc. This group also includes the haters, the pickers, the owners of the universe, etc. These individuals are also useless to projects and teams.
  • The aspirants:  I define the aspirants as those that don't feel like searching, reading, asking for advice, etc. They memorize a couple procedures and like to repeat them over and over. They usually paste links to long, complex, high-level tutorials when common users ask any obvious question. They are not really looking to learn and improve their technical skills. These people are friendly and present at any community, but they won't commit to any project. We can't count on them.

And here's where the polarization occurs.  The remaining types are:

  • The hackers: There's a broad range of hackers, with different skill levels. We have those that are obsessive over a limited number of applications and know all of its features and tricks but know very little about other important things and the "big picture". We have those that go deep into every software and aspect of an operating system. And we even have new users, that know very little, but are driven by hacker instincts and learn fast. However, for all hackers, all the fun is in not following any rule (as it has always been). Most hackers are not specialists but generalists. They like to dig everywhere, without focusing too much. Generally, they won't care about developing a complete application or committing to a project from beginning to conclusion.
  • The developers: And we finally get to the developers. A generally very small and overloaded group of highly focused individuals, that adhere to processes, rules, methods and are, effectively, specialists. They typically obsess over one problem or task (or a small set of them) and focus on solving it programmatically. These people are capable of giving up the fun of experimenting hundreds of applications and software in general, and focus exclusively in a small group of applications and programming tasks and methods. 

A typical team commonly has all the user types above. The only ones with potential to create value are the last two. Hackers are generally much more numerous than developers. There's an understanding that hackers won't do what you ask them to do and that developers are too busy doing something else. It's a dark scenario.

One possibility, which I think most serious team managers consider, is that many hackers (not all) would enjoy the tutoring of developers on programming, debugging, profiling, etc. And, on the other hand, developers could use the fresh ideas, and also the testing, of hackers (they can produce better test-reports than ordinary users, the clueless). Therefore, by providing ways to create this interaction, one could enhance motivation and increase commitment and participation levels.

It sounds like a good idea. There are, of course, some potential risks of conflict, bad communication and other problems. But, since we're talking about exchange of knowledge, it can't be bad.

A problem: I'm unaware of a single community that has implemented such project and managed to maintain it for a long period.

In the U+1 Team, we have at least 4 ideas in our "brainstorming" area to create bridges between hackers and developers. But we need more. And, additionally, that has to be done without selling the team to the lobbyists that seem to have solutions for all issues in exchange for the team soul. It will be fun to see if we can manage to succeed in some of these projects, and the results it actually creates in terms of team improvement. Only time (if that's allowed to us) will tell.

Can a small change in Launchpad help protect teams?

I've been wondering how the "teams" mechanism can be poisonous to Ubuntu. Any individual can start a team and ask people to join him in achieving some goal (if any). This is great, however:

  • Most teams have no purpose but to act as a "Tag-Team": "People that like this", "People that do that". These teams are joining others and being absorbed, creating numbers (power) to individuals over absolutely nothing: No real goal, purpose, ambition or project.
  • A small number of teams actually has goals, creates foundation documents, stays true to them and targets something.
  •  If a team is successful, it immediately becomes the target of other unsuccessful teams. It has to be absorbed by some other structure, to benefit some individuals political agenda. A power-game begins immediately.
I'm not saying teams shouldn't exist. Good projects exist and amazing work is done within many of them. But teams shouldn't have the ability to join other teams. 

Launchpad should present teams with the possibility of establishing "partnerships" to other teams. When a team (it's administrators) starts a partnership, it would have to fill in some required information, such as:

  • The partnership name;
  • The partnership goals;
  • The involved parties;
  • The responsibilities of  the involved parties;
  • The reason why a partnership is beneficial to all involved parties;
  • The date in which it automatically expires.
Administrators of the involved teams would then receive a confirmation email from Launchpad, read and accept (or refuse) the terms of the proposed partnership. No team would acquire administrative power over the others structure and members. Each team would keep its members.
If Launchpad were to disable the "Team-Join-Team Fest" (AKA TJTF) and replace it for a "Partnership Management" system, we would be cutting off one of the main methods for manipulating, trading and acquiring power: Absorbing teams.

Not only that: As I mentioned in the previous article, partnerships target efficiency and are easily manageable. We would be able to improve the community measurable results.

What about "Tag-Teams"? They would still be created. But, frankly, who would care about the "Team of people that like pie" and its eventual partnerships? Let them be, as they are just a "social-networking-like" feature that entertains the community.

Sunday, April 8, 2012

Mark Shuttleworth approached the subject

Mark Shuttleworth has posted an amazing article here. (Thanks for the link Graham). This paragraph is very relevant to what I've been thinking about lately:

More challenging is the need to recognise that the success of Ubuntu will attract voices that are more interested in influence than participation; now that Ubuntu is a conduit to millions of users, it is an effective way to broadcast to all of them. When we started, the only people who showed up were those attracted to our values and our mission, now we will attract folk who are interested in our users. That’s why we should weigh the voices of those who have actually contributed much more heavily than those who seek to influence the project without doing any work. And it’s why we need to make sure that the tone of conversation stays true to the Ubuntu code of conduct, and the goals of the project – to serve the needs of others rather than ourselves – maintain primacy.
It's challenging to get people to understand that projects are created over a set of values and that those values should be preserved. Mark clearly sees how successful projects can easily attract those that look only for power.

Independence and Partnerships

Independence and partnerships. These are the solid pillars the U+1 Team was created to rely on. The reasons I have chosen these values are described below.

Independence: It's fairly easy to create any team, promise the world to everyone, ask them to sign up. And then submit this team to any other, artificially producing a "recruitment success" to the team you submit to. You can easily exchange that for a "power position". That's the standard procedure in online communities and the true reason most of them fail. 

The U+1 Team, on the other hand, was designed to rest over a solid and transparent set of rules and governance, which aim at effectively inhibiting this vicious tactic. As long as the team is able to maintain its independence, it can work with other teams through partnerships, much like the real (free) world works. If you have any work experience, you know your employer is unlikely to buy all the companies it relates to. Most likely, it will relate to them through partnerships.

Partnerships can be started, have clear deadlines, delegated tasks and roles, and goals. Their scope can be defined and limited, and they can be ended when it becomes uninteresting to any of the involved parties. New partnerships can be established to replace failed ones. Partnerships allow us to track results of a group and, also, of the involved members.

Independence and partnerships can produce the very same results (if not better ones) as submitting teams and it's members to the typically large, unmanageable and impersonal member-hungry legacy structures we see in the FOSS world. 

However, there seems to be some serious "problems" with those two strong principles: 

  • Partnerships are a two-way street: Both sides have to provide something. You can't simply take what you want in a partnership.
  • They demand people to get involved. They expose each one's work and differentiate real contributors from game players. Leaders also have to show results.
  • Since the power of people in the FOSS world sadly comes from the number of people they have below them, these two values do not serve the ones looking for power. These two principles are actually an obstacle to their strategy. In such cases, power strategists and manipulators will throw all cards in. A hostile takeover is not out of the realm of possibilities.
One should ask: If a group of people have chosen a way to work, a leadership, a place and media to communicate, and they are producing results, why would it be so important for some to "tag" them with another team name, and place them under some extraneous leadership, structure and processes? What is the real deal?

I have committed to respecting these two values when running the U+1 Team, but members are free to make their own choices and even accept to be a part in the manipulation attempts we'll see soon. I ask people to keep an eye open, reflect and refuse to be objects in such dreadful tactics.

Wednesday, March 28, 2012

About excessive specificity

One of the things that have occurred to me recently, is that it is very easy to fall into the mistake of creating a very specific strategy to deal with a problem. Such a strategy wouldn't survive natural dynamics and changes, the unpredictability of the future, without becoming obsolete and inadequate.

I'm convinced that a powerful strategy must consist of general guidelines, that can be replicated to other communities, projects and problems. It must be solid in unquestionably correct principles, but also predict the points in which it must preserve flexibility, creating gaps for customization and adjustment to new environments and scenarios.

Such a specification would potentially have a greater chance to reach broader adherence and adoption, thus becoming a high value-added tool to promote positive change.