Italian Open Source Developers: Simo Sorce

Simo Sorce is the Samba Team GPL Compliance Officer, hired by Red Hat in 2007 where he is a Senior Software Engineer, maintainer of Samba and expert on Windows Integration and Identity Management.

Simo Sorce in 2001 has co-founded a consulting firm specialized around Free and Open Source Software platforms. He is also an international Free Software advocate.

Simo Sorce Simo Sorce

I asked Simo, who about six years ago when he supported my candidature as member of the Italian Free Software Association, to tell us more about his career and interest for free software.

How did you become a Samba team’s member?

While working part-time in the IT department of the University as a Linux/Unix administrator I was tasked with the job of making unix and windows systems talk together for file sharing and most importantly printer sharing purposes. Samba was the obvious tool.
As I am naturally very curious I shortly started wondering how Samba accomplished to bridge the architectural differences between a Unix and a Windows system, especially from an Identity point of view. I knew both architectures and they are very different in some key areas. I started asking questions on the users mailing lists, and I was quickly told that the details were only in the source code.
Being very naive I started reading the code thinking I could grasp everything in a short time. Soon I realized the code was much more complex then I expected but also realized the beauty of some of the challenges in that code, I was hooked.

I started working on the passdb subsystem (the one that manages Identities in samba) and shortly saw the first few patches applied to the development tree. After some time I was contributing regularly and was gifted with the status of Team member.

I asked Alessandro Rubini, Carlo Daffara their opinion about “the” community. What is yours?

I think that “community” is an ambiguous term in the FOSS case, I see this world as a set of sets. Real communities exists only at the project level, and they are not necessarily very well defined at that level either. Usually the project community is composed by a more or less stable core set of developers, often employed by some company, and then a wide range of other people that contribute to a minor degree, or just uses the code and provide a lot of good feedback.
The broader “FOSS community” is more or less the superset of all the single project communities. Not everybody recognize himself in this broader super-community, and some people tend to split it into something artificial like the Free Software vs the Open Source communities. What matters at a higher scale is the set of licenses used on one side and the field a project operates in on the other. Where the licenses are compatible we see a lot more interaction, when they are not a bit less and also some tension when two projects in the same filed need or try to interact. These interactions are the links that define the super-community, more or less, with obviously blurred edges.

I think Simo raised very important issues here. Beyond licenses’ compatibility, that has its own role for example when it comes to M&A, but the idea of “super” communities is even more interesting. As a matter of fact many open source projects are using other projects’ outputs, and the way they interact will gain more and more attention.
Samba is a “pure” community open source project, but the organization is quite different from larger communities like Debian, ASF or Eclipse. What about the project’s organization?

Samba has indeed its own model, partially dictated by the project history and interactions with the industry and other projects. The Samba Team unlike the mentioned organizations is a very lousy loose group, membership is given by agreement of the existing members after on of the team members proposes a candidate.
Historically the Samba Team has always been just the group of people that was trusted to have commit access to the shared CVS tree, and in fact was born only when Andrew ‘Tridge’ Tridgell and Jeremy Allison decided to start using a version control system.
We tend to have a consensus-driven decision system. If most agree we all agree. We don’t take formal votes usually, if someone have a strong opinion against a decision it is his duty to speak in time and argue against it. As most of our decisions are technical in nature we tend to easily agree on a proposal and rarely we get contrasting opinion that we can’t easily settle. Also, usually, the opinion of the developer most intimate with the field being discussed tend to have greater influence than others. For non technical decisions we tend to follow the lead of the Team founders, Tridge and Jeremy.
Recently we joined the Software Freedom Conservancy, and this gives us also a legal status. Before that we were legally just a bank account in Australia used to hold donations that we spent mostly to pay travel fares to remote samba developers that could not easily afford a trip to the 2 main yearly events in the Samba community, the CIFS conference in the US and the SambaXP conference in Germany.

Rough consensus and running code, then. It reminds me the IETF’s approach for its working groups, a great one! I believe that this approach works well for a small group, though.
Talking about open source firms, you worked for years by your own company, then you moved to the States and eventually joined Red Hat. Could you tell us something about your experience in this respect?

The difference between working for a small firm in Italy and working for big corporations in the United states is huge. At an organizational level you have to change from a do-it-all mindset of the small firm to an environment where you have greater opportunities but also many more constraints. I enjoy being able to concentrate more on technical aspects and leave other aspects to dedicated professionals, but sometimes this means you have to play political games to do what you want.

From the business point of view a small firm is agile, can easily re-focus and try to jump in new fields but is usually blocked by lack of financial agility. Here smallest firms are somewhat at an advantage compared to Italy, access to credit is much easier and you actually have real chances of getting funding if you have a very good business plan. But here things are also more brutal. Risks and rewards are higher. It is as easy to get in business as it is to get thrown out of it. Even in big enterprises you still feel the pressure on quarterly results, long term plans exist but there is a very short term focus that keeps all busy on quick results. In the previous company where I was closer to the sales people, a quarter was the life and death deadline, toward the end of the quarter sales got anxious and pushed you harder to help them sell. In Red Hat I am less exposed to this kind of pressure, but we have anyway very hard development project deadlines, from RHEL updates releases to Fedora releases to your own projects releases. You have to make your long term plans in a way that you can split them in short term milestones or it is very difficult to get away with a project.

All in all I miss some of the features a small firm in Italy can give you, but I also enjoy the experience of working in a big global company. I think you have to try both to understand the benefits and the shortcomings of both, and then decide what you like most. If you are good you will have no problems making a living anyway.

You are not alone saying that US is a better country for startups, but I agree with you that besides money a good business plan is the key.

I see also another major difference here. While Simo was working by his own company he had to sell services only partially based on his favorite platform. Unfortunately the Open Source Ecosystem has still to develop a pyramidal approach. Until now System Integrators don’t act as “mediators” towards small specialized firms like his one. While I understand that it is not easy for them to set it up for a large number of OS projects, I really don’t see a reason to not do it with some of.
Happy hacking Simo!

Technorati Tags: SimoSorce, Samba, JeremyAllison, RedHat, Startups, Commercial Open Source, Open Source Strategy

Related Posts