Open Source

Sustaining Open Source and Ecosystems

April 3, 2017 Leave a Comment

The topic on how to value open source, and how to make sure that it can continue to thrive and work can be rewarded, is an old one. It has been heating up again recently with waves of tweetconvos, the latest being:

it's definitely not ideal. I'm just trying to explain why this ideal model of open source projects getting money from big companies doesn't

— vjeux ✪ (@Vjeux) April 1, 2017

It seems obvious that foundational work for companies that make a ton of money from it should be rewarded. However, rewards come in many flavors, and individuals create open source works for varied reasons.

Let’s bypass the topics of “you get other rewards…” (reputation, skill, community, job possibilities, and even rare golden tickets): what role should large companies play?

Large companies should invest in projects that they get value in. There are many ways to do this and the issue of control often comes up. Are you giving money to a project, or looking to hire a particular commiter and steer their direction? When does it make sense to hire vs. pay a contract? There are trade offs for all parties when it comes to bringing someone on as an FTE: e.g. benefits and growth with the company vs the bureaucracy of performance reviews 🙂 Do you sponsor issues or interest or stay at arms reach?

If you look at the majority of large companies you will see all types of arrangements in place that depend on many particulars.

I want to focus in on a type or sponsorship that ties into the question around funding for the Babel library. I think large companies have a responsibility to help an open ecosystem, such as the Web, thrive. At Google or Facebook, we make a great living from the Web and much usage touches both companies.

It is definitely our turn to help out. The government kicked off the incubation. Vint Cerf and friends had what they needed in resource and constraints to make the Internet, open for all to build on top of. This seeded an ecosystem that allowed for many platforms and business models, all leading to today.

Now we have commercial success we need to step in to support the ecosystem. The Web still suffers from an obesity epidemic, and anyone who is helping deserves much credit. As folk invest though, we need to be very careful to do so without king making and accidentally blocking future innovation. It is easy to do damage here, but that isn’t an excuse to sit back and do nothing.

I am excited to see the conversation continue and to work together on how best to garden the special platforms that we now have. Open Collective even has a conference on the topic in June.

Whenever I think about the topic I have to admit that I end up pulling the strings that end with frustration around how we value work in the world at large, and how we do not reward for long term value (see: how we pay teachers).

Open source shouldn’t mean closed protocols

May 11, 2016 Leave a Comment

”An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead” — @moxie0

I enjoyed reading moxie0’s post on ecosystems and their evolution but the paragraph above is concerning. I don’t think it is really true.

If Facebook open sourced every line of code and I took it to setup Dionbook, could I compete? The lock-in of a service isn’t in its source code, it is often elsewhere. In the case of Facebook they have the social graph of their massive user base.

We can also look at some of the other examples used:

Slack vs. IRC: You could look at this as an example of the fast startup beating the slow standard. But is that the full story? There have been hundreds of group chat services, and non of them managed to get the lightning strike success that Slack has gotten so far. Many never got any steam, and even mild successes like Campfire had the team think that the space was feature complete and it slowed to a halt too!

It turns out that speed of innovation can have a lot of stop energy put on it. Success is often a large slowing force here. As soon as you have a large user base things change. Take Twitter. They had to famously take a step back and deal with the scaling challenges of their success. Subtle features such as how mentions work had a huge effect on the backend scaling needs of the data model. A slew of Twitter clones have popped up, and many of them have far more “features” (and some are successful in other regions: Weibo).

You can also look at some of the original Web hits, such as Craigslist. If I had a dollar for every time someone in the valley said to me that “I want to create a modern craigslist” I would be a rich man. But, it hasn’t happened yet. The value is in the market, similar to eBay. Disruption can come, but it often needs to disrupt the model. Slack can grow quickly and be a lil better as its ecosystem is teams. AwesomeMobileEbay doesn’t have that luxury, you end up with a chicken and egg problem.

What about the slow growth of Internet protocols?

“We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that’s how far the internet got. It got to the late 90s.”

Once again, this is partially being a victim of success, and how interoperability is taken as a big deal. Also, HTTP is getting a lot more attention and HTTP/2 is doing great (in relative time). What would the world look like if a company owned these protocols? Imagine paying an IP tax per packet. Would that company be incented to innovate? Or, if they got enough support, would they be big enough to not have to, and instead the incentive is to be rock solid and get as many packets moving?

I think it is really important to think through the incentive structures, as they are the best way to understand and predict things. You have to ask “where is the money going to be made and by whom?” If there isn’t money, that is a problem itself. Maybe that is why IRC never took off, as it was hard to differentiate… but it could also be because the UX and feature set wasn’t there.

The ecosystem is moving, but it moves at a large scale across the experiments of open systems (the Web) and closed ones. We often end up comparing this to forms of government. One of the reasons I am a fan of democracy, even if it isn’t efficient, is that even if you have a benevolent king, you don’t know what his son will be like.

When you enter into an ecosystem it is prudent to think through the incentives and see if you are aligned to the folks with power, and also think through how their goals may change in the future.

But to the main point that open source allows for something almost as future proof as open protocols doesn’t ring true to me. One of the reasons that I am a fan of the Web is because, as messy as it is, it doesn’t empower any one player too much.

“My engineers want to code at night! Oh no!” Oh yes!

September 4, 2015 Leave a Comment

I was talking to someone who was concerned about one of the engineers on his team. This chap was writing a lot of code on the side for a hobby project, and it didn’t feel right to this manager. After listening in to the group for awhile I had to insert myself and ask some questions:

Is he performing his job to a satisfactory level?

In the information age it is hard to measure impact based on the number of hours. At some point the engineering manager has to set the expectations for the engineers job performance. This typically happens already, where it is clear how to meet expectations, exceed them, and more. Putting in the effort to clearly define these levels gives you the tools you need to be much more loosely coupled on items such as time input.

If the engineer is at least meeting the expectations of their role, you shouldn’t be too concerned about what else is going on, but there is always the opportunity to talk about what it means to get to the other levels. At some point the employee may take the trade off to do more in their personal life at the expense of being a role model (not that time is the only way to become a role model).

Measuring the impact that a person has on your business is hard. There are so many complex variables at work, with a myriad of side effects. There is the notion of individual contribution, and also the leverage that you get with the team. A great leader has a huge leverage effect beyond himself, and that is true for any employee.

If he instead spent the same time on a hobby very different to work, how would that make you feel?

The manager didn’t like the engineer writing code on the side, but why? Why does it sometimes make people feel weird if they use the skills they have at work for a hobby, when if they spent the same amount of time on a very different hobby it wouldn’t feel as weird?

If the engineer was cranking away putting hours and hours into becoming a scratch golfer, how would you feel differently?

In some ways you should feel very excited that an engineer on your team loves software so much that he continues to explore it “off hours”. The passion is a great sign that they enjoy their craft beyond a pay check. Understanding the motivations is of course key. The context is what matters here. What are they working on? Is part of the hobby project a way to explore different tech stacks? A different domain? There is a good chance that this “free time” work is a gift. The engineer is growing and you are getting the benefits of that growth, while he is with you.

Is he being paid for work on the side?

It can feel different when someone is hacking on a fun open source side project vs. a paid gig. The incentives are different. On the one hand the golden rule of “as long as they are doing their job” can be applied, but it is still a warning sign. Do they feel they need the money and don’t like what they are doing other than the pay check? Or, is the pay check a happy side effect of working on something genuinely interesting?

When money is changing hands there is another person in the equation: whoever is paying them. If it is consulting work, someone is managing that work. If they are selling an app on an app store, there are customers. When this happens loyalties can be split, so the salient point is “where is the primary focus?” When shit hits the fan and you need this guy, is he around?

In the 24/7 world that we live in, when is it OK to work on this vs. that. Chances are you have had people work for you at all hours of the day. In fact, it may be that some of your engineers work best coding at night, so you should let them do that at times for their day job!

Expectations

As with seemingly so many things in life, it probably all comes down to expectations. You should be able to have an honest transparent ongoing conversion between engineer and manager. You also need to be fair across your work force. You may have some fear that the engineer will leave to work on this hobby, or get another job due to the open source work, but is the alternative of trying to capture someone better?

If you can find a passionate engineer that is creative and wants to explore his craft no matter what, you should probably consider yourself very lucky. If not, what kind of culture are you creating? Whatever you do: don’t just tell them they can’t be creative and put them in a box. If you want obedient fulfillment workers, this is one way to start down that path.

As one of my kids often remarks: “Are you FORCING me?”