Short introduction: KnowledgeTree (KT) is a document management system written in PHP, targetting small to medium businesses. I would name Alfresco as its closest competitor. At Oxford Archaeology we are already using KT, and plan to increase its use to all our offices and documents (that's quite a few Terabytes).
A few days ago, Damien Williams from the Knowledge Tree team issued a call to the KT community: "Please help us serve you, the community, better". Getting things right between an enterprise developing an opensource software and that software's community is a very difficult thing, but also a very interesting topic, which I thought was worth answering to.
Let's start with the following: It is incredibly easy to get it wrong.
I love that article and believe it is a great first read for a company who wants to get things right.
Now to my view. "Community" is a broad term. In the knowledge tree world, I believe I've got 5 different community hats, as I am:
- A customer
- A system administrator
- A plugin author
- A soon-to-be-well-maybe-I-hope core developer
- A free software activist
For every of these hats, I have different needs, opinions, suggestions, which I will detail now. Those are focused on Knowledge Tree, but I think they might apply to pretty much any other software we are deploying.
As a customer
As a customer, I want the software to be cost-efficient, and to answer the needs of my users in terms of speed, interface and features.
I am interested in case studies - is any other large deployment known? If yes, I am interested in a PDF where the customer details his deployment, the problems encountered, and how well it scaled. This will reassure me that I won't run into problems later that I couldn't have guessed when deploying.
Screenshots & Videos: What does the software do? How does it look like? Even better would be the ability to test-drive the software, without a complex registration system - or no registration at all.
A regular newsletter where I can read about upcoming features, technological innovations, interaction with other software can also be very interesting..
I also absolutely need to be able to give input - ask for features, get my voice heard for important decisions that will affect the direction the project wil take - even if in the end I am in a minority and another direction is taken. Even better, I would like to be asked to help, test-drive new beta features, give feedback about our deployment, ....
As a system administrator
As a system administrator, I need to get the best uptime and performance out of the software, while keeping it as secure as it can be. These are difficult tasks, that require a lot of information.
Where are the bottlenecks going to be? Is all the load going to be on the Apache servers? Is the database going to be the issue? Will I be able to scale the software horizontally - ie, have a cluster of apaches, a separated SQL install, or will my only option be to throw more RAM at one big box?
Therefore, as a system administrator, I need:
- A short, 5-10 pages quick start guide. Sysadmins are always happy when they can get something running in a snap.
- An in-depth, exhaustive manual which would detail every single configuration item. From the configuration files, to how I can finetune the SQL database, optimise the Apache servers... Are there any functions that I should consider deactivating if the load gets too high?
- A good point for this manual would be to describe several different test cases. We had the simple one-server setup in the quickstart, now I want to know how I can setup a 5 apaches, replicated SQL, NFS, memcache'd KnowledgeTree.... Can all the elements be split?
Eventually I will run into issues. If I don't want to query the support for every tiny problem, a forum for system administrators is usually a great place to start asking questions. Having persons with a deep understanding of KT provide very basic support there is a great way to get more people use KnowledgeTree, and eventually participate in the forums later. Getting completely ignored is probably the worst thing that can happen there though.
If I run in more serious issues (potentially preventing people from working), I will report it to the support, which I expect to be quick, friendy and knowledgeable. In most free software companies you can get the software for free - so the support really need to be worth it
On the security side, I need to be aware of critical security issues as quick as possible - either via a mailing list, or via a RSS feed that I could follow.
As a plugin author
As a happy user of the software, I absolutely need this one feature that, heck, I seem to be the only one needing. So I am left with the task of either writing it myself, or getting someone to do it for me. When I can and time & skills allow, I tend to save the bucks and do it myself.
When you start writing code, what really helps are hello worlds. Simple pieces of code, demonstrating basic features, that you can just use, and extend. For KnowledgeTree, some "demo" code for every plugin type (dashlet, processor, admin page...) would be an amazing resource. Basic pieces of code, "bricks", also help a lot - how do I connect to DB? Surely I don't need to rewrite a logging system from scratch and I can just reuse the one existing? Getting a "Hello world" plugin and adding some bricks to it could get a good half of the work done in many cases. Maybe that's an area where I could contribute.
My other concern when writing a plugin is: what am I allowed to do? Sure I can just include any class or file from the project and just start using it - but which ones have an interface that is frozen? It'd be rather disappointing if at the next Knowledgetree upgrade my whole plugin breaks down, and I need a massive rewrite to get it working again. Or at least, an automated test that would tell me if my plugin will be, or not, compatible with a certain version of KT... Some indications in this area would be highly valued.
A manual intended to plugin developers would probably help kickstart plugin development - and provide a better consistency and quality among them all. Global programming guidelines, indenting, GUI recommandations for consistency with the rest of the software? Objects/Classes/Interfaces already implemented I should be aware of before starting to reinvent the wheel?
A forum for plugins developers would be a great place to exchange tricks, advertise for a plugin, ask for reviews... would probably be rather empty at the beginning, but would hopefully improve over time.
As a core developer
Well, assuming I'm good enough, assuming I've been around for a while, and assuming I've got enough time for it - here are the things I would be interested in should I ever want to contribute more than a few lines of code.
One of the first things is, as Tim Towtdi said, some things require discussions. If I am going to revamp completely some pretty central and critical code and spend three weeks on it, one of the things I wouldn't be to happy to hear after that would be "right, that's a solution, but actually we thought on this other way which we actually think is better".
Ideally, a public mailing list would exist where the core developers would discuss all the important technical choices for the software. Reading this, I could know what is going on, the global direction, give input on implementation choices, and ask for input when I want to start to code something that might be non-trivial.
Let me stress this again: the discussions that matter should be public, the decision-making process should be fair and published, and some sort of meritocracy should be put in place. If someone has been contributing code to the core for the last two years, his voice should count as much as the voice of a developer from the company (at least on issues where the outcome would not directly hurt the company..).
A documented code is also quite important when you want to contribute. Giving a PHPDoc output is a nice start, the second step is to actually use PHPDoc style comments so that the documentation is not just a list of functions Having to go through 20 000 lines of code to be able to contribute is what you want to avoid.
As a free software activist
I'm afraid that even with all the controversy about this, I have at least one foot in the FSF camp... I hate running BLOBs - y'know, those software where the commercial tells you "it is great, it is fast, it will scale" - and unless you try it on a large scale, you just have to believe him. If there is a bug, you just have to wait that they fix it, even if you might have the skills to fix it. Security is another concern.
It is a bit like a candy where the list of ingredients would be a secret: it might taste good, you'll have to trust big corporation when it tells you "no worries, it's good for you". But they forgot to write "Warning: might contain nuts".
So, I don't like black boxes, and am not a big fan of KnowledgeTree's decision to use Zend. I also *very* strongly objet the direction taken by the offline client that uses Adobe AIR - maybe it could have been coded in HTML5, with its offline features, drag&drop fileapi, and so on. Standards and cross-platform programming should not be an option...
As any of those
A community manager is also often a good idea. The community manager can act as a single point of contact for the community. He should be someone who is communicative, who has some time to spend on IRC and Forums, who the community knows and appreciate, and who would sometimes have to stand to defend the ideas of the community, which might not be the ones from the company - so someone appreciated inside the company as well . It certainly doesn't have to be a full time person - any developer with strong free software values would probably be good.
I am very happy that knowledge tree is asking for input from the community. Caring about the community and valuing it is probably the most important thing in an opensource project anyway.
I hope this feedback will give knowledge tree, as well as other opensource companies, some indications about what makes us, the customers, the sysadmins, the programmers, the floss advocates, happy. I would also be happy to hear what is important for you, when dealing with a company that writes opensource software...