Now it’s important to be clear, there are quite a number of open source organisations that are set up as actual charities or at least are independent organisations where the money donated actually goes towards the open source projects supported by that organisation. For example, when you donate to the Apache Software Foundation they use that money to pay for servers, bandwidth, legal advice the projects need, subsidising conferences around the projects and so on1. These are great places to donate your money or time to — they handle donations very professionally as the funds directly benefit the projects and ecosystem around the projects.

What bothers me are the projects which ask for donations but don’t have any way to keep the donations separate from the main contributors personal funds. That money isn’t going to the project, it’s going to the person — that’s not a donation. From the New Oxford American Dictionary:

donation |dōˈnā sh ən|

noun

something that is given to a charity, esp. a sum of money : a tax-deductible donation of $200.

• the action of donating something.

If someone asked you to donate to the poor and then pocketed the money you gave them, you’d be pretty annoyed — even if that person themselves was poor. On the other hand, if that person asked for money because they were poor, you’d expect them to pocket it. Why should we not expect the same honesty from open source developers?

What Do You Need Money for Anyway?

For small open source projects there are so many free services available that money really isn’t an issue. If you’re asking for donations to support your project, what exactly is that money going to be used for? How is that money going to further the project’s goals?

Bottom line, it’s not.

Between Sourceforge, Google Code, GitHub and a whole suite of others, small open source projects are very unlikely to require any kind of funding. At best it might contribute to the main developer buying a faster computer so they can be more productive, but is that really for this project or something they want for themselves? Again, it comes down to honesty – if the only computer they can afford hampers their productivity then upfront ask for donations towards a faster computer, it’s not only more honest, it’s also more compelling.

A More Honest Term

I have no problem with people asking for money as reward for their efforts developing software, that’s how I make my living. It doesn’t matter if the payment is optional or compulsory, what matters is that there’s honesty about what the payment is for.

The New Oxford American Dictionary can come to our aid here, since it includes a section under the term present about choosing the right word:

THE RIGHT WORD

What's the difference between a birthday present and a Christmas gift ? Both words refer to something given as an expression of friendship, affection, esteem, etc.

But gift is a more formal term, often suggesting something of monetary value that is formally bestowed on an individual, group, or institution (: a gift to the university).

Present, on the other hand, implies something of less value that is an expression of goodwill (: a housewarming present; a present for the teacher).

Largesse is a somewhat pompous term for a very generous gift that is conferred in an ostentatious or condescending way, often on many recipients (: the king's largesse; the largesse of our government).

A gratuity is associated with tipping and other forms of voluntary compensation for special attention or service above and beyond what is included in a charge (: known for her generous gratuities, the duchess enjoyed watching the waiters compete with each other to serve her), while a lagniappe is a Southern word, used chiefly in Louisiana and southeast Texas, for either a gratuity or a small gift given to a customer along with a purchase.

If you give money or anything else as a gift to a philanthropic, charitable, or religious organization, it is known as a donation (: donations for the poor).

But if your employer gives you money at the end of the year in addition to your regular salary, it isn't a Christmas gift; it's a Christmas bonus.

Since we’re not giving to a philanthropic, charitable or religious organization, donation isn’t the word we want. Gift or present might be since mostly the monetary contribution is an expression of esteem. Importantly both terms imply that the receiver can do whatever they like with it, it’s not earmarked for a project in any way.

The best term in there however seems to be gratuity or the more colloquial tip. It’s recognition that someone has done something for you above and beyond what they charged you for. It also seems to be really getting at the heart of what I believe most people are after: encouragement. Having someone part with even a small amount of money is a very strong sign of appreciation, especially when it’s combined with a well-worded note rather than just money turning up in a PayPal account.

So perhaps going forward if you need money to support your open source project, provide some information about what the money will be used for and why it’s important to the project. If you just want to be rewarded for your hard work or encouraged, put out a virtual tip jar rather than a donation button.

1 – actually many of those types of services and even server hardware may be donated as well↩

The big difference that I see between projects thriving with GitHub and those where forking looks like more of a problem is that thriving projects have a “campfire” other than the source code for people to gather around. Often that’s a mailing list, other times it’s IRC and various other technologies but there’s always one common place where the community can build. GitHub by itself is unlikely to build up such a community because there isn’t a really good way to engage everyone in conversation. As such, you get a lot of forks and people making improvements, but not really working together and often the various forks never get folded back into the original.

The good news is that despite all the forks often remaining off on their own, it doesn’t seem to be detrimental to the original project. People find the main GitHub repository through other means, mostly links on the web, so there doesn’t seem to be confusion over which fork is the “main” one. On the other hand, most of those forks represent a wasted effort which could have pushed the project forward if only there had been some communication.

Finally, it’s interesting that the GitHub model of anyone creating a fork is far more successful for projects which don’t need a contributor agreement to be signed. In that case, any fork that looks promising can be pulled in without needing extra permissions, so even without the extra communication channel the effort can be utilised. With a contributor agreement, you have to reach out and get the author to sign, which is a significant barrier.

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 ↩

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.

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.

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 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. ↩