Training programs for developers in FLOSS companies: a need

My Experience
When I started with Free Software, there was a need for training people in the new tools that were emerging, not just to users, but also to professional that came from the proprietary world. There, the formal learning culture, through certification, is well established. Due to the business models around the delivery of technical information from soft companies to its channel and customers, investing significant amount of resources in these certifications programs was justified. For professionals, it is a way to improve their curriculum and skills.

Before embracing Free Software, I developed my career in the training sector so I made a living trying to solve this problem for companies that were in the process of discovering Free Software.

In the FLOSS world, these investments is not seen as a “requirement“. Although the Free Software commercial space is getting more mature and more and more companies provide these kind of trainings, the general mindset is that you learn by doing, that the code and resources are out there that the formal training is not worth it due to its high cost, that Free Software is a learning environment by itself and that, by simply providing “learning time” to your employees they will develop the skills and learn the concepts they need. It is the typical “engineering innovation” kind of culture.

At a management level, the culture of getting training is solid, but many Free Software companies fail in spreading that culture to the technical level. In my 15+ years as professional I have seen very few companies that takes seriously the improvement of employees skills through training, specially in the engineering area.

Training program

Like when leaning a new language, in order to improve your technical skills, formal training is needed, specially at two points in time:

  1. At the very beginning of your learning process, when you are facing something “new“.
  2. When you reach certain level where improving is not a matter of practicing any longer. It is the case when you make yourself understandable but need to express properly.

In the same way professionals put effort in being efficient in their everyday tasks, it is smart to be efficient in learning new concepts, developing new skills. Formal training in the first case is about that.

In the second case, in my opinion, there is no substitute for formal training. There is a point in which your investment in “studying” is less and less effective, reaching a point in which investing effort in “improving” is not perceived as worth it anymore. Internal training should cover this second case.

Despite its cost, investing in having junior developers formally trained by senior ones is worth it.  Since nobody is senior in everything, seniors become juniors at some point and the other way around. So having regular training sessions covering the first case (introduction to topics) given by employees have interesting secondary benefits.

For the second case, I always recommend going for external trainers. Even in the case you have the experts at home, bringing external people always adds value, a different vision. It is important also that that person is not just a good professional, but a good trainer. It is not so common to find both skills in the same person….at home. If you have one of those…. send him/her to train your customers, not your employees. You will get a higher return.

Do not forget to evaluate and reward your internal trainers. Provide them training also, so they become better trainers. This actions should be part of a more general designed path to increase the number of engineers within your organization that can be successful facing customers and promoting the use of your products and technologies in events. It is what I like to call Engineering Marketing.

One of those secondary benefits you might have not think about is the technical documentation generated for these sessions. In some cases, specially when you are training in technologies or products your company develops, these material are a perfect base for the technical documentation you provide to customers. You can eat you own food also in this area or, at least, design it to give it an early try.

Technical support engineers and presales ones are used to “making themselves understandable“. When thinking about creating or improving such a program, think about them as potential trainers. If you have technical writers in the company, involve them too in the material generation. Yes, it increases the cost of the program, but it increases the outcome too. So instead of focusing only in the cost, try to find ways to translate part of the output to your customers too, so the investment is also worth it from the “sales” perspective in the short/mid term.

Some tips about the training sessions.

In my experience, if your company is young, these sessions should take place on Friday, after lunch. It creates a good atmosphere during the less productive time of the week. It is the “fun time“. If your company is a more senior one, it is harder to have a significant number of attendees on Friday afternoon so Thursdays afternoons, at the end of the day, would be the best option.

It always come a question when designing these sessions. Should they be part of the workday schedule or should they take place after work as optional?

In my opinion, these sessions should not be mandatory but they should become part of the working hours. They need follow up though, so evaluation is needed. There are many techniques to make these evaluation processes part of the learning process itself so they are not perceived as “boring“. You also have to module the consequences of “failing” in these actions so you incentive participation. Having extra sessions for those who do not accomplish the goals can be a good compromise.

Who can you talk to you about this?

There are two people that I recommend you to contact if you want to know about a successful experience in having seniors training juniors as part of the organization culture. They are Miki Vazquez and Gonzalo Aller.

If you do not have a well established training program within your engineering dept. these two people might help you from different points of view: Paul Brown and Roberto Brenlla. They might help you to design and follow up a technical training program, in collaboration with your HR dept. and your technical managers.

Do you know other professionals or companies who are driving successful internal training programs for engineers (employees)? If so, please let me know. I would appreciate it, and some readers too.

What is the KDE Program?

Executives find valuable to become part of a common network that allow them to open their organizations to new markets, more opportunities in current markets, new products, services and talent. KDE can offer them such a worldwide network formed by many organizations.
In order to do it, KDE build a structured Program based on the following global principles:
  • Networking as a major value to build self-sustaining cooperative system.
  • Meritocracy and compromise.
  • Mentoring.
  • Single contact point for every organization.
  • Think global, act locally.
  • Scalability, depending on the organization dimension and expectations.
  • Building the field first, creating the rules, and then, let the players play.

The KDE Program(*) is the result of our determination to create a global network formed of organizations committed to KDE related principles, technologies, products and services. It also is:

  • A structured project to add value to KDE, while increasing market opportunities for every member through coordinated networking  activities.
  • A way for KDE to connect with end users through new organizations.
  • A new approach for supporting KDE in a way every member gets, not just the result of our work, our software, but also the knowledge that allows us to create it, so they can learn and add it to their production process.
  • A channel to introduce KDE into new markets through a worldwide network of organizations that actively contribute to it.
  • An opportunity to recognize and reward those organizations that have historically supported KDE.
  • A new approach to take free software communities beyond their current influence area.
    (*) Remember that I am still looking a good name for the Program

KDE Program: Mission and Goals


The last weeks I’ve been putting some effort in thinking about how KDE (and any free software community) can build a network of organizations taking in consideration the weaknesses and strengths KDE (or any other FLOSS project) have.

I wrote a few posts about previous ideas I thought it should be taken in consideration before putting effort in defining a formal design for a Program that leads us to the discussion and execution of an action plan.

Now the idea is to define the Mission and Goals of such a program. In order to understand why of the following ideas, I recommend reading previous posts about this topic in my blog:

Some preious ideas about building new ecosystems around free software projects (I, II, III, IV and V)
Mission

Since we develop and publish KDE for free (as free beer), organizations usually do not understand well where our value is and how can they take advantage of it in a way our ecosystem is nourished, which is essential to keep the wheel spinning. Most organizations, especially corporations, associate value with money. This classical, product oriented, point of view must change in order for us to be recognized as we think we deserve. We can improve the way we communicate our value associating networking (as a service) to our software.

So the KDE Program Mission is:

  1. Helping organizations to know us, what we do and how we do it, so they appreciate the value of KDE and support our action.
  2. Giving them something valuable associated with our software, affordable for KDE, that allow them to increase the chance to grow.
Both ideas can be summarized:

The mission of such a project is to create a global, sustainable and structured network of organizations that shares KDE principles and interests.

KDE Program Goals

Major Goal
The major goal of the KDE Program (KDEP) is to establish the conditions and develop the actions needed to create a network of organizations committed to KDE principles and goals. This network will evolve in an ecosystem by increasing the relations among them and with the KDE community.

This network/ecosystem will be defined to grow, not just in number but in value, satisfying its members shared goals.

Other goals

Other goals of the KDEP are:
  • Present KDE as an attractive opportunity for organizations to become part of a global network that will benefit all of us.
  • Increase the number of organizations involved with KDE.
  • Improve KDE’s relationships with other organizations.
  • Create new business opportunities for those organizations involved in this Program.
  • Support local teams. Relations grow better in common environments.
  • Open job opportunities for KDE developers.
  • Increase the number of new developers so we make sure the new ecosystem can grow.
  • Spread KDE principles and vision to other organizations.
  • Feed KDE with third party experiences, knowledge, technologies, etc.
One of the things that is taking me some time is to look for a proper name for such a program. Any help is welcome.

    Some previous ideas about building new ecosystems around free software projects (V)

    Related to our topic, the most relevant internal factors /strengths and weaknesses) I can think of are the following:

    Strengths

    • Passion.
    • Collaboration. Sense of community/identity.
    • Worldwide project.
    • Prominent FLOSS project. Well known brand.
    • Leading technology. Innovative.
    • Well defined product (software).
    • Broad base of skills.
    • Efficient development process.
    • Economically sustainable.
    • Internal communication.


    Passion: KDE, like other community projects, is formed by people passionated about what they do and aboutfreedom.

    Collaboration. Sense of community/identity: this culture make them extremely efficient and determined when decisions are taken, reaching goals that might seem impossible.

    Worldwide project: KDE is a worldwide project, with active members all over the world, that speaks in many different languages and come from many different cultures.

    Prominent FLOSS project. Well known brand: KDE is one of the current leading free software projects in the world and its brand has a high value, not just because of the product delivered, but because of the clear identity behind it.

    Leading technology. Innovative: KDE develop some of the most interesting technologies in the software industry for desktops.

    Well defined product (software): KDE Platform, KDE Workspaces and KDE Applications form a whole product that give answer to millions of user needs all over the world.

    Broad base of skills: KDE is formed by people with many different skills, experience and motivations. It is a rich community.

    Efficient development process: to develop and deliver the product throughout 15 years, KDE have a
    complex, efficient and innovative development process. Coordination.

    Economically sustainable: KDE is todays an economically sustainable project. Budget control and management is efficient.

    Internal communication: KDE has solid communication channels and procedures with high participation.


    Weaknesses

    • Weak marketing culture. Lack of experience.
    • Lack of resources for non technical activities.
    • Complex ecosystem.
    • Complex decision making process.
    • Diffuse points of contact.
    • Self criticism.


    Weak marketing culture. Lack of experience: marketing haven’t been a priority in the past. We can do much better in this area.

    Lack of resources for non technical activities: some non technical areas need more manpower.

    Complex ecosystem: KDE is a big project with a complex structure. It is not easy to understand it when you come from traditional organizations.

    Complex decision making process: because of its nature, some kind of decisions are hard to make in KDE. This is common to most community driven projects.

    Diffuse points of contact: approaching KDE can be hard to do since we lack of globally defined roles. Some knowledge of how KDE work is needed to make the approaching process efficient, specially for non technical issues.

    Self criticism: KDE has a strong sense of self-criticism, which is really good for internal processes, but harmful if it is made public continually focusing on weaknesses.

    Once again, if you think some other elements must be added, feel free to make comments to this post.

    Some previous ideas about building new ecosystems around free software projects (IV)

    After the previous three articles about very basic previous ideas to take in consideration before designing an engagement program for organizations, we need to think about what are going to be the concepts to base our program on.

    To have a better chance to succeed, we have to build our program on our strengths and not on our weaknesses. In order to identify those strengths, I’ve made a simple SWOT diagram.

    This entry will describe the major opportunities and threats I see that might affect to our plan of building new ecosystems with organizations.

    Opportunities

    • Free Software culture expansion.
    • Desktop – web relation.
    • Free Software business models success.
    • KDE has millions of users.
    • KDE cross platform strategy.
    • Software everywhere.
    • Increasing market pressure over Universities to include free software topics.
    • Free Software seen as strategical for by many countries.

    Free Software culture expansion: more and more organizations are interested in crowd sourcing techniques and in collaboration processes like the ones we use for software development. Movements like Open Data, Open Gov. Free Culture, copy-left, Free hardware, etc. are strongly related to the free software culture. Some of those movements are interesting for many organizations. A community project like KDE can expand his influence to other areas.

    Desktop – web relation: interaction between the desktop and the web, along with the irruption of small devices, can allow us to expand our influence to the web world, where many organizations are extremely interested.

    Free Software business models success: more and more organizations, specially companies, are developing free software business models where upstream collaboration is seen as a good value.

    KDE has millions of users: KDE have millions of users so we are a good target for organizations that wants to reach them.

    KDE cross platform strategy: KDE is a multiplatform and multidevice project. There is a shiny future ahead of us if we keep pushing in the current direction.

    Software everywhere: software is becoming strategical in many industries. Free Software is becoming popular is most of them. KDE has more and more open markets every year.

    Increasing market pressure over Universities to include free software topics: since free software is getting popular in IT industry, the pressure over Universities and other Education organizations is much bigger than in the past. This mean that the cost for KDE to find potential contributors will decrease.

    Free Software seen as strategical for by many countries: more and more countries are defining national IT strategies around free software due to political, social and economic reasons. This will open us new markets.

    Threats

    • Classic Free Software threats like software patents, closed formats, etc.
    • Key players without a clear and stable strategy.
    • Increasing our relations scope.
    • Management.
    • Resource dimensioning.

    Classic Free Software threats like software patents, closed formats, etc: KDE and any action we take toward building new ecosystems with different types of organizations are permanently threatened by them.

    Key players without a clear and stable strategy: because of different reasons, many stakeholders that traditionally or lately have been supporting KDE, change their strategy often. Although KDE has proven in the past to be good at isolating the impact produced by them, tensions might increase in the future.

    Increasing our relations scope: KDE has been very successful at attracting technical contributors and other non-profits related with free software. It is not clear that we can extend that success to other type of organizations.

    Management: KDE will face some management challenges in the near future due, among other factors, to the growth rate it is experimenting. Increasing the ecosystem to other type of organizations will stress even more the actual management resources.

    Resource dimensioning: overload takes any organization through many non desired consequences like quality decrease, internal tensions, expenses, management inefficiencies, etc. Like in any community project, properly resource dimensioning and control is specially difficult, since our community is formed mostly by volunteers.

    Isolation from the free software-business relation: KDE, like other free software communities haven’t been in the past very interested in the business side of free software. We are more technical focused. The increasing economic success of free software will force us to put energy into this area to avoid isolation.

    Yes, there are probably many more, but I hope most of them are somehow included in these ones. Otherwise, feel free to add more through comments to this blog post.