It would be hard to have not noticed the on-going debate around “open core”. From what I can tell, it largely, but not completely, boils down to concerns about a product being called “open source” if the core that’s open source is generally unusable without the commercial-only additions. Mostly, people are ok with there being separate commercial-only plugins or tools provided so long as the open source product can stand alone and be useful and effective. Dave Neary hits on what I think is a key warning sign that a product is using a damaging open-core model:

And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretence that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom.

The open source definition is all about what license is being used for the software, but the effectiveness of something being open source is at least equally affected by the development model in use. The ability for anyone to jump in and contribute to the project reasonably easily is what drives extra innovation and enables the development investment to be spread among many users of the software. Having access to the source code and the ability to modify it yourself is useful to avoid lock-in, but maintaining the entire software is generally too expensive to be worthwhile for users – it’s cheaper to incur the costs of switching to another product instead.

What Dave Neary’s paragraph above starts to move towards is looking for a product that uses open development rather than just open source. Bertrand Delacrétaz wrote up how we work at Apache recently and it’s a great model of things to look for in open development1. In particular Apache lives and dies by the first item: “All technical discussions and decisions on public mailing lists” or as I’ve often heard it put, “if it didn’t happen on the mailing list, it didn’t happen”. Unless all discussions wind up happening in a public forum, be it a mailing list, forum, wiki, wave or whatever, it’s unlikely that open development will be possible2.

So all of this leads me to a somewhat unexpected realisation: any open source company that insists on having all its developers colocated is failing to do open development effectively. If your employees can’t develop effectively from remote locations, how can you possibly expect to benefit from significant community contributions?

Anyone have examples of companies using exclusively co-located developers but still fostering an open development model?

1 – of course there are other approaches to open development, but few are as well articulated as the Apache way these days.↩

2 – Apache does use face to face meet-ups, but they make a point of keeping the mailing list in the loop about what was discussed there so everyone can still be involved ↩

The new Ephox Enterprise TinyMCE site has now gone live, a result of our new partnership with Moxiecode, the company behind everyone’s favorite open source editor TinyMCE. I’m really excited about the potential of this partnership and have really enjoyed the opportunity to work with the Moxiecode team so far.

What We’re Adding…

We think we can bring a lot to the TinyMCE community, the things below are just where we’re starting.

Enterprise Grade Support

We’re really proud of the level of support we’ve been able to offer for EditLive! and we’re bringing that over to TinyMCE. TinyMCE gets used in all kinds of mission critical systems where down time costs real money. Ephox’s support packages offer service level agreements to ensure you get help quickly and keep things running smoothly.

More Resources for TinyMCE

Ephox is dedicating resources to help develop TinyMCE, improve it’s quality, answer questions on the forums (even for the free LGPL version) and generally help make TinyMCE even better.

We’ve already had a number of patches accepted into the main TinyMCE branch and are using our build farm to run TinyMCE’s tests across a wide range of browsers and platforms to help the Moxiecode team keep quality levels high (check out the results here). You’ll also see Ephox folk popping up in places like the TinyMCE forums to answer TinyMCE questions.

Quick and Easy Commercial Licensing

If you don’t want to distribute changes you make to TinyMCE under the LGPL or prefer a more traditional commercial software license for whatever reason, you can quickly and easily buy one straight from our web store, with our without a support package.

Express Edit

We’re currently working to update our “Express Edit” feature of EditLive! to make it simple to integrate both EditLive! and TinyMCE with the same set of APIs and have the most appropriate editor for the situation load. Express Edit has been around for a while, but with the power of TinyMCE we think it’s time has really come to shine. With Express Edit you can offer all the advanced features of EditLive! but know that if Java isn’t available or you just need a lightning fast editor to make a quick change you’re users will have TinyMCE available too. Basically, you get the best possible editor for any situation.

Committed To…

In case you were worried there’s a few things that we’re absolutely committed to:

EditLive!

We still see EditLive! as being Microsoft Word for the web. It’s a full featured, enterprise editor that dramatically improves author productivity and assists them in creating higher quality content. EditLive! has been the leading online editor for many years now and we are going to continue improving it as fast as we can. There’s plenty of great stuff coming down the pipeline for EditLive! including of course an improved Express Edit.

Open Source

Ephox as a company may not have had much to do with open source in the past, but most of the people working for Ephox have and we’re big fans. Now we get the privilege of working with the vast TinyMCE community and that’s really exciting.

Most importantly, TinyMCE is absolutely still available under the LGPL, Ephox is even providing a direct download link from our site to ensure everyone knows they are quite welcome to take TinyMCE and use it for free. The only difference between the LGPL community edition download and the commercially licensed options we’re providing is the license information.

TinyMCE

Ephox and Moxiecode are working together closely on this venture. Ephox Enterprise TinyMCE is a distribution of TinyMCE, much like projects such as Debian include other open source products. Like Linux distributions we may find and need to fix problems with TinyMCE which causes our distribution to vary slightly until those changes can flow back upstream. To avoid any confusion, Ephox distributions of TinyMCE have an extra component to the version number, for example the current TinyMCE release is 3.3.6, so the current Ephox distribution is 3.3.6-170. This makes it clear which base version of TinyMCE is being used, that it’s been modified (even if only to add our naming) and which build from Ephox it is.

We’ve also called our distribution “Ephox Enterprise TinyMCE”, this is mostly a marketing thing but again it helps to avoid confusion in case there are fixes in our build that haven’t yet made it back upstream.

Questions? Comments?

If you have any questions, concerns or comments feel free to post them below or get in touch with me directly at adrian.sutton@ephox.com or by phone on +44 7 525 806 170 and I’ll do my best to get you an answer.

From the job description:

We are seeking a Software Developer who is experienced in creating sophisticated, highly interactive, JavaScript applications. Ideally we desire someone that has experience in TinyMCE or has experience working as part of an open source project. The right person will have the ability to work remotely in a highly collaborative manner with virtual teams.

I’m pretty excited about this new opening within Ephox. Lots of great stuff to come out of it hopefully, but in particular helping Ephox to start working better with Open Source communities and developing some awesome stuff with JavaScript. While TinyMCE experience is something we’re particularly keen to have “ready to go” if possible, whoever fills this role is going to become a web content editor expert in general from Tiny to CK, Dojo and of course our personal favourite EditLive!

The position is open regardless of your location in the world, though if you happen to be near Brisbane, Maidenhead or Palo Alto we have nice offices you can come in and work from if you like.

I keep seeing otherwise intelligent people1 encounter problems with software but never actually report them to anyone who could fix them. For commercial software opening a support ticket takes just a few minutes and usually gets the issue resolved pretty quickly so you can stop wasting time suffering through it or complaining about it. For open source software it’s often a bit more difficult – you need to join the users mailing list and ask questions there, follow up if you don’t get a response and maybe even put together a solid bug report. Still nothing ominous.

Of course, the opposite effect happens too. Once someone finds they can report an issue and get it fixed for them, they often go a bit crazy reporting things – even before they’ve done a bit of investigation to confirm they’ve place the blame on the right bit of software2.

I’ve been watching both these things happen within Ephox lately and it’s amazing how many things you can get solved quickly when you do get the right balance between reporting too soon and reporting too late (or not at all). It’s a skill I think we need to work to improve.

1 – Myself included sometimes.↩

2 – I’m sure there should be a good quip about the bug being in your code rather than the library/compiler/OS/etc but I can’t find one.↩

The conversation that has sprung up around how the use of distributed version control, Github in particular, affects community is a refreshing change in the blogosphere1. It’s people collectively thinking things through rather than just reacting in uproar or following the latest meme.

The latest installment is from Ben Hyde, git: Balene for Knowledge2. It’s definitely worth reading in its entirety, but let me pull out a couple of key points:

[Source control] provides a locus around which the work can rendezvous. It a campfire, and the community gathers around it. I accept that. But let’s be clear, it isn’t the only campfire. Other examples: the irc channel, the email, the bug tracking, the release process, the distribution system, the license, the social networks, etc. etc.

and:

The thing that blew me away about git was that it helps to address this problem. It increases the probability that users will reveal their knowledge. It helps to create a cultural norm toward that behavior. To me this is far more important than the risk that their forking would quench the community campfire.

The thing that really strikes me about these two comments – GitHub doesn’t just provide forks with a git branch to work on, it also provides a wiki and issue tracker. It does keep track of the network and provide tools to help feed changes back and they do work well, but it unconditionally forks more than just the source control.

So perhaps one improvement GitHub could make is to enable a project to be forked without creating the wiki, issue tracker etc. Not only would that make it clearer that this was just an experimental or temporary fork rather than an alternate, long term project, it would further reduce the barrier to people getting involved. Right now, creating a fork means creating a whole open source project and it feels like you should be managing it as a project which feels like hard work. If you only forked the source control, it would just be a place to code out in the open so that you can get what you need from the project but also make it easily available to everyone else.

1 – wow that really feels like a blast from the past…↩

2 – in response to J Aaron Farr’s A Community of Rockstars which amusingly is part of the latest uproar. ↩