Kenya

Some photos from the Coko team meeting in Kenya. It was a very productive and fun week. We have a team member in Kenya (Richard) so it was great to visit where he lives (our accommodation for the meetings was next door to his place). It’s great to go where the team is. Last year, we had a meeting in Athens and saw the ‘home’ of Cokos Yannis and Christos.

dsc00555

I can recommend a safari for team-building. If your team is in Africa or nearby (most of our team is in central Europe), Kenya is easy to get to and accommodation and food are cheap and good. A safari is also very well priced, far cheaper than any similar (if there is anything similar to safari!) team-building exercise you could think of in Europe or Northern America. Richard and his partner Steph are starting a locally owned safari business with the intention that it will become under local control and ownership (they are working with some Maasai friends), so if you are interested in safaris as as a team-building exercise, let me know and I’ll put you in touch.

The last photos are of our team dinner at the end of the week. As you can see, most people were pretty tired by this point. Tired but happy!

It was truly an extraordinary week and our team came out of it with a sharp focus and stronger bonds. As we say at Coko (coined by Charlie) “Software is a conversation.” Awesome.

dsc00405
Left to Right: Charlie, Steph, Alf, Julien, Yannis, Christos, Karien, Richard, John
dsc00436
L to R: Alf, Julien, Henrik, Yannis, Christos

dsc00445

dsc00455
Left to Right: Charlie, Richard, Kristen, John, Henrik

dsc00451

dsc00516
L to R: Richard, Jure, Alex

dsc00469

dsc00520

dsc00548

1_dsc00471

1_dsc00531

dsc00557

dsc00582

dsc00578

dsc00598  dsc00605

dsc00612

dsc00608

dsc00621    dsc00648  dsc00675

dsc00660

dsc00694

dsc00680

dsc00723

juan

a

dsc00733  dsc00753  dsc00754

dsc00779  dsc00766  dsc00785

dsc00787   dsc00817  dsc00828

dsc00826      dsc00889

dsc00884 dsc00912

dsc00913

dsc00924

dsc00937

dsc00935  dsc00947    dsc00965

dsc00976  dsc00977

dsc00986

dsc00997

img_3289
And one of me (on right) taken by Alf.

Is Buying Closed Source Projects a Good Strategy?

Many years ago, Blender, the open source animation software, was purchased by its users and converted to open source. It’s an amazing story. The background is that Blender used to be closed source. When the company that owned it went through something of a re-organisation, they decided to stop working on the application. The users were frustrated by this and so they decided to take matters into their own hands. They did a deal with the owners and ran a “Free Blender” campaign, raising 100,000 Euro as a one-off payment to change the license to the GPL.

It’s a great story and super inspirational.

In more recent times, there have been a couple of interesting big purchases of proprietary software by organisations that might, or will, change the project to some form of open source license. Chan Zuckerberg Institute purchased Meta, a research search engine startup. It’s not clear whether this will actually become an open source project: it seems there is an attempt to make it free and ‘non-commercial’, and they will somehow consider how they might create opportunities for developers to contribute to the project. That sort of sounds like there is a chance it will go open source (not conflating non-commercial with open source of course), but they haven’t said this. What they have said is that they need some time to segue Meta out of its current commercial operating context. We shall see.

On the other hand… Mozilla just purchased Pocket, a bookmarking app. This case is clearer – Mozilla purchased the company and will make it open source as soon as possible. Mozilla is not itself new to the process of opening code, its own roots lie in the opening of the Netscape Communicator code in 1998 to the management of Mozilla (although the code was thrown away by all accounts and rewritten from the ground up). However, the purchase of Pocket is not that, it is the acquisition of a project that started its life as closed source, with the intent to bring it into the open source world.

So, I wonder about this kind of move and I worry a little. I worry because it could send a couple of signals to the open source world that aren’t very helpful. Firstly, I worry that new projects might see this as a potential business model. If a new project was starting with a change-the-world attitude they might consider starting closed, not open, in the hope that later they could be purchased by a like-minded org like CZI or Mozilla – maybe to be one day open-ourced by that organisation. It’s a long shot business model now… but what if these kinds of purchases continue? Perhaps, if it was common, this would not seem like an unusual choice of business model at all. That could discourage many potentially wonderful open source projects from starting open. That would be a dreadful effect if it were to occur. Again, I don’t see that happening now, the odds are too long for this kind of model, but if this kind of acquire-and-convert model catches on…

Secondly, I don’t like the idea of open source organisations like Mozilla putting money into a closed source application, period. It feels like giving the opposition a boost. I’m of the mind that there are two camps in software – open and closed. I don’t subscribe to the Star Wars type epic good vs evil battle which once seemed to have a hold of the free software sector and still seems to linger here and there. However, I do believe in the empowering nature of open source and I do place it on a higher, more valued, ground than closed source software. I also believe that the culture of open source projects is fundamentally different than closed source projects. The motivations, internal architecture, and ‘operating systems’ of the two are very different. I just can’t stand closed source culture and I really don’t like using or supporting closed source software. I like, instead, to help open source software, and the movement in general, in any way I can. It’s kind of a clan I have self-subscribed to, and while subscribed I’ll do what I can help.

So why not, instead, take that, apparently quite large, sum of money that Mozilla used to purchase Pocket, and put it into open source projects? It feels like Mozilla is turning its back on open source. It feels like another move Mozilla makes that diffuses their brand while they continue to search for a new cause (while never, it seems, finding it). I don’t know what Mozilla is anymore. Apart from people enjoying Mozfest, I have no idea what they do or why. When they start funding proprietary applications, validating closed source business models, I just groan. I hope they don’t do more of this kind of ‘strategic acquisition’ as it’s one more step away from the ‘keeper of the faith’ type organisation I was hoping they might still be.

I’m not arguing that converting closed source to open source is a bad idea in general. Who is going to argue that the Blender move isn’t inspirational or ‘the right thing’ to do. I don’t hear anyone saying that. In fact, a community getting together to save the project they love by collectively putting all their pennies in a jar is a good open source moment if there ever was one. But large open source organisations like Mozilla, or orgs that are primarily driven to openness, like CZI, acquiring closed source projects and opening them, is not good for open source.

Workflow Engineering

At Coko we build open source tools for scholarly publishing… sort of… that’s the tagline, but actually, there is a lot more to it. We have built open source technologies for publishers, it is true, but we have been careful to build frameworks which can be moulded to meet a large variety of use cases.

To understand what we actually do, it is worthwhile to look not just at the technology but at how we produce the technology. Essentially, we facilitate publishing staff through a process where they design their own platform… which is awesome in itself …but, actually, that’s not quite it either. What they are actually doing is designing their own workflow, one that gets rid of the current pains and opens up new possibilities. When we do that, we are essentially working as consultative workflow engineers – helping the publishing teams work out what an ideal workflow is for them, and then working out the technology/cultural change mix that must occur to get them there.

I’m very proud of how we work. We don’t create ‘black boxes’ and throw them at a publisher and say, there yo go! Use that! Rather we help them design what they want and build it (using our flexible frameworks and bringing in existing open source software, where possible).

It also allows us, as Karien Bezuidenhout (Shuttleworth Foundation) has said, to ‘bake cultural change into the product development process’. Very true.