«Screwing up is a great way to find out that your assumptions were wrong or that your model of the world was a little bit off. As long as you update your model and move forward with a better picture, you’re doing it right. [...] There are still some bad ways to fail. Repeating the same mistake over and over is one. Not listening to customers or peers before or after a failure is another. Never ignore the evidence; particularly when it says you’re wrong.»
Valve Handbook for new employess. A tour through Valve, a world-class video-game and distribution company with a flat structure.
Etiquetado: English RSS Mostrar/ocultar comentarios | Atajos de teclado
-
Andrés
-
Andrés
«When you run a business, if your software has a bug, your customers don’t care if it is your fault or Linus’ or some random Rails developer’s. They care that your software is bugged. Everyone’s software becomes my software because all of their bugs are my bugs. When something goes wrong, you need to seek out what is broken, and you need to fix it.»
Why you should read the source if your shop sells custom apps on top of a framework. HN original post. Related: The costs of going it alone & Working with upstream: an interview with Lazslo Peter. -
Andrés
The Linux Foundation has released the Who writes Linux (2012 data) report. Interesting to see how it has been internalized as a marketing tool to show how vibrant is the community. Check it out and compare it to LibreOffice report and ours on FOSS4G desktop.
-
Andrés
Analysis of free software communities: coda
As you can see in my last posts, I finally managed to translate the paper we released last year in V jornadas de SIG Libre (please, beg my english!). It took me a year and my wisdom teeth removed to find the time.
Our intention (Fran and me) when this paper first poped out from our heads was to foster debate on the best practices around a free software project. While at CartoLab, we presented the idea to Alberto; he encouraged us to work on it and gave the time and resources needed; also in the later stages he contributed to polish the trends and conclusions. I’m deeply grateful for all his patience and empathy.
I’m very proud of the work we have done: the first study of this kind in the GIS arena, and somehow a picture of 10 years of FOSS4G software development (for the desktop side). I hope the study is worth the effort and it continues to create debates on how to better work together.
-
Andrés
Analysis of free software communities (V): generational analysis
- Images: on the left, contributions of top 3 developers along the project history; on the right, evolution of developers participating during 2010.
- Data: trunk from project repositories during the period 1999-2010.
Is it something we could extrapolate from the data there?
This indicator gives us some sense on how the leadership changed and how the knowledge transfer was done in every project. The paper elaborates a bit more the points of turnover and integration of new blood in the project (highly correlated with this indicator) with statistics of top 10 developers.
All that will give us some insights on every project:
GRASS
- The charts and data depict how a new generation took over the leadership from 2005 onwards. The process seems to be happened in a very organic way -in the sense that people grew its skills at a steady pace for a long time- and also deep to the roots: from the top10 only 4 out of 10 people continue collaborating with the project.
- The data also shows how the top3 represent half of the work in the project, which suggest that several developers are highly involved with no one having too much influence (actually, the top contributor during 2010 means 40% of work).
gvSIG
- The charts and data depict a highly distributed team with a high rate of turnover. Top3 is responsible for less than half of the contributions, being top10 around 60%. The change of leadership happened very quickly around 2007 and only 2 out of 10 contributors from top 10 kept working in 2010.
- Besides, the top10 shows a homogeneous involvement in terms of number of contributions, which may reflect that all of them had a similar role and impact in the development of gvSIG.
QGIS
- The charts and data depict a project dependent of its top3 with a contributions-friendly culture. Top3 activity means a hight rate of contributions over total but seems they have integrated well new blood as 9 out of 10 most active developers working in QGIS have started in different years and continue involved.
- Top10 people have different ratios of involvement, ranging from 6% to 50%, which may reflect the heterogeneity of its core developer base (from volunteers to full-time developers).
-
Andrés
Analysis of free software communities (IV): community workhours
- Images: on the left, number of changes to the codebase (commits) agregated by hour of day. On the right, number of commits grouped by day.
- Data: trunk from project repositories during the period 1999-2010.
Is it something we could extrapolate from the data there?
This indicator is intended to give us some information on the patterns of behavior of contributors. Specifically, we can track how is a typical week for the core developers in every project: the timeline shows when the integration happened, don’t reflect the time in which the work was done; so it’s telling us the history of people with commit permissions, what we know as the leaders.
Let’s try to extract some information from there:
GRASS
- Internationalization: the hourly chart represents a gauss bell centered on 15h GMT, which in most European countries would be after lunch, being morning in the Americas. That could reflect that both continents represent the vast majority of core commiters. Nevertheless, the work is relatively well distributed along different hourly zones.
- Volunteers: the daily chart shows a light drop of work during the weekend, likely due to hired developers or people who likely make contributions mostly within their working hours. Nevertheless, there is still a high rate of contributions being integrated during weekend, which may be a sign of a well stablished volunteer base of core-developers.
gvSIG
- Internationalization: almost all the integration happens in a journey from Monday to Friday, with a hourly range from 09:00 to 20:00 GMT. That is strongly correlated to the hours of opening of a typical shop in Spain and reflects the nature on how the application was built in that period: led by a public body which contracted development to Spanish firms.
- Volunteers: seems that volunteer work in core was reaching to none, which reflects the original nature of the project in that period.
QGIS
- Internationalization: the hourly chart is nearly to a plain rate of contributions, which is a strong sign of a highly distributed leadership along the world. It’s even difficult to suggest which zones would be the prominent in terms of developers.
- Volunteers: the daily chart reflects a steady work along the week, with no signs of falling during the weekend, which may be related to a strong base of volunteers core commiters.
-
Andrés
Programming on principle
If you only watch a keynote this year, make it this one: Bret Victor – Inventing on Principle.
The serendipity again: I found this video few days after I finished reading Implementation patterns, by Kent Beck. Both two are connected, in the sense that Bret Victor talks about the importance of values and principles in our life and work -with amazing demo examples implementing his particular principle! Beck does the same at the level of programming.
-
Andrés
«An open project and its community are the sum of individual people doing what they care about. It’s flat-out wrong to think that any healthy open project is a pool of developers who can be assigned priorities that “make sense” globally. There’s no product manager. The community priorities are simply the union of all community-member priorities.»
Havoc Pennington, A few thoughts on open projects. A lot of experience condensed in every word. -
Andrés
On delivering software
More than ten years ago, some visionaries got together in the mountains of Utah to relax, ski and discuss on the challenges of their profession. That was the very moment when the Agile movement cristallized. They wrote a manifest and 12 principles. The first gem goes like:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
And only now we all are understanding what they mean. Even them.
- In Software G Forces: the effects of acceleration, Kent Beck discusses the technological and business challenges of making your releases shorter. And why that matters (see also a good summary of Beck ideas by Mary Poppendieck).
- On the other hand, Jeff Humble and David Farley have published a (jolt-award wining) book called Continuous delivery, which goes (technological) deeper on the value proposal done by Beck. I highly recommend this talk by Jeff at DevOps Hamburg and the introductory article.
Seems that it takes 10 years for the new ideas to mature and emerge in other shapes and wrappings. Nice to see that we, (“software deliverers”) as a profesion, are continuously improving.
-
Andrés
Have you seen the LibreOffice stats shown at FOSDEM? They have got a lot of momentum from its very beginning and seem doing well. I’d like to see the source of that, though, to compare how they build the report with ours.
Andrés 21:56 el 20 marzo, 2012 Enlace permanente |
Related: Open Source Leadership, by Bruce Momjian.