Plugins being changed from free to Commercial licensing

[B_ Normann P_ Nielsen]

I was just updating plugins for Confluence, and Yet another has changed from free to Commercial licensing.

I think this is a stupid attitude towards installations that have utilized these for several years/releases - suddenly You have to pay up or have the worload of remove the function from several N Confluence pages.

Seems to start with the "Table Plus" pluing from Bob Swift, and now I see the CLI will cost from version 3.

To me it seems like takes people hostages (not mentioning to much about greed thoughts here :-/ )

And thinking of the prices rises for JIRA and Confluence (https://answers.atlassian.com/questions/38696/is-it-just-me-who-has-a-shocking-price-rise-for-jira-5), I am wondering if I should start looking for alternatives....

[MatthewC · Accepted solution]

I can understand that it's difficult to accept, Atlassian and it's plugin developers can sometimes be the victim of their own success. for me the first big example of this was the calendar plugin which went the way of Team calendars. yes, we used calendars a lot, in fact some teams relied heavily on it. But Atlassian didn't get any money to maintain it. When bugs came up and users made a lot of noise complaining, what were they to do? Do work for nothing or turn it commercial?

Atlassian isn't a charity or an open source project, it's a private company with some very lucky investors!

WRT the table-plus macro, yes it's useful but is Bob Swift legally obliged to keep updating it forever? Does Bob become our Prometheus, forever bound to keep updating code we take for free? You could step up to the plate and produce a compatible plugin & maintain it for free?

The Jira 5 Enterprise rise was handled very badly and I think people were right to be upset. However, they seem to have learnt the lessons and the same rise on Confluence hasn't seemed so out of place. After all, it has steady been putting n enterprise features over the last few years. There is lot of working going on for Jira enterprise which is only just now starting to show itself.

As for alternatives, there are plenty. But I would challenge you to find one with the same feature set, support and usability with the same price/user.

[Ellen Feaheny [AppFusions]]

QOTD: "Does Bob become our Prometheus, forever bound ..."

Awesome comment Matthew.. well said!

[JamieA]

It's pretty much essential to Atlassian's business model that the plugin developers are paid. If not, people get bored and stop maintaining their plugin, which makes the Atlassian tools look bad. Atlassian want their products to be a platform for other excellent products (eg Balsamiq), so you get locked in to them. To do that they need high-quality, maintained plugins, which generally means commercial. With the amount of testing required for all the releases, you are generally talking more than a "one man and his dog, part-time operation" these days.

The other factor here is the marketplace, which makes it very easy to click a button and make a previously free plugin a paid one. Which is kind of a testament to the marketplace I guess.

But I agree with the pain factor... I'm faced with working out the extent of usage of newly-commercial plugins, then baking off against free alternatives, then coming up with a migration plan.

[tavery]

If you ask me, it would be a lot better for both customers and plugin developers if atlassian included the option of five commercial plugins of your choice in their base price. Getting approval to buy JIRA is enough of a headache, and then discovering that there are X number of plugins you ALSO have to buy to get reasonable functionality is a nightmare, since the approval process for each one is annoying. It would also give the developers who are really doing stand out work, like Adaptavist, a reasonably secure income stream. Atlassian isn't just letting their customers down, after all, they're also taking advantage of a lot of developers hard work and not helping them either. Plus, if they're doing some profit sharing, they may be more aware of which plugins are truly vital to the product and be willing to pay developers to absorb the plugin into the product - giving them a real payoff.

[Nic Brough -Adaptavist-]

Mmm, but how do you handle

1. People who don't need 5 commercial plugins initially?

2. Plugins of different pricing?

Remember that plugins are priced by their owners and not by Atlassian. Some plugins are bigger and more complex and more difficult to maintain because they do more than others.

I see what you're getting at, and I think things are moving in the right direction - you can at least go to one place to see the prices, rather than the old system of buying <atlassian thingy> and then having to run off and get a stack of other quotes for plugins. I think this is screaming for "add to basket" so you can get a simple quote for everything you need in one place.

[tavery]

I think the real problem is that atlassian farms out basic product features to free plugins and then the plugins become commercial, causing havoc on anyone using them. For example, numbered headings - really - that's really a plugin? Doesn't that seem like kind of basic functionality? Or the table-plus macro - being able to put reasonable tables into a page seems like kind of a baseline requirement for a decent wiki.

Our organization has gone through this several times. We were using confluence as an external facing wiki and are moving away from it precisely because of these kind of migration headaches. Most software companies care about backward compatibility for their customers. Most software companies recognize that they can't crowdsource basic features on their platform.

At least most companies that stay in business do.

[Nic Brough -Adaptavist-]

As mentioned above, you can carry on using the free versions, you just lose updates. Most, if not all, of the developers of these plugins have left the free versions as open source, so you can fork them onwards.

I completely agree with you on the subject of Atlassian absorbing functionality into the core. From memory, and using Jira as an example, both Greenhopper and Labels were originally plugins, and have now been drawn in (albeit the GH was always commercial). There are other smaller examples. One of the upgrades I'm looking at at the moment includes "drop four plugins because Jira does them off-the-shelf now"

But, this should happen a lot more in my opinion - again using Jira as the example, the very first thing I do on any clean install, or when arriving at a client that doesn't have them, is install the Jira Toolkit and the Suite Utilities. I've been doing that for about <mumble> years, and wouldn't use Jira without them. They absolutely need to be absorbed and distributed as part of the core.

[Norman Abramovitz]

I cannot disagree that the new Marketplace fosters a monetary detrimental oriented behavior both on part of the buyer and seller and it is very frustrating, but the people who build the plugins should be compensated for their time and effort. There are alternative ways for compensating as well.

For example, the price could be lowered to lets say to $2.50 at the lowest end such that your extra $10 would cover four plugins instead of just one plugin. At least the cost for an extension is not as expensive as the total system. I know I uninstalled a couple of plugins and lost functionality since the new cost did not justify the added functionality.

Atlassian could offer a free license to plugin developers for their business that have "very" popular plugins. The license is worth something to the company and gives the company a reason to continue supporting the plugin development. Atlassian gets a supported plugin that its customers like, so I see that as win-win.

[B_ Normann P_ Nielsen]

Agreed, and dont get me wrong, We (I) dont mind paying for stuff that actually are good and woking, we do use Confluence and JIRA, right?

And Yes, developers should be compensated in some way, I agree with that too.

[Yassin]

It is very important to analyze the App very well before installing and integrating it into your processes.

I usually prefer getting a paid App than a free App because I know there is commitment from the vendor specially if they offer support. If I have to install and offer my users certain free App, I always check

1 - with the vendors if they are planning to offer a paid version in the future, to avoid surprises. I usually get no answer or honest answers like: "we won't be offering any support, paid version or new feature" or "we are working on new features and will make the app paid in the future", ...

2 - Does the vendor document the Deinstallation Steps and their side effects?

3 - Agree with my users on rollback process: for example if the App created "To do" list and we have to remove, work on converting the active objects/data of the App to Sub-Tasks, ...

Sometimes things are not so easy as doing these 3 checks, because you have a requirement which you must fulfill but communicating these risks to your stakeholder from the beginning will help.

And the best option is always not to install so many apps, because it just slows down the system and increase your dependencies, which results in doing so much admin work to achieve too less results.

By the way I know companies having ZERO Apps, but it is just because they didn't find out there is a Marketplace :P 

[Sergio Storch]

Hi brave frontierpeople,

I see this discussion as a treasure for quite a bit of dilemmas in intelectual property issues, such as in music, video and open educational resources etc.

Good practices in the design of pricing and fair return to investors who ensure economic sustainability for the public interest is a frontier in political economy. There s good theory emerging from economics on that. Of course these reflections are off-topic, but I see this as something that may help lubricate the discussion.

Now an idea that may be helpful in some practical development: how about designing some way of retribution to the people in the community who contribute to the ecosystem with knowledge from the users side? Something such as discounts based on reporting on implementation practices that may come to be as important intellectual assets as developing and testing code, in the form of karmas for high quality blog posts, case studies, content for training and strategies for user engagement, leading communities of practice etc?

[AndreasS]

Hey Guys, there is a similar but new and completely open source plugin called Tableenhancer for Confluence (see https://marketplace.atlassian.com/plugins/com.tngtech.confluence.plugins.tableenhancer). You can just try it out, having no further costs. If there is any functionality missing just, open up an issue on https://tngtech-oss.atlassian.net/browse/TABENH.

[B_ Normann P_ Nielsen]

THanx for all the input and comments, I am "answering" this question so I wont get any reminders on it :-)

BR,

Normann

[tavery]

OK.

1) Given that really basic functionality is now commercial, such as numbered headings and reasonable tables, I think that the case you're really talking about is where people don't _think_ they'll need plugins, because they don't understand just how restricted the core functionality is. It's a much better customer experience for atlassian to give people what they need - or what they'll need to grow - than to have them feel nickle and dimed or unable to get the platform to do what they want because they can't get their corporate masters to understand that confluence/JIRA doesn't include seemingly basic functionality that they now need to pay for. That's the kind of thing that if folks have put their necks out to advocate for atlassian, really irritates them, because it makes them look bad.

2) There are a couple of ways to manage the pricing issue - you brought up a good one - allow people to select packages with relatively set prices. It's definitely doable - it just requires atlassian to recognize that the health of their ecosystem will impact the health of their own product.

On another subject...

I'd also like to say to the comment above that said you should stage your atlassian upgrades totally ignores the fact that even if you DO stage your upgrades, that doesn't change the amount of work you have to do to rip out a plugin that was formerly free or that is no longer compatible with the new version. We have regularly had to wait months to be able to upgrade to a new version because of these issues. Plus, even with testing the upgrade before we go live we've still been bitten by issues, depending on who was doing the testing and how long they took to do it. Checking all of the plugins we have is pretty difficult, especially since the admins don't generally know how or where all of them are used.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

Normann, sorry you are upset with the changes I have made - they are explained with this blog. Unfortunately, there are no good ways to publish this type of information to a wider audience. Others below have covered some of this, but here it is from the horse's month. In summary and to address your points:

1. It had become too much effort to keep things updated as a spare time effort as Jamie has mentioned below. And Jamie, I found my dogs sleep too much to provide much coding assistance :).
2. Warning on upgrade. This has been discussed with Atlassian and hoping there are improvements coming. Later versions of UPM are better at indicating an upgrade is commerical.
3. You can remain on the older open source version. If you mistakenly upgraded, then you can downgrade by uninstalling and installing the old version - get the url from the Marketplace version tab that is marked open source and use that on the upload plugin dialog. This only works without problems if pages with macro have not been migrated to native Confluence 4.x format. So revert your upgrade as soon as you recognize the problem.
4. Evaluation licenses will keep pages/macros working without purchase.
5. Regarding converting an existing plugin from OSS to commercial instead of creating a new plugin. There are down sides to the other approach as well. It would be confusing having 2 plugins listed that do the same thing. For those companies that do want support and future security, it is much easier for them to upgrade an existing plugin. From the feedback I have received, this class of user is a high majority.

[B_ Normann P_ Nielsen]

Q: But is Bob Swift legally obliged to keep updating it forever?

A: No, And I have not claimed that ! My complain is sorely that the plugins became payable overnight with no warning, making a lot of pages useless. I think that Jozez idea of Pro version are quite nice, so I could have been on the free/working/not-maintaned version until I either replace it, or pay for the Pro.

On the CLI side I have that option, I can live with 2.X.X, or upgrade to 3.X.X

Q: Does Bob become our Prometheus, forever bound to keep updating code we take for free?

A: No, and I have not claimed that. See first answer. What I dont like in the "its free, get addicted/hooked, now pay" ...

Q: You could step up to the plate and produce a compatible plugin & maintain it for free?

A: Would like to, but not able to.

PS: Nobody doubts that Atlassian are in the game to ean money for the investors :-) I think the possibility for 10 users for $10 and free for certain products are very graciuos.

[Ellen Feaheny [AppFusions]]

I think Bob Swift commented direct to your original comments above.

Best practices in Atlassian admin is to do staging upgrades - so you do not get into this pickle, since you should never make assumptions on plugins upgradability out the shoot.

Did you do one before you got into this pickle? Maybe good idea next time.

==

Bob Swift has been a diligent saint - SAINT - for years in the ecosystem - so ANY level of bashing is simply wrong.

Be grateful for the years of free plugins that you enjoyed.. if anything, send him a check for the years of good coded graciousness he provided!

[Jozef Kotlár]

Yes, it is rather painfull, when free plugin changes to paid. More gentle way would be to provide another Pro version with more features.

[Vishwajeet Singh]

IMHO that's the risk you carry when you use any opensource plugin and sorry but I didn't liked your use words "takes people hostages", earlier version sources are still available to you and you can maitain it on your own.

To every company I have worked in past I advise them to use opensource plugins with keeping in mind that in future they might have to maintain it or pay someone for it.

Just tell me what happens when a developer stops supporting future upgrades for the plugin, you will still not like it right, you should be happy that people are maintaining it whether commercial or not, as day you decided to use it you directly or indirectly accpted the fact that you will maintain it in future or will pay someone to do it.

PS: I am not associated with any of the mentioned plugins.

[B_ Normann P_ Nielsen]

Well, At the moment I am pretty sure that for the Table plugin I was not warned before upgrading it, but for the "Email this issue" I was, so I decided to uninstall.

Secondly, I will still claim to the hostage frase, If You have 1000 pages with the tables-plus pluging, You now have 1000 pages with a red bar telling about a license error.... Thats bad, for both Customers and internal users...

And yes, I think there is a big difference between stopping development (this does not kill functionality 100% normally) and suddenly change licensing type, and "sneak it in" with a common upgrade..